Wikitech-l January 2009

wikitech-l@lists.wikimedia.org

94 participants
89 discussions

Subpage titles
by Michael J. Walsh 05 Jan '09

05 Jan '09

This is a proposal to change how the MediaWiki software displays subpages. This isn't really an issue over a Wikipedia because subpages in the main namespace are disabled, but using subpages at Wikisource is a standard way of dividing up works, leaving only a table of contents at the root article. The problem is that this results in pages titles like this: United States Code/Title 35/Chapter 14/Section 151 or even Nicene and Post-Nicene Fathers: Series II/Volume I/Constantine/The Life of Constantine/Book II/Chapter 23 which IMHO looks more like a file system than a user-friendly website. I would suggest United States Code » Title 35 » Chapter 14 » Section 151 or my own favourite United States Code » Title 35 » Chapter 14 » Section 151 (With "Section 151" in bigger font.) This would effectively involve moving the subpages div above the title and changing the title from the entire path to just the subpage name. See: http://en.wikisource.org/wiki/Wikisource:Scriptorium#Subpage_formatting for the discussion I started on Wikisource and further down the same page http://en.wikisource.org/wiki/ Wikisource:Scriptorium#Subpage_formatting:_some_more_examples for some formatted versions of the above examples and http://en.wikisource.org/wiki/Nicene_and_Post- Nicene_Fathers:_Series_II/Volume_I/Constantine/ The_Life_of_Constantine/Book_II/Chapter_23 and http://en.wikisource.org/wiki/Treaty_on_European_Union/ Protocol_on_the_convergence_criteria_referred_to_in_Article_109j_of_the_ Treaty_establishing_the_European_Community for examples of how ugly the current setup can be. Michael

8 18

Change redirection on wikimania.wikimedia.org
by James R. 04 Jan '09

04 Jan '09

Hi guys, Could someone with the access please change the redirection on http://wikimania.wikimedia.org/ to the wikimania2009.wikimedia.org site? As it is now 2009, I think it would be best suitable to change this to the latest site. Thanks, James -- [[User:JamesR]] (formerly [[User:E]]) English Wikipedia Administrator Wikimedia Australia Member

4 6

what interwiki links here?
by Mohsen A. Momeni 04 Jan '09

04 Jan '09

Hi, How to get links to a page incoming from another wiki in a wiki family? a particular other wiki which is local to the main wiki? For example, getting all wikiquote links to a page of wikipedia. If there is no such extension implemented, how can I do it (beginner in php)? Thanks, Regards, -- __ \ /_\\_-//_ Mohsen A. Momeni

3 2

MediaWiki offline reader
by Ángel 03 Jan '09

03 Jan '09

I'm hereby presenting a new Offline Reader for MediaWiki. Already presented last year on another mailing list, here it is explained in depth, for the technical community. The impatients can go directly to http://www.wiki-web.es/mediawiki-offline-reader/ and download some samples. Note: Almost all docs are in Spanish only, so if you have an special interestest on some of them, or don't mind on them not being in English, just ask. :-) The application works from the wiki text found in XML dumps, and includes MediaWiki to parse them. Unlike other existing programs[1], MediaWiki isn't working in a web server fashion, the whole app is written in PHP, using PHP-GTK [2]. MediaWiki is run as a subquery, using the runkit extension [3]. The html result is fed back to GtkIEEmbed for the display. The format for the files, is the same XML as the dumps, and the problem of bzip files being too big [5] is overcome by using separated borrow-wheels blocks (in fact, for easiness I'm using full bzip2 files concatenated) each N articles. Similar to the (independent) approach taken by Thanassis Tsiodras (ttsiod) on [6]. However, instead of splitting the existing files, they're recompressed split each N articles, and creating an index at the same time. The same path is taken for categories, which are stored in a new category xml dump, which combines the information spread along page, category, categorylinks and page_props. See bug 16176 [7] for more information, although my implementation can probably be improved. Instead of hacking MediaWiki at high-level for Article, Title... (this could be a use case for the recently suggested wikiNeedL), it is incorporated as database driver [8], and applying some regex to the SQL as in [5]. Limitations: * The parser is slow, almost all the caching layers are disabled. Pages with many links/templates produce many accesses to fetch the pages. This is specially noticeable on first load, as Main Pages are usually complex and the interface looks freezed (MediaWiki runs on the same thread as the message loop). * Windows-only for now (the only dependance is IE, there're assumptions based of it's protocol behavior). * Only a few special pages are working (the most noticeable is the lack of Special:Search for fulltext) * It doesn't show the full author list. Sweet and happy new year! Ángel González 1 - Magnus wp_de_2004_05, Standalonewiki, YAWR, Tntreader... 2 - http://gtk.php.net/ 3 - http://pecl.php.net/package/runkit 4 - http://live.gnome.org/GtkIEEmbed 5 - http://permalink.gmane.org/gmane.science.linguistics.wikipedia.technical/36… 6 - http://users.softlab.ece.ntua.gr/~ttsiod/buildWikipediaOffline.html 7 - https://bugzilla.wikimedia.org/show_bug.cgi?id=16176 8 - Files DatabaseIndexedXml.php, DumpIndexSearcher.php, {Article,Category}Fetcher.php

