[Evergreen-dev] [Evergreen-general] Evergreen 3.11.0a not properly switching into Czech in the staff client

[Linda Jansová]

Dear all,

As we are still struggling to make Czech work in our staff client, we 
have just upgraded our demo installation to 3.11.1 to see whether the 
issue still persists (it does) and also to have an easier way to share 
with you what exactly happens.

The 3.11.1 demo installation is now available at:

https://evergreendemo.jabok.cuni.cz/ (OPAC)

https://evergreendemo.jabok.cuni.cz/eg/staff/ (web staff client)

Apart from our usual logins (see also 
https://wiki.evergreen-ils.org/doku.php?id=community_servers) we have 
now also added the standard username/password combination of admin and 
demo123.

It appears that those parts of the staff client which have /eg in the 
URL (e.g., 
https://evergreendemo.jabok.cuni.cz/eg/staff/circ/patron/bcsearch) are 
in Czech.

Those parts which have /eg2 in the path (e.g., 
https://evergreendemo.jabok.cuni.cz/eg2/staff/cat/bib-from/id) keep 
redirecting to en-US (as was also noted earlier in this thread) while 
also the home icon changes to just one letter (ů) and the correct 
translations of Search (which is Hledat) and Cataloging (which is 
Katalogizace) become invisible in the menu, letting us to choose the 
menu items only by using the arrows.

We very much look forward to upgrading to Evergreen 3.11 because it 
offers so many new exciting features but as most Czech librarians 
working with Evergreen are not proficient in English, we have to 
postpone the upgrade until Evergreen starts speaking Czech again...

Do you have any ideas what could be wrong and, subsequently, how to fix it?

Thank you very much for sharing your insights!

Linda


On 6/22/23 08:18, Linda Jansová wrote:
>
> Hi Jason and others,
>
> Given your hint that the heart of the issue might lie in the eg to eg2 
> transitions, we did some more tests which have led us to the following 
> observations:
>
> After logging in (at /eg/staff) one gets redirected to 
> /eg2/en-US/staff/admin/workstation/workstations/manage.
>
> I am not sure whether it is important or not (well, maybe not) but I 
> have found one hardcoded occurrence of this part of URL in the code:
>
> https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2Fstaff%2Fadmin%2Fworkstation%2Fworkstations%2Fmanage 
> <https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2Fstaff%2Fadmin%2Fworkstation%2Fworkstations%2Fmanage>
>
> There are also a couple of other cases where a URL with /eg2/en-US is 
> being explicitly used:
>
> https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2F 
> <https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2F>
>
> (Perhaps there are some more when the URL is combined from smaller 
> chunks of text and so it is not that easy to spot the places where 
> these might pop up.)
>
> Getting back to the logging in process: when being at 
> /eg2/en-US/staff/admin/workstation/workstations/manage, we have 
> noticed the following error:
>
> /eg/staff/t_splash (Error: [$compile:tpload] Failed to load template: 
> ./t_splash (HTTP status: -1 )
>
> https://errors.angularjs.org/1.6.10/$compile/tpload?p0=.%2Ft_splash&p1=-1&p2 
> <https://errors.angularjs.org/1.6.10/$compile/tpload?p0=.%2Ft_splash&p1=-1&p2>=)
>
> When we tried to go to /eg/staff/t_splash in the browser, we actually 
> saw the webpage (even correctly translated to Czech, especially after 
> letting the browser repair encoding as this was actually just a part 
> of a HTML page beginning with <div class="container">). So it seems to 
> be there...
>
> We also tried to have a closer look at our eg_vhost.conf. In it we 
> have both Czech and English enabled:
>
> # cs-CZ
>
> RewriteCond %{REQUEST_URI} ^/eg2/
>
> RewriteCond %{REQUEST_URI} !^/eg2/cs-CZ/
>
> RewriteCond %{HTTP_COOKIE} eg_locale=cs_cz
>
> RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/cs-CZ/$1 [NE,R=307,L]
>
>
> # Default / en-US.
>
> # No alternate supported cookie provided.
>
> RewriteCond %{REQUEST_URI} ^/eg2/
>
> RewriteCond %{REQUEST_URI} !^/eg2/([a-z]{2}-[A-Z]{2})/
>
> RewriteRule ^/eg2/(.*) https://%{HTTP_HOST}/eg2/en-US/$1 [NE,R=307,L]
>
> When we tried to disable the English part of it, we saw 404s in our 
> staff client. So this is definitely not a way to go (although – in 
> theory – if this worked, we would probably be quite happy living with 
> Czech as the only language for our staff client interface).
>
> I was also thinking that perhaps the eg_vhost.conf may include some 
> rewrites to cover the cases of switching between eg and eg2 but 
> couldn’t locate any. So this logic is probably described somewhere else...
>
> Although we are most likely on the wrong track, I thought it might be 
> useful to share our findings anyway (if not anything else, then 
> perhaps it could to help narrow down the search scope)…
>
> Linda
>
>
> On 6/20/23 22:35, Linda Jansová wrote:
>> Hi Jason,
>>
>> Thank you very much for looking into this!
>>
>> Perhaps it may be useful - especially now that it seems that the 
>> cookies are not to blame for this :-) - to mention that we are on 
>> Ubuntu 20.04 LTS and the latest OpenSRF tarball has been used.
>>
>> If there is any other piece of information that might be useful, we 
>> will be more than happy to provide it.
>>
>> Linda
>>
>> On 6/20/23 22:10, Jason Boyer wrote:
>>> Hi Linda. I've looked at this a bit today and can say that it 
>>> shouldn't have anything to do with that cookie message. It seems 
>>> like the transition between the Angular (/eg2/) and AngularJS (/eg/) 
>>> sides of the client doesn't work correctly, but I do see in the 
>>> browser console "Applying locale cs-CZ" so the cookie is arriving 
>>> and being parsed as expected, but for some reason isn't taking 
>>> effect. I'll keep looking but wanted to let you know that I do at 
>>> least have an idea what it *isn't*. :)
>>>
>>> Jason
>>>
>>> -- 
>>> Jason Boyer
>>> Senior System Administrator
>>> Equinox Open Library Initiative
>>> JBoyer at equinoxOLI.org
>>> +1 (877) Open-ILS (673-6457)
>>> https://equinoxOLI.org/
>>>
>>>> On Jun 19, 2023, at 8:30 AM, Linda Jansová via Evergreen-general 
>>>> <evergreen-general at list.evergreen-ils.org> wrote:
>>>>
>>>> Dear all,
>>>>
>>>> We have just installed Evergreen 3.11.0a (it is a fresh install 
>>>> from the tarball) and have proceeded to setting up Czech as a 
>>>> language to be used not only in the Bootstrap OPAC but also in the 
>>>> staff client.
>>>>
>>>> However, it seems that the staff client does not reliably keep 
>>>> Czech as the interface language beyond the login screen.
>>>>
>>>> After logging into the staff client (with the original login screen 
>>>> being in Czech), a browser developer tool in Firefox says that 
>>>> "Some cookies are misusing the recommended “SameSite“ attribute" 
>>>> (the attached screenshot provides the same information in a visual 
>>>> format).
>>>>
>>>> There is a link that provides more information on the nature of the 
>>>> attribute:
>>>>
>>>> https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value
>>>>
>>>> It appears that eg.auth.token and eg.auth.time do not provide a 
>>>> valid value for the aforementioned SameSite attribute, meaning that 
>>>> Lax (as a fallback value) is used instead. This, according to 
>>>> Mozilla.org, "Means that the cookie is not sent on cross-site 
>>>> requests, such as on requests to load images or frames, but is sent 
>>>> when a user is navigating to the origin site from an external site 
>>>> (for example, when following a link). This is the default behavior 
>>>> if the |SameSite| attribute is not specified."
>>>>
>>>> Could that be a reason why the staff client does not honor the 
>>>> selected locale and keeps changing things from Czech to English 
>>>> (and sometimes also vice versa)?
>>>>
>>>> If so, do you have any idea how to properly fix it?
>>>>
>>>> If not, where else should we look?
>>>>
>>>> I am also attaching our eg_vhost.conf with our current setup.
>>>>
>>>> Thank you very much for any kind of help provided!
>>>>
>>>> Linda
>>>>
>>>> <eg_vhost.conf><Screenshot at 2023-06-19 
>>>> 14-05-14.png>_______________________________________________
>>>> Evergreen-general mailing list
>>>> Evergreen-general at list.evergreen-ils.org
>>>> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.evergreen-ils.org/pipermail/evergreen-dev/attachments/20230728/f0edef94/attachment.htm>