en_GB.xml Gregorian Date Formats

George S. via CLDR-Users cldr-users at unicode.org
Wed Mar 14 16:47:43 CDT 2018


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 <mailto: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 <mailto: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 <tel:%28303%29%20438-9585>
>>>     http://www.mhsoftware.com <http://www.mhsoftware.com/>
>>>     _______________________________________________
>>>     CLDR-Users mailing list
>>>     CLDR-Users at unicode.org <mailto:CLDR-Users at unicode.org>
>>>     http://unicode.org/mailman/listinfo/cldr-users
>>>     <http://unicode.org/mailman/listinfo/cldr-users>
>>
>
>     -- 
>     George S.
>     *MH Software, Inc.*
>     Voice: 303 438 9585 <tel:%28303%29%20438-9585>
>     http://www.mhsoftware.com
>
>     _______________________________________________
>     CLDR-Users mailing list
>     CLDR-Users at unicode.org <mailto:CLDR-Users at unicode.org>
>     http://unicode.org/mailman/listinfo/cldr-users
>     <http://unicode.org/mailman/listinfo/cldr-users>
>
>

-- 
George S.
*MH Software, Inc.*
Voice: 303 438 9585
http://www.mhsoftware.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://unicode.org/pipermail/cldr-users/attachments/20180314/4cefc92a/attachment-0001.html>


More information about the CLDR-Users mailing list