And then I want to bring back to mind my last message about "localize transcluded image description pages". My proposal was easy to implement, uncontroversial, so I think, and it would provide a big gain in usability. At least it's relatively easy to implement for somebody with commit access, unlike me.

Aryeh Gregor hett schreven: wrote: Well, I kind of did. As far as I can judge, it's just changing 00298 function getDescriptionRenderUrl( $name ) { 00299 if ( isset( $this->scriptDirUrl ) ) { 00300 return $this->scriptDirUrl . '/index.php?title=' . 00301 wfUrlencode( 'Image:' . $name ) . 00302 '&action=render'; 00303 } else { 00304 $descUrl = $this->getDescriptionUrl( $name ); 00305 if ( $descUrl ) { 00306 return wfAppendQuery( $descUrl, 'action=render' ); 00307 } else { 00308 return false; 00309 } 00310 } 00311 } to 00298 function getDescriptionRenderUrl( $name ) { 00299 global $wgLang; 00300 if ( isset( $this->scriptDirUrl ) ) { 00301 return $this->scriptDirUrl . '/index.php?title=' . 00302 wfUrlencode( 'Image:' . $name ) . 00303 '&action=render&uselang='. $wgLang->getCode(); 00304 } else { 00305 $descUrl = $this->getDescriptionUrl( $name ); 00306 if ( $descUrl ) { 00307 return wfAppendQuery( $descUrl, 'action=render&uselang='. $wgLang->getCode() ); 00308 } else { 00309 return false; 00310 } 00311 } 00312 } As outlined in my first post. If I understand the code right, the cache key is set in File.php: 01079 $key = wfMemcKey( 'RemoteFileDescription', 'url', md5($renderUrl) ); It includes $renderUrl (and the URL includes the uselang part) and shouldn't need changes thus. No further changes needed. But as I also said, I am no expert on the Mediawiki code and I may have missed some code parts (I don't think so, but it would need much chuzpe if I'd deny that it's possible). Therefore I asked that a developer (or anybody else familiar with the internal mechanics of Mediawiki) take a look and implement those three lines or adapt it if I am wrong. Marcus Buck _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Chad hett schreven: First: Sorry, that the code wasn't that legible. It looked fine and changes were highlighted when I send it, but I didn't bear in mind, that the list is text-only. I don't understand your concern. The language _is_ passed via the URL. A user with another language set in the preferences will access another URL and will thus have another cache key. The keys will only match, if the language set in preferences is identical. Or where I am wrong? Marcus Buck _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Chad hett schreven: The cache key is set with $key = wfMemcKey( 'RemoteFileDescription', 'url', md5($renderUrl) ); in File.php. $renderUrl is the return value of 'getDescriptionRenderUrl': e.g. " http://commons.wikimedia.org/wiki/Image:foobar.jpg?action=render&uselan… ". The language is present in the key. So I still fail to understand the big difference. Why would I still get the last cached version whatever the language is? Providing the language as parameter might be a little more elegant, but it should not affect the functionality. Marcus Buck _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I was going to provide a specific parameter for it. That entire key sucks though anyway, I should probably ditch the md5()'d URL in favor of using the actual name. Fwiw: I've got a patch working, but I'm not quite ready to commit it yet. While we're at it, are we sure we want to use $wgLang and not $wgContLang? Image description pages are "content", not a part of the interface. That being said, I would think it would be best to fetch the information using the wiki's content language.

Should be done with a wiki's content language as of r46372. -Chad

You're hitting on a core issue here, which is the lack of support for multilingual projects. Mediawiki does not currently support this. Using hacks such as uselang has helped hide the issue, but its far from ideal. I would venture that multilingual content could be handled with the user's language setting/headers/uselang param being helpful to show the appropriate content. Until that happens, each project only has one content language. In cases like the ones you mentioned, this happens to be English.

Let's suppose I use the French Wikipedia with Arabic interface. I would find it very odd that the content is not in French, even though I use Arabic as my interface language.

On multilingual projects, its ok to present in your user language. On single-language projects it is not. Using uselang for content is an icky hack anyway. Multilingual projects need to be supported in core, or we're just going to perpetuate these hacks.

Basically, I figured support the majority of cases (single language projects) rather than the minority (multi- language projects). The former get the benefit of the hack, the latter see no change. -Chad