[Koha-bugs] [Bug 26392] Wrap all translatable strings in opac-main.tt

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392

--- Comment #33 from David Cook <dcook at prosentient.com.au> ---
(In reply to Martin Renvoize from comment #28)
> Just for documentation, we had a good discussion around this on IRC this
> morning with a few options to think about.. discussion is around 8.13:
> http://irc.koha-community.org/koha/2020-12-11#i_2316124

Looking at http://irc.koha-community.org/koha/2020-12-11#i_2316124, I'm
thinking about separation of concerns...

On one hand, using t() could make it easier for a frontend web designer to do
their design in English and offload translations to others without worrying
about the backend. 

On the other hand, using t() is looking quite complex and not
designer-friendly. It really looks like we're trying to shoehorn a solution
into the templates. 

Take the following example:
[% tx('Published on {published_on} by {author}', { published_on =
filter(date_var, 'KohaDates', options), author = filter(author, 'html') }) |
html %]

Compare it with this much simpler Vue.js i18n example:

https://kazupon.github.io/vue-i18n/guide/formatting.html#named-formatting

A lot of the i18n systems out there work based on this token idea. 

Now of course in the Koha version we're doing a lot of extra things. I'd
actually argue that we shouldn't be using KohaDates in the templates and really
should format the date in the Perl and then push the correctly formatted date
to the template (ie view). After all, if we were getting the date by an AJAX
call (say using Vue.js), we'd want the correct data, since we're just rendering
it in the presentation layer of our application. Regarding html escaping, we'd
just have that on by default. To avoid double-encoding, we could turn off the
html filter at the function level.

-- 
You are receiving this mail because:
You are watching all bug changes.