Fix setting reading the search language cookie

[joelit]

Reasons for creating this PR

There was a bug reading the content language cookie, due to a method not being updated to follow the new cookie convention. This PR is built upon #1689 .

Link to relevant issue(s), if any

• Closes #1692

Description of the changes in this PR

Changed the name of the cookie

Known problems or uncertainties in this PR

• Should there be an additional test to catch the bug described in #1692 ?
• Does this bug warrant a closer inspection of the content language & UI language management logic?

Checklist

• [x] phpUnit tests pass locally with my changes
• [ ] I have added tests that show that the new code works, or tests are not relevant for this PR (e.g. only HTML/CSS changes)
• [x] The PR doesn't reduce accessibility of the front-end code (e.g. tab focus, scaling to different resolutions, use of .sr-only class, color contrast)
• [x] The PR doesn't introduce unintended code changes (e.g. empty lines or useless reindentation)

[sonarqubecloud[bot]]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[joelit]

I don't think nothing sets the SKOSMOS_LANGUAGE cookie anymore, though. It looks like it's becoming dead code in 3.0.

[osma]

I don't think nothing sets the SKOSMOS_LANGUAGE cookie anymore, though. It looks like it's becoming dead code in 3.0.

You're right that it's not being set by the current Skosmos 3 code. In the Skosmos 2 code, we set event handlers for the UI language selection links:

https://github.com/NatLibFi/Skosmos/blob/6b9b380a62949f1715223ea018b1201c56498177/resource/js/docready.js#L488-L494

I think the same should be done for Skosmos 3. I can open a new issue about this.

[osma]

Opened a new issue #1696

[joelit]

Closing this PR, as the preferred solution was to get rid of the search language cookie (PR #1720). For example, the content language state of one vocabulary might not make sense when switching to another vocabulary with different supported languages. Better to handle search language with clang url parameter.