ID for language-invariant strings

Doug Ewell doug at
Sun Mar 16 00:42:21 CET 2008

Frank Ellermann <nobody at xyzzy dot claranet dot de> wrote:

> For almost-English 'i-default' might work,

Here is the text from RFC 2277 that describes the intended use of 
'i-default'.  I leave it to the list to decide whether Peter's scenario 
is consistent with this.

4.5.  Default Language

When human-readable text must be presented in a context where the sender 
has no knowledge of the recipient's language preferences (such as login 
failures or E-mailed warnings, or prior to language negotiation), text 
SHOULD be presented in Default Language.

Default Language is assigned the tag "i-default" according to the 
procedures of RFC 1766. It is not a specific language, but rather 
identifies the condition where the language preferences of the user 
cannot be established.

Messages in Default Language MUST be understandable by an 
English-speaking person, since English is the language which, worldwide, 
the greatest number of people will be able to get adequate help in 
interpreting when working with computers.

Note that negotiating English is NOT the same as Default Language; 
Default Language is an emergency measure in otherwise unmanageable 

In many cases, using only English text is reasonable; in some cases, the 
English text may be augumented by text in other languages.

> '' (empty) can be better than 'zxx' where empty tags are allowed,

This would have to be Peter's call.  I can see some advantages in using 
the empty tag here.

> to discourage overzealous translators 'en-x-fontname', or 'x-fontname' 
> might do the trick.

Peter didn't want any sort of private-use solution.

> The 'invariant' is too long, a hypothetical 'invar' would be limited 
> to BCP 47 applications, same issue as for 'i-default'.

You're right, I forgot how to count to 8.  'invar' or some synonym less 
than 8 letters long might work.

As for the solution being limited to BCP 47 applications, I'm not sure 
whether that is Peter's intent.  As I said, if the goal is to add a new 
ISO 639 code element, then this list has little say in the matter, 
except to provide +1's and -1's to the JAC.

Doug Ewell  *  Fullerton, California, USA  *  RFC 4645  *  UTN #14  ˆ

More information about the Ietf-languages mailing list