en_GB.xml Gregorian Date Formats

[Philippe Verdy via CLDR-Users]

The "non-localisable" argument is clearly untrue.

"Localisable" does NOT mean "translatable", it means that a locale can have
specialized data, and in this case, the parent locale of each locale is a
localisation data for that locale, even if iits data not text meant to be
read and translated by humans, but a technical code. The same applied to
localisable number formats which contain almost only technical data not
meant to be read by humans directly, but automatically processed by
computers.

So I'm also in favor of deprecating the old supplemental file and integrate
what it currently contains directly within the data of each relevant child
locale: this will be clearer, and immediately usable by all CLDR-using
applications and libraries, with also less maintenance (which is complex to
do in a separate global files containining long lits of codes (possibly
forgetting some, not coherent with BCP 47 fallback mechanisms, and in fact
unnecessarily long to process when applications just need ONE parent locale
which is specific to each locale, without processing **all** the
supplemental data file to locate if a locale has some parent).

The current format also easily allows specifying the same child language
multiple times with different parent selectors. This is bad because this
should never occur (even if you have some quality check tool to detect such
situation). All applications will need to process this supplemental file to
reverse the mappings that are listed. This is non-sense.

2018-03-15 21:35 GMT+01:00 George S. via CLDR-Users <cldr-users at unicode.org>
:

> On 3/14/2018 5:04 PM, Steven R. Loomis via CLDR-Users wrote:
>
> You're quoting from https://www.unicode.org/reports/tr35/tr35.html#Parent_
> Locales
>
> > <identity>…    <parent locale="en_001"/> …</identity>
>
> > There are many things in the locale files that are not strictly
> localizable. Here's an example:
> > <dayPeriodWidth type="narrow">
>
>  "narrow" here is a distinguishing attribute  ( see
> https://www.unicode.org/reports/tr35/tr35.html#Definitions ) and is part
> of the identity of the element content that follows.
>
> I think the point of the quote is that the "parent locale" is structural
> and not part of the identity of the specific xml file.
>
>
> I can think of few things more structural than where does this locale's
> defaults originate from. Without that identity, the child file's definition
> is incomplete. Placing the relationship data in another file in a different
> directory entirely requires novices like myself to do a tremendous amount
> of research to understand what's going on. Even though the maintainers may
> have had really excellent reasons for this structure, from the developer
> standpoint it's not sensible.
>
> If you look at the parent locales in supplemental, they are organized from
> the point of view of the parent, for setting "which locales inherit from
> en-150?"
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20180315/fc031a0b/attachment.html>