yay readme-driven development!
- grunt/broccoli/etc:
- preprocessor (generate templates w/ all block t calls converted to inline t calls)
- extractor (get all inline translation strings)
- this should probably actually be implemented in i18nliner-js; we can just register ourselves with it somehow
- basic handlebars helper
- ember support
- bound helper support
- ability to nest link-to (and possibly others) in a block translation (like we do in i18nliner.rb)
- bower
====
I18nliner is I18n made simple.
No .js / .json translation files. Easy inline defaults. Optional keys. Easy pluralization. Wrappers and blocks, so your templates look template-y and your translations stay HTML-free.
I18nliner lets you do stuff like this:
and even this:
Instead of maintaining .js/.json files and doing stuff like this:
I18n.t('account_page_title');
Forget the translation file or anything in your .js files, and just do this in your handlebars:
Regular I18n options follow the (optional) default translation, so you can do the usual stuff (placeholders, etc.).
Sure, but you don't need to write them. Just run:
i18nliner dump
This extracts all default translations from your codebase, merges them with any
other ones (from pre-existing translation files), and outputs them to
locales/generated/translations.json
(or .js
if using i18n.js)
TODO grunt/broccoli instructions/links
Why waste time coming up with keys that are less descriptive than the default translation? I18nliner makes keys optional, so you can just do this:
{{t "My Account"}}
I18nliner will create a unique key based on the translation (e.g.
'my_account'
), so you don't have to. See I18nliner.inferred_key_format
for
more information.
This can actually be a good thing, because when the en
changes, the key
changes, which means you know you need to get it retranslated (instead of
letting a now-inaccurate translation hang out indefinitely). Whether you want
to show "[ missing translation ]" or the en
value in the meantime is up to
you.
Suppose you have something like this in your template:
You probably don't want the HTML as part of the translation, because it makes things brittle and potentially insecure. At the same time, you probably want the translators to get the entire sentence with minimal noise. So what do you do?
I18nliner lets you specify wrappers, so you can keep HTML out the translations, while still just having a single string needing translation:
Delimiters are increasing numbers of asterisks.
But wait, there's more!
Perhaps you want your templates to look like, well, templates. Try this:
Or even this:
In case you're curious about the man behind the curtain, I18nliner adds a pre-processor that turns the second example into something like this during Handlebars parsing:
In other words, it will infer wrappers from your (balanced) markup, and
will create placeholders for any other (inline) handlebars expressions.
Block helpers (e.g. {{#if cond }}...
) are not supported within a
block translation. The only exception to this rule is nested translation
calls, e.g. this is totally fine:
TODO grunt/broccoli instructions/links for enabling pre-processing
I18nliner ensures translations, interpolated values, and wrappers all play nicely (and safely) when it comes to HTML escaping. If any translation, interpolated value, or wrapper is HTML-safe, everything else will be HTML- escaped.