The default_journal_language setting (core.models.Setting) is not used to determine what language to put the content in, so far as I can tell. This is done by Django's translation.get_language based on the user's browser settings.
However, get_language also relies on cookies to detect the last language. This causes problems in cases where English is the last-used language. For example, here's a user story:
I browse a non-Janeway website in English. Then I navigate to a Janeway journal with Spanish as the only designated language. On this journal site, English should not come into play unless there is a translation missing for a bit of text on the page. However, Janeway detects that I was just on an English site, so it puts the journal in English for me, even though the journal editor wanted the journal to be available only in Spanish, and has no plan to provide English translations. This means the nav bar comes through in English, but the content is in Spanish. I am confused.
To summarize, there are two problems for the end user:
Editors and press managers are confused by the default_journal_language setting because they think Janeway isn't working when in fact users are seeing different things than they are
Some users will be shown a mixed-language website when they should be shown the full, non-English version chosen by the editor
Solution
[ ] Constrain the logic of get_language so that the resulting language only takes effect if it is one of the journal's chosen languages (as in, our website is available in both English and Spanish, or, our website is only available in Spanish).
[ ] Make the default_journal_language setting control which language is shown in cases where get_language does not result in an actionable / available language.
Problem
The
default_journal_language
setting (core.models.Setting
) is not used to determine what language to put the content in, so far as I can tell. This is done by Django'stranslation.get_language
based on the user's browser settings.However,
get_language
also relies on cookies to detect the last language. This causes problems in cases where English is the last-used language. For example, here's a user story:I browse a non-Janeway website in English. Then I navigate to a Janeway journal with Spanish as the only designated language. On this journal site, English should not come into play unless there is a translation missing for a bit of text on the page. However, Janeway detects that I was just on an English site, so it puts the journal in English for me, even though the journal editor wanted the journal to be available only in Spanish, and has no plan to provide English translations. This means the nav bar comes through in English, but the content is in Spanish. I am confused.
To summarize, there are two problems for the end user:
default_journal_language
setting because they think Janeway isn't working when in fact users are seeing different things than they areSolution
get_language
so that the resulting language only takes effect if it is one of the journal's chosen languages (as in, our website is available in both English and Spanish, or, our website is only available in Spanish).default_journal_language
setting control which language is shown in cases whereget_language
does not result in an actionable / available language.