https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #1 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 109666 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109666&action=edit Bug 26392: Wrap all translatable strings in opac-main.tt -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #2 from Julian Maurice <julian.maurice@biblibre.com> --- Test plan: 1. Apply patch 2. cd misc/translator && ./translate update fr-FR 3. Open and translate misc/translator/po/fr-FR-messages.po (don't forget plural forms) 4. cd misc/translator && ./translate install fr-FR 5. Go to http://OPAC/cgi-bin/koha/opac-main.pl and try to make all translated strings to show up (log in, log out, create news, do some checkouts, holds, ...) -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #109666|0 |1 is obsolete| | --- Comment #4 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 109943 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109943&action=edit Bug 26392: Wrap all translatable strings in opac-main.tt -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #6 from Julian Maurice <julian.maurice@biblibre.com> --- (In reply to Owen Leonard from comment #3)

This looks good overall but I see one issue:

If I have the NewsAuthorDisplay set to "none" it looks like the template is still trying to show an author. I see something like this on each news item:

Published on 10.03.2019 by

I think the "author" variable is getting evaluated as true even if the [% IF %] block inside it evaluates as false. I think the "author" BLOCK belongs inside the "[% IF ( (newsdisp == 'opac'..."

You're 100% right :) Thanks Fixed in the last patch. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #109943|0 |1 is obsolete| | Attachment #109944|0 |1 is obsolete| | --- Comment #7 from Owen Leonard <oleonard@myacpl.org> --- Created attachment 109947 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=109947&action=edit Bug 26392: Wrap all translatable strings in opac-main.tt Signed-off-by: Owen Leonard <oleonard@myacpl.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #9 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- 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? 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. Could it make sense to only use the new syntax when we need singular/pluaral or other more advanced methods? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #11 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Hi Julian, I wonder if we should postpone this to next release now maybe, but I hope we can get some more active discussion. What do you think? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #13 from David Cook <dcook@prosentient.com.au> --- This does not look developer friendly... As an aside... The following could be written better: <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> Following the suggestions from https://developer.atlassian.com/server/framework/atlassian-sdk/pluralising-i...: <li><a href="/cgi-bin/koha/opac-user.pl#opac-user-checkouts"><span class="user_checkouts_count count_label">Checkouts: [% checkouts | html %]</span></a></li> Then you're just needing to translate "Checkouts" rather than singular and plural forms. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #15 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #14)

We can also translate using singular/plural forms now - just missing an example right now, but there is documentation on the wiki:

https://wiki.koha-community.org/wiki/Internationalization,_plural_forms, _context,_and_more_RFC

So we can make it read 1 checkout, 2 checkouts depending on the actual number.

Yeah, I saw that, but it does require the developer to know the syntax, and it puts more work on translators. I think there are certainly contexts where you need to do that, but not in my above example. I was reading somewhere too about plurals being problematic in other languages like Chinese and Russian, but my language skills don't extend that far. I do see Slovak mentioned in https://wiki.koha-community.org/wiki/Internationalization,_plural_forms,_con..., so that's interesting! Perhaps I just need to read more before I comment too much. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #17 from Owen Leonard <oleonard@myacpl.org> --- (In reply to David Cook from comment #13)

This does not look developer friendly...

We've been saying this kind of thing would not be developer-friendly for years, and it's time to get over it! - Developers are smart. Most of them are smarter than me and I can handle this fine. - It's not more work for translators. It's *easier* work for translators. Right now the translation files are a mess because we're trying to parse language strings out of a mess of HTML, CSS, and JavaScript. We humans are the ones who know which strings should be translated so we should tell the computer. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia@bugs.koha-communit |tomascohen@gmail.com |y.org | CC| |tomascohen@gmail.com -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org --- Comment #19 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- (In reply to David Cook from comment #18)

Overall, I'll do whatever other people decide needs to be done, but I just worry that we're trying to re-invent the wheel sometimes and do things a harder way, when other projects have already sorted out internationalization more gracefully.

How could we do that better? Do you have any suggestions? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #21 from Owen Leonard <oleonard@myacpl.org> --- (In reply to David Cook from comment #18)

when other projects have already sorted out internationalization more gracefully.

If you're referring to the question of syntax, other projects I've seen do something similar. For instance in Drupal: <?php print t('Skip to main content'); ?></a> Translatable strings are wrapped in the t() function. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #23 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #19)

