Internationalization will be handled through the CR in the way described at http://openacs.org/forums/message-view?message_id=182480

Old thinking

One of the major drawbacks of the current complex survey system is it's lack of internationalization of content.

Use Case

An internation organization conducts surveys for it's member base. The member base consists of people speaking different native languages. To increase turnout it is recommended to conduct the survey in the native languages. The answers shall be evaluated across all languages.

Options

There are two options how to tackle this problem.

You create a survey for each language. The reporting accumulates the data of all the different surveys and reports on this accumulated data. Drawback is the fact that you'd have to link items together (this item is identical to that item, yet in a different language), which is not good in terms of user interface.
You add internationalization of content to the necessary tables. This has the drawback of an additional join with the localization table. Again, two options:
- Create one localization table for each table that stores content.
- Create one central locationzation table for all other tables.

We will tackle this problem using the second option. Not clear though which way to go.

Solution

Internationalization is actually a special case of how we handle revisions of an Assessment through its lifecycle more generally. So the solution here will be useful for all other attributes. There are several alternative ways to accomplish this.

CR Approach
If we make each different "translation" of an Item Choice, Item, Section, or Assessment a new revision in the CR (ie we make a new as_item and as_item_rev when the object is first created with the as_item containing the "default locale", then insert new as_item_revs for each new language), we will automagically get the behavior we want. Probably.
Central Approach
Each table that is to be localized get's a locale field, which stores the default locale for content columns. An additional as_localized table will store the translations for additional locales, if available. We make the assumption that most items will not be internationlized. This is why we denormalize the as_localized table.
- Addition to each table
  - default_locale - This field describes the default locale used for each of the content columns within the table. It is mandatory and should not be changed unless all content rows get changed with it.
- ad_localized
  - locale - locale / language of the content.
  - table_name - name of the table for which this content is stored.
  - column_name - name of the column in the table that stores the original contentl
  - primary_key_name - name of the column that stores the primary key (as we need to state for which row we are storing that content).
  - primary_key_value - ID of the row we store the additional translation for.
  - content - translated content for the table and the column.
Decentralized approach
- Create one table for each to be localized table. As an example we can take the as_item table.
- Item Localized Content (as_item_localized) stores all the content of additional locales of an item. These will overwrite the values stored in as_items (lazy overlaying), if the users locale matches the locale defined here.
  - item_id - references as_items
  - locale - locale of this content
  - item_text - the primary "label" attached to an Item's display
  - item_subtext - a secondary label, needed for many kinds of questions
  - definition - some descriptive text
  - instructions - optional text displayed on user pages