en_GB.xml Gregorian Date Formats

Fri Mar 16 21:44:51 CDT 2018

Dear All,

I would like to add my support to this proposal of moving the parentLocal information back into the ldml file. When dealing with adding a new locale, it is very helpful if everything about that locale is stored in the one file and so can be edited independently and submitted as a unit rather than having to change other files in order to add a new locale. In my analysis and limited experience of working with LDML I would suggest that there are two areas where we have overlaid a solution using our namespace:

1. Parent locale

It may be convenient from an overall database perspective to have the parent child relationships stored as supplemental data, but I think this was a retrograde step and would love to see the <fallback> element reinstated. Adding a new locale then is simply a process of adding a new file rather than adding a file and editing the supplemental data and merging and managing that. Supplemental data should be supplemental not required for the interpretation / flattening of an LDML file.

I am thinking that perhaps the parentLocale was pulled out of the ldml file and into supplementalData because it was thought to be useful in language tag processing. I'm not sure that it is and as mentioned is more trouble than it is worth being there rather than back in the ldml file.

2. Language names

When adding a new locale, very often the language name or more likely the variant for that language, needs to be given for key languages like English and French. Changing these core locales is not something we want to encourage those creating emerging locales to be involved in. So instead we have added the ability to specify those strings for just the locale itself, in the locale itself. I realise that this is doing the opposite of what I said in the previous section. But it allows the new locale to be self contained. At the point the locale gets integrated, then it is a simple matter to move the information out of the new locale into the other locales where it really belongs. So this is an interim solution that again works to keep a single LDML file editable as a unit rather than seeing changes to a locale as edits to a large database of files.

I realise that philosophically to the CLDR technical team, the CLDR is just one big database and that it is the integrity and management of that database as a whole that is key. But for many language groups, their view of that database is their LDML file and they would like to have full control over information from that one file rather than needing to be given write access to globally shared files.

Yours,
Martin

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