Globalize

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

https://github.com/strongloop/strong-deploy/pull/54#discussion_r48563276 is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re: https://github.com/strongloop/strong-deploy/pull/54#discussion_r48567703

space is allowed in keys in json (any string is):

// fr/messages.json

{
    "hello, {person}, I am a string!": "bonjour, {person}, je suis un string!",
}

which could be used like: glb.log("hello, {person}, I am a string!", {person: "Tetsuo"});

I'm not sure how difficult to achieve this would be, but I'd like you to consider it more carefully. Strengths are:

1. our source code is readable (as opposed to the current APIs in globalize, which make the log messages unreadable without a cumbersome lookup by a human of a key in a json file)
2. unreadable source is error-prone source
3. it facilitates automated detection of strings, calls to glb.log() (for example) in dev mode can write properties that are not already added into the messages dictionary into it, providing a clue that there is a new or changed message string

There might be some down sides.

What do other users of the globalize package do? Have you done some checking for blogs/design advice?

My experience may be biased by GNU gettext, in that I've worked on code that uses GNU internationalization, and other than seeing _(....)_ wrapped around strings, I didn't even notice the internationalization.

I may be biased, but translators are not going to see our source, we have to maintain and debug it all the time, we need to put effort into making it easier for us. Also, if its hard for us, we'll get it wrong, and then the best translatio won't help, because we will have bugs in our source.

[Setogit]

Thanks for elaborating it, Sam. I agree. The space characters in object keys is already supported in the latest PR of strong-globalize. So, we should be able to do: glb.log("hello, {person}, I am a string!", {person: "Tetsuo"}); today.

There are two known issues beyond that. Apparently, this is still wilderness to people in Node.js globalization community.

One is that GPB stumbles on a space character in object keys; will discuss with them in early January along with other JSON spec issues in GPB.

The other is https://github.com/rxaviers/cldrjs/issues/35: pathNormalize is not JSON compatible

Without GPB ('en' only) and with my local fix to the #35 issue, glb.log("hello, {person}, I am a string!", {person: "Tetsuo"}); does work with our strong-globalize, i confirmed.

[sam-github]

Looking pretty good, @Setogit, I think I found some issues, and also it looks like a glb.Error() wrapper would be useful to you.

What do you think about my positional arg suggestion?

Also, did you see http://jaysoo.ca/2014/03/20/i18n-with-es6-template-strings/ ?

It looks close to what we are doing, and has some interesting ideas. It appears to be an almost complete replacement for globalize() in a couple pages of javascript, so I must be missing something.

[sam-github]

@rmg @kraman PTAL

This is an example of what our code will look like once globalized. More than an example, this is the globalized strong-deploy.

Looks pretty good to me, minimally intrusive.

See https://github.com/strongloop/strong-globalize/blob/refactor-a/README.md for more information on the toolset.

Also, note that once the code is converted to use glb.*(), that there is a code scanner utility in strong-globalize to extract the messages, so the message JSON does not need manual maintenance.

[rmg]

I expected strong-globalize to provide an API for operating on Strings, not replicate/wrap all the existing API's that current use Strings..

var t = require('strong-globalize').translate;
var f = require('strong-globalize').format;

console.log(t('Strings for life!'));
console.error(f('%j: %s', new Date(), process.argv[2]));

[Setogit]

Also, all the followings work too:

var g = require('strong-globalize');

console.log(g.t('Strings for life!'));
g.log('Strings for life!');
console.error(g.t('%j: %s', new Date(), process.argv[2]));
console.error(g.t('%j: %s', g.d(new Date()), process.argv[2]));
console.error(g.t('%s: %s', g.d(new Date()), process.argv[2]));
g.error('%j: %s', new Date(), process.argv[2]);
g.error('%j: %s', g.d(new Date()), process.argv[2]);
g.error('%s: %s', g.d(new Date()), process.argv[2]);

Now that i've dog-fooded and globalized strong-deploy, strong-pm, strong-build, strong-mesh-models, strong-service-install and cli.js of strong-arc, i personally like the following because the key strokes i hit is least (and, it was even fun particularly because messages.json is auto-created and machine-translated to 9 languages (Russian is coming soon) in seconds). I don't mind writing code like this from the beginning:

var g = require('strong-globalize');

g.log('Strings for life!');
g.error('%s: %s', g.d(new Date()), process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[Setogit]

This requires https://github.com/strongloop/strong-globalize/pull/5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

LGTM, but we can't merge until strong-globalize is published.