Requesting a page in a non-available language does not redirect as it should

[nstuardod]

I help maintaining a site that publishes content in two languages: es (default) and en. Localized content works and non-translated content is handled properly falling back to Spanish.

This worked fine until our client attempted to do the following: they had a page (/old_page with just a Spanish version) that was meant to be replaced with a different page (/new_page, Spanish-only too) so they set a up a redirect from /old_page to new_page. However they complained about redirects not working properly. After researching the issue we noticed the HTTP response depends on the language requested to the app:

• GET /old_page/ with no Accept-Language: 302 to /new_page/, OK
• GET /old_page/ with Accept-Language: es: 302 to /new_page/, OK
• GET /old_page/ with Accept-Language: en: 200, old page gets rendered using the spanish version, NOT OK
• GET /en/old_page/ with no Accept-Language: 302 to /new_page/, OK
• GET /en/old_page/ with Accept-Language: es: 302 to /new_page/, OK
• GET /en/old_page/ with Accept-Language: en: 302 to /old_page/, old page gets rendered using the spanish version, NOT OK

Our client claimed they expected something like:

• GET /old_page/ with Accept-Language: en: 302 to /new_page/ as the fallback contains a redirect
• /en/old_page/ with Accept-Language: en: same as above.

Although we know that creating an English version for old_page with a redirect works, we think that defeats the idea of setting up fallback languages. Is this the expected behavior of Django CMS?

[fsbraun]

I think the client's expectation is reasonable. I suggest the workaround with the English redirect for the time being and listing this as an issue.

[nstuardod]

Well, after checking the commit history, I found that this issue was solved in v3.9.0 (34a26bd). After cherry-picking that change to a local fork this issue was fixed.