Hi Alex, Comments inline.
Cheers, Norbert On Jan 23, 2012, at 17:14 , Alex Sexton wrote: > A few questions inline. I'd love to continue to improve Jed to the point > where it can handle the problems that you've outlined. > > On Mon, Jan 23, 2012 at 6:57 PM, Norbert Lindenberg > <[email protected]> wrote: > Well, Jed does a little more than you give it credit for, but there's still > no real overlap. > > Jed provides the following functionality: > - an incomplete implementation of resource loading (no language negotiation, > no I/O, only dictionary lookup), > > I thought this should be a separate library, much like it looks like you guys > punted on adding this in directly, as it varies greatly between the client > and the server and different library environments. I might recommend Jed > Schmidt's (yes, _the_ Jed) "locale" project: https://github.com/jed/locale Yep, we punted, for the reason you state. The "incomplete" is primarily in comparison to gettext, which is referenced on the Jed home page, and which does provide complete resource loading. I'd probably cut any reference to gettext and resource loading from this library and focus on the message formatting part. Although, then you'd be competing directly with Google's MessageFormat: http://code.google.com/p/closure-library/source/browse/trunk/closure/goog/i18n/messageformat.js > - an incomplete implementation of plural handling (it interprets plural > rules, but doesn't include any localized rules), > > Perhaps I'm unfamiliar with this problem, can you give an example of > something it can't handle? (like different pluralizations based on different > genders and things?) I'd love to add full support for this, going forward. Jed seems to expect that application developers look up the plural rules ("plural_forms") for the languages they care about, stick them somewhere in their applications, and pass them to Jed. Why don't you as the author look up the rules and integrate them into the library? You could get rid of all the parsing code, which is about half the library, and instead provide a small set of functions implementing the different rules, similar to lines 265-267 of tests.js, and a function mapping from language tags to the corresponding plural rule function. The number of different rules seems to be under 20. If you think maintaining these functions and the mapping table manually is too hard, you can use your existing code at build time to generate them. > - a non-internationalized implementation of number formatting (even standard > sprintf would at least have a localized decimal separator), > > I am using the most well-vetted sprintf implementation that I could get my > hands on: http://www.diveintojavascript.com/projects/javascript-sprintf - it > is a little bit lacking, I agree. I'd love to avoid writing my own sprintf > implementation, but have it on my backlog to do (specifically for localized > decimal separators). Do you know of a better sprintf alternative in JS? I like MessageFormat patterns and the additional functionality in NumberFormat: grouping separators, currency and percent formats, currency symbols, and non-Western digits. But if you and your users prefer sprintf syntax with its limitations, can you contribute localized decimal separators to the one on diveintojavascript? Writing your own implementation just to add one feature really seems overkill... > - a partially internationalized implementation of message construction (using > the incomplete plural handling and non-internationalized number formatting, > omitting gender handling) > > This is probably heavily reliant on me understanding the first point about > incomplete plural handling. So I'll dodge it for now. The new part here is gender handling, as in: - [Robert|Sophie|Robert and Alice|Sophie and Alice] went to Paris. - Robert est allé à Paris. Sophie est allée à Paris. Robert et Alice sont allés à Paris. Sophie et Alice sont allées à Paris. Here's a good overview of what message construction looks like nowadays: https://docs.google.com/present/view?id=ddsrrpj5_68gkkvv6hs > The current Globalization API, for comparison: > - omits resource loading because it would require some I/O facility, which > ECMAScript doesn't have, > - omits message construction with plural and gender handling because the team > couldn't agree on one solution, > - provides fully internationalized number formatting. > - also provides collation and date and time formatting, which Jed doesn't > address. > > There are other JavaScript internationalization libraries though that have > functionality overlapping with the Globalization API: > - Number formatting: Closure .i18n.numberformat; Dojo .currency, .number; > jQuery Globalize > - Date and time formatting: Closure .i18n.datetimeformat; Dojo .date;; jQuery > Globalize; YUI .DataType.Date; > - Collation: none to my knowledge. > > Jed does overlap with the quasi proposal for Harmony - they both do message > construction, which needs internationalization. The quasi proposal has some > ideas for that, but they don't seem fully thought through, and don't > integrate with the Globalization API. > > Norbert _______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
