Breaking changes to data file names

[John Emmons]

That's what I was thinking, Steven ( i.e. just symlink to the real file 
name ).


Regards,

John C. Emmons
Globalization Architect & Unicode CLDR TC Chairman
IBM Software Group
Internet: emmo at us.ibm.com




From:   Steven R Loomis/Cupertino/IBM at IBMUS
To:     "Doug Ewell" <doug at ewellic.org>
Cc:     cldr-users at unicode.org
Date:   03/19/2015 11:12 AM
Subject:        Re: Breaking changes to data file names
Sent by:        "CLDR-Users" <cldr-users-bounces at unicode.org>



they are intended to be permanent as per 
http://unicode.org/cldr/trac/ticket/8031 

But this is a good point - https://www.rfc-editor.org/rfc/rfc6067.txt and 
http://www.rfc-editor.org/rfc/rfc6497.txt

Perhaps core.zip could be a redirect (or symlink ) to the actual file? 

-s


"CLDR-Users" <cldr-users-bounces at unicode.org> wrote on 03/19/2015 08:53:19 
AM:

> From: "Doug Ewell" <doug at ewellic.org>
> To: cldr-users at unicode.org
> Date: 03/19/2015 08:57 AM
> Subject: Breaking changes to data file names
> Sent by: "CLDR-Users" <cldr-users-bounces at unicode.org>
> 
> The data files at http://www.unicode.org/Public/cldr/27/ are named:
> 
> cldr-common-27.0.zip
> cldr-keyboards-27.0.zip
> cldr-tools-27.0.zip
> 
> Is this a permanent change in the naming scheme, or a development
> artifact that leaked out by accident?
> 
> If it's permanent, then it breaks the statements in RFCs 6067 (sections
> 2.1 and 2.2) and 6497 (sections 2.4 and 2.9) that BCP 47 extension data
> is located in core.zip. At least the registration records in
> language-tag-extensions-registry, and probably the RFCs themselves, will
> have to be updated promptly.
> 
> --
> Doug Ewell | http://ewellic.org | Thornton, CO ����
> 
> 
> _______________________________________________
> 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/20150319/cdd3f6c3/attachment-0001.html>