Facet names and values in dropdown box are not translated properly acording to chosen TPAC locale

Bug #1703888 reported by Eva Cerninakova
26
This bug affects 4 people
Affects Status Importance Assigned to Milestone
Evergreen
Invalid
Undecided
Unassigned

Bug Description

Facet names and formats in dropdown box does not obey the chosen TPAC locale.
I have tested this in following catalogs:

- Jabok Library catalog (Evergreen 2.10.5).
Nor facets nor values in "format" dropdown box in on the Basic search page (see facet-formats-translations-2.png) or some of the values in dropdown boxes in Advanced Search page are not translated correctly.

- Jabok Library test catalog (Evergreen 2.12.2),
Nor facets nor values in "format" dropdown box in on the Basic search page (see facet-formats-translations-1.png) or some of the values in dropdown boxes in Advanced Search page are not translated correctly.

Note: Both installations mentioned above, contains data from the same Evergreen database. (As most of our patrons use Czech, and we need the Czech catalog at the first place, I decided to "solve" the problem by changing MARC codes value names to Czech expression. Similarly, I set the Czech names for facets. However, this is not ideal, because when English TPAC locale has been chosen, the values have still been displayed in Czech.)

- Terezín Initiative Institute test catalog,
Facet names are translated correctly, but this does not apply to "Format" dropdown box in on the Basic search page (see image facet-formats-translations-3.png) or some of the values in dropdown boxes in Advanced Search page

- Laurentian University catalog
Facet names are translated correctly, but this does not apply to "Format" dropdown box in on the Basic search page (see image facet-formats-translations-3.png) or some of the values in dropdown boxes in Advanced Search page.

Summary:
1) The values in dropdown boxes are not displayed correctly in any of the catalogs I have tested. However, I was not able to find the pattern for translated/untranslated values in the Advanced Search Dropdown boxes (why some of them are translated and why some are not).
2) The facet names are not displayed correctly only in both catalogs containing Jabok Library data (however, I know some other libraries came across the same problem too). Probably this might not be caused by a bug but (e.g.,by some setting inherited from some of the used previous Evergreen versions?

Tags: i18n
Revision history for this message
Eva Cerninakova (ece) wrote :
Revision history for this message
Eva Cerninakova (ece) wrote :
Revision history for this message
Eva Cerninakova (ece) wrote :
Revision history for this message
Eva Cerninakova (ece) wrote :
summary: - Facet names and formats in dropdown box are not translated properly
- acordin to chosen TPAC locale
+ Facet names and values in dropdown box are not translated properly
+ acording to chosen TPAC locale
Revision history for this message
Ben Shum (bshum) wrote :

Hi Eva,

Basically, the problem you're seeing is that your entries in database table config.i18n_core do not match up the english database values for the fields you wish to see translated. This content is based on the fieldmapper design and how we define what the label is to be translated for the database value.

I identified several problems with the "filter by" fields and other db.seed i18n issues in bug 1160347 (https://bugs.launchpad.net/evergreen/+bug/1160347). There is a working branch on that with partial progress towards fixing the mismatches in the db.seed data.

In my own test server, I can see that as long as I load the correspondingly generated db.seed file for Czech and the expected values match, I can get translated values for the facets. Fixing the translated values for the filter by fields will come with the changes I proposed in my working branch, along with re-building the i18n PO file for db.seed's templates.

A related bug is this one reported by Dan Scott regarding db.seed PO file containing duplicate IDs which breaks the generated SQL files too by creating too many INSERT SQL statements with duplicate ID values (see bug 1681864 - https://bugs.launchpad.net/evergreen/+bug/1681864); I proposed a fix in that bug as well to remove the duplicate IDs and generate cleaner source files in the future.

I'll try to follow up on my original branches to clean up the source data files for db.seed and hopefully we can get it integrated into master for the upcoming 3.0 series.

Revision history for this message
Ben Shum (bshum) wrote :

This is an example screenshot from my test server (running recent master with fixes I'm creating in the previously mentioned branches in the other bugs) where it shows the working translated facet values and also the format picker (although not 100% translated, perhaps)

Revision history for this message
Eva Cerninakova (ece) wrote :

Hi Ben,

It looks promising. :-) Thanks for the information and the work you have done (we really appreciate it because the problems with localization are not only a complication for Evergreen users but also a handicap to the promotion of Evergreen in the Czech Republic).

Andrea Neiman (aneiman)
tags: added: i18n
Revision history for this message
Ben Shum (bshum) wrote :

Not sure if we should close this bug as "invalid" since it seems like the problem should be resolved in newer systems once the latest db.seed changes take effect and are translated and inserted in config.i18n_core. Question to the team prior to closing this issue.

Changed in evergreen:
status: New → Incomplete
Revision history for this message
Eva Cerninakova (ece) wrote :

- We have followed Bens steps and I can confirm that it works with our Evergreen installation.

- Before closing this issue, it would be useful to include the information about loading translation from the associated 950.data.seed-values-xx-YY.sql to documentation or to the README process for setting up a new server.

Revision history for this message
Eva Cerninakova (ece) wrote :

The "Audience" string for advanced search filter is missing in db.seed template.

Revision history for this message
Ben Shum (bshum) wrote :

The "Audience" string is in db.seed template but is mistranslated in cs-CZ.po locale. In that file, it shows up as:

msgid "Audience"
msgstr "Audience"

Looking at translations in LP, I see that it was applied with that translation back in March 2017. Probably needs to be translated appropriately in there. I changed it in LP to "Čtenářské určení" based on the suggestion it presented from another of Eva's translations. The next sync from LP to master should catch and fix that.

In the meantime, I updated the string on my Czech test server and it appears to be functional now.

I found the mistake in my config.i18n_core table using:

SELECT * FROM config.i18n_core WHERE translation = 'cs-CZ' AND string = 'Audience';

That got me the ID I needed to use to update and fix the entry using the corrected value:

UPDATE config.i18n_core SET string = 'Čtenářské určení' WHERE id = XXXX;

Restarted everything to clear caches, and it worked for me.

Revision history for this message
Eva Cerninakova (ece) wrote :

Thanks Ben
"Čtenářské určení" is the right term.
 I a am sorry for confusion - I must probably had make a typo yesterday when I was looking for Audience in db.seed

Revision history for this message
Eva Cerninakova (ece) wrote :

We have not found this problem in any of our new Evergreen installation we have done within the last year. Facet and dropdown boxes are always translated properly, so I would say the bug is no more relevant.

I suggest this bug to be closed (it is only important to make sure that the information about loading translation from the associated 950.data.seed-values-xx-YY.sql is always included to documentation or to the README process for Evergreen server installation).

Revision history for this message
Terran McCanna (tmccanna) wrote :

Thanks Eva and Ben, I will mark it as "Invalid" since it should be resolved.

Changed in evergreen:
status: Incomplete → Invalid
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.