patron alert block are shown untranslated

Bug #1770981 reported by Eva Cerninakova on 2018-05-13
This bug affects 5 people
Affects Status Importance Assigned to Milestone

Bug Description

Patron system generated block and alerts are shown untranslated in the web staff client Evergreen 3.1.1), see the attachment.
Note: The alert and block strings are included into

Eva Cerninakova (ece) wrote :
tags: added: i18n webstaffclient
Eva Cerninakova (ece) on 2018-07-26
tags: added: webstaffblocker
Bill Erickson (berick) wrote :

Eva, can you confirm no data exists in the database matching this query?

select * from config.i18n_core where fq_field = 'csp.label' and identity_value = '1';

From my tests, the UI will display the translated values if they exist, so I assume the issue is there is no way to create the translations? (I don't see one in the admin UI).

Eva Cerninakova (ece) wrote :

I tried the query. The translation value exist in the database (but is not shown in the staff client - currently in Evergreen 3.1.4).

Bill Erickson (berick) wrote :

Thanks, Eva. The locale for the database entry matches your login locale? Can you confirm it shows the translated value in the XUL client? What version of OpenSRF are you running?

I'm on Evergreen master, using en-US, and I have a row like this:

id | 1
fq_field | csp.label
identity_value | 1
translation | en-US

Which appears in the screen (see attached).

Eva Cerninakova (ece) wrote :

The database entry matches the login locale.
In XUL client the value is translated (see attachment).
We are runnig OpenSRF 3.0.1

Bill Erickson (berick) wrote :

Hoping someone else with a 3.1 server can confirm this behavior. Running multiple locales is not required. All that's required is adding an en-US (or other) translation to the database and see if the web client loads it instead of the default value when viewing a patron with the exceeds-fine penalty.

To test, add a row to the database:

insert into config.i18n_core
(fq_field, identity_value, translation, string)
values ('csp.label', '1', 'en-US', 'Patron Exceeds Fines Test Translation');

Will ping IRC...

Kathy Lussier (klussier) wrote :

I followed Bill's steps on a server running 3.1.4. I see the "Patron Exceeds Fines Test Translation" alert in the patron sidebar, on the Message tab, and on the Stop Sign alert screen.

Bill Erickson (berick) wrote :

Thanks, Kathy. Glad it's not a 3.1 thing. After you tested, I decided to also try a non-en-US translation and finally hit a road block. I set my locale to fr-CA and it still wants to load the en-US translation. Closer inspection showed the locale of the OpenSRF message (for API set to en-US instead of fr-CA. If OpenSRF is not relaying the correct locale in the browser client, that would explain a few things. Looking closer...

Bill Erickson (berick) wrote :

Confirmed the local was not getting properly set at the network/OpenSRF layer. Patch en route...

Bill Erickson (berick) wrote :

Fix pushed:;a=shortlog;h=refs/heads/user/berick/lp1770981-webstaff-apply-osrf-locale

Code translates the values from the eg_locale cookie into the OpenSRF global local variable to ensure all network calls are stamped with the correct locale. I suspect this will fix a number of i18n data display issues.

I suspect the issues noted in bug #1560805 are to some extend related.

Changed in evergreen:
milestone: none → 3.1.5
status: New → Confirmed
importance: Undecided → High
tags: added: pullrequest
Eva Cerninakova (ece) wrote :

Bill, Kathy, thanks a lot - it is really promissing ;-)

Ben Shum (bshum) wrote :

Worked for me on my test system. Pushed fix to master and backported to rel_3_1 and rel_3_0.

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