4 ms·
I strongly believe that we're currently in the early stage of the same cycle with localization formats. The most popular ones, like gettext, xliff, .properties
by zbraniecki 9y ago
I strongly believe that we're currently in the early stage of the same cycle with localization formats.
The most popular ones, like gettext, xliff, .properties are very limited, while the most sophisticated one - MessageFormat - is stopping a few steps short of having all needed capabilities and is very hard to read/write by hand.
I'm very excited for the next 3-5 years where I believe we'll see more development in this field and hopefully we'll end up with a good equivalent of CSS for Web Localization.
Full disclosure:
I work on a project that my team believes to be a good contender for that - Project Fluent ( http://projectfluent.io/ http://projectfluent.io/ )
I also work within TC39 on ECMA402 on APIs that will make coming up with new localization APIs much easier (PluralRules API, language negotiation and selection etc.).
- seanwilson 9y ago> I strongly believe that we're currently in the early stage of the same cycle with localization formats. I was looking into this recently and I'm amazed how many different but very similar formats there are. For example, Django uses gettext, JavaScript has several different JSON formats (e.g. i18next, polyglot) and Go has its own JSON/TOML/YAML format. Each format seems so similar I don't understand why they didn't use an existing one. Usually you want your translators to use a web interface to edit translations so different formats make this troublesome.