Problem when displaying Czech (or another language?) strings in TPAC

Bug #1373578 reported by Eva Cerninakova
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Evergreen
Undecided
Unassigned
2.9
Undecided
Unassigned

Bug Description

In Evergreen 2.6.2 I have discovered some problems with displaying Czech strings in TPAC which I guess have something to do with translation file cs-CZ.po (or possibly with translation files for another languages too).

1) If "has local copy alert" is set to "true" In the Library settings editor when user places a hold and there is a local copy available in the library then usually the message appears, that the "hold was not successfully placed" and the action must be canceled or overridden.

When the OPAC language is set to English, this message is displayed :
 "Problem: There is already copy available at you local library" - see http://knihovna.jabok.cz/Evergreen/snapshots/hold-overrriding-en.jpg

But if the Czech is on in the OPAC, instead of the "tanslated" message "There is already copy available at you local library" looks like this:

"Project-Id-Version: evergreen Report-Msgid-Bugs-To: FULL NAME POT-Creation-Date: YEAR-MO-DA HO:MI+ZONE PO-Revision-Date: 2012-05-05 14:07+0000 Last-Translator: Eva Cerninakova Language-Team: Czech MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Generator: Launchpad (build 15195) X-Launchpad-Export-Date: 2012-05-06 04:45+0000"

(see http://knihovna.jabok.cz/Evergreen/snapshots/hold-overrriding-cz.jpg).

I guess the problem has something to do with the language template file "cs-CZ.po" in /openils/var/data/locale/cs-CZ.po as the string that appears in the "unsuccessful hold" message contains some text from the top of the translation file (see http://knihovna.jabok.cz/Evergreen/cs-CZ.po).

2) When some characters are required in Launchpad translation (like space or line break
(e.g. https://translations.launchpad.net/evergreen/master/+pots/tpac/cs/+translate?batch=10&show=all&search=The+selected+username+may+be+in+use)

it is imported to the language file cs-CZ.po (/openils/var/data/locale/cs-CZ.po) like this:

#: ../../Open-ILS/src/templates/opac/parts/myopac/main_refund_policy.tt2:10
#, fuzzy
msgid "To ensure your necessary receipt information is not lost, enter your email address above and a receipt will be emailed to you. Otherwise, make certain you have a printed receipt in hand before closing the payment receipt screen."
msgstr ""
"Abyste se ujistili, že nedojde ke ztrátě informací \n"
" na potvrzení, vložte svou e-mailovou adresu výše \n"
" a potvrzení vám bude zasláno e-mailem. Nebo,\n"
" než zavřete okno s potvrzením platby,\n"
" ujistěte se, že jste potvrzení vytiskli."

 The problem is, that if the message string is divided into more than one lines (each enclosed with " "), the string is not displayed in TPAC when the language is set to Czech and instead of it the English string (message ID) is used.

Michele Morgan (mmorgan)
summary: - Problem when displayin Czech (or another languge?) strings in TPAC
+ Problem when displaying Czech (or another language?) strings in TPAC
Revision history for this message
Eva Cerninakova (ece) wrote :

The problem described in point 1) still occurs in 2.10 (tested in 2.10.1 on Czech locale)see attachment.

Revision history for this message
Galen Charlton (gmc) wrote :

A patch for the first problem is available at the tip of the user/gmcharlt/lp1373578_dont_maketext_empty_string branch in the working/Evergreen repository:

http://git.evergreen-ils.org/?p=working/Evergreen.git;a=commitdiff;h=4e729cf35c4966648a7fb37cf5f19c8951d02e60

Changed in evergreen:
status: New → Confirmed
tags: added: i18n pullrequest
Revision history for this message
Galen Charlton (gmc) wrote :

Eva, it looks like the second problem is fixed for me in 2.10 -- can you confirm whether it now works for you?

Changed in evergreen:
milestone: none → 2.10.4
Revision history for this message
Eva Cerninakova (ece) wrote :

We have not came across the second problem since 2.8 upgrade. Just for a case I randomly tested some language strings in question in Evergreen 2.10 and I can confirm the problem is positively solved.
Thanks a lot :-)

Changed in evergreen:
milestone: 2.10.4 → 2.10.5
Revision history for this message
Ben Shum (bshum) wrote :

Galen's patch worked for me, pushed it to master, rel_2_10 and rel_2_9.

Changed in evergreen:
status: Confirmed → Fix Committed
Changed in evergreen:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Bug attachments