en_GB.xml Gregorian Date Formats

[Steven R. Loomis via CLDR-Users]

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/20180316/3385173f/attachment.html>