Re: Language tag education and negotiation

Leif wasn't sure where I was headed with my earlier post. Let me 
summarize where I see this discussion going and propose in which 
directions the solutions could be found.

Andrews points about the need for customization is well taken - I would 
tend to agree with him that whenever developers have added the ability 
to break out of the "one size fits all" mold, additional groups of users 
are suddenly able to be served in ways that's natural to them.

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.

There are parts of the planets where it is common for people to command 
more than one language. If their command of multiple languages is 
unequal, the result is the standard case of 'fallback' language. 
However, where people are truly bilingual, the fallback language becomes 
dependent on context - it is no longer a static choice. I mentioned the 
case where users would like to avoid reading a translation into one of 
their languages, as long as an 'original' in the other language is 
available. There are also cases where the type of information (legal, 
scientific, etc.) might cause such users to have different language 
preferences. To support users in such cases, one might need additional 
customization, such as selecting from among two or more preference lists 
based on domain.

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

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

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

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.

A./

Received on Monday, 28 April 2008 04:14:46 UTC