2 2

There's hack value ...
by David Gerard 03 Jan '09

03 Jan '09

... and then there's Dangerously Batshit Insane. https://dgl.cx/wikipedia-dns - d.

3 2

Deprecate 'sysop' throughout MediaWiki?
by MZMcBride 02 Jan '09

02 Jan '09

There's been a bit of recent discussion about deprecating the term 'sysop' throughout MediaWiki by replacing it with 'admin' or 'administrator'. The primary advantage here would be that 'admin' or 'administrator' is more clear and better defines the role that these users play within a wiki. See also related bug: https://bugzilla.wikimedia.org/show_bug.cgi?id=16737 There are a number of different places that 'sysop' is used throughout the software, and it may or may not be advantageous to change all of them (for example inside the user_groups table). On the other hand, however, changing only some of the software while not changing other parts may simply lead to more confusion. Thoughts on the idea in general? Thoughts on the details? MZMcBride public(a)mzmcbride.com

9 8

Re: [Wikitech-l] On extension SVN revisions in Special:Version
by Chad 02 Jan '09

02 Jan '09

Perhaps ditching the absolutely useless svnversion param to $wgExtensionCredits entirely. Its redundant to version and provides (as mentioned) nothing of any real use. -Chad On Dec 31, 2008 4:54 PM, "Brion Vibber" <brion(a)wikimedia.org> wrote: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Special:Version displays SVN version numbers for extensions out of $wgExtensionCredits, which seems to be done with $LastChangedRevision$ keywords in the extension's entry point file. This produces massively incorrect numbers in many cases, since the entry point file is relatively rarely changed in non-trivial extensions consisting of multiple files. Updates to the body, class, i18n, and other files are not reflected. If we're running on a SVN checkout of the extension, we could check the directory for its current revision much as we do for MediaWiki itself; this would tell us for instance if an extension's subdirectory has been updated separately from the core MediaWiki. But if we aren't on a SVN checkout, or if individual files have been updated to different versions, this may or may not tell us anything useful. Anybody have a suggestion on how to best handle this? - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklb6VcACgkQwRnhpk1wk44MNACg2c0ztpocjHfsb5l+KxSu8e+I wXgAoMSrjFeTPzEnMY4904bxXZv+DiYf =GNqG -----END PGP SIGNATURE----- _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

1 0

An update on localisation in MediaWiki (2008)
by Siebrand Mazeland 01 Jan '09

01 Jan '09

On 31 December 2007 I sent an e-mail, to which this is a follow up[1]. First things first, because not everyone reads e-mails completely: * MediaWiki localisation (that is the translation of English source messages to other languages) depends on you! If you speak a language other than English, care about this and like translating, go to http://translatewiki.net, register a user and start contributing translations for MediaWiki messages and extension messages. When your localisation is complete, keep coming back regularly to re-complete it and do quality control. Thank you in advance for all your contributions and effort. * The i18n and L10n area of MediaWiki requires continuous efforts. If this area of FOSS has your interest, please do not hesitate and offer your development skills to further MediaWiki's i18n and L10n capabilities[5,6]. All statistics are based on MediaWiki 1.14 alpha, SVN version r45277 (1 January 2009). Comparisons are to MediaWiki 1.12 alpha, SVN version r29106 (31 December 2007). ==Introduction== * Localisation or l10n - the process of adapting the software to be as familiar as possible to a specific locale (in scope) * Internationalisation or i18n - the process of ensuring that an application is capable of adapting to local requirements (out of scope) MediaWiki has a user interface (UI) definition for 348 languages (up from 319). Of those languages at least 26 language codes are duplicates and/or serve a purpose for usability[2]. Reporting on them, however, is not relevant. So MediaWiki in its current state supports 322 languages (up from 302). To be able to generate statistics on localisation, a MessagesXx.php file should be present in languages/messages. There currently are 326 such files (up from 262), of which 27 are redirects from the duplicates/usability group or just empty[3]. So MediaWiki has an active in-product localisation for 299 languages (up from 236). The MediaWiki core product recognises several collections of localisable content (three of which are defined in messageTypes.inc): * 'normal' messages that can be localised (2168 - up 26% from 1726) * optional messages that can be localised, which usually only happens for languages not using a Latin script (173 - up 7% from 161) * ignored messages that should not be localised (149 - up 49% from 100) * namespace names and namespace aliases (17 - no change) * magic words (132 - up 10% from 120) * special page names (86 - up 13% from 76) * other (directionality, date formats, separators, book store lists, link trail, and others) Localisation of MediaWiki revolves around all of the above. Reporting is done on the normal messages only. MediaWiki is more than just the core product. On http://www.mediawiki.org/wiki/Category:All_extensions some 1200 extensions (up 60% from 750) have some kind of documentation. This analysis will scope only to the code currently present in svn.wikimedia.org/svnroot/mediawiki/trunk. The source code repository contains give or take 370 extensions (up 61% from 230). Of those 370 extensions, about 300 contain messages that can be visible in the UI in some use case (debugging excluded). Out of those 300, about 35 have an exotic implementation for localisation support, no localisation at all (just English text in the code), or are outdated, broken or obsolete. Compared to last year, when there were about 5 different 'standard' implementations of i18n in extensions, the situation has changed a lot. The vast majority of extensions now make use of $wgExtensionMessagesFiles and wfLoadExtensionMessages. Currently some 6,000 messages for extensions can be localised in a consistent way (up 200% from 2,000). ==MediaWiki localisation in practice== Ways to to MediaWiki localisation have not changed a lot in the past year. Still, the changes that have taken place have a profound impact on the quality and volume of localisation for MediaWiki. * in local wikis: we have scavenged all Wikimedia wikis for existing translations, imported those in the base product and tried to recruit translators to audit and extend the centralised localisation. This project has been very succesful, and aside from a few exceptions, local wikis now customise and no longer do base localisation. * through bugzilla/svn: A user of MediaWiki submits patches for core messages and/or extensions. These users are mostly part of a wiki community that is part of Wikimedia. Compared to last year, this group of localisation contributors has decreased. The maintainer for German for example started working in Betawiki, because he stated that he was no longer able to keep up with the workload. Languages that remain getting (very) frequent updates through subversion are Danish, Hebrew, and Chinese (4 variants). The number of localisations maintained this way has dropped from more than 10 to about 6. Localisation updates submitted through Bugzilla are virtually non-existent. * through Betawiki: In the past year Betawiki has about doubled in size (translators, translations, supported products, traffic, etc.). 95% or more of the localisation volume for MediaWiki goes through this wiki, and a lot of development has been done on the Translate extension in the past year. Betawiki staff remains committed to MediaWiki i18n and L10n, and still has a strong belief in collaborative localisation. ==The professional amateur approach== 2008 was also the year in which MediaWiki localisation got outside stimuli. A grant given to Stichting Open Progress[8] by Hivos[9] enabled us to provide bounties for less resources languages[10], and enabled us to have an end of year translation rally[11]. Niklas Laxström[12] participated in the Finnish Summer Coding Project[13], which led to a more feature rich and usable Translate extension, allowing translators to be more productive. We (Betawiki staff and Stichting Open Progress) intend to continue trying to get funding to improve language support for MediaWiki and FOSS in general. If you think you can help in any way to achieve this goal, please do no hesitate to contact any of us. Multiple developers contribute on i18n and L10n features. Most, if not all features that are added to subversion these days are audited for i18n or L10n omissions. These are usually corrected quickly after being discovered. Core messages and extension messages have been made more consistent. These are ongoing processes, that we need your help and awareness for[5,7]. ==MediaWiki localisation statistics== Per end of 2007 MediaWiki localisation has no longer only focused on a complete translation of core messages, but also on messages used in the most often use cases. This resulted in a set of about 25% of the MediaWiki core messages that really have to be translated before a language is really usable with MediaWiki. Because software like MediaWiki is ever changing, an updated of this list will be released in the coming week[4]. Daily statistics for MediaWiki and extension localisation are created at http://translatewiki.net/wiki/Translating:Group_statistics. Last year, some (arbitrary) milestones have been set for four collections of MediaWiki related messages. For the usability of MediaWiki in a particular language, the group 'core most used' is the most important. A language must qualify for MediaWiki to have 'minimal support' for that language in the first group. Reaching further milestones indicates the maturity of a localisation: * core most used (485 messages): 98% * core (2,168 messages): 90% * wikimedia extensions (1,067 messages): 90% * extensions (6,013 messages): 65% Currently the following numbers of languages have passed the above milestones: * core most used: 109 (33.9% of supported languages - up 132% from 47) * core: 68 (21.1% of supported languages - up 39% from 49) * Wikimedia extensions: 36 (11.2% of supported languages - up 260% from 10) * extensions: 21 (6.5% of supported languages - up 200% from 7) As you can see, the changes in the past year are gigantic. And these changes have been accomplished even though many messages have disappeared from and have and been added to all the message groups. Currently MediaWiki core contains 303,863 messages (up 77% from 171,261 ultimo 2007). ==Conclusion== So... Is MediaWiki doing well on localisation? Just like last year, my personal opinion is that we do a proper job, but can still do a lot better. Observing that there are more than 250 Wikipedias that all use the Wikimedia Commons media repository, and that 109 languages have a minimal localisation, there is a lot of room for improvement. With the Wikimedia Foundation using Single User Login, MediaWiki must do better. Last year I mentioned a few example cases of languages that did very well, and also a few language that didn't do well. So what happened there? Well, Hindi got a boost, but sank away as messages were added without an active maintainer. Asturian and Extremaduran have no active maintainers. Bikol Central is not doing to bad, and Lower Sorbian and Galician are doing great. Languages from Asia have heavily improved their MediaWiki localisation last year. But where are the languages from Africa? In the past year we have seen steady contributions for Amharic and Afrikaans, some for Swahili, Wolof and Yoruba, but all in all, just not enough to provide (native) speakers with a user interface in their own language. With the Wikimedia Foundation aiming to put MediaWiki to good use in developing countries and products like NGO-in-a-box that include MediaWiki, the potential of MediaWiki as a tool in creating and preserving knowledge in the languages of the world is huge. We have to tap into that potential and *you* (yes, I am glad you read this far and are now reading my appeal) can help. If you know people that are proficient in a language and like contributing to localisation, please point them in the right direction. If you know of organisations that can help localise MediaWiki: please approach them and ask them to help. We have all the tools to successfully localise MediaWiki into any of the 7000 or so languages that have been classified in ISO 639-3. We only need one person per language to make and effort and make it happen. Reaching the first milestone (core most used) takes about six hours of work. Using Betawiki or the gettext file, little to no technical knowledge is required. This was the pitch, basically the same as in 2007, but with more experience and data. Three of the four goals I set in last years' e-mail have not been reached. I did not take into account how rapidly MediaWiki would grow, or how quickly we could standardise i18n implementation for extensions. Goals for MediaWiki localisation per end of 2009 remain largely the same as for 2008: * core most used: 130 languages with 98% or more localised * core: 90 languages with 90% or more localised * wikimedia extensions: 50 languages with 90% or more localised * extensions: 30 languages with 65% or more localised I would like to wish everyone involved in any aspect of MediaWiki a wonderful 2009. Cheers! Siebrand Mazeland [1] http://lists.wikimedia.org/pipermail/translators-l/2007-December/000571.html [2] als,be-x-old,crh,de-formal,dk,en-gb,hif,kk,kk-cn,iu,kk-kz,kk-tr,ku,nb,ruq, simple,sr,tg,tp,tt,zh,zh-cn,zh-sg,zh-hk,zh-min-nan,zh-mo,zh-yue [3] als,be-x-old,crh,dk,hif,ii,iu,kk-cn,kk-kz,kk-tr,ks,ku,lld,nb,ruq-grek,ruq, simple,tg,tp,tt,ydd,zh-cn,zh-min-nan,zh-mo,zh-my,zh-sg,zh-yue [4] http://translatewiki.net/wiki/Most_often_used_messages_in_MediaWiki [5] i18n Bugzilla issues: https://bugzilla.wikimedia.org/buglist.cgi?query_format=advanced&component=I nternationalization&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNE D&bug_status=REOPENED [6] Translate extension bugs and feature requests: http://translatewiki.net/wiki/User:Siebrand#Bugs [7] http://translatewiki.net/wiki/Support [8] http://www.openprogress.org/Stichting_Open_Progress [9] http://www.hivos.nl/eng [10] http://translatewiki.net/wiki/Translating:Language_project [11] http://translatewiki.net/wiki/Betawiki:News/Newsletter_2008-12-2 [12] http://nike.fixme.fi/blag/ [13] http://www.coss.fi

1 0

Last code update of 2008!
by Brion Vibber 01 Jan '09

01 Jan '09

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Code Review Tuesday took a little extra long this week. ;) But it's still 2008 here in California, so let's get this party started! http://www.mediawiki.org/wiki/This_week%27s_updates to r45274 now live... And in the next couple days I plan to start rolling out some things that have been in testing, and rolling out new tests of things we didn't quite get enabled on test yet: http://www.mediawiki.org/wiki/Things_to_start_testing_in_2009 (this list will expand over the coming days) We'll also start firming up a roadmap for coming activity... 2009's gonna be sweet! - -- brion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAklcJuEACgkQwRnhpk1wk47eiQCfVHqzx7DJRuf5ngtTClEP3ekm kOkAnRuHihXPftHMu/jnu2QN2H/ICJeT =qose -----END PGP SIGNATURE-----

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Wikitech-l January 2009