Re: Language tag education and negotiation

Asmus Freytag 2008-04-28 06.13:
> The reality remains that many, if not most developers, as well as many 
> if not most people in charge of creating or managing content are 
> either not aware of some of the complexities faced by users that are 
> not strictly monolingual, nor can they always anticipate the effect 
> that some of their choices have on such users.

Agreed.

[...]
> Of course, a meta tag that (reliably :-) ) described something as 
> 'translation', or conversely as 'official language version' would be 
> useful, too.

I saw a W3 incubator document written by Japanese authors were the 
authorative text was in English, but a parallell text in their 
mothertongue, Japanese, existed as well. Which document, should in that 
case count as "original version"?

Perhaps I am wrong, but to me, being able to always select the original 
seems like solving an edge case. I am not against solving it, bt 
language negotiaton to me seems most important on official info pages, 
web application - ie. on "service pages" where one do not want to switch.

And for instance, for a news paper, I'd expect that if it was bilingual, 
then selecting French over English would mostly affect the "chrome" of 
the web site: It would give me French titles and layout, while many of 
the very articles would appear only the language the journalist where 
using.  The Norwegian Goverment web site works like that when it comes 
to Nynorsk/Bokmål: If an article isn't available in Nynorsk, then you 
still get a Nynorsk page, but with a note that the very article was not 
available in Nynorsk, and therefore you receive it in Bokmål.

> There are also parts of the planet where the gap between neighboring 
> languages is not so wide, so that they remain more or less mutually 
> intelligible, putting many of their speakers into a 'bi-lingual' 
> situation by default. As Leif keeps pointing out, if the tags are not 
> defined correctly, it may be necessary to allow users to set up a not 
> strictly linear fallback list. (and tying such things to system 
> locales is clearly evil).

What do you mean by a strictly linear fallback?

> What would be educational in this case, is to create a well-edited 
> list of examples, from Norwegian, to Dinka, to examples for the case 
> of translation averse bi-linguals, as well as the case of language 
> choices needing to be based on (textual) domain or (internet) domain.

Agreed, very much.

> The examples should walk the reader through the scenario in a way that 
> both developers and content providers can see and understand the 
> consequence for their users of the kinds of choices and defaults they 
> have made. The examples should also be diverse enough to be able to 
> serve as the basis for user interface innovations in this area. 

Agreed.

> For example, this could take the form of exposing the customization in 
> terms most users understand (Leif suggested "main language" and 
> "second language" - but I want to warn again about users where there's 
> not a broad gulf between their "main" and "second" languages). UI 
> improvements could also take the form of having the user agent give 
> information about available alternative language versions, so that the 
> user can override an unfortunate result of automatic language 
> negotiation with a single click. And additional improvements can be 
> imagined.

Regarding overriding unfortunate results, if it was simple for the user 
to set up site-spesific language preferences, then that could be good.

As for 'main language', 'second language', yes, perhaps those words 
could be misunderstood.  Very often 'second langauge' means 'another 
language that I am fluent in'.

Her is an idea:

    * Instead of multiple variants of the same language to choose
      between, let there only be one option:
          o E.g only one English option, but let users very simply
            choose the order of preference when it comes to -GB, -US etc.
          o Same for Norwegian: One option, but let users simply choose
            betwen preferring Nynorsk or Bokmål.
    * However, *removing* sub-choices should be one step more difficult:
          o Removing Bokmål from Norwegian should be more difficult than
            simply choosing to prefer Nynorsk over Bokmål.
          o Removing  en-GB from English, should be more difficult than
            simply chosing to prefer en-US.
    * Packaging: For monolingual applications, an order of preference
      should be preset:
          o Example: Firefox and Thunderbird are now offerd in
            localized, monolingual versions. For the Nynorsk version,
            the Norwegian option should automatically be set to prefer
            Nynorsk over Bokmål.
    * Packaging: For multilingual applications, and also when the user
      ads a new language to the application's preferred languages, the
      users should be prompted about order of preference with regard to
      -GB versus -US, Dinka 1 verus Dinka 2.
          o However, if an application is offered for instance only in
            US English or only in Bokmål, then it would make sense to
            not take the order of preference for granted - and prompt
            upon starting the application the first time. (Apple tries
            to solve this by assuming that the user wants webpages in
            the same language as the GUI of the Mac OS X, thus avoiding
            the need to choose first time you open e.g. Safari. This is
            in principle elegant. However, Apple has made it so that in
            reality for instance Safari only prefers the primary
            language. Thus if you set OS X to French, and second
            language to German, Safari will only send the message that
            it prefers French.)

> The second item that would be needed, would be a list of those 
> language tags that are known to be problematic, either because of the 
> nature of the way they map the languages, or because of rampant 
> misuse. With such a list, developers, tool makers, and content 
> providers can, for example, create better defaults, or, alternatively, 
> decide to alert affected users to customize their setups more actively.

Agreed. Strongly. When the language tags are as unintuitive an 
un-miraculous as they are, this is needed.
-- 
leif halvard silli

Received on Monday, 28 April 2008 22:13:21 UTC