Page MenuHomePhabricator

show translated titles per user language, based on interlanguage links (patch included)
Closed, DeclinedPublic

Description

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.


Version: 1.7.x
Severity: enhancement

Details

Reference
bz5638

Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:11 PM
bzimport added a project: MediaWiki-Parser.
bzimport set Reference to bz5638.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 1572
patch against 1.7 HEAD

first take, any comments welcome.

attachment LocalTitles.diff ignored as obsolete

jan.wartenberg wrote:

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.

Created attachment 1655
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.

attachment LocalTitles.diff ignored as obsolete

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.

  1. Consider use of the lang attribute.
  2. Perhaps avoid hardcoding the <i>

The check for language code is probably not needed here:
+ if ( $wgContLanguageCode == $wgLanguageCode && $localTitle ==
$wgOut->getPageTitle() ) {

Created attachment 1697
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

  1. Consider use of the lang attribute.

done

  1. 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.

  1. 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?

Attached:

  1. 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?

dunc_harris wrote:

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.

wikirestauro wrote:

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.

rd232 wrote:

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.

rd232 wrote:

Created bug #29928 for more generic discussion of the problem, away from the rejected solution of interlanguage links.