The file opac-detail.tt exposes a lot of template directives to translation where translators should not be confronted with. Some examples from po file are: $[% SUBFIELD.code %] [% SUBFIELD.value %] %s [%% INCLUDE \"openlibrary-readapi.inc\" bib = { normalized_isbn => " "normalized_isbn, lccn => lccn, normalized_oclc => normalized_oclc } %%] See: [% IF ( nextTitle ) %][% nextTitle |html %][% ELSE %]next biblio[% END " "%]
Created attachment 64132 [details] [review] Bug 18754: Translatability: Get rid of exposed tt directives in opac-detail.tt Work in progress, not yet ready for testing.
Created attachment 64178 [details] [review] Bug 18754: Translatability: Get rid of exposed tt directives in opac-detail.tt The file opac-detail.tt exposes a lot of template directives to translation where translators should not be confronted with. Some examples from po file are: $[% SUBFIELD.code %] [% SUBFIELD.value %] %s [%% INCLUDE \"openlibrary-readapi.inc\" bib = { normalized_isbn => " "normalized_isbn, lccn => lccn, normalized_oclc => normalized_oclc } %%] See: [% IF ( nextTitle ) %][% nextTitle |html %][% ELSE %]next biblio[% END " "%] To test: - Apply patch - Do a search in OPAC that has more than 1 results - Go to the detail page of one of the items found - Verify that the details display as before and that you can browse the results with Previous and Next - In staff client, change OPACXSLTDetailsDisplay from 'default' to empty for "no xslt" and repeat steps above - In staff client, set HTML5MediaEnabled to 'OPAC' or 'OPAC and staff client' - Verify that media catalogued in field 856 still work - Create a new translation for a 'language' aa-AA (perl translate create aa-AA) - Verify that template directives ar no longer exposed in aa-AA-opac-bootstrap.po
Still applies on current master
Created attachment 65412 [details] [review] Bug 18754: Translatability: Get rid of exposed tt directives in opac-detail.tt The file opac-detail.tt exposes a lot of template directives to translation where translators should not be confronted with. Some examples from po file are: $[% SUBFIELD.code %] [% SUBFIELD.value %] %s [%% INCLUDE \"openlibrary-readapi.inc\" bib = { normalized_isbn => " "normalized_isbn, lccn => lccn, normalized_oclc => normalized_oclc } %%] See: [% IF ( nextTitle ) %][% nextTitle |html %][% ELSE %]next biblio[% END " "%] To test: - Apply patch - Do a search in OPAC that has more than 1 results - Go to the detail page of one of the items found - Verify that the details display as before and that you can browse the results with Previous and Next - In staff client, change OPACXSLTDetailsDisplay from 'default' to empty for "no xslt" and repeat steps above - In staff client, set HTML5MediaEnabled to 'OPAC' or 'OPAC and staff client' - Verify that media catalogued in field 856 still work - Create a new translation for a 'language' aa-AA (perl translate create aa-AA) - Verify that template directives ar no longer exposed in aa-AA-opac-bootstrap.po Followed test plan which works as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz>
I am wondering if constructions like those below should be considered as improvements to the template (recognizing translation benefits). But as always, we have to find some balance. [% IF ( collectionvolume ) %] [% ' ; ' _ collectionvolume %] [% END %] [% ' ( ' _ (itemloop.size || 0) _ ' )' %] Another QA/RM opinion please.
Given the number of hard-to-read lines, I would not mark this one as trivial btw.
(In reply to Marcel de Rooy from comment #6) > Given the number of hard-to-read lines, I would not mark this one as trivial > btw. Who can better deal with code - translators or developers? We should avoid to expose code or code fragents to translators IMO, otherwise we risk that translators break something.
I would vote for added complexity in the templates in order to make translation easier.
Just a note about BLOCK..INCLUDE versus BLOCK..PROCESS: The PROCESS directive is slightly faster than INCLUDE because it avoids the need to localise (i.e. copy) the variable stash before processing the template.
Created attachment 65504 [details] [review] Bug 18754: Translatability: Get rid of exposed tt directives in opac-detail.tt The file opac-detail.tt exposes a lot of template directives to translation where translators should not be confronted with. Some examples from po file are: $[% SUBFIELD.code %] [% SUBFIELD.value %] %s [%% INCLUDE \"openlibrary-readapi.inc\" bib = { normalized_isbn => " "normalized_isbn, lccn => lccn, normalized_oclc => normalized_oclc } %%] See: [% IF ( nextTitle ) %][% nextTitle |html %][% ELSE %]next biblio[% END " "%] To test: - Apply patch - Do a search in OPAC that has more than 1 results - Go to the detail page of one of the items found - Verify that the details display as before and that you can browse the results with Previous and Next - In staff client, change OPACXSLTDetailsDisplay from 'default' to empty for "no xslt" and repeat steps above - In staff client, set HTML5MediaEnabled to 'OPAC' or 'OPAC and staff client' - Verify that media catalogued in field 856 still work - Create a new translation for a 'language' aa-AA (perl translate create aa-AA) - Verify that template directives ar no longer exposed in aa-AA-opac-bootstrap.po Followed test plan which works as intended Signed-off-by: Alex Buckley <alexbuckley@catalyst.net.nz> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 65505 [details] [review] Bug 18754: [QA Follow-up] Tiny corrections Converted one INCLUDE directive to PROCESS; we are not changing variables here. (The PROCESS directive is slightly faster than INCLUDE because it avoids the need to localise (i.e. copy) the variable stash before processing the template.) Removed one vim inserted letter i. Error in [% IF ( XISBN.publicationyear ) _ ', ' _ XISBN.publicationyear %][% END %] The concatenation became part of the condition. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
(In reply to Marc Véron from comment #7) > (In reply to Marcel de Rooy from comment #6) > > Given the number of hard-to-read lines, I would not mark this one as trivial > > btw. > > Who can better deal with code - translators or developers? We should avoid > to expose code or code fragents to translators IMO, otherwise we risk that > translators break something. (In reply to Owen Leonard from comment #8) > I would vote for added complexity in the templates in order to make > translation easier. Okay. Send it to the next level.
Pushed to master for 17.11, thanks to everybody involved!
Pushed to 17.05.x, will be in 17.05.05.
These patches have been pushed to 16.11.x and will be in 16.11.13.
Pushed to 16.05.x, for 16.05.18 release