http://en.wikipedia.org/wiki/Diabetes_mellitus
Languages
* 中文 * Afrikaans * አማርኛ * العربية ... * 粵語 * Žemaitėška * 中文
The first and last are the same. The first is a link to a template. Maybe there should be some error detection system put in place to reject edits that cause two links for the same language.
On Sun, 18 Mar 2012 17:39:19 -0700, jidanni@jidanni.org wrote:
http://en.wikipedia.org/wiki/Diabetes_mellitus
Languages
- 中文
- Afrikaans
- አማርኛ
- العربية
...
- 粵語
- Žemaitėška
- 中文
The first and last are the same. The first is a link to a template. Maybe there should be some error detection system put in place to reject edits that cause two links for the same language.
That's a template bug http://en.wikipedia.org/wiki/Template:OGTT doesn't noinclude it's own zh link. ;) I believe we've told you to report en.wp errors to en.wp instead of here before.
WikiText is loose, we don't throw errors for small mistakes, we try to work around them. Rejecting edits for something that may not even be their fault is a bad user experience too. In this case the user adding a [[zh:]] to a page shouldn't be punished because a template author forgot to includeonly the language link meant only for the template.
On Sun, 18 Mar 2012 19:47:48 -0700, jidanni@jidanni.org wrote:
Well OK, but in no case could
Languages
- 中文
- 中文
be legitimate.
We observer the illegal ones float to the very top of the list to boot.
At least they could be made a different color.
They don't flot to the top of the list. That one was just the first language link defined on the page. And there's no metadata where we could put making them a different color. Color of the ui is skin business not the business of the parser.
Besides, ;) color doesn't show up in your precious text browsers.
Ah, all along the seemingly consistent order of available languages on the bottom of each page depends on hand sorting them in the source of each page.
Let's imagine it is the year 2050 and each article has been translated into each language. A simple misplaced language would e.g., cause ZH users, who are used to looking for their language at the bottom, to not find it.
Also some authors might think, "ZH is the worlds most populous language, it belongs on the top!" So to prevent anarchy consider some standard sort automatically implemented. OK, enough FUD from me today, bye.
On Mon, Mar 19, 2012 at 09:52, jidanni@jidanni.org wrote:
Let's imagine it is the year 2050 and each article has been translated into each language. A simple misplaced language would e.g., cause ZH users, who are used to looking for their language at the bottom, to not find it.
Much before that happens, Universal Language Selector[1] should fix that issue.
[1] http://mediawiki.org/wiki/Universal_Language_Selector
On Sun, 18 Mar 2012 21:39:19 -0700, Srikanth Lakshmanan srik.lak@gmail.com wrote:
On Mon, Mar 19, 2012 at 09:52, jidanni@jidanni.org wrote:
Let's imagine it is the year 2050 and each article has been translated into each language. A simple misplaced language would e.g., cause ZH users, who are used to looking for their language at the bottom, to not find it.
Much before that happens, Universal Language Selector[1] should fix that issue.
A relevant article: http://www.gpaumier.org/blog/628_universal-language-picker/
On Sun, 18 Mar 2012 21:22:03 -0700, jidanni@jidanni.org wrote:
Ah, all along the seemingly consistent order of available languages on the bottom of each page depends on hand sorting them in the source of each page.
Pretty much... just like categories.
Let's imagine it is the year 2050 and each article has been translated into each language. A simple misplaced language would e.g., cause ZH users, who are used to looking for their language at the bottom, to not find it.
Also some authors might think, "ZH is the worlds most populous language, it belongs on the top!" So to prevent anarchy consider some standard sort automatically implemented.
Except language sorting is even more chaotic than sorting category names on a multilingual wiki (different languages sort the same set of special letters differently).
What do you sort by? By lang code? But that's a technical bit that has nothing to do with the user. By name in English? But that has nothing to do with the name the user is expecting. By native name? But that's sorting by letters, with multiple scripts, different languages sort things differently, and some don't even have rules for how to sort some characters. Things still end up in places people aren't expecting. And it 'still' isn't a fair way to sort things. By wiki size, activity, link popularity? Now the language system has to start tracking piles of data that isn't even available locally. It has to fetch data from remote wikis and some of that data might not even exist. It's also an immense amount of code. By language we expect the user to want? Sure... but that's only part of the list. And worse our pages our static. We can't go and start varying by Accept-Language causing the cache size Wikipedia takes up to be multiplied by over 100.
OK, enough FUD from me today, bye.
;) Long as you know where you stand.
On 19 March 2012 03:47, jidanni@jidanni.org wrote:
Well OK, but in no case could
Languages
- 中文
- 中文
be legitimate.
I disagree. There are plenty of examples where an English article (for instance) is covered in two or more languages in another language, where it makes no sense to link to a disambiguous page.
"S" == Svip svippy@gmail.com writes:
S> On 19 March 2012 03:47, jidanni@jidanni.org wrote:
Well OK, but in no case could
Languages
- 中文
- 中文
be legitimate.
S> I disagree. There are plenty of examples where an English article S> (for instance) is covered in two or more languages in another S> language, where it makes no sense to link to a disambiguous page.
All I know is make sure the links look different then.
wikitech-l@lists.wikimedia.org