In function getInitialPageText in SpecialUpload.php hardcoded headings are added to the license and file description provided by the user. It would be great, if those hardcoded headings could be changed to a MediaWiki message that can be altered onwiki. On Commons, which is multilingual, for example the headings are more like information clutter than useful structuring tools. The file description heading will always be in the user language and the license heading always in the content language, English (I have no idea why the difference, but it's in the source code). That does add more confusion than benefit. Especially since both description and license are wrapped in templates by default and thus don't need the headings to be distinguishable.
Would be nice if that could be fixed.
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. I would appreciate, if somebody could change the code. Thank you.
Marcus Buck
On Mon, Jan 26, 2009 at 10:13 AM, Marcus Buck wiki@marcusbuck.org wrote:
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.
Why don't you submit a patch, then?
Aryeh Gregor hett schreven:
On Mon, Jan 26, 2009 at 10:13 AM, Marcus Buck wiki@marcusbuck.org wrote:
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.
Why don't you submit a patch, then?
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
On Mon, Jan 26, 2009 at 11:12 AM, Marcus Buck wiki@marcusbuck.org wrote:
Aryeh Gregor hett schreven:
On Mon, Jan 26, 2009 at 10:13 AM, Marcus Buck wiki@marcusbuck.org
wrote:
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.
Why don't you submit a patch, then?
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Wouldn't exactly work. You'd need to cache per-language, or otherwise all users would get the latest cached version, whatever it happens to be. We should probably pass the language as a parameter, so it can be called there appropriately. We'll cache it a level above, which I believe is where it's done right now.
-Chad
Chad hett schreven:
Wouldn't exactly work. You'd need to cache per-language, or otherwise all users would get the latest cached version, whatever it happens to be. We should probably pass the language as a parameter, so it can be called there appropriately. We'll cache it a level above, which I believe is where it's done right now.
-Chad
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
On Mon, Jan 26, 2009 at 11:30 AM, Marcus Buck wiki@marcusbuck.org wrote:
Chad hett schreven:
Wouldn't exactly work. You'd need to cache per-language, or otherwise all users would get the latest cached version, whatever it happens to be. We should probably pass the language as a parameter, so it can be called there appropriately. We'll cache it a level above, which I believe is where it's done right now.
-Chad
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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
It doesn't have to do with what the language preference is, we're just checking based *on* language. My point is that getDescriptionRenderUrl() shouldn't be checking $wgLang itself, it should be getting the language passed as a parameter (in addition to $name). This way, we can properly cache the description page (in File::getDescriptionText()) by language. Otherwise, the cache won't be accurate, and you'll get the last cached version, whatever the language. By adding per-language caching on this, we can make it work effectively.
-Chad
Chad hett schreven:
It doesn't have to do with what the language preference is, we're just checking based *on* language. My point is that getDescriptionRenderUrl() shouldn't be checking $wgLang itself, it should be getting the language passed as a parameter (in addition to $name). This way, we can properly cache the description page (in File::getDescriptionText()) by language. Otherwise, the cache won't be accurate, and you'll get the last cached version, whatever the language. By adding per-language caching on this, we can make it work effectively.
-Chad
and you'll get the last cached version, whatever the language.
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&uselang...". 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
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.
-Chad
On Mon, Jan 26, 2009 at 12:16 PM, Marcus Buck wiki@marcusbuck.org wrote:
Chad hett schreven:
It doesn't have to do with what the language preference is, we're just checking based *on* language. My point is that getDescriptionRenderUrl() shouldn't be checking $wgLang itself, it should be getting the language passed as a parameter (in addition to $name). This way, we can properly cache the description page (in File::getDescriptionText()) by language. Otherwise, the cache won't be accurate, and you'll get the last cached version, whatever the language. By adding per-language caching on this, we can make it work effectively.
-Chad
and you'll get the last cached version, whatever the language.
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&uselang... ". 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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Chad hett schreven:
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.
-Chad
Well, you are right in some way, but if we can go the whole way, why not do it? I see a point for content language for monolingual wikis, but at least on multilingual wikis like Meta or Incubator or Wikispecies "content language" is set to "en" although it's actually not the language of the content but only the language set by default. On multilingual wikis the user language is the language we should go with.
Marcus Buck
Chad wrote:
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.
Well, if you actually visit the description page on Commons, you'll see the templates in your interface language -- that's kind of the _point_ of the autotranslated templates.
Then again, Commons is kind of a special case, since, being a multilingual project, it doesn't _have_ a real content language; in a technical sense its content language is English, but that's only because MediaWiki requires one language to be specified as a content language even if the actual content is multilingual. So I can see arguments either way.
What language is the "shareduploadwiki-desc" message shown in, anyway? Seems to be $wgLang, which would seem to suggest that the actual description should be shown in the interface language too, for consistency.
On Mon, Jan 26, 2009 at 12:44 PM, Ilmari Karonen nospam@vyznev.net wrote:
Chad wrote:
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.
Well, if you actually visit the description page on Commons, you'll see the templates in your interface language -- that's kind of the _point_ of the autotranslated templates.
Then again, Commons is kind of a special case, since, being a multilingual project, it doesn't _have_ a real content language; in a technical sense its content language is English, but that's only because MediaWiki requires one language to be specified as a content language even if the actual content is multilingual. So I can see arguments either way.
What language is the "shareduploadwiki-desc" message shown in, anyway? Seems to be $wgLang, which would seem to suggest that the actual description should be shown in the interface language too, for consistency.
-- Ilmari Karonen
Should be done with a wiki's content language as of r46372.
-Chad
Chad hett schreven:
Should be done with a wiki's content language as of r46372.
-Chad
Thanks! That's already a big improvement, but why content language? As I pointed out in response to your question, it need's to be user language on Meta, Incubator, Wikispecies, Beta Wikiversity, old Wikisource, and all the multilingual wikis of third party users. It's not actually necessary on non-multilingual wikis, but it does no harm either. So why content language? This could be solved with a setting in LocalSettings.php "isMultilingual", but that's another affair and as long as that does not exist, we should use user language.
Marcus Buck
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
On Jan 27, 2009 4:08 PM, "Marcus Buck" wiki@marcusbuck.org wrote:
Chad hett schreven:
Should be done with a wiki's content language as of r46372. > > -Chad
Thanks! That's already a big improvement, but why content language? As I pointed out in response to your question, it need's to be user language on Meta, Incubator, Wikispecies, Beta Wikiversity, old Wikisource, and all the multilingual wikis of third party users. It's not actually necessary on non-multilingual wikis, but it does no harm either. So why content language? This could be solved with a setting in LocalSettings.php "isMultilingual", but that's another affair and as long as that does not exist, we should use user language.
Marcus Buck
_______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia....
Chad hett schreven:
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.
The facts are correct, but if you thereby implicate that English thus should be regarded as a valid output for non-English users of those projects, I don't agree. This implication is wrong.
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.
The average user with a non-technical approach does not feel a strict distinction between "interface" (served by the php scripts) and "content" (rendered from database content). Especially on file description pages (file history and file links for example appear as headings just in the same way as the content headings). It won't seem odd to me.
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.
The ways of achieving and accessing may change in the future, but you will never have a clear separation of "content" and localizable elements. Multilang support can be as core as imaginable, but still you will have localizable elements stored in "content" areas.
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
Well, you could put it in other terms and the majority/minority thing switches: content lang allows localization for monolang projects only, when user lang allows it for _all_ projects. So content lang is the minority. Whether Arabic file description pages for users of the French Wikipedia preferring Arabic is a good or a bad thing is not decided and not even decidable. There are some points for content lang, but no strong points. There are some points for user lang, but no strong points either. If there are equally good points for both solutions this supports my interpretation of the majority/minority relation. Your interpretation is based on the assumption that content lang on monolang projects is _obviously_ a good thing.
Marcus Buck
wikitech-l@lists.wikimedia.org