patron alert block are shown untranslated

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).

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).

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
string | PATRON OWES TOO MUCH

Which appears in the screen (see attached).

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

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...

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.

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 open-ils.actor.user.fleshed.retrieve) 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...

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

Fix pushed:

http://git.evergreen-ils.org/?p=working/Evergreen.git;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.

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

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