Re: [Wikitech-l] Downloadable client fonts to aid language script support?
Brion Vibber schrieb: El 5/11/09 5:04 PM, Ariel T. Glenn escribió: Στις 11-05-2009, ημέρα Δευ, και ώρα 16:15 -0700, ο/η Brion Vibber Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code 2000. (eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc) -- brion Except for the Wiktionaries, given that they will include lemmas from (eventually) all languages. For an indication of the size of the problem even now, folks might look at the entry for http://en.wiktionary.org/wiki/dictionary ... H, well forcing a large automated font download on every reader's first visit probably isn't ideal. :) Short of crafting embedded type subsets for each page using just the required characters I'm not sure there's a good way to treat that case other than offering extra fonts for download. -- brion How about a small button somewhere? download fonts now!. Could be hidden if no special chars are visible on the page. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Downloadable client fonts to aid language script support?
I don't know about Safari, but Firefox 3.5 first renders the text and then downloads the fonts and rerenders, if I read this correctly: When rendering a page using downloaded fonts, Firefox first renders using available fonts, then updates the display as downloadable fonts are retrieved. This allows the content to render quickly and refresh to match the intended look over time. https://developer.mozilla.org/en/CSS/@font-face Best regards, Bence Damokos 2009/5/12 Daniel Kinzler dan...@brightbyte.de Brion Vibber schrieb: El 5/11/09 5:04 PM, Ariel T. Glenn escribió: Στις 11-05-2009, ημέρα Δευ, και ώρα 16:15 -0700, ο/η Brion Vibber Since download time is a concern, we'd generally be looking for smaller font sets, such as one that covers specifically the language of an individual wiki, rather than high-coverage fonts like that or Code 2000. (eg a Tamil font for ta.wikipedia.org, a Canadian Aboriginal Syllabary font for iu.wikipedia.org, etc) -- brion Except for the Wiktionaries, given that they will include lemmas from (eventually) all languages. For an indication of the size of the problem even now, folks might look at the entry for http://en.wiktionary.org/wiki/dictionary ... H, well forcing a large automated font download on every reader's first visit probably isn't ideal. :) Short of crafting embedded type subsets for each page using just the required characters I'm not sure there's a good way to treat that case other than offering extra fonts for download. -- brion How about a small button somewhere? download fonts now!. Could be hidden if no special chars are visible on the page. -- daniel ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
Petr Kadlec wrote: The problem is much more difficult than that (see the linked bug). Commas, case sensitivity and whitespace are a trivial problem in comparison with non-ASCII letters. It is exactly this attitude of oh, it's so difficult that has blocked bug 164 from being fixed. I doubt it will get fixed in the coming year. But the more aggressive use of DEFAULTSORT could be applied within a year. I know this is not the right or most advanced solution, it's just an improvement that *can be made*. -- Lars Aronsson (l...@aronsson.se) Aronsson Datateknik - http://aronsson.se ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
2009/5/12 Lars Aronsson l...@aronsson.se: Petr Kadlec wrote: It is exactly this attitude of oh, it's so difficult that has blocked bug 164 from being fixed. Well, not really. Bug 164 would be fixed almost completely for Czech-language wikis by using database features designed for exactly this problem. [1] But, I guess you know the situation. I doubt it will get fixed in the coming year. But the more aggressive use of DEFAULTSORT could be applied within a year. I know this is not the right or most advanced solution, it's just an improvement that *can be made*. More aggressive use of DEFAULTSORT could be applied right now, and some people already do that. But, to ask people to create strange codes (like Šácholanotvaré → SŠahωolanotvare [2]) to enforce proper sorting… I can’t believe this would be that much improvement… (Not to say that users would make many errors with such a complicated system.) If Swedish sorting rules are simple enough that removing all whitespace and punctuation and converting to lower case would solve most of the problems, I would say that such feature would not be too difficult to implement right into MediaWiki (into LanguageSv.php), writing those DEFAULTSORT codes explicitly into every article would be nonsense, IMHO. (So, go ahead with it, I won’t stop you or anything, I’m just trying to say that this is not really a solution for Czech language.) -- [[cs:User:Mormegil | Petr Kadlec]] [1] http://dev.mysql.com/doc/refman/4.1/en/charset-collation-effect.html [2] Really! http://jdem.cz/beqz6 (And that is only a partial solution, implementing only about a half of the Czech sorting rules.) ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dump throughput
On Mon, May 11, 2009 at 3:27 PM, Brian brian.min...@colorado.edu wrote: In my opinion fragmentation of conversations onto evermore mailing lists discourages contribution. I have to agree that I don't think the dump discussion traffic seemed large enough to warrant a whole new mailing list. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Wiki editor wysiwyg
On Mon, May 11, 2009 at 2:50 PM, Daniel Schwen li...@schwen.de wrote: The simple (albeit ugly) solution would to add a parser version field to the revision table, drag the old parser along as 'legacy', make the new parser the default (and only) option for all new edits, and spit out a warning when you are editing a legacy revision for the first time. The warning you be made dependent on the cases that break with the new parser. That would require specifying the new language, getting people to actually agree on it, and writing a parser for it. There doesn't seem to be enough support for such a monumental effort to actually happen. Cases that break could be detected by comparing tidied HTML output from both parser versions. And then what would you do? It's unlikely you could fix them all automatically. Of course, these are wikis, so fixing a reasonable number of cases by hand isn't out of the question. Nah, well, now slam me for not reading through four years of discussions and finding out why my proposal is dumb ;-) It's not dumb, just apparently not considered worth the effort right now by the powers that be (and I tend to agree). ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Downloadable client fonts to aid language script support?
On Tue, May 12, 2009 at 4:16 AM, Bence Damokos bdamo...@gmail.com wrote: I don't know about Safari, but Firefox 3.5 first renders the text and then downloads the fonts and rerenders, if I read this correctly: Yes, that's what I understand as well. It was discussed on www-style just a little while ago: http://lists.w3.org/Archives/Public/www-style/2009May/0036.html Safari avoids Firefox's behavior to avoid re-rendering text, on the same principle as browsers these days don't start layout until they've got all CSS (to avoid FOUC). See also: https://bugs.webkit.org/show_bug.cgi?id=25207 ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
On Mon, May 11, 2009 at 3:29 PM, Lars Aronsson l...@aronsson.se wrote:
There is a way to avoid all such problems, namely by a more
aggressive use of DEFAULTSORT that removes from sorting all upper
case letters (except the initial one), all whitespace and all
commas. It would mean almost every article needs a DEFAULTSORT.
In the examples above:
{{DEFAULTSORT:Walesjimmy}}
{{DEFAULTSORT:Europeancourtofauditors}}
{{DEFAULTSORT:Europeanunionmission}}
{{DEFAULTSORT:Europeanquarterofbrussels}}
{{DEFAULTSORT:Moonillusion}}
This would be a good thing to do in the software. We could implement
the framework reasonably easily, if anyone cares to, and then let each
language do its thing. A basic English implementation like this would
be easy enough.
Of course, any change to the sortkey beyond the first will require
that all existing sort keys be changed by a batch job -- otherwise
sorting will be a mess. Every change to the sortkey algorithm would
either require that all pages be reparsed (very expensive), or that a
special conversion script be defined to account for that exact change.
Unless it's minor enough that the inconsistency is acceptable, I
guess.
On Tue, May 12, 2009 at 7:18 AM, Petr Kadlec petr.kad...@gmail.com wrote:
Well, not really. Bug 164 would be fixed almost completely for
Czech-language wikis by using database features designed for exactly
this problem. [1] But, I guess you know the situation.
...
[1] http://dev.mysql.com/doc/refman/4.1/en/charset-collation-effect.html
Note the version. Wikimedia uses MySQL 4.0, which doesn't contain any
charsets or collations other than binary. If we used a higher
version, utf8 might be an option: that would use a Unicode collation,
I guess, which should at least be okay for most languages, if not
perfect. (But MySQL's utf8 has other downsides, like being
variable-width and not supporting Unicode outside the BMP.)
If Swedish sorting rules are simple enough that removing all
whitespace and punctuation and converting to lower case would solve
most of the problems, I would say that such feature would not be too
difficult to implement right into MediaWiki (into LanguageSv.php),
writing those DEFAULTSORT codes explicitly into every article would be
nonsense, IMHO. (So, go ahead with it, I won’t stop you or anything,
I’m just trying to say that this is not really a solution for Czech
language.)
There's no reason this couldn't be implemented for Czech as well in
the software, in principle. Ideally we'd use something based on
Unicode collation as a baseline, with optional customizations per
language:
http://unicode.org/reports/tr10/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] Dump throughput
Aryeh Gregor wrote: On Mon, May 11, 2009 at 3:27 PM, Brian brian.min...@colorado.edu wrote: In my opinion fragmentation of conversations onto evermore mailing lists discourages contribution. I have to agree that I don't think the dump discussion traffic seemed large enough to warrant a whole new mailing list. If we find that doesn't work then we'll steer the conversation back to wikitech. But here is my reasoning The admin list was meant to receive any and all automated mails from the backup system and I didn't want to busy the readers of wikitech-l with that noise. Previously there was a single recipient of any failures which was not very scalable or transparent. The discussion list was meant to capture consumers who have approached me that are active users of the dumps but have no direct involvement with mediaiwki and are not regular participants of this list. This runs the list of researchers, search engines, etc .. that are not concerned with all the other conversation that go on wikitech and simply want updates on any changes within the dumps system . --tomasz ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
El 5/12/09 4:18 PM, Petr Kadlec escribió: 2009/5/12 Lars Aronssonl...@aronsson.se: Petr Kadlec wrote: It is exactly this attitude of oh, it's so difficult that has blocked bug 164 from being fixed. Well, not really. Bug 164 would be fixed almost completely for Czech-language wikis by using database features designed for exactly this problem. [1] But, I guess you know the situation. * Not available until MySQL 5 migration complete (Domas, what's the status on testing?) * Collation use for sorting needs to be double-checked to confirm it wouldn't interfere with present uniqueness constraints * Collations not available in MySQL for all languages * Multilingual sites possibly not well served by table-wide language-specific coding Doing our own localized sort key encoding and adding another indexed column to sort on would avoid some dependency issues but has its own deployment and maintenance difficulties. It would also be possible to use a separate column for the collated sorting while using MySQL 4.1+'s native collations, if the uniqueness constraints are a problem, but this is still dependent on rolling out an upgrade from 4.0. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
On Tue, May 12, 2009 at 4:38 PM, Brion Vibber br...@wikimedia.org wrote: * Collation use for sorting needs to be double-checked to confirm it wouldn't interfere with present uniqueness constraints Since cl_sortkey isn't part of any unique key, this appears not to be an issue for this use. Of course, it's an issue for every other sorted list of titles, but those can't have custom sort keys specified to begin with and don't seem to be included in this proposal. Perhaps they should be, though. In that case we'd probably end up needing an extra column in every single table that includes the page title, just for sorting (but we'd be able to use flexible algorithms to generate the sort key, rather than being stuck with MySQL's). * Multilingual sites possibly not well served by table-wide language-specific coding utf8 sorting would be a lot better than binary sorting for any site, I'm pretty sure. (I assume utf8 sorts sanely and not according to codepoint.) Doing our own localized sort key encoding and adding another indexed column to sort on would avoid some dependency issues but has its own deployment and maintenance difficulties. You don't need another column for categorylinks, you can use the existing cl_sortkey, so that should be relatively easy to deploy. It doesn't help with non-category use cases, of course. It would also be possible to use a separate column for the collated sorting while using MySQL 4.1+'s native collations, if the uniqueness constraints are a problem, but this is still dependent on rolling out an upgrade from 4.0. In that case we may as well make it like cl_sortkey and populate it ourselves, surely. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
Hoi,
Collation based on Unicode ... what do you mean by that ? Do you mean the
order of the characters in the UTF-8 or do you mean the Unicode CLDR order.
The last is the only sensible approach. The idea of the DEFAULTSORT is imho
awful; you want people to invest heavily on something that could work
properly when we decided to use the appropriate standards.
The one argument why I think this DEFAULTSORT is that it is too much of a
burden for the other languages and projects. Most projects still need to
concentrate on basic content and this is just another must have
distraction. Again, it makes sense to implement the appropriate standards in
stead of applying an ugly hack.
Thanks,
GerardM
2009/5/12 Aryeh Gregor
simetrical+wikil...@gmail.comsimetrical%2bwikil...@gmail.com
On Mon, May 11, 2009 at 3:29 PM, Lars Aronsson l...@aronsson.se wrote:
There is a way to avoid all such problems, namely by a more
aggressive use of DEFAULTSORT that removes from sorting all upper
case letters (except the initial one), all whitespace and all
commas. It would mean almost every article needs a DEFAULTSORT.
In the examples above:
{{DEFAULTSORT:Walesjimmy}}
{{DEFAULTSORT:Europeancourtofauditors}}
{{DEFAULTSORT:Europeanunionmission}}
{{DEFAULTSORT:Europeanquarterofbrussels}}
{{DEFAULTSORT:Moonillusion}}
This would be a good thing to do in the software. We could implement
the framework reasonably easily, if anyone cares to, and then let each
language do its thing. A basic English implementation like this would
be easy enough.
Of course, any change to the sortkey beyond the first will require
that all existing sort keys be changed by a batch job -- otherwise
sorting will be a mess. Every change to the sortkey algorithm would
either require that all pages be reparsed (very expensive), or that a
special conversion script be defined to account for that exact change.
Unless it's minor enough that the inconsistency is acceptable, I
guess.
On Tue, May 12, 2009 at 7:18 AM, Petr Kadlec petr.kad...@gmail.com
wrote:
Well, not really. Bug 164 would be fixed almost completely for
Czech-language wikis by using database features designed for exactly
this problem. [1] But, I guess you know the situation.
...
[1] http://dev.mysql.com/doc/refman/4.1/en/charset-collation-effect.html
Note the version. Wikimedia uses MySQL 4.0, which doesn't contain any
charsets or collations other than binary. If we used a higher
version, utf8 might be an option: that would use a Unicode collation,
I guess, which should at least be okay for most languages, if not
perfect. (But MySQL's utf8 has other downsides, like being
variable-width and not supporting Unicode outside the BMP.)
If Swedish sorting rules are simple enough that removing all
whitespace and punctuation and converting to lower case would solve
most of the problems, I would say that such feature would not be too
difficult to implement right into MediaWiki (into LanguageSv.php),
writing those DEFAULTSORT codes explicitly into every article would be
nonsense, IMHO. (So, go ahead with it, I won’t stop you or anything,
I’m just trying to say that this is not really a solution for Czech
language.)
There's no reason this couldn't be implemented for Czech as well in
the software, in principle. Ideally we'd use something based on
Unicode collation as a baseline, with optional customizations per
language:
http://unicode.org/reports/tr10/
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
El 5/12/09 1:49 PM, Aryeh Gregor escribió: On Tue, May 12, 2009 at 4:38 PM, Brion Vibberbr...@wikimedia.org wrote: * Collation use for sorting needs to be double-checked to confirm it wouldn't interfere with present uniqueness constraints Since cl_sortkey isn't part of any unique key, this appears not to be an issue for this use. Of course, it's an issue for every other sorted list of titles, but those can't have custom sort keys specified to begin with and don't seem to be included in this proposal. Perhaps they should be, though. In that case we'd probably end up needing an extra column in every single table that includes the page title, just for sorting (but we'd be able to use flexible algorithms to generate the sort key, rather than being stuck with MySQL's). As a general issue we also need to consider managing paging through collation-sorted lists, since sort keys for different inputs may produce the same result. At the moment I think category lists are paged by offset (bad!) but we should ensure this is planned for. * Multilingual sites possibly not well served by table-wide language-specific coding utf8 sorting would be a lot better than binary sorting for any site, I'm pretty sure. (I assume utf8 sorts sanely and not according to codepoint.) Well, utf8 doesn't tell you anything specific there... :) There's a general as well as binary which would be the same as what we do now (except for not supporting 4-byte characters AT ALL) http://dev.mysql.com/doc/refman/5.0/en/charset-unicode-sets.html For a multilingual site we'd probably end up using utf8_unicode_ci, which at least partially implements the Unicode Collation Algorithm (UCA), which sounds kind of confusing since at least a glance at http://www.unicode.org/reports/tr10/ makes it quite explicit that collation properties are language-dependent... presumably that's an un-tailored version which won't have most language-specific properties. Doing our own localized sort key encoding and adding another indexed column to sort on would avoid some dependency issues but has its own deployment and maintenance difficulties. You don't need another column for categorylinks, you can use the existing cl_sortkey, so that should be relatively easy to deploy. It doesn't help with non-category use cases, of course. You would if you need to store a processed sort key index that's not in the form of displayable characters. (eg, the output of the UCA) It would also be possible to use a separate column for the collated sorting while using MySQL 4.1+'s native collations, if the uniqueness constraints are a problem, but this is still dependent on rolling out an upgrade from 4.0. In that case we may as well make it like cl_sortkey and populate it ourselves, surely. For the unique case of categorylinks yes. For everything else, additional columns are not already present. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
On Tue, May 12, 2009 at 5:46 PM, Brion Vibber br...@wikimedia.org wrote: As a general issue we also need to consider managing paging through collation-sorted lists, since sort keys for different inputs may produce the same result. At the moment I think category lists are paged by offset (bad!) but we should ensure this is planned for. Category lists use Pager, so they're paged by index offsets, not LIMIT M, N. Note that they should probably be ordered by (cl_sortkey, cl_from) or something instead of just (cl_sortkey) -- currently, equal sortkeys will cause problems. But Pager doesn't support multi-key sort right now. I'm not sure what you mean here, though. What does sort keys for different inputs may produce the same result mean? You're just talking about sort key conflicts? In that case it seems best to just disambiguate by whatever's handy, in this case cl_from (which is the page_id and so not very meaningful). If it's coming up often enough to be a problem, the sort keys should be improved! You don't need another column for categorylinks, you can use the existing cl_sortkey, so that should be relatively easy to deploy. It doesn't help with non-category use cases, of course. You would if you need to store a processed sort key index that's not in the form of displayable characters. (eg, the output of the UCA) Why? cl_sortkey isn't ever displayed to the user, so I don't see why it couldn't contain binary characters. I guess it's in the URL of links past the first page, but that's not a huge deal. Although it is a definite downside I didn't think of (it's nice to have manually-editable URLs!). It would also be possible to use a separate column for the collated sorting while using MySQL 4.1+'s native collations, if the uniqueness constraints are a problem, but this is still dependent on rolling out an upgrade from 4.0. In that case we may as well make it like cl_sortkey and populate it ourselves, surely. For the unique case of categorylinks yes. For everything else, additional columns are not already present. I was saying that if we were going to make extra columns, we may as well roll our own sort keys instead of bothering with collations, since it's not like we'd save a column. But of course if rolling our own would mean two extra columns instead of one, that would be a definite downside. Still, MySQL's collation support is unlikely to ever extend to nearly as many languages as we support, and it can't handle niceties like eliding initial A or The in English, say. So it doesn't seem like as good a solution. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
El 5/12/09 3:01 PM, Aryeh Gregor escribió: On Tue, May 12, 2009 at 5:46 PM, Brion Vibberbr...@wikimedia.org wrote: As a general issue we also need to consider managing paging through collation-sorted lists, since sort keys for different inputs may produce the same result. At the moment I think category lists are paged by offset (bad!) but we should ensure this is planned for. Category lists use Pager, so they're paged by index offsets, not LIMIT M, N. Note that they should probably be ordered by (cl_sortkey, cl_from) or something instead of just (cl_sortkey) -- currently, equal sortkeys will cause problems. But Pager doesn't support multi-key sort right now. Ah, even better -- it's already broken! :) You don't need another column for categorylinks, you can use the existing cl_sortkey, so that should be relatively easy to deploy. It doesn't help with non-category use cases, of course. You would if you need to store a processed sort key index that's not in the form of displayable characters. (eg, the output of the UCA) Why? cl_sortkey isn't ever displayed to the user It sure is -- the first letter of each sort key entry is displayed in a nice large type in the category list. -- brion ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] More aggressive DEFAULTSORT
On Tue, May 12, 2009 at 7:33 PM, Brion Vibber br...@wikimedia.org wrote: Ah, even better -- it's already broken! :) Yup. Can be fixed without schema changes, though, at least. It sure is -- the first letter of each sort key entry is displayed in a nice large type in the category list. Good point. That would have to be adjusted. The effective first letter could probably be extracted from the sort key somehow, even if it's binary. If not, we could cheat and make it the last character or something. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] flagged revisions
Hi all, The 'flagged revisions' bug ( https://bugzilla.wikimedia.org/show_bug.cgi?id=18244 ) - has, by my reading been 'reopened' for 2 weeks now. Being as this is a reasonably big deal in the wiki scheme of things, I presume it's possible that matters are being discussed, or otherwise moved forward in some way, behind the scenes, but at this point, I thought it was probably worth making sure that this hasn't just been sort of forgotten. I think the enabling of flagged revisions on the english wikipedia is a very important, positive step for the project, and hope it might be acted upon in reasonably good order as a high priority. Apologies if such prodding is not a great fit on this list - don't mean to bug anyone (geddit?) ;-) cheers, Peter, PM. On Tue, May 5, 2009 at 3:55 PM, private musings thepmacco...@gmail.comwrote: Hi all, It seems to me that there's been sterling work on the 'flagged revisions' front - with the bulk of the credit due to User:Cenarium over on en, and the various folk working away over there. With that in mind, could I please encourage a dev.s attention to; https://bugzilla.wikimedia.org/show_bug.cgi?id=18244 Hopefully we can enable the extension as soon as possible :-) best, Peter, PM. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Re: [Wikitech-l] flagged revisions
On Tue, May 12, 2009 at 8:20 PM, private musings thepmacco...@gmail.com wrote: The 'flagged revisions' bug ( https://bugzilla.wikimedia.org/show_bug.cgi?id=18244 ) - has, by my reading been 'reopened' for 2 weeks now. Being as this is a reasonably big deal in the wiki scheme of things, I presume it's possible that matters are being discussed, or otherwise moved forward in some way, behind the scenes, but at this point, I thought it was probably worth making sure that this hasn't just been sort of forgotten. People do periodically check on bugged labeled shell. Only a very few people can fulfill them, so it may take a while, but it will happen eventually. ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
[Wikitech-l] The Wikipedia Usability Initiative is still hiring.
The Wikipedia Usability Initiative has extended the application deadline for the Software Developer position till May 30th. We are recruiting two candidates for this position. Both local applicants to the San Francisco Bay Area and remote applicants are encouraged to apply. Please help spread the word. http://wikimediafoundation.org/wiki/Job_openings/Software_Developer_(project) Naoko Komura Program Manager Wikipedia Usability Initiative Wikimedia Foundation - Job Title Software Developer Employment Duration June 1, 2009 to April 16, 2010 About the Wikipedia Usability Initiative The Wikipedia Usability Initiative was realized by a grant from the U.S.-based Stanton Foundation. The goal of this initiative is to measurably increase the usability of Wikipedia for new contributors by improving the underlying software on the basis of user behavioral studies, thereby reducing barriers to public participation. This position is part of the program team for the initiative. For more information, please see the press release. http://wikimediafoundation.org/wiki/Press_releases/Wikipedia_to_become_more_user-friendly_for_new_volunteer_writers Job Purpose The core responsibility of this position is to design, develop, test and deploy new features and improvements of the MediaWiki software for the the Wikipedia usability initiative by working closely with the interaction designer and peer developers of MediaWiki. Reports to Program Manager Job Summary *Propose software design solutions and obtain consensus from senior and peer tech teams *Create implementation prototypes based on design concepts *Develop, test, and deploy new features and improvements to the MediaWiki core and to MediaWiki extensions *Collaborate in designing and implementing QA processes including multi-lingual and performance tests *Work closely with operations staff to ensure proper integration with testing and production systems Required Qualifications *Computer Science degree or equivalent work experience *5+ years experience as a software developer is required *Experience with PHP development is required *Extensive experience with AJAX/HTML/CSS is required *Experience with cross-browser compatibility testing is required *Experience with security implications of JavaScript/PHP software is required *Experience with LAMP is a major plus *Experience with testing and analyzing usability and accessibility is a major plus *Experience with MediaWiki is a major plus *An understanding of internationalizing and localizing software products a major plus *Any other free/open software development experience highly welcome *Comfortable in a highly collaborative, consensus-oriented environment *Experience with wikis and participatory production environments is a plus *Understanding of the free culture movement is a plus *The ideal candidate will be creative, highly motivated, and able to operate effectively in multiple cultural and language contexts Salary The salary is in the range of $75,000 to $85,000 plus benefits, commensurate with experience. This position will be filled in June 2009. Due to the volume of responses that we anticipate we will not reply to all applications, so please do not interpret our silence as a lack of interest. Based in San Francisco, CA., but remote candidates will be considered. -- Support Free Knowledge: http://wikimediafoundation.org/wiki/Donate ___ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
