Page MenuHomePhabricator

LanguageConverter should depend on the page content language instead of the wiki content language
Closed, ResolvedPublic

Description

Now that I introduced a "page content language" (see Title.php), which allows extensions to change the language a page is written in, LanguageConverter should depend on that instead of $wgContLang (the wiki content language).

I thought it was relatively easy to fix, but while trying, it was apparently more tricky, so I thought I'd submit a bug report :)


Version: unspecified
Severity: enhancement

Details

Reference
bz30364

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 21 2014, 11:51 PM
bzimport set Reference to bz30364.
bzimport added a subscriber: Unknown Object (MLST).

While you're at it, could you make a page on mediawiki.org describing the 'page content language' concept and interface, and talk it up on wikitech-l?

I can't find *any* instances of the phrase appearing in wikitech-l archives, which makes me suspect that unless someone's been *explicitly following your changes on trunk* they have no idea what's happening in this arena.

Thanks!

I had already made a page describing the directionality improvements with some info on the page content language. Now I added a specific page http://www.mediawiki.org/wiki/Language_in_MediaWiki (and generally improved some i18n documentation).

I will send an e-mail to wikitech-l.. I am subscribed to several mailing lists but I almost never post to them :-) Should do that though.

I'm quite close to fixing this, but the problem is that $wgEnableParserCache needs to be false in order to make non-wgContLang conversions work. Probably the caching system somewhere depends on wgContLang where it should rather depend on the page language..

Created attachment 9049
Working patch if parser cache is disabled

attachment pagecontentlangconversion.patch ignored as obsolete

Had to find a way to use the title object to ParserOptions, but got it eventually. Fixed in r96798 :)

Robin: can you look at that restoring that revision with the issues fixed?

Ah... so we had a bug for this.

Preferences are going to be troublesome with multiple page languages though.

It's a side-nitpick though I didn't think Title was the best place for that. SpecialPages may be outputting content that actually came from another page and actually be in that page's language rather than the user's language.

Special pages can markup the content themselves fortunately.

Created attachment 9083
Working patch

This is the latest patch.

I haven't been able to fix the parser bug, but I can reproduce it on qqq message pages after adding $wgExtraLanguageNames['qqq'] = 'Message documentation'; to LocalSettings

Attached:

Committed in r97849 without the change in WikiPage, it caused an infinite loop, see bug 31098.