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

[Galen Charlton]

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
> 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
>> 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
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
<http://evergreen-ils.org>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20240221/e6590c02/attachment-0001.htm>