https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392
--- Comment #27 from Julian Maurice <[email protected]> --- (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. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
