History: Language Synchronization

Source of version: 9 (current)

!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. Different situations will require different mechanisms. This page documents the different options available and leaves the decision to the wiki engine implementers. Some implementations might offer multiple solutions and leave the choice to the site administrator. !Prerequisite * The wiki engine must be aware that two pages are actually the same document in a different language. !Unit size In current implementations of translation support, two major techniques are being used: * Per page translation: Each page his an entity of it's own and is translated as a whole. This technique is being used by most wikis who support page correspondence between languages. * Per block translation: In order to be translated, the content is separated into small chucks of 2-3 sentences. Each block can be translated individually. This technique is used on traduwiki. The CLWE project opts for ''per page translation''. !Synchronization models !!1. Master Language Model 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. ::{img src=img/wiki_up/master.dot.png}:: !!! 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 unless it is the master language !!! Known implementations * ''TBD'' !!2. Forced Synchronization Model 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'' !!3. Pivot Language Model 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. ::{img src=img/wiki_up/pivot.dot.png}:: !!! 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 !!!Note: * There could be more than one pivot languages for a given site. They could be chosen to cover most of the continets. For example: English, Chinese, Spanish, and some African language. Users could choose to translate through any of those pivot languages. !!! Known implementations * ''TBD'' !! 4. Unrestricted Pivot Language Model 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. ::{img src=img/wiki_up/merge.dot.png}:: !!! 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''