Library card request - untranslated error message

Bug #1613709 reported by Eva Cerninakova on 2016-08-16
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

When "non English language"is set in OPAC
- and patron requests a library card via OPAC ( .../eg/opac/register)
- and invalid date is provided
the error message pop-up window:
"You have entered an invalid date, or an improperly formatted date. Please enter Date of Birth in YYYY-MM-DD or YYYY/MM/DD format and try again"
is not translated.

(tested in Evergreen 2.10.5, cs-CZ)

Ben Shum (bshum) wrote :

For reference, that alert seems to come from this file in the source: Open-ILS/src/templates/opac/parts/js.tt2

And yes, appears to be untranslatable.

Changed in evergreen:
status: New → Confirmed
importance: Undecided → Medium
tags: added: i18n
Eva Cerninakova (ece) wrote :

The reference was very helpful :-) Thanks a lot
I have modified the code in Open-ILS/src/templates/opac/parts/js.tt2 (the line 10) to:

            alert ("[% l('You have entered an invalid date, or an improperly formatted date. Please enter Date of Birth in YYYY-MM-DD or YYYY/MM/DD format and try again.') %]")

and added the translation of the string to cs-CZ.po file
Now the error message is translated properly, so I think this piece of code could be used as a patch (if the patch hasn´t been created yet).

But I think I have discovered there is a wrong information in the date of birth field example and in the error message - I don´t think the YYYY/MM/DD format work: when the date of birth in the patron registration form is entered in this format, the field remain blank when the pending patron is loaded in the staff client.
I have tested this both in the Czech and the English OPAC and both in the English and the Czech staff client locale (not the web staff client) and with the original js.tt2 file (just to be sure my modification or the file is has not been the source of the problem).
The YYYY-MM-DD format is O.K.

Jason Stephenson (jstephenson) wrote :

The problem is that valid formats for that field can be controlled by a regular expression in a org. unit setting. We can't really factor for sites that customize that setting, so the default string should match the default setting.

If any site customizes that setting, and this string is made translatable, then they can provide their own translation that contains a format matching their regular expression. Even if your OPAC is in English, you can provide your own translations to override/replace the default strings. It's not what most sites do, but it is one way to do it.

Jason Stephenson (jstephenson) wrote :

Yeah, never mind my previous comment. I should have double checked before typing that lie.

Jason Stephenson (jstephenson) wrote :

Actually the regex is right there in the code and it allows a space, a slash, or a dot to separate the date components.

Jason Stephenson (jstephenson) wrote :

I pushed a branch to the working repo. with the simple change recommended by Eva.;a=shortlog;h=refs/heads/user/dyrcona/lp1613709_translatable_alert

Galen Charlton (gmc) wrote :

I've pushed this to master, rel_2_10, and rel_2_9. Thanks, Jason!

Changed in evergreen:
milestone: none → 2.11-beta
tags: added: pullrequest
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