Summary

The language synchronization subproject consists of installing the required mechanisms for the wiki engine to be aware of the state of the translation in the different languages related to the other ones.

Prerequisite

• The wiki engine must be aware that two pages are the same document in a different language

Options

Master language

The master language is mapped directly from the world of traditional translation. All changes to the content are made to a single version and translation is made to other languages from the master version afterwards.

Pros

• Easy to implement
• Easy to identify which translations are the most up to date
• Well suited for controlled environments

Cons

• Not the wiki way
• Impossible for contributors to contribute in their native language

Known implementations

• TBD

Force synchronization

This model allows contributions to be made to any language as long as the language contains the most up to date content. If the content is not up to date, the contributor will first have to incorporate changes from the currently most up to date version. The model is very similar to the master language model, but it allows to change the master language over time.

Pros

• Easy to implement
• Easy to identify which translations are the most up to date
• Well suited for controlled environments
• Allows contributions to be made in any language

Cons

• Additional steps required for someone willing to contribute content
• Only possible to contribute if the current master language is understood
• Scales poorly when the amount of languages increase, but acceptable for bilingual wikis

Known implementations

• TBD

Pivot language

In this model, the pivot language acts as a reference version. Unlike the master model, changes are not prohibited in translations. When a contribution is made to a translation, the change must be translated to the pivot language. Once the contribution is part of the pivot language, translations can incorporate the change. The changes are invisible to translations until they are part of the pivot language.

Pros

• Allows contributions to any language
• Easy to identify which versions are up to date in relation to the pivot version

Cons

• Pivot language can be out of date in relation to translations

Known implementations

• TBD

Unrestricted pivot language

This variant removed the restriction imposed by the pivot model that translation is only possible from or to the pivot version. In this model, any language can be considered to be a pivot model. The internal mechanisms are very similar, but the use is more flexible. It could allow for translation of dialects or non-common languages to be translated to a similar language before being translated to other languages.

This model would have to be tested in a real setting to determine if it can work. It could allow pivot hierarchies to be created based on geographic language clusters.

Pros

• Allows to contribute to any language
• Reduces the need for translators to the pivot language from any language or dialect
• As wiki way as it can be

Cons

• Hard to keep track up to date level of translations, involves analysis of change propagation
• Could turn to chaos

Known implementations

• TBD