en_GB.xml Gregorian Date Formats

Fri Mar 16 18:11:09 CDT 2018

El El jue, mar. 15, 2018 a las 1:35 p. m., George S. via CLDR-Users <
cldr-users at unicode.org> escribió:

> 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
>
> ...
> 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.
>

The design goal has always been for simplifying maintainance of the
repository, and stability for the consumers (including yourself) over ease
or simplicity of implementation.

That said, perhaps a *comment* could be generated in this specific case,
based on the parentLocale data, when the CLDRFile is written out.  If this
is a common concern, a comment might make it easier for readers.

>
> 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?"
>
>
> As a developer, that uses LDML files, I can absolutely guarantee you that
> I will NEVER ask that question. en-150 is a synthetic thing you folks
> created to organize data. It's just not related to my workflow. en-GB is my
> workflow. As a maintainer of the data, perhaps that's useful for you.
>

This exactly - it is designed for maintaining the data, and it is a lot of
data.  So how can we improve things, given these different design goals?
  And anyway, en-GB.xml shouldn’t be your workflow, it should be the fully
resolved contents plus all metadata.   We have tools to generate a fully
resolved XML file, would that be of interest?

>
>
> Parsing the supplementalData is critical to processing CLDR data.
>
>
> That's true because of design decisions that were made by the maintainers.
> It's not the only possible solution, and I don't think from the consumer
> (developer) standpoint, it's even remotely the best. But, these are my
> opinions and are generally uninformed and only accurate from my point of
> view.
>

JSON data for example is pre-resolved.  Perhaps there should be another
layer  in between the maintenance and the consumption of the data?  CLDR
has various converters to different formats.

I don’t see how changing the inheritance structure would be a net benefit-
it would break all existing consumers of the data (of which there are
many). Surely there is a better solution?

