Discuss
  • Internationalization summary 1/19 (TC39 meeting)

Internationalization summary 1/19 (TC39 meeting)

# Nebojša Ćirić (14 years ago)

Thanks to Waldemar the meeting notes related to intl work were already posted to the list. I would like to expand them, and restart discussion on couple of remaining issues.

Testing

  • We got ECMA number allocated to us (402) so we can use it for testing infrastructure and any future needs.
  • Talked to David Fugate about where to put the tests and how to run them without affecting ES5 tests.
  • Interested parties should ask for access to the test262 repository (follow these instructionstest262:submission_process ).
  • We need bugzilla entry for intl work for testing (we already have one for the draft)
  • Mr. Istvan pointed out that we may need to produce TR (one page) that points to the tests. It's not gating on our progress.

Requirements for March meeting

  • Draft ready and reviewed by TC39 members
  • Two distinct implementations and testing in place

Microsoft and Google representatives stated that they could have implementations ready by given deadline (barring large changes to the current spec). We are working on updating the draft and introductory document and should have them ready for the review soon. We started work on testing, but will need time to tell how quickly we can progress there.

General

Going back to module vs. global object discussion. General agreement was that we should pick a global name and work with that, then use modules when they are ready, but that we should wait for Brendan to pitch in before making a final decision. Most of the group was for shorter name i.e. "intl" if it doesn't introduce conflicts. The reason for this discussion was the current state of the module spec, i.e. it's not clear yet where load/loaded will reside (not everybody agrees on Object.system). In order to produce an implementation by March and have draft accepted we do need to decide rather soon on this.

Range vs. TypeError discussion. We eliminated ValueError proposal from our spec and decided to use RangeError. A "fierce" discussion followed and I think the final decision was to keep using RangeError.

# Brendan Eich (14 years ago)

Just saw this tweeted:

slexaxton.github.com/Jed

Wondered if anyone has any reactions. We have a Globalization API rushing to standardization while libraries to do some of what it does exist on github.com. It seems to me we ought to look at the latter while finalizing the former -- if not actually interact with developers using the latter more.

# Nebojša Ćirić (14 years ago)

He is unfortunately using term "internationalization" for "localization". This library only lets you handle resource loading - i.e. translated messages.

Our library deals with proper formatting and sorting (and possibly many more in the future). The actual sorting (collation) is the hard part where no native JavaScript implementation exists and with a good reason - data size and algorithm complexity would be hard to overcome.

I don't feel we are rushing anything, it's been 1.5 yrs since we started, but this is my first standard so I may be too optimistic :).

  1. јануар 2012. 13.26, Brendan Eich <brendan at mozilla.com> је написао/ла:
# Norbert Lindenberg (14 years ago)

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),
  • an incomplete implementation of plural handling (it interprets plural rules, but doesn't include any localized rules),
  • a non-internationalized implementation of number formatting (even standard sprintf would at least have a localized decimal separator),
  • a partially internationalized implementation of message construction (using the incomplete plural handling and non-internationalized number formatting, omitting gender handling)

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

# Alex Sexton (14 years ago)

I'm the author of said "Jed" library. I'd be happy to update the info on the Jed site with the correct terminology, but I was wondering why the term "internationalization" is incorrect? It's an implementation of the Gettext spec (with a few wrappers) which GNU defines as an internationalization tool (and so does wikipedia, etc, etc):

www.gnu.org/software/gettext/manual/gettext.html#Concepts

The easiest to read summary being:

"Also, very roughly said, when it comes to multi-lingual messages, internationalization is usually taken care of by programmers, and localization is usually taken care of by translators."

Jed specifically doesn't handle the loading or setting of locales, it is rather the mechanism for implementing applications in a non-language-specific manner. Gettext has proved to be useful in other languages, as it handles pluralization and positional interpolation (with sprintf's help), and it seems to work well in JavaScript.

The APIs that Jed offers on top of Gettext are just sugar (they call directly into the dcnpgettext function but they're pretty because omg chaining).

I'd love to learn more about the internationalization specs that you are working on. Is there a link to them somewhere? I'd love to bridge the gap between what you're talking about and what I've put into Jed.

Thanks! Alex Sexton

Nebojša Ćirić cira at google.com Mon Jan 23 14:19:05 PST 2012

He is unfortunately using term "internationalization" for "localization". This library only lets you handle resource loading - i.e. translated messages.

Our library deals with proper formatting and sorting (and possibly many more in the future). The actual sorting (collation) is the hard part where no native JavaScript implementation exists and with a good reason - data size and algorithm complexity would be hard to overcome.

I don't feel we are rushing anything, it's been 1.5 yrs since we started, but this is my first standard so I may be too optimistic :).

---------- Forwarded message ----------

# Alex Sexton (14 years ago)

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 < ecmascript at norbertlindenberg.com> 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: jed/locale

  • 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.

  • 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: 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?

  • 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.

# Norbert Lindenberg (14 years ago)

I'd agree that Jed is an internationalization library. Code that enables localization to me is internationalization. But the internationalization/localization/globalization community speaks a number of different dialects...

The current spec of the proposed ECMAScript Globalization API is at: globalization:specification_drafts and an easier-to-read but slightly out-of-date guide at: norbertlindenberg.com/2011/11/ecmascript-globalization-api/index.html

Norbert

# Norbert Lindenberg (14 years ago)

Following up on Nebojša's summary, I'd like to

  • Rename the namespace object of the Globalization API from "Globalization" to "Intl".
  • Then rename the API itself from "Globalization API" back to "Internationalization API".

I searched a bit and found indications that the global "Globalization" may have been used for some time by the library now known as jquery/globalize. I haven't found any evidence of "intl" or "Intl" being used in the global namespace ("Intl" is used in the YUI namespace).

Within ECMAScript it seems there's a preference for capitalized namespace names: Math, JSON, hence "Intl".

Our API was conceived as the "Internationalization API", then became the "Globalization API" to match the name of the namespace object. With "Intl", "Internationalization API" again is the better match.

Comments?

Thanks, Norbert