After tidying I see many instances on HTML closing tags `>` being on its own line. I used `git grep -nP '^\s*>\s*$'` to see that there are many cases of this.
There are other problems with HTML structure like: <li ><a class="revert_recall dropdown-item" data-id="[% recall.id | html %]"><i class="fa fa-undo"></i> Revert waiting</a></li > I suspect we don't want this.
> I suspect we don't want this. I want this. At least we wanted it during the "tidy all". It has been advertised and explained during the work, and is in the document https://koha-hedgedoc.servers.llownd.net/Bug-38664_Tidy-the-whole-codebase, section "The translation process". After the tidy we have: ``` - <option value="r" selected="selected">Remote-sensing image</option> + <option value="r" selected="selected"> + Remote-sensing image + </option> ``` It will generate the following changes in the .po files: ``` +#: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt:89 +#, fuzzy, c-format +msgid "Remote-sensing image " +msgstr "Image de télédétection" ``` I have tried to fix this in the translation script, see commit "WIP trim msgid". It actually fixes some problem with the current script: ``` +#. For the first occurrence, #. SCRIPT -#: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt:114 +#: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt:139 msgid "b- Large print" msgstr "b- Gros caractères" -#. SCRIPT -#: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt:114 -msgid "b- Large print " -msgstr "b- Gros caractères " ``` Was it enough? No it was not, we were loosing important spaces in some places. SOLUTION - we modified prettier's default behaviour: https://prettier.io/docs/en/options.html#html-whitespace-sensitivity Using "htmlWhitespaceSensitivity: 'strict'" in `.prettierrc.js` fixes the problem by splitting the tags themselves ``` + [% IF m.version == ( mm.version ) %] + <ul + ><li><strong>Mentor:</strong> [% INCLUDE person p=mm %]</li></ul + > + [% END %] ``` So we don't always need to split the tags. We could manually fix, but it needs to be done on a case-by-case basis.
> I suspect we don't want this. We wanted this. At least we did during the "tidy all" initial process. It has been advertised and explained during the work, and is in the document https://koha-hedgedoc.servers.llownd.net/Bug-38664_Tidy-the-whole-codebase, section "The translation process". After the tidy we have: ``` - <option value="r" selected="selected">Remote-sensing image</option> + <option value="r" selected="selected"> + Remote-sensing image + </option> ``` It will generate the following changes in the .po files: ``` +#: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt:89 +#, fuzzy, c-format +msgid "Remote-sensing image " +msgstr "Image de télédétection" ``` I have tried to fix this in the translation script, see commit "WIP trim msgid". It actually fixes some problem with the current script: ``` +#. For the first occurrence, #. SCRIPT -#: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt:114 +#: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt:139 msgid "b- Large print" msgstr "b- Gros caractères" -#. SCRIPT -#: koha-tmpl/intranet-tmpl/prog/en/modules/cataloguing/value_builder/marc21_field_007.tt:114 -msgid "b- Large print " -msgstr "b- Gros caractères " ``` Was it enough? No it was not, we were loosing important spaces in some places. SOLUTION - we modified prettier's default behaviour: https://prettier.io/docs/en/options.html#html-whitespace-sensitivity Using "htmlWhitespaceSensitivity: 'strict'" in `.prettierrc.js` fixes the problem by splitting the tags themselves ``` + [% IF m.version == ( mm.version ) %] + <ul + ><li><strong>Mentor:</strong> [% INCLUDE person p=mm %]</li></ul + > + [% END %] ``` So we don't always need to split the tags. We could manually fix, but it needs to be done on a case-by-case basis.
Thanks for taking the time to explain, I think we can resolve this.
*** This bug has been marked as a duplicate of bug 39085 ***