Proposal to add Resource and Bundle APIs to the Core Lib

[jasnell]

See: https://gist.github.com/jasnell/1ee1e23a30875683dca2

This is very early in the design and there are many issues to work out still, but the proposal is to introduce locale-aware Resource loading to the core lib.

var Resource = require('resource');
Resource.load('fr-CA', 'templates/template1-jade', function(err, template) {
  // do something with template
});

Bundle would be a thin layer over resource to introduce message bundle capability...

{
  "greeting": "hello %s"
}

var Bundle = require('resource').Bundle;
Bundle.load('en-US', function(err, bundle) {
  console.log(bundle.format('greeting', 'world'));
});

See the gist for more detail.

This is related to #9174: Globalization of Node Error Messages. That issue seeks to externalize Node's own internal messages so that node can be translated. Within the core js api, the bundle api used to externalize node's message ought to be identical to that used by module developers (i.e. the Bundle object in the example above).

[piscisaureus]

Why does this need to be a core module?
Is there anything missing from core that makes it impossible to implement it in userland?

[tinganho]

@jasnell I think if you want a robust localization solution, you can't use the identifiers %s as a solution, they will not get you any far. Because you can't for instance handle pluralization.

I wrote the i18n tool http://l10ns.org. May I suggest using ICU'smessageformat instead?

I'm just curios why you guys want such a high-level API built-in to core? This is more than getting the JS runtime running?

[jasnell]

@piscisaureus and @tinganho ... This was born out of the need to localize node itself. Node's own error messages and outputs are currently not localized at all, which is a bit of a challenge for many of our international users. Because the solution we pick for that needs to work both in the native source as well as the javascript core lib source, it makes sense to go with a basic approach that will also work for module developers. We're also working with folks on the client side (jQuery in particular) as well as representatives of the Ecma-402 and Unicode community to make sure that if anything is done here, we're doing it in a way that is consistent end-to-end.

That said, please consider this as much a Should we do this discussion as it is a How do we do this. We'll need to get Node globalized in either case, but whether we expose anything new via the core lib is a separate question.

[caridy]

/cc @ericf

[caridy]

@jasnell I understand the part were we want to have nice error messages (just like chrome does it for users in different regions).

I believe we should solve this internally first (for core messages), using standard equipment (ECMA-402 + and related standards), and if we think this is something people will want to use in their own code for error reporting, and probably beyond that, we can eventually provide access to those internals, but I will be very worry if we try to solve that bigger problem where we are still in a very early stage on the work we are doing on the loader, which related to this as well.

We can work with @srl295, @tinganho and the others to formalize a proposal for the internal use of ICU messages, which is part of the work we are lining up to introduce ICU messages in ECMA-402 (profills are available today in intl-messageformat package).

[piscisaureus]

That said, please consider this as much a Should we do this discussion as it is a How do we do this.

My suggestion would be to keep it as simple as possible. Providing a prescriptive framework for doing (not so) common things conflicts with our desire to solve most problems in module land and keep the core small.

We'll need to get Node globalized in either case, but whether we expose anything new via the core lib is a separate question.

I'm not against that, but I would suggest starting with imagining the end result and not the way to get there.

Node doesn't print so many messages (node --help, errors, "warning: possible eventemitter leak detected").

For node --help I can imagine how localization might be helpful.

For error messages, it's really a mixed bag. I'm Dutch and I've used localized software a lot. Error messages can be puzzling sometimes, but localized error messages tend to be much worse!
That's because it's not always clear how certain concepts translate. Try to translate "warning: possible eventemitter memory leak detected" to german or chinese. To make it worse, localizing error messages makes it impossible to google them, search stack overflow, or ask for help. So in this particular case I would suggest that, if we localize error messages at all, we'd print both the localized and the English message.

But first of all, localization should begin with text that's intended to be read: the docs.
That's a lot more work but not so much a technical problem.

[jzaefferer]

We're also working with folks on the client side (jQuery in particular)

What are you referring to? Both @rxaviers and me, who work on Globalize, haven't talked to you or anyone related about this.

[caridy]

@piscisaureus is right

I think the argument of getting help when an error happen is very real. I did a quick search, I could not find too many people asking for help with errors in "spanish" (my native language) in chrome console, things like:

[rxaviers]

makes it impossible to google them

I agree with @piscisaureus and @caridy.

[jzaefferer]

if we localize error messages at all, we'd print both the localized and the English message.

That seems reasonable.

[tinganho]

But first of all, localization should begin with text that's intended to be read: the docs.

I just want to share my experience with having localized docs. Firstly—I have been working in Sweden and China. In Sweden there is barely any benefit of using any non-English docs. Because there are barely any docs written in Swedish anyway.

In comparison with Asian countries—I was amazed of how many localized docs there are in Chinese and especially in node—since I work with it daily. And I have been heard from friends that the same thing applies to other Asian countries like Japan and South Korea. This is happening because many people can't speak English. I have been talking with many Chinese developers and there entry into the programming world is to read localized docs in Chinese(I have meet a friend who started a startup about doing tutorials in Chinese for iOS programming). But the side effect of this is that they live in their own bubble. They are far behind American/European counterparts, because they are not following what's happening in the global programming community. As an result of that—hiring managers recognizes this problem and they don't hire programmers who are (very) bad at English. My point is localizing docs is sometimes (or often) not good, because it create bubbles and fragments the community. I think it's far better to push them to learn the universal language for programming languages—English.

And those who are bad at English and still do programming, they barely even know the meaning of their naming of methods and variables, though they know the logic behind everything—like what each keywords does etc. Maybe I'm a little bit too harsh, but I think they should study more English before they do programming.

I'm not sure if seeing an all non-English library is good for the Javascript community either like this one: https://github.com/yanhaijing/data.js/tree/master/doc. And I believe it's trend going on, because I've seen more and more all non-English library appear. Just searching for the Chinese word "use" in NPM yields 1768 results https://www.npmjs.com/search?q=用.

[jasnell]

@jzaefferer I work closely with Andy Smith (our rep on the jquery board) and have had a number of conversations with Dave Methvin (several this week in fact). Both have said the same thing: talk to @jzaefferer and @rxaviers as soon as possible. Once I'm back from the conference this week the plan was to reach out and talk to both of you... up until now I just hadn't had the time. I'd love to get more of your input on the direction here.

I definitely like the idea of printing both versions of the messages. I'd have to play with that a bit, particularly with the node --help output, but it's a great idea.