ID for language-invariant strings
doug at ewellic.org
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