Fix locale generation and update locales

[tbosch]

After updating the google closure library locales, the locale generation fails.
The locale files then contain a reference to goog.i18n.pluralRules.get_vf_ in the pluralCat property.

Update locale files:

• i18n/update-closure.sh
• i18n/generate.sh

Note: Right now no unit test if failing because of this, only jshint complains about it! We should really add unit tests for the locales as well (maybe in the i18n subfolder?).

Idea for solving this:

• add the function goog.i18n.pluralRules.get_vf_ to every locale file, and also the functions that this function is using.
• when we have a nice way for doing this, also apply this to https://github.com/angular/angular.js/blob/master/i18n/src/closureI18nExtractor.js#L90 where we replace a closure object with a custom object that we manually insert at https://github.com/angular/angular.js/blob/master/i18n/src/closureI18nExtractor.js#L164
• also extend the unit tests for closureI18nExtractor.js when this is implemented.

[tbosch]

This is needed so that we get the current locales from closure into Angular and are able to fix #6164 correctly.

[evankroske]

I can't reproduce the problem. Both commands appear to complete successfully. Could you verify that this is still an issue?

[tbosch]

Yes, still a problem:

1. run the scripts above
2. search for get_vf_ in src/ngLocale directory.

[evankroske]

I see two approaches to fixing this problem:

1. Continue parsing Closure locale implementation: replace get_vf_ with an equivalent function literal.
2. Generate locale data from CLDR instead: write script to parse CLDR files (XML) and generate Angular locale files.

Option 1 would be quicker, but I think option 2 would be cleaner. The parser is already pretty hairy, and it's only going to get worse. CLDR was designed to be parsed, but Closure's locale implementation was not.

What do you think? Should we discuss this on the mailing list?

[tbosch]

I don't know CLDR do much, but it could be worth a try.

@Iminar: What do you think?

On Mon, Apr 28, 2014 at 9:42 PM, Evan Kroske [email protected]:

I see two approaches to fixing this problem:

1. Continue parsing Closure locale implementation: replace get_vf_
   with an equivalent function literal.
2. Generate locale data from CLDR http://cldr.unicode.org/ instead:
   write script to parse CLDR files (XML) and generate Angular locale files.

Option 1 would be quicker, but I think option 2 would be cleaner. The
parser is already pretty hairyhttps://github.com/angular/angular.js/blob/master/i18n/src/closureI18nExtractor.js#L129,
and it's only going to get worse. CLDR was designed to be parsed, but
Closure's locale implementation was not.

What do you think? Should we discuss this on the mailing list?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/6179#issuecomment-41641143
.

[tbosch]

@IgorMinar FYI

[tbosch]

How to convert CLDR into JSON: http://cldr.unicode.org/index/cldr-spec/json
The output of this should be very easy to use...

[tbosch]

Ah, CLDR is now available as JSON as well: http://cldr.unicode.org/index/json-format-data

[tbosch]

@caitp FYI

[caitp]

So, the trouble with the (full) JSON data is that it's huuuuge --- 50mb for the zipped package, which could make releases take generally forever if it's automated. There is a much smaller collection of JSON data, however it doesn't contain all of the locales supported by closure-library, so I'm hesitant to use it.

The XML version is a lot tinier than the (full) JSON data, and there are already tools written in node to process the XML, so I think it should be possible to put together a workable solution for generating this stuff for release --- although it's considerably much less effort to just continue using Closure's stuff.

[evankroske]

I think that we should use node-cldr to generate the locale data. I wrote a script to compare the data generated from node-cldr to what we have today: #7702 I think that the differences are caused by the fact that node-cldr is using newer version of CLDR.

[caitp]

@evankroske that's actually what I've been working on over the past couple days, heh. we're doing this.

(node-cldr seems to agree with me that having the fully processed json in the tree is a waste of diskspace, the xml is much tinier)