<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">
<p style="line-height: 100%; margin-bottom: 0in">
Dear all,</p>
<p style="line-height: 100%; margin-bottom: 0in">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.</p>
<p style="line-height: 100%; margin-bottom: 0in">The 3.11.1 demo
installation is now available at:</p>
<p style="line-height: 100%; margin-bottom: 0in"><a class="moz-txt-link-freetext" href="https://evergreendemo.jabok.cuni.cz/">https://evergreendemo.jabok.cuni.cz/</a>
(OPAC)</p>
<p style="line-height: 100%; margin-bottom: 0in"><a class="moz-txt-link-freetext" href="https://evergreendemo.jabok.cuni.cz/eg/staff/">https://evergreendemo.jabok.cuni.cz/eg/staff/</a>
(web staff client)</p>
<p style="line-height: 100%; margin-bottom: 0in">Apart from our
usual
logins (see also
<a
href="https://wiki.evergreen-ils.org/doku.php?id=community_servers"
class="moz-txt-link-freetext">https://wiki.evergreen-ils.org/doku.php?id=community_servers</a>)
we have now also added the standard username/password
combination of
admin and demo123.</p>
<p style="line-height: 100%; margin-bottom: 0in">It appears that
those parts of the staff client which have /eg in the URL (e.g.,
<a
href="https://evergreendemo.jabok.cuni.cz/eg/staff/circ/patron/bcsearch"
class="moz-txt-link-freetext">https://evergreendemo.jabok.cuni.cz/eg/staff/circ/patron/bcsearch</a>)
are in Czech.</p>
<p style="line-height: 100%; margin-bottom: 0in">Those parts which
have /eg2 in the path (e.g.,
<a
href="https://evergreendemo.jabok.cuni.cz/eg2/staff/cat/bib-from/id"
class="moz-txt-link-freetext">https://evergreendemo.jabok.cuni.cz/eg2/staff/cat/bib-from/id</a>)
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.</p>
<p style="line-height: 100%; margin-bottom: 0in">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...</p>
<p style="line-height: 100%; margin-bottom: 0in">Do you have any
ideas what could be wrong and, subsequently, how to fix it?</p>
<p style="line-height: 100%; margin-bottom: 0in">Thank you very
much
for sharing your insights!</p>
<p style="line-height: 100%; margin-bottom: 0in">Linda</p>
<p style="line-height: 100%; margin-bottom: 0in"><br>
</p>
</div>
<div class="moz-cite-prefix">
<style type="text/css">p { line-height: 115%; margin-bottom: 0.1in; background: transparent }a:link { color: #000080; text-decoration: underline }</style>On
6/22/23 08:18, Linda Jansová wrote:<br>
</div>
<blockquote type="cite"
cite="mid:d339951e-e7e5-7a91-e1a2-72c08bcdf498@gmail.com">
<div class="moz-cite-prefix">
<p> Hi Jason and others,</p>
<p>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:</p>
<p>After logging in (at /eg/staff) one gets redirected to
/eg2/en-US/staff/admin/workstation/workstations/manage.</p>
<p>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:</p>
<p><a
href="https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2Fstaff%2Fadmin%2Fworkstation%2Fworkstations%2Fmanage"
moz-do-not-send="true">https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2Fstaff%2Fadmin%2Fworkstation%2Fworkstations%2Fmanage</a></p>
<p>There are also a couple of other cases where a URL with
/eg2/en-US is being explicitly used:</p>
<p><a
href="https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2F"
moz-do-not-send="true">https://git.evergreen-ils.org/?p=Evergreen.git&a=search&h=HEAD&st=grep&s=%2Feg2%2Fen-US%2F</a></p>
<p>(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.)</p>
<p>Getting back to the logging in process: when being at
/eg2/en-US/staff/admin/workstation/workstations/manage, we
have noticed the following error:</p>
<p>/eg/staff/t_splash (Error: [$compile:tpload] Failed to load
template: ./t_splash (HTTP status: -1 )</p>
<p><a
href="https://errors.angularjs.org/1.6.10/$compile/tpload?p0=.%2Ft_splash&p1=-1&p2"
moz-do-not-send="true">https://errors.angularjs.org/1.6.10/$compile/tpload?p0=.%2Ft_splash&p1=-1&p2</a>=)</p>
<p>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...</p>
<p>We also tried to have a closer look at our eg_vhost.conf. In
it we have both Czech and English enabled:</p>
<p># cs-CZ</p>
<p>RewriteCond %{REQUEST_URI} ^/eg2/</p>
<p>RewriteCond %{REQUEST_URI} !^/eg2/cs-CZ/</p>
<p>RewriteCond %{HTTP_COOKIE} eg_locale=cs_cz</p>
<p>RewriteRule ^/eg2/(.*) <a class="moz-txt-link-freetext"
href="https://%" moz-do-not-send="true">https://%</a>{HTTP_HOST}/eg2/cs-CZ/$1
[NE,R=307,L]</p>
<p><br>
</p>
<p># Default / en-US.</p>
<p># No alternate supported cookie provided.</p>
<p>RewriteCond %{REQUEST_URI} ^/eg2/</p>
<p>RewriteCond %{REQUEST_URI} !^/eg2/([a-z]{2}-[A-Z]{2})/</p>
<p>RewriteRule ^/eg2/(.*) <a class="moz-txt-link-freetext"
href="https://%" moz-do-not-send="true">https://%</a>{HTTP_HOST}/eg2/en-US/$1
[NE,R=307,L]</p>
<p>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).</p>
<p>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...</p>
<p>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)…</p>
<p>Linda</p>
<p><br>
</p>
</div>
<div class="moz-cite-prefix"> </div>
<div class="moz-cite-prefix"> On 6/20/23 22:35, Linda Jansová
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:ccd88fc1-55e3-a98e-3044-830a2b9a2ac5@gmail.com">
<div class="moz-cite-prefix">Hi Jason,</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Thank you very much for looking
into this!</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">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. <br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">If there is any other piece of
information that might be useful, we will be more than happy
to provide it.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Linda<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 6/20/23 22:10, Jason Boyer
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2F5EE2B5-BE97-47C6-9944-7F98F2902BB6@equinoxOLI.org">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*. :)
<div><br>
</div>
<div>Jason<br>
<div>
<div>
<div dir="auto">
<div dir="auto">
<div dir="auto">
<div><br>
-- <br>
Jason Boyer<br>
Senior System Administrator<br>
Equinox Open Library Initiative<br>
<a class="moz-txt-link-abbreviated
moz-txt-link-freetext"
href="mailto:JBoyer@equinoxOLI.org"
moz-do-not-send="true">JBoyer@equinoxOLI.org</a><br>
+1 (877) Open-ILS (673-6457)<br>
<a class="moz-txt-link-freetext"
href="https://equinoxOLI.org/"
moz-do-not-send="true">https://equinoxOLI.org/</a></div>
</div>
</div>
</div>
</div>
<div><br>
<blockquote type="cite">
<div>On Jun 19, 2023, at 8:30 AM, Linda Jansová via
Evergreen-general <a class="moz-txt-link-rfc2396E"
href="mailto:evergreen-general@list.evergreen-ils.org"
moz-do-not-send="true"><evergreen-general@list.evergreen-ils.org></a>
wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div>
<p>Dear all,</p>
<p>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.</p>
<p>However, it seems that the staff client does
not reliably keep Czech as the interface
language beyond the login screen.<br>
</p>
<p>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).<br>
</p>
<p>There is a link that provides more information
on the nature of the attribute:<br>
</p>
<p><a class="moz-txt-link-freetext"
href="https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value"
moz-do-not-send="true">https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Set-Cookie#samesitesamesite-value</a></p>
<p>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 <code>SameSite</code> attribute is not
specified."<br>
</p>
<p>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)?</p>
<p>If so, do you have any idea how to properly fix
it?</p>
<p>If not, where else should we look? </p>
<p>I am also attaching our eg_vhost.conf with our
current setup.</p>
<p>Thank you very much for any kind of help
provided!</p>
<p>Linda<br>
</p>
</div>
<span id="cid:CCC0BCBE-6DEC-4C20-89FC-1B95E03CF1A9"><eg_vhost.conf></span><span
id="cid:9FEAD1D1-4AB2-4CD6-B3CD-A39C9FBC4AFF"><Screenshot
at 2023-06-19 14-05-14.png></span>_______________________________________________<br>
Evergreen-general mailing list<br>
<a class="moz-txt-link-abbreviated
moz-txt-link-freetext"
href="mailto:Evergreen-general@list.evergreen-ils.org"
moz-do-not-send="true">Evergreen-general@list.evergreen-ils.org</a><br>
<a class="moz-txt-link-freetext"
href="http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general"
moz-do-not-send="true">http://list.evergreen-ils.org/cgi-bin/mailman/listinfo/evergreen-general</a><br>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
<p><br>
</p>
</blockquote>
<p><br>
</p>
</blockquote>
<p><br>
</p>
</body>
</html>