en_GB.xml Gregorian Date Formats

Fri Mar 16 22:16:30 CDT 2018

Martin,

Re#2

Would jenkins or Travis CI be able to take the language name from the newly
submitted locale file and create a "pull request" with the necessary data
to be added to the English or French locale file?

- Hugh Paterson III

On Fri, Mar 16, 2018 at 7:44 PM, Martin Hosken via CLDR-Users <
cldr-users at unicode.org> wrote:

> 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
> > >>
> > >
>
> _______________________________________________
> 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/43a3d173/attachment-0001.html>