Last modified: 2011-07-17 01:28:17 UTC
I would like to propose a patch that would show a "localized title" in the user's interface language for each page that has an interlanguage link for that language. The patch implements this for the page title shown at the top, and for pages listed in categories. This would of corse be a per-wiki option. Example: A user who has the interface set to German would see the title of the page "Horse" as "Horse [Pferd]", both at the top of that page and in any category listing that page. That way, he would know what's going on, even if he does not speak English. Rationale: multilingual projects like commons would geatly benefit from better internationalization support for things like categories. We have had problems with people complaining that if you don't speak englsih, you cannot naviagte the category structure. On the other hand, replicating the category structure in every language seems like an inheritely bad idea. Showing the target of the interlanguage link as a kind-of-translation is not perfect, but would help to ease the pain, I hope. It also avoids overhead in maintanance and code that would be necessary to implement a "real" translation scheme. Patch follows.
Created attachment 1572 [details] patch against 1.7 HEAD first take, any comments welcome.
I support this patch as the different languages are a problem especially on Commons. This patch could improve the situation.
Side note: this could also benefit anonymous users if it was combined with #3665 or a similar scheme to assign an interface language to an anon.
Commited your patch to my branch: http://svn.wikimedia.org/svnroot/mediawiki/branches/hashar/
Discussion on the commons village pump (mostly supporting this patch, no strong objections): http://commons.wikimedia.org/w/index.php?title=Commons:Village_pump&oldid=1842808#Automatic_translation_for_page_titles
Created attachment 1655 [details] updated patch the new patch fixes some code style issues, adds CSS classes for localized titles, and fixes some HTML-escaping. It also now shows "translations" if the user's language is the same as the content language, but the title is different.
I don't much like this: + <h1 class="firstHeading"><?php $this->text('title') . $this->html ('localtitle') ?></h1> Better probably to allow the skin to determine the appropriate formatting. There's some possible waste work here: + if ( $wgInterlanguageTitles ) { + $sql= 'SELECT page_title, page_namespace, page_len, cl_sortkey, ll_title It performs the extra join even if it's unneeded, which it will be in most cases. Check for the default language selection up ahead, then avoid checking it in the loop below: + if ( $wgInterlanguageTitles && ! is_null( $x->ll_title ) + && ( $wgContLanguageCode != $wgLanguageCode || $x->ll_title != $x->page_title ) ) { could be simplified to just check if ll_title is non-null and non-default. Consider a couple things here: + $localTitleHTML = ' <i class="localtitle">[' . $wgContLang- >convertHtml( $x->ll_title ) . ']</i>'; 1) Move it to a Skin function that can be called instead of duplicated in three places. 2) Consider use of the lang attribute. 3) Perhaps avoid hardcoding the <i> The check for language code is probably not needed here: + if ( $wgContLanguageCode == $wgLanguageCode && $localTitle == $wgOut->getPageTitle() ) {
Created attachment 1697 [details] Some more cleanup. Moved most logic into skin The new patch should take care of most issues mentioned above: > Better probably to allow the skin to determine the appropriate formatting. All formating is now down by the skin, in a single function. This function also determines if a loclized title is shown or not. > It performs the extra join even if it's unneeded, which it will be in most > cases. Check for the default language selection up ahead, then avoid checking > it in the loop below No, because the logis that the localized title is suppressed if the user's language is the same as the content language AND the localized title is the same as the "normal" title. The rationale is a) that an egnlish speaker may like to see "Horse" instead of "Equus caballus", or "Vienna" instead of "Wien"; and b) that people not speaking english want to see the translated title even if it's the same, to avoid false friends. > 1) Move it to a Skin function that can be called instead of duplicated in > three places. done > 2) Consider use of the lang attribute. done > 3) Perhaps avoid hardcoding the <i> not done, because the patch would then have to deal with all the skins' CSS files to have a "nice" effect. IMHO, italic should be the default. I see two possible problems with my patch: 1) There is some hack to force a "display title" to be shown instead of the page title - may be bug 2118, or something else, not sure. I'm not sure if my patch is compatible with that; the logic should probably be merged into the new Skin::composeDisplayTitle function. 2) my patch uses htmlspecialchars to encode the page title - the code in CategoryPage previously used Language::convertHTML. I'm not sure about the implications of using one or the other. I would also be very interested in the performance impact this patch may have. The parser cache should work as before, but the additional LEFT JOIN in the category query ads some load. What else should be considered?
>> 3) Perhaps avoid hardcoding the <i> >not done, because the patch would then have to deal with all the skins' CSS >files to have a "nice" effect. IMHO, italic should be the default. You should allow skins and users to customise the appearance of these additional titles, which are an excellent idea BTW. How about <span class="LocalizedTitle">...</span> or something similar?
While I like this, I don't like its reliance on interlanguage links. Interlanguage links are designed for linking to other wikis -- not display. It is therefore easy to think of situations where the two would differ, for example: * The article (or category) in the other language doesn't exist (yet). * Because of odd naming conventions * etc Therefore you need a new list of appropriate titles, e.g. in the format of [[title:de:bar]], [[title:fr:foo]] etc. It should also *not work* for image: namespace files because in image namespace the physical name of the image is just a physical name (though this can probably be fixed later). The third point is that this list can also have other display uses.
I also agree that interwiki links are not good for this. Far better would be using something like OmegaWiki.
i'm a admin of a wiki in italian. If it works is great. another possibility is translate all in spanish (the second language in the world).
I agree with Niklas Laxström, but I suspect a majority of intewrwiki link to be good starters. Most likely, very many names (of persons, in geography, of artworks, technical items and products, but not produce, lifestock and in taxonometry) can be expected to have usable interwiki links.
I just noticed this bug was labeled WONTFIX without providing any reasons. Can we reopen it? Fixing this bug is essential for allowing non-english speaking users to be able to navigate Wikimedia Commons category structure.
I've REOPENED this in the hope of getting a reply to Jarek's question above. The problem this bug seeks to address is FAR too critical to improving Commons to be ignored. If this particular solution cannot work, then alternatives need to be explored.
See comment #10 for an argument against interwikis. Niklas closed this bug with comment #11 using the reason above. Reclosing. We do not want to use the interwikis links.
Created bug #29928 for more generic discussion of the problem, away from the rejected solution of interlanguage links.
