I18N made easier for third party applications. #83

Open
wants to merge 2 commits into
from

Conversation

Projects
None yet
2 participants

qn7o commented Jun 25, 2012

if you include timeago.js inside a large application that already handles i18n, it's now made easy to give timeago.js your own translator() function. and if you don't, timeago will continue to behave the same way than before.

@qn7o qn7o [IMP] add a better support for third party applications i18n support
if you include timeago.js inside a large application that already handles i18n, it's now made easy to give timeago.js your own translator() function.  and if you don't, timeago will continue to behave the same way than before.
1bb29c8

qn7o commented Jun 25, 2012

Yep; at first I renamed it (into "convert()" or something like that), but a colleague suggested me to minify the diff and leave you the discretion to give it the best name ever possible.

qn7o commented Jun 25, 2012

Oh ok, I see what you mean. This is an error; I'll fix that asap, my bad.

@qn7o qn7o [IMP] continue refactoring timeago.js, following the conversation on …
…this pull request: #83

- remove bad usage of global variable stringAndNumber
- use a consistent name for the substitute() function which was actully not substituing anything anymore
6fc5d86
Owner

rmm5t commented Jun 25, 2012

Sorry, I've been meaning to look into some more standard locale/i18n/translation methods for jQuery as I prepare for a Timeago rewrite. Could you fill me in a little more on the significance of the translator function? Is this a convention that plugins adhere to or a convention that another plugin expects?

qn7o commented Jun 26, 2012

I'm not sure if this is a "convention", but in our case (and I hope several others) it's very convenient: our application (OpenERP) uses a rich javascript web client which implements its own i18n mechanism. The translator() function will work like a gettext() function.

This mechanism is also the reason why the resulting string has to be processed in this order:
1/ deduce the strings to use and the number which will go in it
2/ put the strings together
3/ translate the complete string way more comprehensive for translator contributors as it gives more context than little bits of sentence like "ago" or "from now" -- dont forget than translators are not always tech people [1])
4/ substitute %d with the proper number

This way to proceed seems more powerful than translating each bit of the string separately, as can't be sure that every language will use the form "[prefix] words [suffix]", or handle the plural with more fineness than "one or more" [2].

This is made really easy thanks to the translator() function which will act as a placeholder: when initializing timeago, we just give it our own translating function and we're good to go ! And if no function is defined, timeago will continue to behave as expected.

Hope that helps !

[1] especially when using systems like transifex ou launchpad rosetta
[2] see http://www.codeproject.com/Articles/222389/Delivering-Software-to-a-Global-Audience, probably a good read if you are about to refactor the i18n part, especially the "Pluralization" and the "Formatting of Plurals" sections.

Owner

rmm5t commented Jun 29, 2012

@abourguignon Did you know that Timeago's built-in string settings can either take a string or a function? Does that help you in some way here. You could always assign the same function to different settings if that helps.

The Russian translation is a good example of this.

More Locale Examples

qn7o commented Jul 3, 2012

Yep, I know, but it's too early in the code to produce a proper translation.

Once again, the translation function has to be applied on the final string, just before number's substitution. See previous explanations and examples in the linked article.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment