We could use the column code to switch language. Easier than keeping track of all idnew identifiers for each language. This report adds a optional code and optional lang query parameter.
Created attachment 139295 [details] [review] Bug 31385: Allow searching a CMS page by code Test plan: Add a CMS page with two languages for it. Look at the code column in the DB. Try opac/opac-page.pl?code=[CODE]&lang=[LANG]. Test leaving lang empty and passing various languages. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Tomas: What do you think? With this patch which is useful on its own already, we could also offer the URL opac-page.pl?code={CODE] instead of page_id. The extra lang parameter is a bonus.
We already have language as a parameter for other pages, like: OPACBASEURL/anypage?language=fr-FR Maybe we could make it match.
(In reply to Katrin Fischer from comment #3) > We already have language as a parameter for other pages, like: > > OPACBASEURL/anypage?language=fr-FR > > Maybe we could make it match. Good point
Created attachment 139296 [details] [review] Bug 31385: Allow searching a CMS page by code Test plan: Add a CMS page with two languages for it. Look at the code column in the DB. Try opac/opac-page.pl?code=[CODE]&lang=[LANG]. Test leaving lang empty and passing various languages. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com>
(In reply to Marcel de Rooy from comment #4) > (In reply to Katrin Fischer from comment #3) > > We already have language as a parameter for other pages, like: > > > > OPACBASEURL/anypage?language=fr-FR > > > > Maybe we could make it match. > > Good point The problem is again with default here. If you would pass language=default it wont get accepted by getlanguage and its friends..
(In reply to Marcel de Rooy from comment #4) > (In reply to Katrin Fischer from comment #3) > > We already have language as a parameter for other pages, like: > > > > OPACBASEURL/anypage?language=fr-FR > > > > Maybe we could make it match. > > Good point What makes sense to me is to pass the id and optionally the language. Look up the news item by id. We now have the code based on the id. If the language of this one doesn't match the given and logged in language, use the code from this one to look of the correct language version. This means we don't need to go mucking about in the database to find the code for the page. Does that make sense?
(In reply to Kyle M Hall from comment #7) > (In reply to Marcel de Rooy from comment #4) > > (In reply to Katrin Fischer from comment #3) > > > We already have language as a parameter for other pages, like: > > > > > > OPACBASEURL/anypage?language=fr-FR > > > > > > Maybe we could make it match. > > > > Good point > > What makes sense to me is to pass the id and optionally the language. Look > up the news item by id. > > We now have the code based on the id. If the language of this one doesn't > match the given and logged in language, use the code from this one to look > of the correct language version. > > This means we don't need to go mucking about in the database to find the > code for the page. > > Does that make sense? I will give it a try now
I don't see a need to pass default... pass a language or none. If you don't pass a language, this should work like the other pages: - look at the cookie, if there is none - look at the browser default - if the result doesn't match existing content - use default
Kyle suggest to pass the page_id which refers to the default record. But when you pass a language too, you could switch to the specific language. It feels a bit odd however to do so. I think it should be possible to pass default. You could use it as your native language in additional contents to reduce records.
I thin default will always be the native language, but it's supposed to be a fallback. I don't think that triggering it directly makes sense.
Created attachment 139298 [details] [review] Bug 31385: (follow-up) Switch to language param As Katrin suggested, we should use the language URL param instead. If you pass code, we use the language cookie as fallback. If that does not work, we look for default. Test plan: Try former test plan but use code=X&language=Y. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
(In reply to Kyle M Hall from comment #7) > What makes sense to me is to pass the id and optionally the language. Look > up the news item by id. > > We now have the code based on the id. If the language of this one doesn't > match the given and logged in language, use the code from this one to look > of the correct language version. > > This means we don't need to go mucking about in the database to find the > code for the page. Will open another report to show this code URL on the additional contents page, and the need for looking it up will be gone.
Created attachment 139348 [details] [review] Bug 31385: (follow-up) Same change at intranet side Test plan: Try at staff side: tools/page.pl?code=CODE Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 139349 [details] [review] Bug 31385: (follow-up) Add code based URL on the staff CMS view Test plan: Create a page with contents in two languages. Verify that the Default URL shows the default content and the Current language URL shows content based on active language. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
(In reply to Marcel de Rooy from comment #13) > (In reply to Kyle M Hall from comment #7) > > What makes sense to me is to pass the id and optionally the language. Look > > up the news item by id. > > > > We now have the code based on the id. If the language of this one doesn't > > match the given and logged in language, use the code from this one to look > > of the correct language version. > > > > This means we don't need to go mucking about in the database to find the > > code for the page. > > Will open another report to show this code URL on the additional contents > page, and the need for looking it up will be gone. Decided to put it here also.
Created attachment 139390 [details] [review] Bug 31385: Allow searching a CMS page by code Test plan: Add a CMS page with two languages for it. Look at the code column in the DB. Try opac/opac-page.pl?code=[CODE]&lang=[LANG]. Test leaving lang empty and passing various languages. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Kyle M Hall <kyle@bywatersolutions.com> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 139391 [details] [review] Bug 31385: (follow-up) Switch to language param As Katrin suggested, we should use the language URL param instead. If you pass code, we use the language cookie as fallback. If that does not work, we look for default. Test plan: Try former test plan but use code=X&language=Y. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 139392 [details] [review] Bug 31385: (follow-up) Same change at intranet side Test plan: Try at staff side: tools/page.pl?code=CODE Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
Created attachment 139393 [details] [review] Bug 31385: (follow-up) Add code based URL on the staff CMS view Test plan: Create a page with contents in two languages. Verify that the Default URL shows the default content and the Current language URL shows content based on active language. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Nick Clemens <nick@bywatersolutions.com>
(In reply to Nick Clemens from comment #20) > Signed-off-by: Nick Clemens <nick@bywatersolutions.com> Thx Nick
Pushed to master for 22.11. Nice work everyone, thanks!
Not needed in 22.05.x