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
<[email protected]> 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
[email protected]
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 <[email protected]> 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
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
--
Galen Charlton
Implementation and IT Manager
Equinox Open Library Initiative
[email protected]
https://www.equinoxOLI.org <https://www.equinoxOLI.org>
phone: 877-OPEN-ILS (673-6457)
direct: 770-709-5581
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
_______________________________________________
Evergreen-dev mailing list
[email protected]
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-dev
