Last modified: 2013-02-04 07:36:57 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 34832 - $wgOut->addWikiText() doesn't run language converter
$wgOut->addWikiText() doesn't run language converter
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Language converter (Other open bugs)
1.19
All All
: Highest blocker (vote)
: 1.19.0 release
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-01 02:09 UTC by Mark A. Hershberger
Modified: 2013-02-04 07:36 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
this is wrong (deleted)
2012-03-01 02:09 UTC, Mark A. Hershberger
Details
Recent Changes screen on zh.wikipedia.org for 1.18 (282.83 KB, image/png)
2012-03-01 02:14 UTC, Rob Lanphier
Details
Recent Changes screen on zh.wikipedia.org for 1.19 (275.27 KB, image/png)
2012-03-01 02:15 UTC, Rob Lanphier
Details

Description Mark A. Hershberger 2012-03-01 02:09:33 UTC
Created attachment 10137 [details]
this is wrong

See screenshot.  Raw code is displayed.
Comment 1 Rob Lanphier 2012-03-01 02:14:42 UTC
Created attachment 10138 [details]
Recent Changes screen on zh.wikipedia.org for 1.18

This is the correct screen
Comment 2 Rob Lanphier 2012-03-01 02:15:35 UTC
Created attachment 10139 [details]
Recent Changes screen on zh.wikipedia.org for 1.19

This is the wrong version.  Note the -{H|zh:[公告];zh-hans:[公告];zh-hant:[公告];}- -{H|zh:[投票];zh-hans:[投票];zh-hant:[投票];}-  stuff
Comment 3 Mark A. Hershberger 2012-03-01 02:17:30 UTC
The content of attachment 10137 [details] has been deleted by
    Mark A. Hershberger <mah@everybody.org>
who provided the following reason:

robla's screenshots are better

The token used to delete this attachment was generated at 2012-03-01 02:16:33 UTC.
Comment 4 Tim Starling 2012-03-01 02:27:36 UTC
Appears to be due to r96812. Parser::parse() will only run language conversion if the interface message option in ParserOptions is off.
Comment 5 Mark A. Hershberger 2012-03-01 02:29:55 UTC
adding original reporter
Comment 6 Mark A. Hershberger 2012-03-01 02:31:18 UTC
forgot to add Liangent like I said I would.
Comment 7 Tim Starling 2012-03-01 02:39:52 UTC
Adding the developer and reviewer to the CC list.
Comment 8 Tim Starling 2012-03-01 03:04:02 UTC
Apparently OutputPage::addWikiText() is used for content language text without the $interface=true option in many places. So r96812 is incomplete in that it doesn't update those callers. 

There is also the issue of the particularly ugly failure mode. Could we maybe decouple -{}- expansion from language conversion, choosing some sensible default expansion when language conversion is not done? For example say if I put this in MessagesEn.php: 

-{fr:foo;en:bar}-

Could this just expand to "bar"?
Comment 9 Tim Starling 2012-03-01 03:04:56 UTC
(In reply to comment #8)
> Apparently OutputPage::addWikiText() is used for content language text without
> the $interface=true option in many places.

I mean without $interface=false, i.e. without enabling language conversion.
Comment 10 Liangent 2012-03-01 03:09:33 UTC
(In reply to comment #8)
> Apparently OutputPage::addWikiText() is used for content language text without
> the $interface=false option in many places. So r96812 is incomplete in that it
> doesn't update those callers. 

I would say it's like a kind of abuse of language converter. <recentchangestext> should be $interface=true if it's fixed because it's already separated into zh-hans and zh-hant in i18n file. However on zhwiki they're mixed again and used to display something in content language...
Comment 11 Liangent 2012-03-01 03:10:47 UTC
Maybe a new magic word like __FORCECONVERT__?
Comment 12 Siebrand Mazeland 2012-03-01 08:17:27 UTC
srwikis are also broken. See for example http://sr.wikipedia.org/sr-ec/%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%BC%D0%B8%D1%80_%D0%9B%D0%B5%D1%9A%D0%B8%D0%BD.  Those should probably be rolled back until a fix is available, too.
Comment 13 Robin Pepermans (SPQRobin) 2012-03-01 11:35:14 UTC
I did check which callers needed to be updated, but since the {specialpage}-summary messages are hidden by default and they're in fact in the user language, I didn't think about that. So afaics you should just use Mediawiki:Recentchanges-summary/variant, e.g. MediaWiki:Recentchanges-summary/zh-hans.

(I'd like to add that the title of this bug is a bit misleading, since addWikiText isn't supposed to run language converter because in 99% of the cases it's in the user language. Before my commits it gave very ugly results when using a custom user language and custom content variant.)
Comment 14 Tim Starling 2012-03-01 23:39:31 UTC
List of all MediaWiki namespace pages with -{...}-: 

* zhwiki: http://paste.tstarling.com/p/ziKlSa.html
* srwiki: http://paste.tstarling.com/p/Zrndre.html
Comment 15 Tim Starling 2012-03-02 04:03:58 UTC
Edittools was affected by this because of a bug in MessageCache::parse() which caused the interface language option to be set in ParserOptions even if the parameter to MessageCache::parse() was false. Fixed this in 112872. Other messages may have been affected for the same reason.
Comment 16 Liangent 2012-03-02 05:31:57 UTC
(In reply to comment #14)
> List of all MediaWiki namespace pages with -{...}-: 
> 
> * zhwiki: http://paste.tstarling.com/p/ziKlSa.html

In this list I see this: http://zh.wikipedia.org/w/index.php?title=MediaWiki:Clearwatchlist/ja&diff=2220226&oldid=2220225 , where -{}- is used to prevent conversion. Applying Chinese conversion on Japanese can mess things up, so r96812 is meaningful and fixing some issues in some cases...
Comment 17 Tim Starling 2012-03-02 05:48:57 UTC
For recentchangestext and edittools, I have applied fixes in trunk and tagged them for backport. I reviewed all uses of wfMsgForContent() in the MW core, and I don't think there are any others that disable language conversion inappropriately.

Most of the messages in comment #14 are for the user language. For these, perhaps fixing the wikis, either with a script or by hand, would be simplest.
Comment 18 Liangent 2012-03-02 06:53:28 UTC
(In reply to comment #17)
> Most of the messages in comment #14 are for the user language. For these,
> perhaps fixing the wikis, either with a script or by hand, would be simplest.

It isn't that simple because some messages may transclude another template (like recentchangestext).
Comment 19 Robin Pepermans (SPQRobin) 2012-03-02 19:47:18 UTC
(In reply to comment #18)
> It isn't that simple because some messages may transclude another template
> (like recentchangestext).

In the case of recentchangestext, that is a message in the content language, which means language converter should work for it (fixed by Tim Starling in r112873).

(In reply to comment #16)
> http://zh.wikipedia.org/w/index.php?title=MediaWiki:Clearwatchlist/ja&diff=2220226&oldid=2220225 where -{}- is used to prevent conversion.
> Applying Chinese conversion on Japanese can mess things up,
> so r96812 is meaningful and fixing some issues in some cases...

Using any Latin-script language on Serbian wikis, then choosing Cyrillic as variant converted a lot of the UI to Cyrillic. Imho it was a quite major bug. It still amazes me how often people use ugly hacks instead of reporting a bug.
Comment 20 Tim Starling 2012-03-05 06:42:32 UTC
(In reply to comment #19)
> Using any Latin-script language on Serbian wikis, then choosing Cyrillic as
> variant converted a lot of the UI to Cyrillic. Imho it was a quite major bug.
> It still amazes me how often people use ugly hacks instead of reporting a bug.

That is true. However it appears to be used in a beneficial way on the Chinese Wikipedia. Because of the inconvenient fallback sequence in MessageCache::get(), you have to create MediaWiki namespace pages in all 9 variants in order for Messages*.php to be successfully overridden. It's easier to copy and paste the same text to 9 pages, relying on the converter to work its magic, than to convert them manually.
Comment 21 Tim Starling 2012-03-05 12:17:36 UTC
Proposed temporary patch committed in r113024.
Comment 22 Tim Starling 2012-03-08 06:22:26 UTC
The temporary patch is deployed now, so I'm closing this bug. A bug can be opened for the issues on the converter wikis that Robin's changes were intended to fix.
Comment 23 Robin Pepermans (SPQRobin) 2012-03-09 02:29:41 UTC
So, as an update: zh wikis are now running on the 1.18 behaviour (wgBug34832TransitionalRollback true: interface messages converted) and all other wikis on 1.19 behaviour. Only srwikipedia had -{ that needed to be removed on MediaWiki pages.

(In reply to comment #12)
> srwikis are also broken. See for example
> http://sr.wikipedia.org/sr-ec/%D0%92%D0%BB%D0%B0%D0%B4%D0%B8%D0%BC%D0%B8%D1%80_%D0%9B%D0%B5%D1%9A%D0%B8%D0%BD.
>  Those should probably be rolled back until a fix is available, too.

This is actually a different issue, see bug 35076.
Comment 24 Siebrand Mazeland 2013-01-11 16:29:39 UTC
$wgBug34832TransitionalRollback has been removed again per merge of Gerrit change #43449.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links