webclient: locale picker does not work well

Bug #1560805 reported by Ben Shum on 2016-03-23
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

Evergreen master / 2.10 / probably earlier

Now that we have an initial translation updated for webstaff from the Czech users, I tried installing and setting up the translation for the new web-based staff client. Use of the locale picker proved problematic however.

To test, added locales to the /eg/staff/ configuration, there are samples in eg_vhost.conf that explain how to do this.

Once active, there will be a new dropdown added to the menu area for the locale picker with the languages available for use.

When you click on the picker and choose a language, depending on the URL you are on, it may or may not work at all. If there are no current variables in the URL (like hostname/eg/staff/somepage?some_variable&some_more_variables), then the web client will not change locales if you pick another language. It will just refresh with no change. The current picker does a replace on whatever value are assigned in the URL and puts in ?eg_set_locale=language to set the language. This approach is different from how we do things for the TPAC.

The problem code seems to arrive from Open-ILS/web/js/ui/default/staff/services/navbar.js, around line 70:

                $scope.applyLocale = function(locale) {
                    // EGWeb.pm can change the locale for us w/ the right param
                    // Note: avoid using $location.search() to derive a new
                    // URL, since it creates an intermediate path change.
                    // Instead, use the ham-fisted approach of killing any
                    // search args and applying the args we want.
                    $window.location.href =
                            '?set_eg_locale=' + encodeURIComponent(locale)

That window.location.href.replace is problematic for what the regex is trying to match on.

I'm not sure if a change to the regex to allow for the possibility that we might just be on a page like hostname/eg/staff/somepage, without any variables might be the right choice. Or if getting rid of the javascript approach entirely and trying to model it closer to how TPAC functions might be better.

Reporting for now, will look at it more in the coming days.

Ben Shum (bshum) wrote :

Some additional testing notes...

Once you get past this initial hurdle of figuring out how to set the locale, the locale itself does not always apply fully to the web client's strings. So sometimes I found that if I set the locale using the cookie, it'll change the menu names, but not the strings on the links or page content. Or it'll change the page content, but not the menus. It takes a couple browser refreshes to fully translate the page. So perhaps some caching issue during i18n switch?

Chris Sharp (chrissharp123) wrote :

I can confirm this behavior on current master.

Changed in evergreen:
status: New → Confirmed
Linda Jansova (skolkova-s) wrote :

Using web staff client https://i18n.evergreener.net/eg/staff/ (Ben's Bug Squashing Week test server) I can confirm that the issue persists. Changing locale isn't a straightforward process in Evergreen master from May 22nd, 2018, either.

Bill Erickson (berick) wrote :

Fix pushed:


I just replaced the regex/replace with a static destination URL. Any time the locale is changed, the user is sent to the home/splash page.

Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
status: Confirmed → In Progress
tags: added: pullrequest
Changed in evergreen:
milestone: none → 3.1.2
assignee: Bill Erickson (berick) → nobody
status: In Progress → Confirmed
importance: Undecided → Medium
Ben Shum (bshum) wrote :

Loaded Bill's fix to my public i18n server for testing. The initial page change does seem to work, but there are still issues presenting from switching between languages.

First of all, if you haven't logged into the client, changing the locale doesn't do anything other than make the reroute URL change (like hostname/eg/staff/login?route_to=%2Feg%2Fstaff%2F%3Fset_eg_locale%3Dcs_cz, which appears just to be the entity-ized version of the cookie change variable tacked on).

If you are logged in, the very first change seems to alter the cookie setting. However, picking a different language, or the original language, does not seem to actually submit or alter the cookie itself.

Steps to repeat:

1) Log into the web client (register workstation, etc. for first time)
2) Pick another language, like Czech; the client changes the cookie for eg_locale to "cs-CZ"
3) Pick another language, like Spanish; the URL changes so that it appears with the appended ?set_eg_locale=es-ES, but looking at the actual cookie, the language code is still cs-CZ. The next page refresh or submit then changes it.

Continuing testing and analysis, but perhaps not a simple tweak.

Linda Jansova (skolkova-s) wrote :

I have tested it - using Ben's i18n server - taking the following steps:

1) First of all, I cleared all browsing data (including cookies) from Chrome.

2) I entered https://i18n.evergreener.net/eg/staff/. The interface was all in English (English was a default choice in the locale picker.)

3) I logged in, registered a workstation for BR1 and chose that particular workstation.

4) In the locale picker I switched to Czech, resulting in seeing Czech menu but main content on the page remained in English (even after multiple Ctrl+Rs).

5) I logged out of the web client and cleared all browsing data again.

6) I entered https://i18n.evergreener.net/eg/staff/, again seeing the all-English interface.

7) I picked Czech from the locale picker. The menu switched to Czech but the main part of the page remained in English.

8) I logged in again and both menu and the main part of the page were in Czech.

This might mean that - when it comes to switching from one language to another - the right thing happens when one logs in but not when one is either logged out or remains logged in. Could that be a clue?

Linda Jansova (skolkova-s) wrote :

Menu in Czech and main content in English

Linda Jansova (skolkova-s) wrote :

When one switches to Czech before logging in, the menu language changes while the remainder of the page does not.

Changed in evergreen:
milestone: 3.1.2 → 3.1.3
Changed in evergreen:
milestone: 3.1.3 → 3.1.4
Changed in evergreen:
milestone: 3.1.4 → 3.1.5
Bill Erickson (berick) on 2018-07-27
Changed in evergreen:
assignee: nobody → Bill Erickson (berick)
Bill Erickson (berick) wrote :

Hmm, I'm unable to reproduce these issues with my patch. I'm testing in Chrome, rebased to current master. Before logging in and after logging in, every change in the locale selector results in a cookie change for eg_locale (I have dev tools sitting open), a page reload, and content change both in the navbar and the body of the page. I get the same behavior with or without dev tools open (i.e. letting the browser cache do it's thing).

I attempted to test on Ben's test server, but it appears to be offline at the moment.

Ben, any chance you have NGINX (or other) caching enabled on your test server?

BTW, I have OILSWebCompiledTemplateCache set. Cached templates still generate the replaceable strings dynamically, though, so no surprise it's working OK.

Changed in evergreen:
assignee: Bill Erickson (berick) → nobody
Changed in evergreen:
milestone: 3.1.5 → 3.1.6
Eva Cerninakova (ece) wrote :

I don't know whether this might be helpful:
I have found that the "best" way to switch fully to another language interface at the moment is to start by changing the language in OPAC first. The web staff client than take the language from the OPAC settings without necessity to change the language using locale picker in the client. To switching to another language again using the same method needs clearing the cache before.
I have tried on 3.2 beta sandbox in Chrome, Firefox, Opera and Firefox for mobile devices.

Linda Jansova (skolkova-s) wrote :

When I used Ben's 3.2 beta1 test server for the first time (earlier this week), I actually couldn't successfully switch the web client to Czech without switching the OPAC to Czech first. After switching the OPAC to Czech, the web client could also be in Czech.

Changed in evergreen:
milestone: 3.1.6 → 3.2.1
Changed in evergreen:
milestone: 3.2.1 → 3.2.2
Changed in evergreen:
milestone: 3.2.2 → 3.2.3
Changed in evergreen:
status: Confirmed → New
milestone: 3.2.3 → 3.3-beta1
Changed in evergreen:
milestone: 3.3-beta1 → 3.3-rc
Changed in evergreen:
milestone: 3.3-rc → 3.3.1
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers