Cross-posted to wikipedia-l and wikitech-l, I suggest you reply to wikitech-l.
I've just committed a change to make special page names case-insensitive and localisable. The default name for a special page can be changed, but a redirect from the English name will always be kept. At present, there are no local sets of names committed, although one has been proposed for German. I have created a wiki page for discussion and coordination of this task:
http://www.mediawiki.org/wiki/Special_page_names
The following is for developers, everyone else can stop reading here.
There are a few practice changes associated with this change, for both core and extension developers.
Instead of Title::makeTitle( NS_SPECIAL, 'Contributions' ); use SpecialPage::getTitleFor( 'Contributions' );
Instead of Title::makeTitleSafe( NS_SPECIAL, "Blockip/$ip" ); use SpecialPage::getSafeTitleFor( 'Blockip', $ip );
Instead of ($title->getNamespace() == NS_SPECIAL && $title->getDBkey() == 'Userlogout') use $title->isSpecial('Userlogout')
Only the last of these three changes is compulsory for extensions; recognition of core special page names must be migrated. Old titles will continue to work, so the first two changes are optional for extensions and can be done at your leisure. All three changes should be considered compulsory for core code.
Extension special pages can provide local special page names using the LangugeGetSpecialPageAliases hook.
Hard-coded special page names in messages should be changed simultaneously when the special page names themselves are changed. Special page names are language-dependent, not site-dependent, so there should be no need for a {{SPECIALNAME:xxx}} function.
-- Tim Starling
Tim Starling wrote:
Hard-coded special page names in messages should be changed simultaneously when the special page names themselves are changed. Special page names are language-dependent, not site-dependent, so there should be no need for a {{SPECIALNAME:xxx}} function.
Tim, can you clarify what you mean here?
If special page names are dependent on the content language, then messages absolutely must *not* hardcode the *localized* special page names or you'll get broken links when using a non-default UI language.
As with namespaces in links, a message should either use the canonical form (which will always work) or a magic variable which will be replaced with the proper localized form.
-- brion vibber (brion @ pobox.com)
Hi!
If special page names are dependent on the content language, then messages absolutely must *not* hardcode the *localized* special page names or you'll get broken links when using a non-default UI language.
Yet another argument against non-default UI.
As with namespaces in links, a message should either use the canonical form (which will always work) or a magic variable which will be replaced with the proper localized form.
And add 20% overhead to page execution on default installs.
Domas Mituzas wrote:
Hi!
If special page names are dependent on the content language, then messages absolutely must *not* hardcode the *localized* special page names or you'll get broken links when using a non-default UI language.
Yet another argument against non-default UI.
Maybe, but it is very much the friction that exists between function and functionality. When the function, MediaWiki, prevents functionality it is certainly not a good thing either. There is a need for non default UI in our projects with Commons as one of the more prominent ones. Here you have a situation where the size of the content starts to prevent the discovery of what is looked for. Certainly having English as the default UI is a good thing, but it does not help a seven year old French girl to find a picture of a "cheval".
As with namespaces in links, a message should either use the canonical form (which will always work) or a magic variable which will be replaced with the proper localized form.
And add 20% overhead to page execution on default installs.
So it does cost but is there an alternative, an alternative that provides us with the required functionality ??
Thanks, GerardM
Hi!
Certainly having English as the default UI is a good thing, but it does not help a seven year old French girl to find a picture of a "cheval".
Example of commons is really worst you could pick. First of all, we shouldn't use mediawiki for image repository at all ;-)
So it does cost but is there an alternative, an alternative that provides us with the required functionality ??
I did hear about technology in the works, that will make all translations magic - puff, it is all in there. No, there is no other technology. Hence it is question of functionality, sometimes.
Domas Mituzas wrote:
Hi!
Certainly having English as the default UI is a good thing, but it does not help a seven year old French girl to find a picture of a "cheval".
Example of commons is really worst you could pick. First of all, we shouldn't use mediawiki for image repository at all ;-)
I agree up to a point. The thing is however that we use MediaWiki for Commons; it is no use crying over spilled milk. The question therefore is how to make Commons work using MediaWiki and technology that makes the content available not hindered by the current insistence on English and Latin. That is a challenge I think the WiktionaryZ technology is getting ready to address,
So it does cost but is there an alternative, an alternative that provides us with the required functionality ??
I did hear about technology in the works, that will make all translations magic - puff, it is all in there. No, there is no other technology. Hence it is question of functionality, sometimes.
There is no technology that will make the need for translations disappear. What Multilingual MediaWiki will do is make it possible to have content indicated as being of a language at the article level in stead of at the database level. Then again, you may have read the specifications of Meta. FYI development on MLMW had to start all over again because of health issues that made it impossible for the first developer to finish it. MLMW is again under way and there have been some private showings of where it is currently at.
WiktionaryZ already shows content based on the language selected as the User Interface; this is triggered when the language of content and the language of the UI are the same. When a DefinedMeaning does not provide a definition or an Expression in the language of the UI, the content will be shown in English. When there is no English, you will get whatever is available. The functionality to show the language names in the language of the UI has been programmed, it just needs to be activated. This is for Erik to do.
Thanks, GerardM
On 10/31/06, Gerard Meijssen gerard.meijssen@gmail.com wrote:
disappear. What Multilingual MediaWiki will do is make it possible to have content indicated as being of a language at the article level in stead of at the database level. Then again, you may have read the
Only at the article level, and not at some section or even paragraph level? Pity, because already at commons there are lots of articles that have individual paragraphs labelled "de: " or "fr: " or whatever. Some clever way of only showing one of multiple translations based on preferences would be cool...
Steve
At wikisource, I'm working on an extension to transclude marked sections of a document, which would allow marking sections like this, so you could transclude a language from a multi-lingual document.
There is a discussion at http://en.wikisource.og/wiki/project:labeled_section_transclusion
Steve Bennett wrote:
On 10/31/06, Gerard Meijssen gerard.meijssen@gmail.com wrote:
disappear. What Multilingual MediaWiki will do is make it possible to have content indicated as being of a language at the article level in stead of at the database level. Then again, you may have read the
Only at the article level, and not at some section or even paragraph level? Pity, because already at commons there are lots of articles that have individual paragraphs labelled "de: " or "fr: " or whatever. Some clever way of only showing one of multiple translations based on preferences would be cool...
Steve
Domas Mituzas wrote:
Hi!
If special page names are dependent on the content language, then messages absolutely must *not* hardcode the *localized* special page names or you'll get broken links when using a non-default UI language.
Yet another argument against non-default UI.
As with namespaces in links, a message should either use the canonical form (which will always work) or a magic variable which will be replaced with the proper localized form.
And add 20% overhead to page execution on default installs.
The overhead can mostly be removed by introducing a pre-cache transform of messages -- essentially a preprocessing stage with a reduced set of functions. Even default installs have a message cache, but we don't use it nearly as well as we could.
-- Tim Starling
"Tim Starling" wrote:
The overhead can mostly be removed by introducing a pre-cache transform of messages -- essentially a preprocessing stage with a reduced set of functions. Even default installs have a message cache, but we don't use it nearly as well as we could.
-- Tim Starling
I had been thinking about the same. They could be stored half-parsed on the message cache, so all {{ns: }} {{special: }} etc. (some tamplates may also be included) wouldn't need extra work.
Brion Vibber wrote:
Tim Starling wrote:
Hard-coded special page names in messages should be changed simultaneously when the special page names themselves are changed. Special page names are language-dependent, not site-dependent, so there should be no need for a {{SPECIALNAME:xxx}} function.
Tim, can you clarify what you mean here?
If special page names are dependent on the content language, then messages absolutely must *not* hardcode the *localized* special page names or you'll get broken links when using a non-default UI language.
As with namespaces in links, a message should either use the canonical form (which will always work) or a magic variable which will be replaced with the proper localized form.
Sorry, yes, I should clarify. What I *meant* to say was exactly what you said, or at least I would have done, had I thought of it. Plus what Domas said. We can add a parser function, but encourage use of the redirects, since they will likely be faster.
Note that the sidebar already has some special-case code to display the local default name, if an alias was specified. All the links generated by the skin will display the local default, this is only an issue for hard-coded special page links in messages.
-- Tim Starling
Tim Starling wrote:
I've just committed a change to make special page names case-insensitive and localisable. The default name for a special page can be changed, but a redirect from the English name will always be kept. At present, there are no local sets of names committed, although one has been proposed for German.
So what would be the canonical name of the page that is currently [[Special:Recentchanges]]? You see, you said "the English name", but in my dictionary, "Recentchanges" is not an English word. It should be [[Special:Recent changes]]. The same applies to more than half of all the special pages. :)
Timwi
wikitech-l@lists.wikimedia.org