| SPQRobin | |
| Aug 13 2011, 11:28 PM |
| F8110: pagecontentlangconversion-new.patch | |
| Nov 21 2014, 11:51 PM |
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
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 :)
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.
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.