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 =
$window.location.href.replace(
/(\?|\&).*/,
'?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.
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?