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 without
introducing 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%).
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_localewith 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%).