defunkt/mustache — pull request #153 by ernie (2013-07-19 13:20:43+00:00)
Title: Support i18n in templates. (no translate_only option)

(This is an alternative to #150 that is simpler, by dropping an option supported by that PR)

* To HTML-escape an i18n string: {{% some.key.name }}
* To return an i18n string unmodified: {{$ some.key.name }}

i18n keys are loaded from the "mustache" namespace by default. This is
because they support etags and utags, which are not the standard means
of i18n interpolation.

Options relating to translation:

* i18n_namespace - Sets the namespace containing a Mustache's i18n keys
* locale - Override translation locale during render (I18n.locale by
default)

Some caveats:

* Use of tags other than {{}} and {{{}}} inside an i18n string has
unspecified behavior. It certainly isn't *intended* to work, so any
success had is purely by accident.

Rationale:

While it's possible to implement I18n by handling translations in each
view class, it's less than optimal to do so. If you want to support true
i18n interpolation, then you're forced to provide interpolation
variables from within the view class, and the view class may not have
access to all the information required to supply those variables.

An alternative is to use lambda return values, which of course could
perform the translation as a filter, but this is somewhat more
laborious, since the responsibility is now on the user to create a
mapping between the attributes of the view and those inside the locale
file.

Regarding the implementation itself:

I chose `%` as the sigil both because its appearance brings to mind both
the current `%{}` interpolation syntax and the notion of key/value pairs
in general (to this former Perl guy). `$` was chosen for the unescaped
version for proximity to `%`.

One thing I did take the opportunity to do, while I was in here, was
improve the handling of lambda return values to a section tag. While the
LoD violation here is a bit offputting, and could certainly be
refactored out, I find the notion of setting the otag and ctag on a
`tokenizer` for the template to be more readable than defining a
singleton method which then must duplicate the logic in the Template
class's tokens method with modifications.