Last modified: 2011-07-17 01:28:17 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 5638 - show translated titles per user language, based on interlanguage links (patch included)
show translated titles per user language, based on interlanguage links (patch...
Status: RESOLVED WONTFIX
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
1.7.x
All All
: Lowest enhancement with 20 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-04-18 13:18 UTC by Daniel Kinzler
Modified: 2011-07-17 01:28 UTC (History)
9 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
patch against 1.7 HEAD (8.27 KB, patch)
2006-04-18 13:20 UTC, Daniel Kinzler
Details
updated patch (6.57 KB, patch)
2006-05-05 00:29 UTC, Daniel Kinzler
Details
Some more cleanup. Moved most logic into skin (6.95 KB, patch)
2006-05-08 20:34 UTC, Daniel Kinzler
Details

Description Daniel Kinzler 2006-04-18 13:18:45 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.
Comment 1 Daniel Kinzler 2006-04-18 13:20:14 UTC
Created attachment 1572 [details]
patch against 1.7 HEAD

first take, any comments welcome.
Comment 2 Jan Wartenberg 2006-04-18 21:31:19 UTC
I support this patch as the different languages are a problem especially on
Commons. This patch could improve the situation.
Comment 3 Daniel Kinzler 2006-04-20 15:21:25 UTC
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.
Comment 4 Antoine "hashar" Musso (WMF) 2006-04-20 20:59:13 UTC
Commited your patch to my branch:
http://svn.wikimedia.org/svnroot/mediawiki/branches/hashar/

Comment 5 Daniel Kinzler 2006-05-04 18:31:07 UTC
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
Comment 6 Daniel Kinzler 2006-05-05 00:29:58 UTC
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.
Comment 7 Brion Vibber 2006-05-05 02:12:08 UTC
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() ) {
Comment 8 Daniel Kinzler 2006-05-08 20:34:10 UTC
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?
Comment 9 Phil Boswell 2006-05-25 10:29:40 UTC
>> 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?
Comment 10 Duncan Harris 2007-05-27 17:03:10 UTC
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.
Comment 11 Niklas Laxström 2009-04-07 07:45:32 UTC
I also agree that interwiki links are not good for this. Far better would be using something like OmegaWiki.
Comment 12 gixie 2010-01-05 14:20:13 UTC
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).
Comment 13 Purodha Blissenbach 2011-05-02 15:46:57 UTC
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.
Comment 14 Jarek Tuszynski 2011-05-04 14:51:35 UTC
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.
Comment 15 Rd232 2011-06-09 10:06:40 UTC
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.
Comment 16 Antoine "hashar" Musso (WMF) 2011-07-16 07:47:56 UTC
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.
Comment 17 Rd232 2011-07-17 01:28:17 UTC
Created bug #29928 for more generic discussion of the problem, away from the rejected solution of interlanguage links.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links