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

[Linda Jansová via Evergreen-general]

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=search=HEAD=grep=%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=search=HEAD=grep=%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=-1 
=)


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

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

[Linda Jansová via Evergreen-general]

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=search=HEAD=grep=%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=search=HEAD=grep=%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=-1 
=)


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 ). 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
jbo...@equinoxoli.org
+1 (877) Open-ILS (673-6457)
https://equinoxOLI.org/

On Jun 19, 2023, at 8:30 AM, Linda Jansová via Evergreen-general 
 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:

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

[Linda Jansová via Evergreen-general]

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
jbo...@equinoxoli.org
+1 (877) Open-ILS (673-6457)
https://equinoxOLI.org/

On Jun 19, 2023, at 8:30 AM, Linda Jansová via Evergreen-general 
 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

14-05-14.png>___

Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general


___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

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

[Jason Boyer via Evergreen-general]

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
jbo...@equinoxoli.org
+1 (877) Open-ILS (673-6457)
https://equinoxOLI.org/

> On Jun 19, 2023, at 8:30 AM, Linda Jansová via Evergreen-general 
>  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
> 
>  14-05-14.png>___
> Evergreen-general mailing list
> Evergreen-general@list.evergreen-ils.org
> http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general

___
Evergreen-general mailing list
Evergreen-general@list.evergreen-ils.org
http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general