[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 #10 from Julian Maurice <julian.maurice at biblibre.com> ---
(In reply to Katrin Fischer from comment #9)
> This appears to work well, but it doesn't really make the templates easier
> to read...
> 
> - <li><a href="/cgi-bin/koha/opac-user.pl#opac-user-checkouts"><span
> class="user_checkouts_count count_label">[% checkouts | html %]</span>
> checkout(s)</a></li>
> 
> Turns into:
> 
> +                                        [% count = BLOCK %]<span
> class="user_checkouts_count count_label">[% checkouts | html %]</span>[% END
> %]
> +                                        <li><a
> href="/cgi-bin/koha/opac-user.pl#opac-user-checkouts">[% tn('{count}
> checkout', '{count} checkouts', checkouts) | html | $Expand count = count
> %]</a></li>
> 
> Can you explain a bit how this works? What is the BLOCK and Expand needed
> for?
Sure.

[% var = BLOCK %]...[% END %] puts the content of the block inside variable
var, so here the 'count' variable will be equal to something like this:

    <span class="user_checkouts_count count_label">42</span>

The expand plugin replace text enclosed with braces by another string passed in
parameter

    [% t("Hello {name}") | $Expand name = "World !" %]

Will result in "Hello World !".
It is the same as

    [% tx("Hello {name}", name = "World !") %]

But having this as a separate plugin allows to add other filters in between.

    [% t("Hello {name}") | html | $Expand name = "<strong>World</strong> !" %]

Which is needed if we want to prevent translations to add unwanted html (like a
<script> element for instance) and if expanded variables contain html that we
do not want to filter, like in the example in the patch.

> We add tons more of | html filters... could this impact performance? I
> remember when adding the filters in the first place it was an issue. It also
> adds to the text. I wonder if there would be another way to go about these.
If I remember correctly, the issue was not about HTML filtering in itself, but
the module we used was doing a lot of expensive string concatenation, which was
the real performance issue.

> Could it make sense to only use the new syntax when we need singular/pluaral
> or other more advanced methods?
It could.
I agree with you when you say the template is less easy to read, but there is a
long term benefit if we manage to translate all the strings that way : it will
be no longer needed to copy the templates using `./translate install`

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