On 28 December 2010 16:54, Stephanie Daugherty <sdaugherty(a)gmail.com> wrote:
> Not only is the current markup a barrier to participation, it's a barrier to
> development. As I argued on Wikien-l, starting over with a markup that can
> be syntacticly validated, preferably one that is XML based would reap huge
> rewards in the safety and effectiveness of automated tools - authors of
> tools like AWB have just as much trouble making software handle the corner
> cases in wikitext markup as new editors have understanding it.
In every discussion so far, throwing out wikitext and replacing it
with something that isn't a crawling horror has been considered a
non-starter, given ten years and terabytes of legacy wikitext.
If you think you can swing throwing out wikitext and barring the
actual code from human editing - XML is not safely human editable in
any circumstances - then good luck to you, but I don't like your
chances.
- d.
On 28 December 2010 16:06, Victor Vasiliev <vasilvv(a)gmail.com> wrote:
> I have thought about WYSIWYG editor for Wikipedia and found it
> technically impossible. The main and key problem of WYSIWIG are
> templates. You have to understand that templates are not single
> element of Wikipedia syntax, they are integral part of page markup.
> You do not insert "infobox template", you insert infobox *itself*, and
> from what I heard the templates were the main concern of many editors
> who were scared of wikitext.
> Now think of how many templates are there in Wikipedia, how frequently
> they are changed and how much time it would take to implement their
> editing.
Yes. So how do we sensibly - usably - deal with templates in a
word-processor-like layout? Is there a way that passes usability
muster for non-geeks? How do others do it? Do their methods actually
work?
e.g. Wikia has WYSIWYG editing and templates. They have a sort of
solution to template editing in WYSIWYG. It's not great, but people
sort of cope. How did they get there? What can be done to make it
better, *conceptually*?
What I'm saying there is that we don't start from the assumption that
we know nothing and have to start from scratch, forming our answers
only from pure application of personal brilliance; we should start
from the assumption that we know actually quite a bit, if we only know
who to ask and where. Does it require throwing out all previous work?
etc., etc. And this is the sort of question that requires actual
expense on resources to answer.
Given that considerable work has gone on already, what would we do
with resources to apply to the problem?
- d.
On Dec 28, 2010 11:31 PM, "Neil Kandalgaonkar" <neilk(a)wikimedia.org> wrote:
>
> I've been inspired by the discussion David Gerard and Brion Vibber
> kicked off, and I think they are headed in the right direction.
>
> But I just want to ask a separate, but related question.
>
> Let's imagine you wanted to start a rival to Wikipedia. Assume that you
I think this isn't as useful a question as it might be; defining a project
in terms of competing with something else leads to stagnation, not
innovation.
A better question might be: what would be a project that would help people
involving freely distributable and modifiable educational and reference
materials, that you could create with today and tomorrow's tech and
sufficient resources, that doesn't exist or work well today?
-- brion vibber (brion @ pobox.com)
At some point in the past, it was determined that the StringFunctions
extension (now part of the ParserFunctions extension) would be
disabled on enwiki. I know saw a comment to the effect of: if
StringFunctions was turned on, it would only encourage people to start
writing parsers in wikicode.
Maybe other people were already aware, but not me, that we have a set
of hacked-up string functions on enwiki, for example [[Template:Str
len]]. There's a whole category of them at [[Category:String
manipulation templates]].
I'd like to know the current opinion of the server ops about these
things. Is there any chance of StringFunctions being enabled? If not,
should we feel free to work around it as these templates do?
I'm writing to this list so it will be possible to link from enwiki to
the mailing list archives, so responses on-list would be best.
- Carl
Hi all,
A short note for everyone interested in usability testing: the videos of the usability testing of sentence-level editing are available on Wikimedia Commons. Videos are in Dutch, transcripts/notes are in English. http://commons.wikimedia.org/wiki/Category:Sentence-level_editing
Best wishes,
Jan Paul
I've checked in a quick tweak in r79029 that adds thumbnail previews of
image files on Special:Upload before you submit the form, in browsers
supporting the HTML 5 FileAPI [1] (such as the current stable releases of
Firefox and Chrome).
This helps with a longstanding problem that's bugged me for years: when the
AJAX filename conflict thingy trips, you get a thumb of the *existing* file
but not of the file you're about to upload, making comparisons harder! Now
you've got the file you just selected sitting right above it, which is
rather more convenient.
Files larger than 10MB aren't previewed as a guard against accidentally
hitting a really big file that eats your browser's memory and kills
everything. :)
On browsers that don't include the FileAPI FileReader class, or when
selecting a file that isn't a PNG, JPEG, GIF, or SVG file, you won't see any
change in behavior.
[1] http://www.w3.org/TR/FileAPI/
[2] https://developer.mozilla.org/en/using_files_from_web_applications
-- brion vibber (brion @ pobox.com)
At bugzilla:18861
https://bugzilla.wikimedia.org/show_bug.cgi?id=18861
there is a discussion about how transcluded pages are not seen by the search engine, and I
have made an assumption that is Wikisource's issue where its pages that are transcluded
across from the Page: namespace don't make the main namespace search.
An example of the behaviour
The work "Highways and Byways in Sussex" which is proofread in the Page namespace as
individual pages, and transcluded into chapters in the main namespace.
http://en.wikisource.org/wiki/Highways_and_Byways_in_Sussex
* search in the main namespace
http://en.wikisource.org/wiki/Special:Search?search=singleton&prefix=Highwa…
* compared with searching the individual pages in the Page namespace
http://en.wikisource.org/wiki/Special:Search?search=singleton&prefix=Page%3…
I am guessing that the search engine does not transclude pages before it undertakes it
indexing function. Is someone able to confirm that for me?
Is there any fix that anyone can suggest, or even know where such an issue can be raised
beyong Bugzilla? Would a fix lie in the search engine? Or does the fix lie in the
transclusion process? Thanks.
Regards, Andrew
Hi all,
Recently, I've been working with the Symfony web framework [1]. One of the classes they include is called the sfFinder class [2], which is a fluid, easy-to-use file finder class. It searches for files or directories in the filesystem, using a fluid PHP 5 interface. It has no dependancies, so it should work fine with MediaWiki. After finding numerous instances of opendir(), readdir(), closedir(), etc. in MediaWiki, I thought that it would be a good idea to use one centralized class to do all file searching. There is only 1 potential issue I see, though. It is MIT licensed, which is GPL compatible, so it should be okay to implement it, but I'm not too clear on this issue.
The usage is simple:
sfFinder::type('file')->name('*.php')->in('/path/to/dir'); //list of PHP files in directory and all subdirectories
sfFinder::type('file')->name('*.php')->in('/path/to/dir')->recurse(0); //list of PHP files in that directory only
sfFinder::type('dir')->name('foo')->in('/path/to/dir'); //list of directories with the name "foo"
There is documentation at [3], but it's for an old version. The code is very similar though, so most of it should apply to the current version.
What would people think of a change like this. I would like to see this happen, but I'd like some more opinions before I look into implementing it.
-X!
[1] - http://www.symfony-project.org
[2] - http://trac.symfony-project.org/browser/branches/1.4/lib/util/sfFinder.clas…
[3] - http://www.symfony-project.org/cookbook/1_2/en/finder
I have recently encountered this text in which the author claims very
high MySQL speedups for simple queries (7.5 times faster than MySQL,
twice faster than memcached) by reading the data directly from InnoDB
where possible (MySQL is still used for writing and for complex
queries.) Knowing that faster DB is always good, I thought this would be
an interesting thing to consider :)
http://yoshinorimatsunobu.blogspot.com/2010/10/using-mysql-as-nosql-story-f…
I there any list of halfway implemented CSS?
E.g.,
(rgrep "allpagesredirect" "* .*" "~/mediawiki/" nil); emacs
./includes/specials/SpecialAllpages.php:337: $link = ( $s->page_is_redirect ? '<div class="allpagesredirect">' : '' ) .
./includes/specials/SpecialPrefixindex.php:161: $link = ($s->page_is_redirect ? '<div class="allpagesredirect">' : '' ) .
is halfway implemented because it only appears in the .php files, but
not in the standard CSS files.
So allpagesredirect is #1, redirect-in-category is #2, where is the
complete list of them, and how one best should use them?
One has to poke around the CSS files that certain (e.g., Wikipedia.org)
sites use to find bits and pieces of them, mixed together with a lot of
other stuff.
Can't there be a
/** Use the full set of CSS bindings, like Wikipedia does, without
having to put them into Mediawiki:Common.css and maintain them on
every single site of our WikiFamily. */
$wgUseFullCss = true;
https://bugzilla.wikimedia.org/show_bug.cgi?id=26266