Two ideas:
- If the store the nls_language in the cr-recisions, we use the revisions for multiple languages. To determine which is the live revision, we either create a live_p in cr_revisions or create a cr_item_live_revision_map, which shows the live revisions for each language. Obviously, the live_revision column in cr_items would be made obsolete and we have to make a unique constraint on (nls_language, cr_item_id)
- If we follow the cr_child_rel approach, the nls_language needs to go out of cr_revisions and into cr_items.
For the assessment system we look at various options, have a look at
https://openacs.org/projects/openacs/packages/assessment/design/i18n. One core element is the overlaying of language as we assume that most content will not be translated. To avoid heavy joining we denormalized the localized tables, meaning all content to be localized would be stored within the table with a default_locale and only if the user does not support the default_locale we'd look up the localization table for additional text.