The CLDR Java tooling is available in the source repository, it could be a
> source of comparison for file handling.
>
> Steven
>
>
> <parentLocales>
> <parentLocale parent="root" locales="az_Arab az_Cyrl bm_Nkoo bs_Cyrl
> en_Dsrt en_Shaw ha_Arab iu_Latn mn_Mong ms_Arab pa_Arab shi_Latn sr_Latn
> uz_Arab uz_Cyrl vai_Latn zh_Hant yue_Hans"/>
> <parentLocale parent="en_001" locales="en_150 en_AG en_AI en_AU en_BB
> en_BE en_BM en_BS en_BW en_BZ en_CA en_CC en_CK en_CM en_CX en_CY en_DG
> en_DM en_ER en_FJ en_FK en_FM en_GB en_GD en_GG en_GH en_GI en_GM en_GY
> en_HK en_IE en_IL en_IM en_IN en_IO en_JE en_JM en_KE en_KI en_KN en_KY
> en_LC en_LR en_LS en_MG en_MO en_MS en_MT en_MU en_MW en_MY en_NA en_NF
> en_NG en_NR en_NU en_NZ en_PG en_PH en_PK en_PN en_PW en_RW en_SB en_SC
> en_SD en_SG en_SH en_SL en_SS en_SX en_SZ en_TC en_TK en_TO en_TT en_TV
> en_TZ en_UG en_VC en_VG en_VU en_WS en_ZA en_ZM en_ZW"/>
> <parentLocale parent="en_150" locales="en_AT en_CH en_DE en_DK en_FI en_NL
> en_SE en_SI"/>
> <parentLocale parent="es_419" locales="es_AR es_BO es_BR es_BZ es_CL es_CO
> es_CR es_CU es_DO es_EC es_GT es_HN es_MX es_NI es_PA es_PE es_PR es_PY
> es_SV es_US es_UY es_VE"/>
> <parentLocale parent="pt_PT" locales="pt_AO pt_CH pt_CV pt_GQ pt_GW pt_LU
> pt_MO pt_MZ pt_ST pt_TL"/>
> <parentLocale parent="zh_Hant_HK" locales="zh_Hant_MO"/>
> </parentLocales>
>
>
> On Wed, Mar 14, 2018 at 2:47 PM, George S. via CLDR-Users <
> cldr-users at unicode.org> wrote:
>
>> Personally, I find the reasoning to be circular:
>>
>> "Since parentLocale information is not localizable on a per locale basis,
>> the parentLocale information is contained in CLDR’s supplemental data."
>> <http://unicode.org/reports/tr35/tr35-info.html>
>> There are many things in the locale files that are not strictly
>> localizable. Here's an example:
>>
>> <dayPeriodWidth type="narrow">
>>
>> saying you're not going to put the parent locale in because it's not
>> localizable is kind of silly when you have lot's of data in the file that's
>> not localizable.
>>
>> I'm suggesting:
>>
>> <identity>
>>     <version number="$Revision: 13722 $"/>
>>     <language type="en"/>
>>     <territory type="GB"/>
>>     <parent locale="en_001"/></identity>
>>
>> But it's your guys' project.
>>
>>
>> On 3/14/2018 3:26 PM, Steven R. Loomis wrote:
>>
>> George,
>> > It would be nice if the en_GB.xml file referenced it's parent
>>
>> I appreciate the idea, however, the XML files are not designed to
>> be looked at in isolation. That's why we put this notice at the top:
>>
>> " CLDR data files are interpreted according to the LDML specification (
>> http://unicode.org/reports/tr35/) "
>>
>> Is there a better way to word this?
>>
>> Please also see the Implementer's guide and FAQ at
>> https://github.com/unicode-org/cldr-implementers-guide/  - if you think
>> this would be a good FAQ can you open an issue, or better yet a pull
>> request there?
>>
>>
>> On Wed, Mar 14, 2018 at 1:57 PM, George S. via CLDR-Users <
>> cldr-users at unicode.org> wrote:
>>
>>> Thanks for responding. I knew I'd gone down this road before. Drat.
>>>
>>> I'll make the same comment I made three years ago:
>>>
>>> It would be nice if the en_GB.xml file referenced it's parent so that
>>> mortals might have some idea of where to look. Having the relationship
>>> squirreled away in a file in another directory with a non-obvious name
>>> isn't very handy.
>>>
>>>
>>>
>>> On 3/14/2018 2:38 PM, Peter Edberg wrote:
>>>
>>> en_GB inherits from en_001, not from en.
>>>
>>> - Peter E
>>>
>>> On Mar 14, 2018, at 12:48 PM, George S. via CLDR-Users <
>>> cldr-users at unicode.org> wrote:
>>>
>>> I'm looking at the file comm/main/en_GB.xml and I'm really confused. I'm
>>> looking at the Gregorian calendar section, and there's no
>>>
>>> dateFormats / dateFormatLength=short
>>>
>>> the value in en.xml is
>>>
>>> M/d/yy
>>>
>>> If I look at en_AU.xml there is an entry with a value of "d/M/yy".
>>>
>>> Similarly, en_IE.xml there is no short dateFormatLength value.
>>>
>>> Can anyone help me understand how this all works? I'm using a library
>>> that generates it's localization files from LDML, and it's coming up with a
>>> lot of wrong answers. Before I go to them, I'd like to understand why
>>> things are formatted in this way.
>>>
>>>
>>> --
>>> George S.
>>> *MH Software, Inc.*
>>> Voice: 303 438 9585 <%28303%29%20438-9585>
>>> http://www.mhsoftware.com
>>> _______________________________________________
>>> CLDR-Users mailing list
>>> CLDR-Users at unicode.org
>>> http://unicode.org/mailman/listinfo/cldr-users
>>>
>>>
>>>
>>> --
>>> George S.
>>> *MH Software, Inc.*
>>> Voice: 303 438 9585 <%28303%29%20438-9585>
>>> http://www.mhsoftware.com
>>>
>>> _______________________________________________
>>> CLDR-Users mailing list
>>> CLDR-Users at unicode.org
>>> http://unicode.org/mailman/listinfo/cldr-users
>>>
>>>
>>
>> --
>> George S.
>> *MH Software, Inc.*
>> Voice: 303 438 9585 <%28303%29%20438-9585>
>> http://www.mhsoftware.com
>>
>> _______________________________________________
>> CLDR-Users mailing list
>> CLDR-Users at unicode.org
>> http://unicode.org/mailman/listinfo/cldr-users
>>
>>
>
>
> _______________________________________________
> CLDR-Users mailing listCLDR-Users at unicode.orghttp://unicode.org/mailman/listinfo/cldr-users
>
>
> --
> George S.
> *MH Software, Inc.*
> Voice: 303 438 9585
> http://www.mhsoftware.com
> _______________________________________________
> 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/7a62c83a/attachment-0001.html>