[Evergreen-dev] [Evergreen-general] Untranslated column headers in the staff client - how to proceed?

Linda Jansová linda.jansova at gmail.com
Thu Feb 22 01:24:28 EST 2024


Dear Stephanie and Galen,

Thank you very much for bringing up the issue!

Galen, your insight that POEditor is not actually involved, although 
these string are used in the staff client, is indeed a valuable one!

The examples in rows 8 to 12 in the file 
https://docs.google.com/spreadsheets/d/13_AwTRNLobGIgA6bFqw0pC3tWXq8D8i13CshCbOb1u4/edit?usp=sharing 
might indicate that we have the translations available but they are just 
not getting properly displayed in the interface.

In our installations we use both English and Czech, so I suppose the 
replacement for the single-language site wouldn't be the right option 
for us as these would actually count as two languages rather than one (?).

Linda

On 2/22/24 00:29, Galen Charlton via Evergreen-dev wrote:
> Hi,
>
> Upon checking, POEditor is not involved. Labels from the IDL are 
> translated via Launchpad - for example, 
> https://translations.launchpad.net/evergreen/main/+pots/fm-idl.dtd/cs/+translate.
>
> The way that the mechanism is supposed to work is that a version of 
> fm_IDL.xml is produced that uses XML entities. In the tarball, that 
> version gets produced as Open-ILS/web/reports/fm_IDL.xml. The 
> translations are written to DTD files, e.g., 
> ./Open-ILS/web/opac/locale/cs-CZ/fm_IDL.dtd in the tarball.
>
> The entity version of fm_IDL.xml goes in /openils/var/reports; the DTD 
> files for each desired local goes in 
> /openils/var/web/opac/locale/$LOCALE, e.g., 
> /openils/var/web/opac/locale/cs-CZ/fm_IDL.dtd.
>
> The entity version of fm_IDL.xml includes the following line to select 
> the right DTD to load the translation dynamically:
>
>      <!--#include virtual="/opac/locale/${locale}/fm_IDL.dtd"-->
>
> For a single-language site, "${locale}" could be replaced with a 
> single locale value.
>
> As far as I can tell, the I18N instructions during the release process 
> are doing the right thing; what's missing is effective documentation 
> or installation tools to automatically install the right stuff. What 
> we have at the moment is this email, this [1], and some content on the 
> wiki that doesn't discuss the IDL translation in particular, as far as 
> I can tell.
>
> So, the components are present, just, to put it politely, underdocumented.
>
> [1] 
> https://docs.evergreen-ils.org/docs/latest/reports/reporter_add_data_source.html#_add_a_new_class_to_fm_idl_xml_for_your_data_source
>
> Regards,
>
> Galen
>
> On Wed, Feb 21, 2024 at 5:24 PM Stephanie Leary via Evergreen-dev 
> <evergreen-dev at list.evergreen-ils.org> wrote:
>
>     Hi, all. I want to revisit the issue of missing translations that
>     Linda brought up on Jan. 2. If I understand correctly, the main
>     problem is that we have strings in the IDL that are not being
>     imported into POEditor.
>
>     This is the procedure the 3.12 release team used:
>     https://wiki.evergreen-ils.org/doku.php?id=dev:release_process:evergreen:how_to_build
>
>     As you can see, there are several steps related to translations.
>
>     The POEditor instructions are here:
>     https://wiki.evergreen-ils.org/doku.php?id=poeditor
>
>     Are we missing some steps?
>
>
>     Stephanie Leary
>     Front End Developer
>     Equinox Open Library Initiative
>     stephanie.leary at equinoxOLI.org
>     https://www.equinoxOLI.org <https://www.equinoxOLI.org>
>     phone: 877-OPEN-ILS (673-6457)
>
>
>     On Tue, Jan 2, 2024 at 12:23 AM Linda Jansová via
>     Evergreen-general <evergreen-general at list.evergreen-ils.org> wrote:
>
>         Dear all,
>
>         We have begun working with the 3.12 version which is - when it
>         comes to
>         correctly displaying Czech - significantly better than the
>         previous
>         version - of course a big thank you goes out to everyone who
>         has helped
>         along the way :-)!
>
>         One of the so far unresolved issues we would like to start
>         working on
>         now are the column headers. These often remain untranslated as
>         we have
>         reported here:
>
>         https://bugs.launchpad.net/evergreen/+bug/2042915
>
>         There is also a spreadsheet with a couple of examples:
>
>         https://docs.google.com/spreadsheets/d/13_AwTRNLobGIgA6bFqw0pC3tWXq8D8i13CshCbOb1u4/edit?usp=sharing
>
>         It seems that if the string (and, consequently, its
>         translation) is not
>         present in POEditor and can only be found on Launchpad and in
>         fm_IDL.xml
>         and in translation files in GIT, the staff client interface
>         shows the
>         English string instead of the Czech one.
>
>         So I was just wondering how we could proceed, e.g. should we
>         try to
>         compile a comprehensive list of all missing translations from
>         the column
>         headers? And if so, which other pieces of information would be
>         useful to
>         add, e.g., would a spreadsheet like the one mentioned above be
>         a good
>         starting point?
>
>         In some cases when the string is not very unique (actually, it
>         is a
>         rather common situation to come across widely used strings;
>         the unique
>         ones appear less frequently), the GIT links might not be very
>         useful as
>         the string would be found in many more places (and,
>         consequently, files)
>         than just say in a single column header.
>
>         Perhaps trying to locate relevant ".component.html" files with
>         missing
>         i18n-label attributes (using
>         https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=+%3Ceg-grid-column
>         <https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=+%3Ceg-grid-column>
>
>         or a similar approach) would be a better choice? (But maybe this
>         wouldn't work in practice as the example strings from the
>         spreadsheet
>         currently indicate no occurrences in the .component.html files.)
>
>         Or would there be an entirely different way to tackle it?
>
>         Thank you very much for sharing your views!
>
>         Linda
>
>         _______________________________________________
>         Evergreen-general mailing list
>         Evergreen-general at list.evergreen-ils.org
>         http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>
>     _______________________________________________
>     Evergreen-dev mailing list
>     Evergreen-dev at list.evergreen-ils.org
>     http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
>
>
>
> -- 
> Galen Charlton
> Implementation and IT Manager
> Equinox Open Library Initiative
> gmc at equinoxOLI.org
> https://www.equinoxOLI.org <https://www.equinoxOLI.org>
> phone: 877-OPEN-ILS (673-6457)
> direct: 770-709-5581
>
> _______________________________________________
> Evergreen-dev mailing list
> Evergreen-dev at list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20240222/7ca6c31b/attachment.htm>


More information about the Evergreen-dev mailing list