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
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
<evergreen-general@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@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
