Oh, and one more point: you can use ilib's assembly tool to generate browser-friendly ilib files that do not need browserify to run. This also allows you to pick-and-choose which ilib classes your code needs and it automatically pulls in not only its code dependencies, but also its data dependencies.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi Sylvain, yes CLDR 28 was next on the agenda for ilib 13.
In 11.0 and earlier, we had an odd situation where part of the data was on 22.1 and part was on 26. So for consistency and to update all the conversion tools, we were first bringing everything up to CLDR 26 and UCD 8.0. That is the effort currently under way for ilib 12.X. (almost done). Then, when everything is consistent, we are going to update again to CLDR 28 in ilib 13.X.
BTW, the cldr data cannot be used as-is with ilib. There are a number of problems:
it has a different philosophy behind it than CLDR. In ilib, as much preprocessing is done as possible, but not in CLDR. For example, in ilib, there are fully-fleshed out formats for dates for each of the reasonable combinations of date components (day, month, year, weekday, etc.) and time components (hour, minute, second, millisecond, meridiem (am/pm), time zone). In CLDR, there is not. So, the ilib tools use the CLDR data as a basis to generate all of these formats and the results get saved into the dateformats.json files. If we used the cldr data directly from npm, all of that processing would have to be done on the fly each time you instantiate the DateFmt class. We can prevent doing the same thing over and over again if the results are saved. Using ilib's own data also has the advantage that the data are the same whether you are running on a browser, node, Qt, or rhino.
Ilib separates the language-, script-, and region-specific properties from each other so that you can mix and match locales as needed. CLDR does not. (eg. ilib can support "English for Egypt" or "Tamil for USA" whereas CLDR does not.)
ilib has different locale inheritance rules than CLDR. This is related to #2 as well.
CLDR has all properties for a locale in a single file, which makes for a lot of data to load and parse if all you are doing is just trying to get the names of the days of the week. ilib data is separated out more. This is also related to #2 above.
ilib data is based on CLDR data, but also has data not available in CLDR. It is pre-combined with UCD data, and data from wikipedia, IANA, and the International Telecommunications Union (ITU).
The CLDR data file formats are probably more stable now, but when they first came out with json versions of the data, the json schema kept changing frequently. The ilib schema is more stable.
So, we need to do pre-processing first to convert things to ilib format.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for your reply and your work.
For your information, your site is down since November. It will be great to put demo srouce code and tutorial in SF.
Moreover, I have detected that negative format for currency is like "({n} {s})". I think that is old standard.
I supppose that the new major release will fix it to "commonNegative":"(-{n} {s})".
Finally, I have integrated Ilib with browserify using a transformation.
I can declare used languages like this:
require('ilibglobal/transform.js')(['en-EN', 'fr-FR', 'es-ES', 'de-DE', 'it-IT', 'pt-BR']);
My tranformation will convert this line to multi require to import locale .json file in my dsitribution.
Bye and thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, just found out it was down. I'm working on getting it back up again.
I am guessing only from your name that you are interested in French for France? Is that right? In CLDR 28, the accounting format for currency in fr-FR is:
"accounting": "#,##0.00 ¤;(#,##0.00 ¤)",
So that does not fix the problem. If that is not right, then it should be fixed in CLDR.
That integration with browserify sounds interesting! Would you like to share it?
Edwin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I use ilib to manage international currencies. In France the alternative format is {s}-{n}.
This kind of format is the natural way to display currency in France and many other european countries.
Concerning Browserify, I can share the code if you want. It's a little bit complicate but I didn't find other solution. Moreover with Webpack , the solution should be easier because It supports aynchronous static resources.
Tomorrow, I will send you samples of code.
In SF is it possible to create merge request?
bye and thank you for your job.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
I'm using ilib with browserify.
A new version of CLDR has been released:http://cldr.unicode.org/index/downloads/cldr-28.
Is-it possible to integrate in the next version of ilib?
To my mind, for nodejs version, you can try to use this dependency https://github.com/rxaviers/cldr-data-npm to manage CLDR data.
Thank you for your work.
Oh, and one more point: you can use ilib's assembly tool to generate browser-friendly ilib files that do not need browserify to run. This also allows you to pick-and-choose which ilib classes your code needs and it automatically pulls in not only its code dependencies, but also its data dependencies.
Hi Sylvain, yes CLDR 28 was next on the agenda for ilib 13.
In 11.0 and earlier, we had an odd situation where part of the data was on 22.1 and part was on 26. So for consistency and to update all the conversion tools, we were first bringing everything up to CLDR 26 and UCD 8.0. That is the effort currently under way for ilib 12.X. (almost done). Then, when everything is consistent, we are going to update again to CLDR 28 in ilib 13.X.
BTW, the cldr data cannot be used as-is with ilib. There are a number of problems:
So, we need to do pre-processing first to convert things to ilib format.
Thank you for your reply and your work.
For your information, your site is down since November. It will be great to put demo srouce code and tutorial in SF.
Moreover, I have detected that negative format for currency is like "({n} {s})". I think that is old standard.
I supppose that the new major release will fix it to "commonNegative":"(-{n} {s})".
Finally, I have integrated Ilib with browserify using a transformation.
I can declare used languages like this:
require('ilibglobal/transform.js')(['en-EN', 'fr-FR', 'es-ES', 'de-DE', 'it-IT', 'pt-BR']);
My tranformation will convert this line to multi require to import locale .json file in my dsitribution.
Bye and thanks.
Yes, just found out it was down. I'm working on getting it back up again.
I am guessing only from your name that you are interested in French for France? Is that right? In CLDR 28, the accounting format for currency in fr-FR is:
"accounting": "#,##0.00 ¤;(#,##0.00 ¤)",
So that does not fix the problem. If that is not right, then it should be fixed in CLDR.
That integration with browserify sounds interesting! Would you like to share it?
Edwin
I use ilib to manage international currencies. In France the alternative format is {s}-{n}.
This kind of format is the natural way to display currency in France and many other european countries.
I have understood that CLDR has evolved the norm : http://unicode.org/cldr/trac/ticket/5674.
Concerning Browserify, I can share the code if you want. It's a little bit complicate but I didn't find other solution. Moreover with Webpack , the solution should be easier because It supports aynchronous static resources.
Tomorrow, I will send you samples of code.
In SF is it possible to create merge request?
bye and thank you for your job.