adding all of iso639_3 to either en.xml or root.xml

Tue Jul 15 12:34:07 CDT 2014

Some problem same solution: use the following fallback sources in that
order:

- local application data where available (as long as they need to remain
differentiated from CLDR, or if applications need some extra private codes
or conflicting codes like "nrm" in Wikipedia used for "Norman", instead of
the unrelated language encoded in BCP47 and ISO639-3, both of them still
having no code for "Norman" itself)
- local application fallbacks (if needed to handle legacy data for an
interim migration period)
- CLDR data for the effective locale if available
- CLDR date for fallbacks documented in CLDR
- CLDR "en" or "fr" vetted data
- CLDR "en" or "fr" draft" data (optional)
- BCP47 English names (for tlocales using English as a fallback)
- ISO639 names (if ther contradict between ISO 639 parts, use -1, then -2
then -3) if a matching ISO639 code can reasonably be mapped from a locale
code (I doubt it will find anything useful after the BCP47 step).
- display just the locale code itself (possibly with some
application-specific surrounding "decoration", like punctuations or
rendering styles)

So a CLDR application would just require two supplementary LDML data files,
but many CLDR applications won't have it). This will save us of vetting
CLDR data for many languages for which we still have not seen any need for
interoperability between sources using other names than those from BCP47 or
ISO636 or from their own local community and applications.

2014-07-15 18:50 GMT+02:00 Peter Constable <petercon at microsoft.com>:

>  One thing to note: names in ISO 639 are intended primarily for purposes
> of identifying the concepts that are encoded, not providing recommended
> display names. Especially in 639-3, the reference names are not claimed to
> be English names for the languages; they are merely names that have been
> used in literature documenting languages. It was simply not feasible to get
> a review of 7000+ language concepts to determine names that are
> specifically English or French, or specifically autonyms, or to review for
> suitability as display names in UI (in whatever language).
>
>
>
> If CLDR TC or any of its participants can provide vetted English / French
> / whatever names for any of the entries in 639-3, then I expect the RA
> would be open to considering changes. The RA is not constrained to
> providing only reference names of undetermined language origin; they were
> only required to provide unique and unambiguous reference names.
>
>
>
>
>
> Peter
>
>
>
> *From:* CLDR-Users [mailto:cldr-users-bounces at unicode.org] *On Behalf Of *John
> Emmons
> *Sent:* Tuesday, July 15, 2014 9:17 AM
> *To:* Mckenna, Mike
> *Cc:* Mark Davis ☕️; Steven R. Loomis; cldr-users at unicode.org; Martin
> Hosken
>
> *Subject:* Re: adding all of iso639_3 to either en.xml or root.xml
>
>
>
> Another potential problem here is that en.xml and iso639-3 don't always
> agree 100% on the names.  Maybe in root - but I think it is definitely
> going to be hard to maintain.
> I put it on the agenda for the next TC mtg.
>
>
> Regards,
>
> John C. Emmons
> Globalization Architect & Unicode CLDR TC Chairman
> IBM Software Group
> Internet: emmo at us.ibm.com
>
>
> [image: Inactive hide details for "Mckenna, Mike" ---07/15/2014 10:30:29
> AM---I know we at PayPal would certainly be fans of getting al]"Mckenna,
> Mike" ---07/15/2014 10:30:29 AM---I know we at PayPal would certainly be
> fans of getting all of iso639-3 in CLDR. We are currently cob
>
> From: "Mckenna, Mike" <mimckenna at paypal.com>
> To: Mark Davis ☕️ <mark at macchiato.com>
> Cc: Martin Hosken <martin_hosken at sil.org>, "cldr-users at unicode.org" <
> cldr-users at unicode.org>, "Steven R. Loomis" <srl at icu-project.org>
> Date: 07/15/2014 10:30 AM
> Subject: Re: adding all of iso639_3 to either en.xml or root.xml
> Sent by: "CLDR-Users" <cldr-users-bounces at unicode.org>
>  ------------------------------
>
>
>
>
> I know we at PayPal would certainly be fans of getting all of iso639-3 in
> CLDR. We are currently cobbling lists together in English and then
> translating to target languages. I would have no problem with having the
> English names in root since these and the French are the official ISO
> entries.
>
> We use the lists for pull-downs on postal address entry forms and need to
> present them in user language for selection, local language for domestic
> delivery and English for international postal mail.
>
> Thanks,
>
> Mike___
>
> Sent from my iPhone
>
> On Jul 14, 2014, at 11:56 PM, "Mark Davis ☕️" <mark at macchiato.com> wrote:
>
> I'm not sure it would be worth it. People can always pick up a copy of the
> language subtag registry and use it to back-fill.
>
> We do keep a copy of the registry in our tooling data directory, and
> that's what we do in our tooling, such as myCldrFile.getName(language).
>
>
> Mark <https://google.com/+MarkDavis>
>
> *— Il meglio è l’inimico del bene —*
>
>
> On Tue, Jul 15, 2014 at 6:52 AM, Steven R. Loomis <srl at icu-project.org>
> wrote:
>
> If anything should be in en and not root.
>
> Wonder if it could go into seed/en or something.
>
> It's not in en right now because of translation burden. But I'd think we
> could set controls via coverage.
>
> En.xml is hand curated now, that would be another distinction.
>
> Steven
>
> Enviado desde nuestro iPhone.
>
> El jul 14, 2014, a las 9:47 PM, Martin Hosken <martin_hosken at sil.org>
> escribió:
>
> Dear All,
>
> I notice that en.xml only contains localeDisplayNames/languages/language
> entries for a subset of iso639-3. Is there a case for filling out the list
> based on iso639-3 reference names so that people don't have to fallback to
> data not in the CLDR? Or, given iso639 has these reference names, is there
> a case for putting them into the root. I realise it's a bit odd to put what
> amounts to English names into root.xml. OTOH these are the official
> reference names and so act as fallback for all languages, so perhaps it
> would be appropriate. I'm happy either way. But I think CLDR would benefit
> from having the complete reference name mapping of iso639-3 in it.
>
> Yours,
> Martin
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
>
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
>
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
> _______________________________________________
> CLDR-Users mailing list
> CLDR-Users at unicode.org
> http://unicode.org/mailman/listinfo/cldr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20140715/f545cefa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image001.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://unicode.org/pipermail/cldr-users/attachments/20140715/f545cefa/attachment.gif>