Open drikusroor opened 1 month ago
Thank you for adding this!
Perhaps we can also leave the language parameter to another issue. It might actually be less frustrating that way, since we don't want users to just go ahead and change the parameter, right? Right now, if a user sees lang=en
but they prefer Spanish, right might try to edit the lang parameter, while we might not have that translation option.
What I haven't really thought through yet are scenarios as follows:
Do we then (as was now the case) give them a mixture of English and Spanish? Do we "force" the language cookie to one of the translations available for the experiment? I guess the latter. We would then probably select the language cookie as follows:
ExperimentTranslatedContent
, if so, select that languageThere should be a mechanism to check, when entering a new ExperimentTranslatedContent
, if all associated Block
(rules), ThemeConfig
, and Question
objects also have that language available, and raise a warning to the user if that is not the case, listing the objects for which they should still add translations.
If we do implement the TranslatedContent
models with fallback orders, I think an issue to allow users to switch languages would be something to implement soon after.
Thank you for adding this!
Perhaps we can also leave the language parameter to another issue. It might actually be less frustrating that way, since we don't want users to just go ahead and change the parameter, right? Right now, if a user sees
lang=en
but they prefer Spanish, right might try to edit the lang parameter, while we might not have that translation option.
Yes, good idea. I'll add it as a future task.
What I haven't really thought through yet are scenarios as follows:
- an experiment has database translations in, say, Dutch and English
- it uses questions which have also been translated to Spanish
- we get a user whose browser settings indicate they prefer Spanish
Do we then (as was now the case) give them a mixture of English and Spanish? Do we "force" the language cookie to one of the translations available for the experiment? I guess the latter. We would then probably select the language cookie as follows:
- check if any of the preferred languages of the user matches the
ExperimentTranslatedContent
, if so, select that language- otherwise, select fallback (probably English or Dutch in most cases)
There should be a mechanism to check, when entering a new
ExperimentTranslatedContent
, if all associatedBlock
(rules),ThemeConfig
, andQuestion
objects also have that language available, and raise a warning to the user if that is not the case, listing the objects for which they should still add translations.If we do implement the
TranslatedContent
models with fallback orders, I think an issue to allow users to switch languages would be something to implement soon after.
Yes, I was also thinking about this and I agree with your approach. I'll make this approach explicit in the requirements.
- [ ] Translate
ThemeConfig
using a related "TranslatedContent" model
I don't think ThemeConfig
contains any textual content shown to the user right? We might want to skip this one.
SocialMediaConfig
, however, does contain textual content for sharing the Experiment
so we might want to translate this. There are two ways we can do this:
ExperimentTranslatedContent
SocialMediaConfig
model so that
experiment
OneToOne
field becomes a FK
, andlanguage
field gets added to itThemeConfig itself doesn't contain text, but FooterConfig
does.
As for SocialMediaConfig
, I think we could move the content
field to ExperimentTranslatedContent
indeed, and rename it to something like social_media_message
?
Is your feature request related to a problem? Please describe. Right now, we don't have a clear way to provide translated / localised / internationalised experiments to users. The only option we currently have is to create a "new Experiment" for a new language and write the title, description, etc. in that language. However, the app's non-experiment-related or non-configurable content (button's, links, translation keys in the experiment blocks) might still show up in a different language.
Describe the solution you'd like A better way, as discussed on Tuesday July 23, might be to create a new model (named
ExperimentTranslatedContent
or something) which contains all the textual content of an experiment for a given language. In pseudocode, that model would look something like this:Which content should then be shown to the user?
Based on the preference from the client, in the form of a URL parameter (?lang=jp), we can serialise the experiment with the right language content and get a fallback in case the chosen language's content is not available.
Which fallback should then be chosen?
We could use the index to arrange the fallback priority order. In other words, if an ETC (Exp. Translated Content) for Dutch (nl) is listed on top (index = 0), it can be the fallback for an English ETC with index = 1.
Alternatively, we could think about a more elaborate system of fallbacks in the future if needed. An option could be a fallback_for property with an array of languages (en, nl) for an ETC and make Django check that list if it cannot find the content for a preferred language. E.g. the user prefers Catalan, but the Spanish ETC has
fallback_for=[ca,pt]
and therefore falls back to the Spanish ETC.Requirements
ExperimentTranslatedContent
(see pseudocode above)django-nested-admin
to create a nested inline form.ExperimentTranslatedContent
mandatory in order to create/save an experiment. (An Experiment without content should not be possible).get_experiment
's content according to the preferred language and make sure the json structure stays the same (so the frontend needs no revising)Accept-Language
header supplied by the browser.Accept-Language
header, fallback to the highest available experiment language content bases on the index (index=0 would be first fallback).Good to know / Future tasks
We will most likely have to do this for
ThemeConfig
andBlock
as well. I'll list these as a "todo" list below, which allows us to create issues from them easily whenever we want to:ThemeConfig
using a related "TranslatedContent" model~ I don't thinkThemeConfig
contains any textual content shown to the user right? We might want to skip this one.?lang=nl