Last modified: 2006-05-31 17:50:55 UTC
This is a quite general bug, but I'll start specific: [[MediaWiki:Disclaimerpage]] can't be translated. Where it is used in Skin.php, the function called is wfMsgForContent, instead of simply wfMsg. The Commons needs to be able to translate this message, since we have http://commons.wikimedia.org/wiki/Commons:General_disclaimer in four different languages. Furthermore, *there's no need to disallow translation on any other site*! For example, at the English Wikipedia, you only have one version of [[Wikipedia:General disclaimer]], so you want the produced link at the bottom of each page to be the same regardless of the selected language. But that is the case anyway, as long as [[MediaWiki:Disclaimerpage/XY]] doesn't exist for any language codes XY. (And since only admins can create such a page, that isn't a security hole.) So I suggest that Skin.php, line 987, be changed from wfMsgForContent( 'disclaimerpage' ) to simply wfMsg( 'disclaimerpage' ) More generally, the same reasoning above applies to other uses of wfMsgForContent. I suspect that *all* uses of wfMsgForContent can be changed to simply wfMsg, thus improving the ability of users to make translations. (The only complication I'm aware of is cases like [[MediaWiki:Mainpage]], which is used as both a link and the link text. The solution to that problem is to separate the two uses, for example as [[MediaWiki:Mainpage-link]] and [[MediaWiki:Mainpage]]. The "link" version would simply not have any translations created by admins, while the non-link version could be translated as usual.)
All instances of link titles and important license and similar information need to be set to the global instance, so selecting one of the other 100+ languages doesn't show false information. Generally, wfMsgForContent() must be used in any instance where: * The result will be saved back to the database * The result is in rendered wiki text that will be cached and sent to other users * The result is a wiki page title * Using a default localized text would be incorrect 99% of the time
I don't think that [[MediaWiki:Disclaimerpage]] is any of the first three instances (correct me if I'm wrong!). And I don't understand what you mean by a "default" localized text being incorrect. For example, at the Commons, it would be nice to have [[MediaWiki:Disclaimerpage/ja]] point to http://commons.wikimedia.org/wiki/Commons:%E5%85%8D%E8%B2%AC%E4%BA%8B%E9%A0%85 (which is the Japanese version of the page, more or less). The translation, as far as I can tell, would never be "incorrect": for example, there's no Spanish version of the disclaimer page, so we simply wouldn't create [[MediaWiki:Disclaimerpage/es]], forcing the software to default to [[MediaWiki:Disclaimerpage]].
(By the way, not that it's relevant here, but there are cases where wfMsg is used on text that is saved back to the database. For example, when uploading a file with the new license selector feature, the Summary and Licensing headers are translated. I had assumed that was a feature, but I guess it's a bug!)
*** Bug 3553 has been marked as a duplicate of this bug. ***
If a project like commons is multilingual, all the readable messages must be translatable. If you think "important license and similar information" must be unique. Why in english? There are many people with a "en-0" level of english, if that information is important, they must know it in their language. I don't know any reason to no translate "Disclaimerpage", "Copyright" or "Licences" MediaWiki messages.
*** Bug 4977 has been marked as a duplicate of this bug. ***
Brion, why did you set this bug as "invalid"? It is certainly a valid problem, the fact that some MediaWiki messages can't be translated. You wrote above that having a different language in your Preferences could cause MediaWiki to "show false information", but as I explained, that appears to be a misconception.
If you have a particular heavily multilingual project where people are actually going to edit those messages to be accurate and useful, we can whitelist those messages on that wiki to display the localized text. As a general rule, though, sitewide information like that should be showing the primary content language, since 99% of the time that's going to be the only one with the local-to-wiki information in it.
Well, the Commons is supposed to be multilingual. I don't understand what you mean by "local-to-wiki information". Imagine that [[MediaWiki:Disclaimerpage]] were allowed to be translated, by changing the code to use wfMsg instead of wfMsgForContent in the appropriate place. On the English Wikipedia, the change would have ''no effect whatsoever'', since no translation subpages such as [[MediaWiki:Disclaimerpage/es]] exist. Since EN has no translation of [[Wikipedia:General disclaimer]], we simply would not create any such subpages. At the Commons, however, we do have different versions of Commons:General_disclaimer. We would want to create MediaWiki:Disclaimerpage/als, /es, /ja, /zh, and /zh-tw. Since we don't have a German version of that page, we wouldn't create /de. Then people who have German set as their interface language would see the link provided by MediaWiki:Disclaimerpage, since the German translation of that message doesn't exist.
If there's not a local MediaWiki:X/es page, then the default Spanish message for "x" will be shown if you use wfMsg().
Brion, the solution is very easy: create the message in all languages copying the default text in english. A bot can make it in few minutes.
That's not going to happen on 99% of MediaWiki installations. On a handful of large sites we run with large bot-happy populations, we can switch a configuration variable without changing the software and have those particular messages run the localized copy.
Removed bogus dependency: Bug 4243: shared file repository (tracking)
(In reply to comment #10) > If there's not a local MediaWiki:X/es page, then the default Spanish message > for "x" will be shown if you use wfMsg(). > I hope I'm not backing up because of lack of information, but I'm not deeply familiar with the PHP and software. Let me bring this back to a basic level. Commons has enough of a variance of users in different languages to merit full language integration. Unfortunately: this is not working for many different parts of MediaWiki at Commons. One example: MediaWiki:Copyright/de is not bringing the german text to the copyright notice for German preferences. Also, added links like contactus-url are not being translated for the individual languages. These continue to direct to the English pages.
On particular sites where people can and will maintain it, particular messages can be set to pull from the localized version. THIS IS A RUNTIME CONFIGURATION OPTION, NOT A SOFTWARE CHANGE. IT DOES NOT BELONG ON THIS BUG REPORT. IF THERE ARE PARTICULAR MESSAGES ON PARTICULAR SITES THAT SHOULD BE SWITCHED, LIKE THE ONES ON COMMONS THAT HAVE BEEN SWITCHED FOR QUITE SOME TIME, OPEN A SEPARATE REQUEST FOR THAT, WITH SPECIFICITY.
Please read http://bugzilla.wikimedia.org/show_bug.cgi?id=4998 It's O.K.?
(In reply to comment #15) > On particular sites where people can and will maintain it, particular messages > can be set to pull from the localized version. > > THIS IS A RUNTIME CONFIGURATION OPTION, NOT A SOFTWARE CHANGE. > IT DOES NOT BELONG ON THIS BUG REPORT. IF THERE ARE PARTICULAR > MESSAGES ON PARTICULAR SITES THAT SHOULD BE SWITCHED, LIKE THE > ONES ON COMMONS THAT HAVE BEEN SWITCHED FOR QUITE SOME TIME, > OPEN A SEPARATE REQUEST FOR THAT, WITH SPECIFICITY. > 1. Don't shout. It makes you look silly. 2. Tell that to Ævar Arnfjörð Bjarmason, who marked 3553 as a duplicate of this bug; I was concerned solely with the messages in the Commons interface.
The content on [[:Commons:MediaWiki:Contact-link|MediaWiki:Contact-link]] in other languages, such as [[:Commons:MediaWiki:Contact-link/es|MediaWiki:Contact-link/es]], from Commons doesn't change the link to each language version of [[:Commons:Commons:Contact us|Commons:Contact us]]. In adding, [[:Commons:MediaWiki:Contact-link|MediaWiki:Contact]] and [[:Commons:MediaWiki:Contact-link|MediaWiki:Contact-link]] aren't being shown in the list of system messages from [[:Commons:Special:Allmessages|Special:Allmessages]], nor in each other languages. I'm supposing that this bug would be also related to wfMsgForContent function. And yes, I consider it as a bug, not an simply "configuration" subject. Please, make MediaWiki capable to be multilingual for one site. Thanks.
No, that has no relation whatsoever. What on earth?
I think this bug can be fixed by changing wfMsgForContent slightly. Let me first explain how I think wfMsg and wfMsgForContent work currently. Let's take a specific example: Suppose the sitewide language is German (for example, on the German Wikipedia) and you have your interface language set as French. If wfMsg is asked to load message FOO, it first checks for MediaWiki:FOO/fr; if that does not exist, it uses the default message in languages/LanguageFr.php. If wfMsgForContent is asked to load message FOO, it first checks for MediaWiki:FOO; if that does not exist, it uses the default message in languages/LanguageDe.php (in this example, which has German as the sitewide language). So, what I suggest is the following: when wfMsgForContent is asked to load message FOO, it first checks for MediaWiki:FOO/fr. If that does not exist, it checks for MediaWiki:FOO. If that does not exist, it uses the message in languages/LanguageDe.php. Basically, if admins on a wiki create a translation MediaWiki:FOO/fr, it's because ''they really want it to be used''. So MediaWiki should be changed to take that into account. As I currently understand it, that would allow all system messages to be translated, as we require at the Commons, without resulting in showing the (irrelevant) default message from the Language.php file.
wfMsgForContent is primarily for material that will be reinserted into the database (eg content) and needs to be consistent. The suggested change would break that. If there were a need for the suggested behavior it would have to be a different function.
Alright, then make it a different function. I think that most uses of wfMsgForContent ''don't'' actually go back in the database (and as I pointed out above, some uses of wfMsg ''do''), but if you want to say that's what the function is "primarily for", that's fine.
*note* The summary does not reflect all parts of the discussion. I was confused myself. One issue is to translate a MediaWiki *message* but *another* topic is to exchange url's. In 'MediaWiki:Sidebar' everithing what is "befor" the "|" (in LTR wikies left to it) is a reference to an url; what is "after" the "|" is the text in the content language which can be localised with /xx extensions or transcludes from the relevant MessagesXx.php file. The text after the "|" is displayed in the 'Navigation' according to the selected language *but* the url is unchanged. A similar situation (referencing to url's) is done via other MediaWiki messages as 'MediaWiki:Copyright', 'MediaWiki:Disclaimerpage' etc. Imagine that a wiki would show different content depending on the selected language interface for [[Main_Page]] because it would look for 'MediaWiki:Mainpage'. This would be definitively another type of wiki. Beside the existence of a translation of the MediaWiki message the existence of the url where this is pointing would need to be verified as well. Such new "rules" can cause a lot of confusion because it would not be clear if they would aplay to all 'titles' or not. I see no major problem with http://commons.wikimedia.org/wiki/Commons:General_disclaimer (the first message mentioned in comment 0). For this page both translations at 'commons' and many interlanguage links are available.
Closing bug as per last comment: " http://commons.wikimedia.org/wiki/Commons:General_disclaimer Got both translations at 'commons' and many interlanguage links are available. " Stop reopening this bug and use the mailing list instead: wikitech-l on http://mail.wikipedia.org/
(In reply to comment #23) > A similar situation (referencing to url's) is done via other MediaWiki messages > as 'MediaWiki:Copyright', 'MediaWiki:Disclaimerpage' etc. Imagine that a wiki > would show different content depending on the selected language interface for > [[Main_Page]] because it would look for 'MediaWiki:Mainpage'. This would be > definitively another type of wiki. Reinhardt, you might want to check out the Wikimedia Commons, at http://commons.wikimedia.org. I wouldn't go so far as to say that we are "definitively another type of wiki", but we certainly do have translations of [[MediaWiki:Mainpage]], and the link in the navigation box depends on your selected language. > Beside the existence of a translation of the > MediaWiki message the existence of the url where this is pointing would need to > be verified as well. Yes. That is what we have administrators for. > Such new "rules" can cause a lot of confusion because it > would not be clear if they would aplay to all 'titles' or not. I'm sure we at the Commons would be more than capable of dealing with any resulting confusion. Note that as I explained at length to Brion, having the ability to translate all MediaWiki messages would ''not'' mean that we ''would'' translate all messages, or that we would set things up to provide "false information" (Brion's first comment). > I see no major problem with > http://commons.wikimedia.org/wiki/Commons:General_disclaimer (the first message > mentioned in comment 0). For this page both translations at 'commons' and many > interlanguage links are available. Of course, this bug is not discussing the content of [[Commons:Commons:General disclaimer]]. The point is that we have no way whatsoever to translate the "Disclaimers" link at the bottom of every edit page. So if someone sets their interface language to Chinese, they're still forced to go to the English page first, then find the Chinese translation, instead of being taken directly there.
David, stop reopening this bug please.
See Bug 5925 for followup.
*** This bug has been marked as a duplicate of 5925 ***
