When people of the #
Wikimedia Foundation write about language issues, it is most often a disappointment. When it is suggested that the list is ordered by the
ISO-639-1, there is no place in the list for the many many languages that have no such code. There are only 162 languages with such a code and, we have many more
Wikipedias.
Cherokee for instance has the code chr and French is
ᎠᎦᎸᏥ in Cherokee.
|
not properly sorted. |
When a list of languages is shown in the way it is written in that language, the ones in Latin characters come first. When people cannot recognise that languages are written in their native script, it makes sense to provide them with a pointer. This would help a Hindi speaker to type
हिंदी.
|
do you spot two font issues.. |
When such a list is to be completely in the local language as suggested, it would create several problems. Many people like me have a user on many Wikipedias, the language setting is sadly not a global feature and with the word
Nederlands no longer available, the usability is destroyed for me and a large group of people. The second problem is to complete a list of the names of languages for all the
Wikimedia languages.
OmegaWiki has many of them readily available.. Thirdly many Wikipedias are not in one script or orthography. The text of articles on the
Serbian Wikipedia for instance are available both in the Cyrillic and the Latin script. Finally most Wikipedians have insufficient or incomplete support for the fonts required.
The suggestion of a "universal language picker" assumes that language names are uniquely identified in that way. This is just not true. The assumption is also that there is a
need for a language picker on
Commons. The language should be based on the language of the user interface the only possible reason why this would not work is when Commons decides to allow for anonymous uploads.
We are asked for an opinion and having a language picker makes sense in the user preferences. Allowing for a global default would be a huge usability improvement. When it is also possible to override them locally, it would be bliss.
Thanks,
GerardM
2 comments:
Wikipedia’s multilingual portal has faced this issue for a long time. The current sorting order is largely a compromise. Once a visitor finds their wiki, they probably remember its location visually. Unfortunately, we break that for untold numbers of visitors every time we “promote” a language to the next level up.
While a text field with autocompletion – Guillaume’s recommendation – would relieve visitors of having to scan the portal’s large, incomprehensible lists, it would require the use of a keyboard – a no–no for a portal that’s supposed to do nothing but shunt you to another website.
Ideally, we could shelter users from the full list by suggesting a subset of languages based on their IP address or their browser’s default language. But the full list would absolutely need to be accessible and better-designed than our current list – which serves more to stoke the ambitions of stub-bots than to direct readers to their wiki.
Auto completion does not work because the names of languages are not unique.
Thanks,
GerardM
Post a Comment