(In reply to David Cook from comment #18)

...

Overall, I'll do whatever other people decide needs to be done, but I just worry that we're trying to re-invent the wheel sometimes and do things a harder way, when other projects have already sorted out internationalization more gracefully.

How could we do that better? Do you have any suggestions?

Suggestion 1: Referring back to https://developer.atlassian.com/server/framework/atlassian-sdk/pluralising-i..., I think that we could do easy things like "Simplify the Message into a Plural-Independent Phrase". Suggestion 2: Use a token based i18n scheme like Java (which has a huge history in internationalization as it was the origin of ICU): https://docs.oracle.com/javase/tutorial/i18n/intro/steps.html Suggestion 3: Look at what others have done in Perl: https://metacpan.org/pod/Catalyst::Plugin::I18N https://metacpan.org/pod/Mojolicious::Plugin::I18N -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #25 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #27 from Julian Maurice <julian.maurice@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.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #29 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Have to still read discussion, but I also am in favor of keeping stuff readable in templates to some extent. Using only variables in templates and having to look them up in a Perl script adds an extra step and will make it harder again for people to contribute simple changes. Also I foresee use of a lot of silly variable names with the amount of strings we have. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #31 from David Cook <dcook@prosentient.com.au> --- (In reply to Julian Maurice from comment #27)

If we can't expect developers to use 8 functions, what can we expect from them ?

We can expect developers to follow consistent simple rules.

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)

This sounds better to me. It is easier to lookup options for 2 functions than to lookup, compare, and contrast 8 different functions. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #33 from David Cook <dcook@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.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #35 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to David Cook from comment #32)

(In reply to Katrin Fischer from comment #29)

...

Have to still read discussion, but I also am in favor of keeping stuff readable in templates to some extent. Using only variables in templates and having to look them up in a Perl script adds an extra step and will make it harder again for people to contribute simple changes.

Easier doesn't always mean better.

Not always, but I think in this case it applies. Forcing people to invent tons of variables will not make things more readable, but much likely less so. Koha is a very string heavy application. Look at the numbers in our po files on Pootle - I am an active translator.

...

Also I foresee use of a lot of silly variable names with the amount of strings we have.

With DSpace, you see keys like this: "jsp.dspace-admin.eperson-edit.emailexists".

And you say that's easier? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #37 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Tomás Cohen Arazi from comment #36)

(In reply to Katrin Fischer from comment #35)

...

(In reply to David Cook from comment #32)

...

(In reply to Katrin Fischer from comment #29)

...

Have to still read discussion, but I also am in favor of keeping stuff readable in templates to some extent. Using only variables in templates and having to look them up in a Perl script adds an extra step and will make it harder again for people to contribute simple changes.

Easier doesn't always mean better.

Not always, but I think in this case it applies. Forcing people to invent tons of variables will not make things more readable, but much likely less so. Koha is a very string heavy application. Look at the numbers in our po files on Pootle - I am an active translator.

...

...

Also I foresee use of a lot of silly variable names with the amount of strings we have.

With DSpace, you see keys like this: "jsp.dspace-admin.eperson-edit.emailexists".

And you say that's easier?

Yes!

intranet.admin.libraries.list_title

I really don't see the advantage of this. To me it adds an extra step with no visible win. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #39 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #37)

I really don't see the advantage of this. To me it adds an extra step with no visible win.

Here are some random examples from DSpace and Koha. https://github.com/DSpace/DSpace/blob/dspace-6.3/dspace-jspui/src/main/webap... https://github.com/Koha-Community/Koha/blob/master/koha-tmpl/intranet-tmpl/p... For DSpace, just do a Ctrl+F for "fmt:message". Personally, I think that the DSpace template is cleaner (notwithstanding the JSP block near the top but DSpace isn't perfect either). The template is easy to read. The tokens are logical. You can lookup keys in https://github.com/DSpace/DSpace/blob/dspace-6.3/dspace-api/src/main/resourc.... Admittedly DSpace is smaller than Koha, but the Java model used by DSpace is used far and wide. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply CC| |m.de.rooy@rijksmuseum.nl -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Julian Maurice <julian.maurice@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #109948|0 |1 is obsolete| | --- Comment #42 from Julian Maurice <julian.maurice@biblibre.com> --- Created attachment 117795 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=117795&action=edit Bug 26392: Fix opac news display issue when there is no author Signed-off-by: Owen Leonard <oleonard@myacpl.org> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 --- Comment #43 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I feel like this might be better as "in discussion", but it should really be discussed. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Patch doesn't apply --- Comment #45 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Please look at comment43 too? Katrin could you elaborate on what exactly should be discussed here? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Victor Grousset/tuxayo <victor@tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |victor@tuxayo.net --- Comment #47 from Victor Grousset/tuxayo <victor@tuxayo.net> --- About the discussion of t("Koha online catalogue") vs t("opac.homepage.title"), the current approach (1st) doesn't close the door for the 2nd (token based) since the strings would already be wrapped in calls. So it's not closing this door assuming the token based approach is chosen in the end.t It's even a common step, right? About that choice: (In reply to David Cook from comment #38)

I agree that the PO files are huge, but looking through them that are also lots of junk lines, duplicate translations, unnecessary translations, etc. Using tokens would cut down on a lot of that.

How would tokens allow us to get less junk, duplicates and unnecessary translations? Don't a smarter (manual or automated) use of t() already does all that? -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26392 Michał <schodkowy.omegi-0r@icloud.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=38618 -- You are receiving this mail because: You are watching all bug changes.