Page MenuHomePhabricator

Many system messages can't be translated
Closed, ResolvedPublic

Description

Author: dbenbenn

Description:
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.)


Version: 1.6.x
Severity: normal

Details

Reference
bz3413

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 8:49 PM
bzimport set Reference to bz3413.
bzimport added a subscriber: Unknown Object (MLST).

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

dbenbenn wrote:

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]].

dbenbenn wrote:

(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!)

avarab wrote:

*** Bug 3553 has been marked as a duplicate of this bug. ***

sanbec wrote:

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.

bastique.bz wrote:

*** Bug 4977 has been marked as a duplicate of this bug. ***

dbenbenn wrote:

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.

dbenbenn wrote:

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().

sanbec wrote:

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.

gangleri wrote:

Removed bogus dependency:
Bug 4243: shared file repository (tracking)

bastique.bz wrote:

(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.

alon wrote:

(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.

joanot.martorell wrote:

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?

dbenbenn wrote:

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.

dbenbenn wrote:

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.

gangleri wrote:

*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/

dbenbenn wrote:

(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.

arnomane wrote:

*** This bug has been marked as a duplicate of 5925 ***