ID for language-invariant strings

Peter Constable petercon at
Sat Mar 15 00:14:50 CET 2008

> From: ietf-languages-bounces at [mailto:ietf-languages-
> bounces at] On Behalf Of David Starner

> > But if they are tagged as "zxx", then
> > you have to go out of your way to make sure that "zxx" gets ignored
> > when these are thrown at those processes -- which may be in a linked
> > library or in a service off in the cloud -- lest they simply return
> N/A.
> I don't understand the problem here...
> Hyphenation should leave them alone; word wrapping
> should do something basic, etc. (Converting a space to a new line is
> theoretically an error in your names as it might be in program text,
> but in both cases, if it's one the author worried about, they should
> have set it non-wrapping.) Language detection and "smart"
> handling is wrong; changing a font named "Coöperate!"  to "Co-
> <NL>operate!" is entirely correct English, but wrong for a fontname,

I wasn't suggesting that such things be done to name strings that get used in programmatic APIs, nor that things like spelling changes or other transformations might be applied to the data itself. But it may be appropriate to do things with copies of the data for intermediate purposes to obtain some result. For example, suppose from a long list of reference names for cultural elements from some domain, the app wants to support some search functionality, and wants to apply stemming or recognize alternate spellings in order to provide relevant results.


More information about the Ietf-languages mailing list