You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 5, 2019. It is now read-only.
Currently JSON fields are text fields so we could theoretically go for the same model. But since some information within the JSON is not translated we need to store multiple languages in one JSON field. Once we do this we'll write code that makes it easy.
Forms translations are a special case too
Forms translations are special, since we want the exact same definition with different field names. If we translate form definitions we have to make sure that all translations have the same form structure and characteristics. We might also consider making it part of the syntax, but it would have to be optional.
Translatable texts may not be part of an index or a filter (it's pure content)
This might actually work but I don't want to give any guarantees about this. If a value is supposed to be indexed it should not be translated. This should not be a problem however.
All translations are automatically added by onegov.search.
It will detect the translated fields and put each translation in the appropriate language-specific index. OneGov Search has access to each record and knows the mapped model, so this should be somewhat trivial.
The urls of models doesn't change
There is a default locale (for example German) and all links will follow this default locale. The user locale is set per request and has nothing to do with the path part of the url.
The locale may be set through the request
The locale may be set through a header value, or an extra query paramter (e.g. /my/path?locale=de). The current locale is then stored as a cookie.
There is no extra editor view
When editing a page we show a special widget for content which may be translated:
The user will always see the text in the default language (even if using another language) and may then choose to switch to other translations to add them. We do not force the user to fill out anything except for the default language.
Full html translations (redactor) are also done like this, though the widget would have to be integrated into redactor.
On the widget we can indicate the level of the translation. For long texts we should see if they are roughly the same in length (plus minus 25%).
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
See OneGov/onegov.election_day#15
I'm going to try the following approach for now:
Translatable texts are stored as HSTORE types in Postgres
They are accessed through http://sqlalchemy-utils.readthedocs.org/en/latest/internationalization.html. The hard part will be to find a way to marry
get_locale
with the locale stored on the request withoutintroducing a global variable.
JSON needs to be treated differently
Currently JSON fields are text fields so we could theoretically go for the same model. But since some information within the JSON is not translated we need to store multiple languages in one JSON field. Once we do this we'll write code that makes it easy.
Forms translations are a special case too
Forms translations are special, since we want the exact same definition with different field names. If we translate form definitions we have to make sure that all translations have the same form structure and characteristics. We might also consider making it part of the syntax, but it would have to be optional.
Translatable texts may not be part of an index or a filter (it's pure content)
This might actually work but I don't want to give any guarantees about this. If a value is supposed to be indexed it should not be translated. This should not be a problem however.
All translations are automatically added by onegov.search.
It will detect the translated fields and put each translation in the appropriate language-specific index. OneGov Search has access to each record and knows the mapped model, so this should be somewhat trivial.
The urls of models doesn't change
There is a default locale (for example German) and all links will follow this default locale. The user locale is set per request and has nothing to do with the path part of the url.
The locale may be set through the request
The locale may be set through a header value, or an extra query paramter (e.g.
/my/path?locale=de
). The current locale is then stored as a cookie.There is no extra editor view
When editing a page we show a special widget for content which may be translated:
The user will always see the text in the default language (even if using another language) and may then choose to switch to other translations to add them. We do not force the user to fill out anything except for the default language.
Full html translations (redactor) are also done like this, though the widget would have to be integrated into redactor.
On the widget we can indicate the level of the translation. For long texts we should see if they are roughly the same in length (plus minus 25%).
The text was updated successfully, but these errors were encountered: