History: WS08Paper:Future Work

View page
Source of version: 6 (current)

The work described in this paper constitutes a very significant advance in support for collaborative authoring and translation, and in our experience is already usable as is.

But as is often is the case, one can easily think of addition work __could__ be done to improve it. In order to avoid implementing features that are not really useful in the end, our plan is to follow an incremental approach and implement only those improvements which we know are needed, based on feedback from our pilot users. Below is a discussion of some possible directions in which this might take us.

!Prevent translation and original contributions in context of a translation transaction

The last constraint left in terms of what people can edit or translate when, is this: "People should NOT mix translation and original contributions in a same transaction". For example, if you are translating some content, you should resist the urge to make original contributions while in the translation dialog. This could be a problem since people often switch between roles of translator and authors without realizing it. We are thinking about a more constrained translation UI that would prevent translators from accidentally making "original contributions" in the midst of translating.

!Reliance on users to tell us when a translation is complete

If user clicks "Complete translation" button when in fact it's not, then some original contributions in the source page end up not being translated in the target language. Even worse, if someone then uses this target language as the source langauge to translate to a third language, these original contributions will not be propagated to the third language.

Conversly, if the user clicks on "Partial translation" button when in fact the tranlsation is complete, them the page still appears as needing updating when in fact it doesn't. This problem is not as dramatic as the first one, but still.

We are thinking about using automatic bilingual sentence alignment technologies to help prevent these types of situations. When user clicks on "Complete translation", the system would do a quick sanity check to see if indeed, the two linguistic versions seem aligned. In case of doubt, the system would display those parts that don't seem aligned, and would ask the user to confirm that indeed, the translation is complete. Conversly, if the user clicks the "Partial translation" button but the system believes that the two versions are in fact aligned, the system will tell the user so, and ask him if he just forgot to click on the "Final translatioon" button.

!Translating from a foreign language

Because we allow unconstrained editing and translation in all directions, it may be that people will find themselves needing to translate from languages that they do not read. This would be less of an issue if we were to impose one or two of the most commonly read languages as pivots.

Given this, we are thinking about integrating Machine Translation tools into the system, along the lines of what was proposed in (Desilets et al., 2006), to allow translators to gist the content of original contributions done in languages that they cannot read.

!Evaluation in actual translation communities

We of course intend to deploy this in actual translation communities like SUMO. We need to evaluate how successful it is.

Also, we need to evaluate the dynamics of these communities.

For example, eventhough there are no pivot langauges that are imposed, does the community naturally tends to move towards say, English as pivot language?

The Cross Lingual Wiki Engine as it is today is only a first step in the direction of collaborative translation. By providing basic tools to support translators, the project allows better collaboration in a multilingual context. However, there is still very little we know about how translators want to collaborate. The tools described previously collect a significant amount of information about the translation processes. In order to understand the information, advanced data visualization and aggregation tools will be required.

Combined with user feedback, the obtained information will allow to identify the kind of modification required to the existing set of tools to enable collaborative translation and help increase the adoption rate. By identifying usage patterns, we will be able to isolate the impediments and improve the solution to remove them.

!Replication in other wiki engines

Also, the objective of the CLWE is to make collaborative translation widely available. At this time, the base implementation is made in TikiWiki. However, the same concepts and the lessons learned could be applied in multiple other wiki engines.

!Translation management tools

Tools to help the "gardeners" and managers of the site to get a feel for the overall state of the site. What pages are most out of date? What needst to be done, etc..

!Additional misc work

Not sure that I (AD) understand those various points.


On a shorter time scale, issues and potential improvements have already been identified and should be addressed. At the time of writing this paper, the key issues are:

* Content difference may highlight changes already incorporated in some cases. This situation can easily be replicated, but more research is required to eliminate the problem.
* Page relationship broken if linking to a new page. A solution to this problem is already designed, but the changes required are incompatible with the TikiWiki release cycle at this time.
* No support for error correction. Wikis are typically very flexible towards human errors. However, the current implementation does not provide such flexibility.