[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 #27 from Julian Maurice <julian.maurice at biblibre.com> ---
(In reply to David Cook from comment #22) 
> Drupal is an old project as well, and that example looks worrying. Based on
> https://en.wikipedia.org/wiki/Drupal#Themes, it looks like that example must
> be one of those "hard-coded PHP" templates. I wonder what they do in Drupal
> 8+ with Twig.

They still do the same: use t() and formatPlural(). Context and variables to
substitute are passed as optional arguments

(In reply to David Cook from comment #23)
> Suggestion 1:
> Referring back to
> https://developer.atlassian.com/server/framework/atlassian-sdk/pluralising-
> internationalisation-strings/, I think that we could do easy things like
> "Simplify the Message into a Plural-Independent Phrase". 
Yep, we can do that. No need to change the i18n framework for that. And we can
do things differently too if needed, which is not a bad thing IMO.

(In reply to David Cook from comment #24)
> Admittedly, https://metacpan.org/pod/Catalyst::Plugin::I18N uses a similar
> method using l() instead of t().
> 
> I suppose I wouldn't mind t() that much (although the Java way of doing it
> is still better I think) if that were the only macro we were required to
> use, but Bug 26392 introduces t(), tx(), tnx(), txn(), tp(), tpx(), tnp(),
> tnpx(). 
> 
> In my opinion, it's a bit absurd to expect developers to use 8 different
> macros which look almost exactly the same.

If we can't expect developers to use 8 functions, what can we expect from them
?
We can probably reduce the number of functions to 2: t and tn, and transform
the other ones into optional arguments of these 2 functions (the same as
drupal). But developers would now have to remember the name of the options.
(And the parser which extracts translatable strings would have to be modified
too)

(In reply to David Cook from comment #25)
> Regarding the Java method, look at "Fetch the Text from the ResourceBundle"
> at https://docs.oracle.com/javase/tutorial/i18n/intro/steps.html. 
> 
> In my mind, we'd fetch the relevant translated string using a msgId in the
> Perl, and then we'd pass the translated string via a variable to the
> template.
> 
> I think it would make templates look much cleaner and I think that it would
> make it easier to handle translations on the backend too.
> 
> It could also potentially allow plugins to override the output to the
> template, but that's a whole other thing.

I really don't see how what you're describing is a better solution than what we
already have. This is looking worse actually. Correct me if I'm wrong but are
you're suggesting that

[% t('Hello, World!') %]

should be replaced by

$template->param('hello_world_str' => fetch('hello_world_str'))

in Perl script and

[% hello_world_str %]

in template ? I don't find that very clean.

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