Subject: [Ltru] Commonwealth English orthography

From: Nicholas Shanks <[email-masked]>
Date: Thu, 15 May 2008 16:58:50 +0200

Okay, so I have 2 problems. I'd like my computer to use commonwealth  
spellings over US spellings. I'd also like to ship some software with  
only two localisations for English.

Translations on the Mac OS are identified with standard language  
identifiers (good start). Often the translation given under the  
generic "en" code has US spelling, and the commonwealth spelling will  
be given under en_GB (e.g. Firefox), but this isn't guaranteed, and  
software from the UK often has en with Commonwealth spelling and en_US  
in addition. Furthermore, software from other anglophone countries may  
forgo en_GB altogether. My own company (based in Germany) has decided  
that our software will use US spelling for the generic English.

This means I have to set my language fallback list to something like  
this, in order to catch an app's non-US locale if available:

en_GB, en_IE, en_NZ, en_AU, en_ZA, en_JM, en_IN, en_PK, en_BD, en_CA,  
en, fr, de

And provide at least 11 different translations for our software:

en (with US spellings)
en_GB (with commonwealth spellings)
en_everything_else symlinked to en_GB or duplicated (if symlinks don't  
work, haven't tested this yet)

This is so that an australian, who only has "Australian English" in  
his language list preferences (and thus only "en_AU, en" as his  
fallback list) will not get the US spelling.

I would much rather be able to ship:

en (with US spelling), and
en_cwealth   (variant identifier TBD)

I don't want to say anything about the language as it is pronounced,  
only it's orthography (similar to en_oxford, de_1901 and de_1996),  
since the content is written in nature. I realise that this solution  
won't work in the short term, since people won't have the new  
identifier in their OS yet.

Would a formal proposal for this be viable? Has anyone got any  
suggestions before I start?
An alternative i considered is asking the UN to register a three digit  
M49 code for the Commonwealth of Nations. Would this be doable? How  
approachable are the UN?! :-)

— Nicholas

_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 15 May 2008 08:23:02 -0700

You could use a variant, but it probably wouldn't help you very much. Variant subtags fall in the same position as the region subtag and eventually you vector back through 'en'---plus you face the problem of equating the various region codes with the orthographic locale while needing locale data (dates, numbers, lists, etc.) according to the region-based locale information. This is a classic problem many languages in which the defaulting behavior depends on the resource requested originally. One way to address this is at install time or config time. There are other methods, but would suggest that this is probably off-topic for this list.

Have you thought of asking on the cldr, www-international or on i18n-prog lists?

Addison

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Nicholas Shanks
> Sent: Thursday, May 15, 2008 7:59 AM
> To: LTRU Working Group
> Subject: [Ltru] Commonwealth English orthography
>

---

From: John Cowan <[email-masked]>
Date: Thu, 15 May 2008 11:41:06 -0400

> en_cwealth   (variant identifier TBD)

You should take this to [email-masked], which is the mailing list for
proposing *specific* language tags.

In any case, it's not clear that two localizations suffice:  en-CA is definitely
different from en-US or en-GB ("tire centre" vs. "tire center" vs. "tyre centre").
I think en-AU also uses "-ise" in some cases where en-GB retains "-ize".

-- 
The Unicode Standard does not encode            John Cowan
idiosyncratic, personal, novel, or private      http://www.ccil.org/~cowan
use characters, nor does it encode logos
or graphics.                                    [email-masked]
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: Peter Constable <[email-masked]>
Date: Thu, 15 May 2008 08:57:56 -0700

> John Cowan

> proposing *specific* language tags.

I agree.

Peter

---

From: Leif Halvard Silli <[email-masked]>
Date: Thu, 15 May 2008 20:49:43 +0200

Nicholas Shanks 2008-05-15 16.58:
> Translations on the Mac OS [...]
> en (with US spellings)
> work, haven't tested this yet) [...]

As I have stated on list and outside: The problem you take up here, is 
very similar to the Macrolanguage problem.

The problem occurs because you - and Apple - have chosen to use the most 
generic tag 'en' for 'English US', instead of using 'en_US', as you 
should have done.

This behaviour illustrates what happens when one uses the most generic 
tag - the Macrolangauge tag - for the dominant encompassing language, 
instead of using the spesific, encompassing language tag: It makes it 
very difficult and cumbersome to perform language negotiation.
-- 
regards,
leif halvard silli
_______________________________________________
Ltru mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/ltru

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 15 May 2008 13:10:52 -0700

Perhaps the situation is being misunderstood.

In lookup, you have to return *something* when someone asks for "en" (or
"de", or "no", or "zh", or "zh-Hant", etc.) Normally, this should be the
form that is most likely to be what the user understands. For "en", the most
widely used form is the same as "en-US"; for "de" it is "de-DE", and so on.
This may change over time, for English at some time in the past it would
have been "en-GB", and who knows, it may be "en-IN" at some point in the
future.

Mark

-- 
Mark

---

From: "Mark Davis" <[email-masked]>
Date: Thu, 15 May 2008 14:39:47 -0700

By the way, a side note: we have a *very* preliminary results of doing
language detection for written Cantonese, and over a sample of the web
(which includes HTML, PDF, ...) we're seeing the number of Cantonese being
about 0.0014% of the number of Mandarin documents. I want to emphasize that
this is preliminary.

Mark

---

From: Leif Halvard Silli <[email-masked]>
Date: Tue, 20 May 2008 10:27:34 +0200

> Perhaps the situation is being misunderstood.

You better bet spesific if you present assumtions.

> In lookup, you have to return *something* when someone asks for "en"
> (or "de", or "no", or "zh", or "zh-Hant", etc.) Normally, this should
> be the form that is most likely to be what the user understands.

You are confirming the similarities between handeling English and 
handeling a Macrolanguage.

> For "en", the most widely used form is the same as "en-US"; for "de"
> it is "de-DE", and so on. This may change over time, for English at
> some time in the past it would have been "en-GB", and who knows, it
> may be "en-IN" at some point in the future.

Where was the claimed misunderstanding?

The problem on the Mac OS X is that localisations which are "en-US" in 
nature, have been placed, by Apple, inside folders which are tagged as 
'en'.

Thus, we see that Apple has not realized the need for "English 
negotiation".

This is a pity, because if Apple had taken seriously the need for 
English negoatiation, then it would have been simple for them to 
understand - and aknowledge the need for - macrolanguage negotation as well.

The proper thing, in a language negotiation situation, is to be 
spesific. Or - actually, the key is to say two things simultaneously: I 
want "English spesific", but if not, then I want "English general".

The damage of not offering macrolanguage negotiation is/can of course be 
much more serious than the lack of offering a proper "English 
negotiation" can be.

However, those who prefers non-US English would do the rest of the 
languages in the World a great favour if they demanded proper "English 
negotiation" from Apple - or which ever wendor. Because that way they 
raise the awareness of the problem and shows a way to solve it.

-- 
leif halvard silli