Skip to content
This repository has been archived by the owner on Sep 5, 2019. It is now read-only.

Define How to Translate Content in the Database #11

Open
href opened this issue Dec 10, 2015 · 0 comments
Open

Define How to Translate Content in the Database #11

href opened this issue Dec 10, 2015 · 0 comments

Comments

@href
Copy link
Contributor

href commented Dec 10, 2015

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:

screenshot of sketch 10-12-15 15-37-13

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%).

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant