Created attachment 10138
Recent Changes screen on zh.wikipedia.org for 1.18

This is the correct screen

Attached:

Created attachment 10139
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

Attached:

The content of attachment 10137 has been deleted by

Mark A. Hershberger <[email protected]>

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.

Appears to be due to r96812. Parser::parse() will only run language conversion if the interface message option in ParserOptions is off.

adding original reporter

forgot to add Liangent like I said I would.

Adding the developer and reviewer to the CC list.

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"?

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

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

Maybe a new magic word like FORCECONVERT?

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.

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

List of all MediaWiki namespace pages with -{...}-:

• zhwiki: http://paste.tstarling.com/p/ziKlSa.html
• srwiki: http://paste.tstarling.com/p/Zrndre.html

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.

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

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.

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

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

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

Proposed temporary patch committed in r113024.

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.

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.

$wgBug34832TransitionalRollback has been removed again per merge of gerrit 43449.