Last modified: 2014-11-03 18:16:52 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T39703, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 37703 - Interlanguage list should be rendered according to context language (user interface language)
Interlanguage list should be rendered according to context language (user int...
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Internationalization (Other open bugs)
1.20.x
All All
: Normal enhancement (vote)
: Future release
Assigned To: Nobody - You can work on this!
:
: 37542 37756 72423 (view as bug list)
Depends on: 37704
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 21:14 UTC by Krinkle
Modified: 2014-11-03 18:16 UTC (History)
13 users (show)

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


Attachments
Screenshot of current git master as deployed on commons.wikimedia.org (1.20wmf5) (21.75 KB, image/png)
2012-06-18 21:14 UTC, Krinkle
Details

Description Krinkle 2012-06-18 21:14:40 UTC
Created attachment 10767 [details]
Screenshot of current git master as deployed on commons.wikimedia.org (1.20wmf5)

Recently the rendering of the interlanguage list was changed from:

* Sentence case rendering of the language name in the origin language (e.g. in an English interface French would be rendered as "Francais").

To:

* loose word rendering of the language name in the origin language (e.g. in French the language name is usually written lowercase in a sentence, so it is rendered as "francais" (lower case) regardless of context/user interface language).

I think the ideal solution is to render it like this:

* Sentence case rendering of the language name in the user interface language (e.g. French would be rendered as "French" for an English user, regardless of the content language, and Dutch as "Dutch". And for a Dutch user it would read "Frans" and "Nederland". And for a French user interface it would read "francais" and "néerlandais" (lower case).

But since right now we don't all language names in all language, I recommend we revert this recent change to the status quo until we can go all the way. Because right now the interlanguage list looks (imho) very broken to the average user (e.g. written by someone not caring about grammer, inconsistent capitalization). See attachment.


---
See also:
* bug 36819
Comment 1 Krinkle 2012-06-18 21:18:58 UTC
Changed this into an enhancement bug. Filed the recommended quick fix for the sidebars caused by bug 36819 as bug 37705.
Comment 2 Derk-Jan Hartman 2012-06-18 21:26:18 UTC
The reason for the current situation with links in the language of the target is of course to facilitate people in 'finding their way back' to their own language wiki. Ideally, we would have the following:

If user has a preference language set in his global settings (for instance Dutch), all interlanguage links in all wiki's should be in Dutch for this user.

If user has set a specific override language on a wiki (for instance Dutch), all interlanguage links in this specific wiki should be in Dutch for this user.

If a user is logged in on nl.wikipedia.org but has not language preference set, all interlanguage links should be in Dutch (if option 1 is implemented). (or possibly the language the browser is advertising ?)

If a user is not logged in, or if there is no global language option yet, then the 'current' method should be used, where all interlanguage links are in the language of the target wiki's interface language.
Comment 3 Derk-Jan Hartman 2012-06-18 21:27:31 UTC
AND add an index with sentence case per language and on the interlanguage table always apply the sentence case rules of the 'host' language and not the language that is 'embedded' into the rest of the interface.
Comment 4 Krinkle 2012-06-18 21:30:34 UTC
(In reply to comment #2)
> The reason for the current situation with links in the language of the target
> is of course to facilitate people in 'finding their way back' to their own
> language wiki. Ideally, we would have the following:
> 
> If user has a preference language set in his global settings (for instance
> Dutch), all interlanguage links in all wiki's should be in Dutch for this user.
> 
> If user has set a specific override language on a wiki (for instance Dutch),
> all interlanguage links in this specific wiki should be in Dutch for this user.
> 
> If a user is logged in on nl.wikipedia.org but has not language preference set,
> all interlanguage links should be in Dutch (if option 1 is implemented). (or
> possibly the language the browser is advertising ?)
> 
> If a user is not logged in, or if there is no global language option yet, then
> the 'current' method should be used, where all interlanguage links are in the
> language of the target wiki's interface language.

All this just simply means "user language preference". Every User object (even anonymous ones) have preferences (default preferences). And if and when we implement global settings, that is something taken care of at the preferences level, not at the level of "get user language". And by default the user language is the content language (anonymous users / new users that haven't changed it).

The logic you describe is what I meant in my opening post. Your phrasing is more clear :)
Comment 5 Erik Moeller 2012-10-20 21:00:15 UTC
I agree with Krinkle's reasoning. The jumbled case has since been restored to sentence case in the interlanguage links. However, Wikidata will re-introduce this issue.

The list of language links in http://wikidata-test-repo.wikimedia.de/wiki/Q321  is currently rendered purely in the native name and jumbled case, regardless of UI language. This decreases scannability and usefulness.

Krinkle writes that "we don't all language names in all languages". Shouldn't  https://www.mediawiki.org/wiki/Extension:CLDR (which is deployed on the cluster) address this concern?
Comment 6 Lydia Pintscher 2013-10-16 22:37:07 UTC
*** Bug 37542 has been marked as a duplicate of this bug. ***
Comment 7 Lydia Pintscher 2013-10-16 22:40:26 UTC
*** Bug 37756 has been marked as a duplicate of this bug. ***
Comment 8 Lydia Pintscher 2014-04-15 15:43:07 UTC
I am unsure of the scope of this bug now. Can you please clarify what you'd like changed on https://www.wikidata.org/wiki/Q1 for example? And is there anything else this bug covers now?
Comment 9 Andre Klapper 2014-04-25 05:19:04 UTC
Krinkle / Erik: ^^ Can you answer Lydia's question please?
Comment 11 Nemo 2014-07-05 10:03:00 UTC
The endonym must be used and the casing was fixed long ago, nothing to do here AFAIK.
Comment 12 Lydia Pintscher 2014-11-03 18:16:52 UTC
*** Bug 72423 has been marked as a duplicate of this bug. ***

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


Navigation
Links