Continuation of bug 32551
Created attachment 175238 [details] [review] Bug 38630: Make the REST API respect KohaOpacLanguage cookie The REST API can return translated strings to the opac or staff interface, so it should respect the KohaOpacLanguage cookie and return translations in the same language than the interface. Test plan: 1. Do not apply patch yet 2. Log in to koha staff interface 3. Use the browser's devtools to get the value of CGISESSID cookie 4. Make sure you have at least 2 languages installed ('en' + another one - I'll use 'fr-FR' as an example in this test plan) 5. Find an item and note its itemnumber and itemtype 6. Go translate this itemtype's description (admin » item types » edit item type » translate). Add a translation for 'en' and another one for your language. 7. Close your browser tab (do not logout) and restart Koha to flush the memory cache. 8. Execute the following commands (replace variables by the correct value): curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \ -H 'x-koha-embed: +strings' \ -H "Cookie: KohaOpacLanguage=en; CGISESSID=$CGISESSID" \ | jq -r '._strings.item_type_id.str' If you do not have jq, it can be found in most distributions packages. Or you could inspect the JSON manually at the path /_strings/item_type_id/str Restart Koha again, and execute the same command but with your language set in KohaOpacLanguage cookie: curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \ -H 'x-koha-embed: +strings' \ -H "Cookie: KohaOpacLanguage=fr-FR; CGISESSID=$CGISESSID" \ | jq -r '._strings.item_type_id.str' Depending on how Koha sort the languages (not sure how it's done), you should get either the 'en' one or the 'fr-FR' one, but the important thing is you should get the same translation, no matter what the value of KohaOpacLanguage is, which is the issue this patch is trying to fix. 9. Apply the patch and restart Koha 10. Repeat step 8. This time you should get the translation corresponding to the language set in KohaOpacLanguage cookie Side note: * The need to restart Koha before each request is due to a bug (see bug 38454). If already pushed when you're testing this one, you don't have to restart.
I had a go at testing, but didn't have any luck with step 8. 1. Are these commands issued from within the KTD shell, or your local machine? I tried both (with a restart after each command). 2. I get null as the result: curl -sSL "127.0.0.1:8081/api/v1/items/578" \ -H 'x-koha-embed: +strings' \ -H "Cookie: KohaOpacLanguage=en; CGISESSID=f44da5bb4f1805fced9004f8dab49160" \ | jq -r '._strings.item_type_id.str' null 3. The session id keeps on changing. If I go to access the staff interface again, I get session time out, please log in again, and the session id is different (as expected ?). Testing notes (using KTD): 1. Step 3: - Chromium-based browsers: More tools > Developer tools > Application > Storage > Cookies > [Select website] > CGISESSID 2. Step 4: - Install a translation: koha-translate --install fr-FR --dev kohadev - Koha administration > System preferences > I18/L10N > OPACLanguages and StaffInterfaceLanguages [select languages to enable], opaclanguagedisplay - allow 3. Step 8, from within KTD (also tried from local machine): - sudo apt-get install jq - first execution - result = null: curl -sSL "127.0.0.1:8081/api/v1/items/578" \ -H 'x-koha-embed: +strings' \ -H "Cookie: KohaOpacLanguage=en; CGISESSID=f44da5bb4f1805fced9004f8dab49160" \ | jq -r '._strings.item_type_id.str' null
(In reply to David Nind from comment #2) > I had a go at testing, but didn't have any luck with step 8. > > 1. Are these commands issued from within the KTD shell, or your local > machine? I tried both (with a restart after each command). They should be run from the same machine that is running your browser (so probably your local machine) > 2. I get null as the result: > > curl -sSL "127.0.0.1:8081/api/v1/items/578" \ > -H 'x-koha-embed: +strings' \ > -H "Cookie: KohaOpacLanguage=en; CGISESSID=f44da5bb4f1805fced9004f8dab49160" > \ > | jq -r '._strings.item_type_id.str' > null Can you try to remove the '| jq ...' part to see the full JSON response ? > 3. The session id keeps on changing. If I go to access the staff interface > again, I get session time out, please log in again, and the session id is > different (as expected ?). Maybe you have SessionRestrictionByIP enabled and running the command from within KTD logged you out
Created attachment 176226 [details] [review] Bug 38630: Make the REST API respect KohaOpacLanguage cookie The REST API can return translated strings to the opac or staff interface, so it should respect the KohaOpacLanguage cookie and return translations in the same language than the interface. Test plan: 1. Do not apply patch yet 2. Log in to koha staff interface 3. Use the browser's devtools to get the value of CGISESSID cookie 4. Make sure you have at least 2 languages installed ('en' + another one - I'll use 'fr-FR' as an example in this test plan) 5. Find an item and note its itemnumber and itemtype 6. Go translate this itemtype's description (admin » item types » edit item type » translate). Add a translation for 'en' and another one for your language. 7. Close your browser tab (do not logout) and restart Koha to flush the memory cache. 8. Execute the following commands (replace variables by the correct value): curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \ -H 'x-koha-embed: +strings' \ -H "Cookie: KohaOpacLanguage=en; CGISESSID=$CGISESSID" \ | jq -r '._strings.item_type_id.str' If you do not have jq, it can be found in most distributions packages. Or you could inspect the JSON manually at the path /_strings/item_type_id/str Restart Koha again, and execute the same command but with your language set in KohaOpacLanguage cookie: curl -sSL "$KOHA_URL/api/v1/items/$ITEMNUMBER" \ -H 'x-koha-embed: +strings' \ -H "Cookie: KohaOpacLanguage=fr-FR; CGISESSID=$CGISESSID" \ | jq -r '._strings.item_type_id.str' Depending on how Koha sort the languages (not sure how it's done), you should get either the 'en' one or the 'fr-FR' one, but the important thing is you should get the same translation, no matter what the value of KohaOpacLanguage is, which is the issue this patch is trying to fix. 9. Apply the patch and restart Koha 10. Repeat step 8. This time you should get the translation corresponding to the language set in KohaOpacLanguage cookie Side note: * The need to restart Koha before each request is due to a bug (see bug 38454). If already pushed when you're testing this one, you don't have to restart. Signed-off-by: David Nind <david@davidnind.com>
(In reply to Julian Maurice from comment #3) > (In reply to David Nind from comment #2) > Maybe you have SessionRestrictionByIP enabled and running the command from > within KTD logged you out I turned off SessionRestrictionByIP and StaffLoginLibraryBasedOnIP (both enabled by default in KTD), and everything now works as per the test plan. Thanks Julian!
Looking here
The tidy stuff and a POD failure: WARN C4/Languages.pm WARN tidiness The file is less tidy than before (bad/messy lines before: 210, now: 212) FAIL Koha/Language.pm FAIL pod coverage POD is missing for get_requested_language POD is missing for set_requested_language WARN tidiness The file is less tidy than before (bad/messy lines before: 0, now: 2) WARN t/Languages.t WARN tidiness The file is less tidy than before (bad/messy lines before: 10, now: 16) WARN t/db_dependent/api/v1/items.t WARN tidiness The file is less tidy than before (bad/messy lines before: 180, now: 184)
(In reply to Marcel de Rooy from comment #7) > The tidy stuff and a POD failure: > > WARN C4/Languages.pm > WARN tidiness > The file is less tidy than before (bad/messy lines before: > 210, now: 212) > > FAIL Koha/Language.pm > FAIL pod coverage > POD is missing for get_requested_language > POD is missing for set_requested_language > WARN tidiness > The file is less tidy than before (bad/messy lines before: > 0, now: 2) > > WARN t/Languages.t > WARN tidiness > The file is less tidy than before (bad/messy lines before: > 10, now: 16) > > WARN t/db_dependent/api/v1/items.t > WARN tidiness > The file is less tidy than before (bad/messy lines before: > 180, now: 184) As we plan to tidy the whole codebase quite soon (January/February), I think you can ignore the tidy warnings for now. POD should be checked of course.
Will continue on this report early next week. No need to change status.