Globalize

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

camel case: glb

[Setogit]

changed

[sam-github]

why empty?

[Setogit]

that's one of the GPB issues. For es, fr, and pt, this string is translated to empty most likely due to the double curly braces. The issue has been reported to the GPB team.

[sam-github]

#54 (comment) is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re:
#54 (comment)

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.

[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]

In this scenario it totally makes sense, but there's something weird to me about how it completely abstracts away the file opening and reading while still clearly operating on a specified file. I would expect there to have been a path resolver wrapped around the path string instead. I imagine it to look like this:

varUSAGE=fs.readFileSync(glb.resolve('./sl-deploy.txt'),'utf-8').replace(/%MAIN%/g,$0).trim();

If the logical resource is simply a string and the fact that it is in a file is an implementation detail, then I would expect the name to be something like 'USAGE' or something.

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

vart=require('strong-globalize').translate;varf=require('strong-globalize').format;console.log(t('Strings for life!'));console.error(f('%j: %s',newDate(),process.argv[2]));

[Setogit]

Also, all the followings work too:

varg=require('strong-globalize');console.log(g.t('Strings for life!'));g.log('Strings for life!');console.error(g.t('%j: %s',newDate(),process.argv[2]));console.error(g.t('%j: %s',g.d(newDate()),process.argv[2]));console.error(g.t('%s: %s',g.d(newDate()),process.argv[2]));g.error('%j: %s',newDate(),process.argv[2]);g.error('%j: %s',g.d(newDate()),process.argv[2]);g.error('%s: %s',g.d(newDate()),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:

varg=require('strong-globalize');g.log('Strings for life!');g.error('%s: %s',g.d(newDate()),process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

name has to be protected

[Setogit]

This requires strongloop/strong-globalize#5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

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

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

camel case: glb

[Setogit]

changed

[sam-github]

why empty?

[Setogit]

that's one of the GPB issues. For es, fr, and pt, this string is translated to empty most likely due to the double curly braces. The issue has been reported to the GPB team.

[sam-github]

#54 (comment) is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re:
#54 (comment)

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.

[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]

In this scenario it totally makes sense, but there's something weird to me about how it completely abstracts away the file opening and reading while still clearly operating on a specified file. I would expect there to have been a path resolver wrapped around the path string instead. I imagine it to look like this:

varUSAGE=fs.readFileSync(glb.resolve('./sl-deploy.txt'),'utf-8').replace(/%MAIN%/g,$0).trim();

If the logical resource is simply a string and the fact that it is in a file is an implementation detail, then I would expect the name to be something like 'USAGE' or something.

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

vart=require('strong-globalize').translate;varf=require('strong-globalize').format;console.log(t('Strings for life!'));console.error(f('%j: %s',newDate(),process.argv[2]));

[Setogit]

Also, all the followings work too:

varg=require('strong-globalize');console.log(g.t('Strings for life!'));g.log('Strings for life!');console.error(g.t('%j: %s',newDate(),process.argv[2]));console.error(g.t('%j: %s',g.d(newDate()),process.argv[2]));console.error(g.t('%s: %s',g.d(newDate()),process.argv[2]));g.error('%j: %s',newDate(),process.argv[2]);g.error('%j: %s',g.d(newDate()),process.argv[2]);g.error('%s: %s',g.d(newDate()),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:

varg=require('strong-globalize');g.log('Strings for life!');g.error('%s: %s',g.d(newDate()),process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

name has to be protected

[Setogit]

This requires strongloop/strong-globalize#5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

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

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

camel case: glb

[Setogit]

changed

[sam-github]

why empty?

[Setogit]

that's one of the GPB issues. For es, fr, and pt, this string is translated to empty most likely due to the double curly braces. The issue has been reported to the GPB team.

[sam-github]

#54 (comment) is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re:
#54 (comment)

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.

[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]

In this scenario it totally makes sense, but there's something weird to me about how it completely abstracts away the file opening and reading while still clearly operating on a specified file. I would expect there to have been a path resolver wrapped around the path string instead. I imagine it to look like this:

varUSAGE=fs.readFileSync(glb.resolve('./sl-deploy.txt'),'utf-8').replace(/%MAIN%/g,$0).trim();

If the logical resource is simply a string and the fact that it is in a file is an implementation detail, then I would expect the name to be something like 'USAGE' or something.

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

vart=require('strong-globalize').translate;varf=require('strong-globalize').format;console.log(t('Strings for life!'));console.error(f('%j: %s',newDate(),process.argv[2]));

[Setogit]

Also, all the followings work too:

varg=require('strong-globalize');console.log(g.t('Strings for life!'));g.log('Strings for life!');console.error(g.t('%j: %s',newDate(),process.argv[2]));console.error(g.t('%j: %s',g.d(newDate()),process.argv[2]));console.error(g.t('%s: %s',g.d(newDate()),process.argv[2]));g.error('%j: %s',newDate(),process.argv[2]);g.error('%j: %s',g.d(newDate()),process.argv[2]);g.error('%s: %s',g.d(newDate()),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:

varg=require('strong-globalize');g.log('Strings for life!');g.error('%s: %s',g.d(newDate()),process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

name has to be protected

[Setogit]

This requires strongloop/strong-globalize#5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

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

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

camel case: glb

[Setogit]

changed

[sam-github]

why empty?

[Setogit]

that's one of the GPB issues. For es, fr, and pt, this string is translated to empty most likely due to the double curly braces. The issue has been reported to the GPB team.

[sam-github]

#54 (comment) is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re:
#54 (comment)

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.

[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]

In this scenario it totally makes sense, but there's something weird to me about how it completely abstracts away the file opening and reading while still clearly operating on a specified file. I would expect there to have been a path resolver wrapped around the path string instead. I imagine it to look like this:

varUSAGE=fs.readFileSync(glb.resolve('./sl-deploy.txt'),'utf-8').replace(/%MAIN%/g,$0).trim();

If the logical resource is simply a string and the fact that it is in a file is an implementation detail, then I would expect the name to be something like 'USAGE' or something.

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

vart=require('strong-globalize').translate;varf=require('strong-globalize').format;console.log(t('Strings for life!'));console.error(f('%j: %s',newDate(),process.argv[2]));

[Setogit]

Also, all the followings work too:

varg=require('strong-globalize');console.log(g.t('Strings for life!'));g.log('Strings for life!');console.error(g.t('%j: %s',newDate(),process.argv[2]));console.error(g.t('%j: %s',g.d(newDate()),process.argv[2]));console.error(g.t('%s: %s',g.d(newDate()),process.argv[2]));g.error('%j: %s',newDate(),process.argv[2]);g.error('%j: %s',g.d(newDate()),process.argv[2]);g.error('%s: %s',g.d(newDate()),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:

varg=require('strong-globalize');g.log('Strings for life!');g.error('%s: %s',g.d(newDate()),process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

name has to be protected

[Setogit]

This requires strongloop/strong-globalize#5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

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

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

camel case: glb

[Setogit]

changed

[sam-github]

why empty?

[Setogit]

that's one of the GPB issues. For es, fr, and pt, this string is translated to empty most likely due to the double curly braces. The issue has been reported to the GPB team.

[sam-github]

#54 (comment) is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re:
#54 (comment)

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.

[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]

In this scenario it totally makes sense, but there's something weird to me about how it completely abstracts away the file opening and reading while still clearly operating on a specified file. I would expect there to have been a path resolver wrapped around the path string instead. I imagine it to look like this:

varUSAGE=fs.readFileSync(glb.resolve('./sl-deploy.txt'),'utf-8').replace(/%MAIN%/g,$0).trim();

If the logical resource is simply a string and the fact that it is in a file is an implementation detail, then I would expect the name to be something like 'USAGE' or something.

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

vart=require('strong-globalize').translate;varf=require('strong-globalize').format;console.log(t('Strings for life!'));console.error(f('%j: %s',newDate(),process.argv[2]));

[Setogit]

Also, all the followings work too:

varg=require('strong-globalize');console.log(g.t('Strings for life!'));g.log('Strings for life!');console.error(g.t('%j: %s',newDate(),process.argv[2]));console.error(g.t('%j: %s',g.d(newDate()),process.argv[2]));console.error(g.t('%s: %s',g.d(newDate()),process.argv[2]));g.error('%j: %s',newDate(),process.argv[2]);g.error('%j: %s',g.d(newDate()),process.argv[2]);g.error('%s: %s',g.d(newDate()),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:

varg=require('strong-globalize');g.log('Strings for life!');g.error('%s: %s',g.d(newDate()),process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

name has to be protected

[Setogit]

This requires strongloop/strong-globalize#5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

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

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

camel case: glb

[Setogit]

changed

[sam-github]

why empty?

[Setogit]

that's one of the GPB issues. For es, fr, and pt, this string is translated to empty most likely due to the double curly braces. The issue has been reported to the GPB team.

[sam-github]

#54 (comment) is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re:
#54 (comment)

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.

[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]

In this scenario it totally makes sense, but there's something weird to me about how it completely abstracts away the file opening and reading while still clearly operating on a specified file. I would expect there to have been a path resolver wrapped around the path string instead. I imagine it to look like this:

varUSAGE=fs.readFileSync(glb.resolve('./sl-deploy.txt'),'utf-8').replace(/%MAIN%/g,$0).trim();

If the logical resource is simply a string and the fact that it is in a file is an implementation detail, then I would expect the name to be something like 'USAGE' or something.

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

vart=require('strong-globalize').translate;varf=require('strong-globalize').format;console.log(t('Strings for life!'));console.error(f('%j: %s',newDate(),process.argv[2]));

[Setogit]

Also, all the followings work too:

varg=require('strong-globalize');console.log(g.t('Strings for life!'));g.log('Strings for life!');console.error(g.t('%j: %s',newDate(),process.argv[2]));console.error(g.t('%j: %s',g.d(newDate()),process.argv[2]));console.error(g.t('%s: %s',g.d(newDate()),process.argv[2]));g.error('%j: %s',newDate(),process.argv[2]);g.error('%j: %s',g.d(newDate()),process.argv[2]);g.error('%s: %s',g.d(newDate()),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:

varg=require('strong-globalize');g.log('Strings for life!');g.error('%s: %s',g.d(newDate()),process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

name has to be protected

[Setogit]

This requires strongloop/strong-globalize#5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

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

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

camel case: glb

[Setogit]

changed

[sam-github]

why empty?

[Setogit]

that's one of the GPB issues. For es, fr, and pt, this string is translated to empty most likely due to the double curly braces. The issue has been reported to the GPB team.

[sam-github]

#54 (comment) is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re:
#54 (comment)

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.

[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]

In this scenario it totally makes sense, but there's something weird to me about how it completely abstracts away the file opening and reading while still clearly operating on a specified file. I would expect there to have been a path resolver wrapped around the path string instead. I imagine it to look like this:

varUSAGE=fs.readFileSync(glb.resolve('./sl-deploy.txt'),'utf-8').replace(/%MAIN%/g,$0).trim();

If the logical resource is simply a string and the fact that it is in a file is an implementation detail, then I would expect the name to be something like 'USAGE' or something.

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

vart=require('strong-globalize').translate;varf=require('strong-globalize').format;console.log(t('Strings for life!'));console.error(f('%j: %s',newDate(),process.argv[2]));

[Setogit]

Also, all the followings work too:

varg=require('strong-globalize');console.log(g.t('Strings for life!'));g.log('Strings for life!');console.error(g.t('%j: %s',newDate(),process.argv[2]));console.error(g.t('%j: %s',g.d(newDate()),process.argv[2]));console.error(g.t('%s: %s',g.d(newDate()),process.argv[2]));g.error('%j: %s',newDate(),process.argv[2]);g.error('%j: %s',g.d(newDate()),process.argv[2]);g.error('%s: %s',g.d(newDate()),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:

varg=require('strong-globalize');g.log('Strings for life!');g.error('%s: %s',g.d(newDate()),process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

name has to be protected

[Setogit]

This requires strongloop/strong-globalize#5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

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

[Setogit]

connected to strongloop-internal/scrum-nodeops#1157

[sam-github]

camel case: glb

[Setogit]

changed

[sam-github]

why empty?

[Setogit]

that's one of the GPB issues. For es, fr, and pt, this string is translated to empty most likely due to the double curly braces. The issue has been reported to the GPB team.

[sam-github]

#54 (comment) is unresolved (mentioning here because it is not displayed because of code updates)

[sam-github]

re:
#54 (comment)

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.

[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]

In this scenario it totally makes sense, but there's something weird to me about how it completely abstracts away the file opening and reading while still clearly operating on a specified file. I would expect there to have been a path resolver wrapped around the path string instead. I imagine it to look like this:

varUSAGE=fs.readFileSync(glb.resolve('./sl-deploy.txt'),'utf-8').replace(/%MAIN%/g,$0).trim();

If the logical resource is simply a string and the fact that it is in a file is an implementation detail, then I would expect the name to be something like 'USAGE' or something.

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

vart=require('strong-globalize').translate;varf=require('strong-globalize').format;console.log(t('Strings for life!'));console.error(f('%j: %s',newDate(),process.argv[2]));

[Setogit]

Also, all the followings work too:

varg=require('strong-globalize');console.log(g.t('Strings for life!'));g.log('Strings for life!');console.error(g.t('%j: %s',newDate(),process.argv[2]));console.error(g.t('%j: %s',g.d(newDate()),process.argv[2]));console.error(g.t('%s: %s',g.d(newDate()),process.argv[2]));g.error('%j: %s',newDate(),process.argv[2]);g.error('%j: %s',g.d(newDate()),process.argv[2]);g.error('%s: %s',g.d(newDate()),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:

varg=require('strong-globalize');g.log('Strings for life!');g.error('%s: %s',g.d(newDate()),process.argv[2]);

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

name has to be protected

[Setogit]

This requires strongloop/strong-globalize#5

[Setogit]

@sl-node test please

[Setogit]

@sl-node test please

[sam-github]

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