21–30 of 39 posts
Looks great. One thing that wasn't clear, can you provide your own translations or is it all machine translation?
Currently I use i18next with custom functions, where I just write strings like _("car"), ngettext("window", "windows", number) in files. I Can use translator comments, context and everything. (Like //TRANSLATORS: this is used in this way etc.) https://www.gnu.org/software/gettext/manual/html_node/PO-Fil... Babel extracts all translatable strings to POT file. I Translate POT file to my wanted languages PO files with GUI tool of my choice. Then PO file is converted to json and used in translations with i18next library. When New translations are added I just rerun Babel new translations are added, are retranslated if needed and converted to JSON. I looked into a lot of JS libraries and extractors and these was the only one that supported Plurals, context, translator comments, etc.
I looked into Mozilla's L20 which seems nice. But there is no GUI translation editor. You have to find all translatable strings yourself etc. End it seems it's the same here.
One better things is that with FormatJS I wouldn't need moment.js for date localization.
Earlier quoted context omitted.
But when the contents change, how does Localize.js know to translate the DOM again? If you need to call something like 'Localize.translatePage', then you need to track the changes yourself, which is not the correct way. I noticed that one can bypass the DOM modifying by calling Localize.translate to directly translate text, which is what I would do with Angular.JS. I'd just write a simple directive which uses the Loc…
We use MutationObserver ( https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... ) to detect when content on the page changes, so when you add (or change) a on your page, we're able to immediately translate the new content, on-the-fly, as it's being inserted into the DOM. Our goal with Localize.js is to make everything completely "plug and play", and require as little extra development work as possible. We'r…
I wouldn't use it for greenfield development, but it's definitely a great option for websites that wouldn't otherwise be localized. It's great for people to have a near-zero-development option to translate existing sites.
I'd certainly rather have websites translated using this approach than not translated at all!
How does it compare to normal "Gettext workflow"? Currently I use i18next with custom functions, where I just write strings like _("car"), ngettext("window", "windows", number) in files. I Can use translator comments, context and everything. (Like //TRANSLATORS: this is used in this way etc.) https://www.gnu.org/software/gettext/manual/html_node/PO-Fil... Babel extracts all translatable strings to POT file. I Transla…
Internally at Yahoo (just like facebook, and other big companies), we have an infrastructure for translation that works based on a source file written in english by developers, and the whole thing just work. But we have no plans to open up any of that. We believe, such system will grow from the community once people realize that ICU is good enough to internationalize their apps.
As for moment.js, you're right, if you will never need to parse a date, or massage a date value, and the only thing you care about is to format a timestamp that is coming from an API, then `formatRelative` helper should be good enough.
Are there any advantages over i18n-js[1]? Can't say I'm a huge fan of this method of pluralization: Cart: {itemCount} {itemCount, plural, one {item} other {items} } [1]: https://github.com/fnando/i18n-js
I haven't look into i18n-js library in details, but this is what I can spot so far: * the message format in i18n-js seems to be compatible with ICU message syntax, the industry standard used in other programming languages and the one used by formatJS as well. we will have to check if they really implemented all the specs, which makes the messages more advanced, e.g.: ``` Cart: {itemCount, plural, =0 {no items} one {o…
Not sure I follow, taken from a React component:
Component = React.createClass
render: ->
@div null,
@t('welcomeMessage', username: @props.CurrentUser.displayName)Are there any advantages over i18n-js[1]? Can't say I'm a huge fan of this method of pluralization: Cart: {itemCount} {itemCount, plural, one {item} other {items} } [1]: https://github.com/fnando/i18n-js
Yeah, for a simple plural that can be a bit longer. In other languages, though, the pluralization rules get rather complicated[1]. (For example, Arabic has both complicated pluralization rules -and- a lot of people who speak it.) The strength of the ICU message format, in my mind, is that the messages can be "nested" so that the translation can be customized for multiple concerns (plural, gender, whatever). Also, wit…
Though i18n-js does let you write your own pluralizations rules (taken from the readme), while supporting zero/one/many out of the box:
I18n.pluralization["ru"] = function (count) {
var key = count % 10 == 1 && count % 100 != 11 ? "one" : [2, 3, 4].indexOf(count % 10) >= 0 && [12, 13, 14].indexOf(count % 100) = 0 || [11, 12, 13, 14].indexOf(count % 100) >= 0 ? "many" : "other";
return [key];
};
There are many tools to extract gettext strings from source and editors to translate PO catalogs, but I do not know of any that works with ICU messageformat syntax.
Earlier quoted context omitted.
But when the contents change, how does Localize.js know to translate the DOM again? If you need to call something like 'Localize.translatePage', then you need to track the changes yourself, which is not the correct way. I noticed that one can bypass the DOM modifying by calling Localize.translate to directly translate text, which is what I would do with Angular.JS. I'd just write a simple directive which uses the Loc…
We use MutationObserver ( https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... ) to detect when content on the page changes, so when you add (or change) a on your page, we're able to immediately translate the new content, on-the-fly, as it's being inserted into the DOM. Our goal with Localize.js is to make everything completely "plug and play", and require as little extra development work as possible. We'r…
Earlier quoted context omitted.
I haven't look into i18n-js library in details, but this is what I can spot so far: * the message format in i18n-js seems to be compatible with ICU message syntax, the industry standard used in other programming languages and the one used by formatJS as well. we will have to check if they really implemented all the specs, which makes the messages more advanced, e.g.: ``` Cart: {itemCount, plural, =0 {no items} one {o…
> i18n-js is a js library, which means you have to do the formatting in your js code, then passing the formatted data into the template engine where you have the placeholders for them Not sure I follow, taken from a React component: Component = React.createClass render: -> @div null, @t('welcomeMessage', username: @props.CurrentUser.displayName)
I had to re-read the last line several times before I looked up at the function arrow and realized it was coffeescript, and that the "@" were not part of the i18n library, but rather the syntactic sugar for "this".
Earlier quoted context omitted.
We use MutationObserver ( https://developer.mozilla.org/en-US/docs/Web/API/MutationObs... ) to detect when content on the page changes, so when you add (or change) a on your page, we're able to immediately translate the new content, on-the-fly, as it's being inserted into the DOM. Our goal with Localize.js is to make everything completely "plug and play", and require as little extra development work as possible. We'r…
Could implementing things this way cause a problem if another script also post-processed your pages? Could you wind up in a loop where each script kept modifying the page in response to the changes made by the other script?