en_GB.xml Gregorian Date Formats

[Philippe Verdy via CLDR-Users]

No duplication at all: in one case there's a supplemenal file and we always
need infer reverse data.
You can do the opposite: put this data directly in the per-locale files,
and then infer the supplemental file by generating it only for
compatiblity, but most tools will never need that supplemental file which
will just be informational.
You'll avoid also a source of errors in the existing file (e.g. missing
codes in the lists, duplicate codes assigned to the same parent or to
different parents).

It will just be simpler to validate each locale separately without editing
a long line of codes in the supplemental file. If new locales are added by
teams, no need to synchronize your work a team can update one locale and
another update and validate another one. No one needs to touch this
supplemtal file which will just be automatically infered after collecting
the dataset for all locales to publish.
But tools will no longer need this file (they will not need it at all if
the parent locale is already found and specified in per-locale files).

No need to parse all the content of the supplemental file (which is
compeltely unusable without parsing it completely and reversing the
mapping). This supplkemetnal file does not work like normal BCP47 fallback
resolution mechanism, it works in the incorrect direction.

So yes : deprecate it, make it only informational but no longer required.
Inform that in some future future versions (e.g. 5 years after notice) it
will be completely removed. No applicationat all really need it!


2018-03-17 0:14 GMT+01:00 Steven R. Loomis <srl at icu-project.org>:

>
> El El jue, mar. 15, 2018 a las 2:33 p. m., Philippe Verdy via CLDR-Users <
> cldr-users at unicode.org> escribió:
>
>>
>> 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).
>>
>
> This means duplicating data, which makes maintenance more complicated for
> no real benefit, as well as breaking existing consumers. As I wrote, there
> are tools which already generate fully resolved locale data with all the
> inheritance filled in. Perhaps that would be of more interest in
> consumption than the unresolved source data.
>
>
>
>> 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?"
>>>
>>> _______________________________________________
>> 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/20180317/d83a0b0b/attachment.html>