History: WS08Paper:Related Work
Preview of version: 10
Collaborative, wiki-style translation has raised a lot of interest in recent years. This has lead to some academically published work, as well as unpublished work done by practitioners and wiki communities.
The work described in this paper builds heavily on prior work by Désilets et al (2006) and the ideas proposed by Huberdeau (2006).
The LizzyWiki system described in Désilets et al. (2006) removed dependence on many of the constraints and assumptions described in the Introduction, while allowing synergy in a bilingual context. But it still fell short of allowing users to author or translation any page at any point in time. For example, if an author wanted to make an original change two words to a French page which was out of date with its English counterpart, he had to first bring the French page up to date with the English version. This often turned out to be a problem and stop the author dead in his tracks. For example, if the French author did not know how to read English, he would not be able to do his original modification before someone else updated the French page based on the English. In other cases, the author could translate from English to French, but would have to translate several sentences, before he would be allowed to do his two word original contribution to the French page. In contrast, these constraints and assumptions are lifted in our CLWE system.
In his blog, Huberdeau describe principles and designs for a backend that could support a less constrained workflow. The article brought the data management principles to allow original content modification on any linguistic version and the propagation rules. However, the solution was not implemented at the time. No mentions were made of any front-end or workflow details. In a sense, one can think of CLWE as an implementation of the backend design proposed by Huberdeau (2006), combined with frontend and workflow design as per Désilets et al. (2006).
TODO: Review Tomasz Muldner's stuff
Other researchers have turned their attention to the collaborative localization of the User Interface of wiki engines. TODO: AD to find and review the article about this. This sort of work has also been done by practitioners in the TikiWiki community (Need reference here).
Bey et al., turned their attention to linguistic resources that can be used to help communities of translators (NEED REFERENCE). Our work is very different in that it focuses on the tools and processes for collaboratively growing multilingual content. We assume that the community is able to use other external terminological and lexical ressources to resolve linguistic difficulties. TODO: Talk about how some researchers looked at how these linguistic resources could themselves be built in a wiki way: Désilets et al (WikiMania paper, and Aslib paper), some of the Multilingual Computing papers, maybe others.
Outside of academic circles, practitioners and wiki communities have also experimented with collaborative translation.
Wikipedia, the world's largest and most famous wiki site, publishes content in several languages, and has an active community of translators. However, there are very few tools to favour synergy between different linguistic communities. Each language version of Wikipedia is mostly an isolated linguistic silo. It is very difficult to know for example, which changes to an English page have been translated to French, which ones are awaiting translation, and which ones have been discarded as irrelevant for a French audience.
Other sites tackle translation more explicitly. For example, TraduWiki (www.traduwiki.org) supports collaborative, sentence by sentence translation of content available under Creative Commons. Similarly, dotSub (www.dotsub.com) supports collaborative translation of text subtitles for movies. Both of those sites however assume that the content being translated has reached a final stage and will not change once translation has started.
Finally, World Wide Lexicon offers libraries to edit the content of a website in place. To be translated, every piece of content must be given a unique identifier. By switching the website's interface to translation mode, any visitor can contribute a translation to a text block. Content edition is made in context and can be applied to any kind of textual content. The project website can also be used as a translation repository. No content evolution is considered by the translation model.
NOTE FROM AD: I think we are underselling the CLWE innovation here. Maybe what is said at the end of the intro is a better description of what the main innovation is
The primary innovation in the way CLWE handles the content synchronization is that it does not need to analyze any of the content. In fact, it keeps track of the original atomic changes made to the page and how they propagate to other linguistic version. From those translation relations between the pages, the correct text difference and other values can be obtained afterwards.
The work described in this paper builds heavily on prior work by Désilets et al (2006) and the ideas proposed by Huberdeau (2006).
The LizzyWiki system described in Désilets et al. (2006) removed dependence on many of the constraints and assumptions described in the Introduction, while allowing synergy in a bilingual context. But it still fell short of allowing users to author or translation any page at any point in time. For example, if an author wanted to make an original change two words to a French page which was out of date with its English counterpart, he had to first bring the French page up to date with the English version. This often turned out to be a problem and stop the author dead in his tracks. For example, if the French author did not know how to read English, he would not be able to do his original modification before someone else updated the French page based on the English. In other cases, the author could translate from English to French, but would have to translate several sentences, before he would be allowed to do his two word original contribution to the French page. In contrast, these constraints and assumptions are lifted in our CLWE system.
In his blog, Huberdeau describe principles and designs for a backend that could support a less constrained workflow. The article brought the data management principles to allow original content modification on any linguistic version and the propagation rules. However, the solution was not implemented at the time. No mentions were made of any front-end or workflow details. In a sense, one can think of CLWE as an implementation of the backend design proposed by Huberdeau (2006), combined with frontend and workflow design as per Désilets et al. (2006).
TODO: Review Tomasz Muldner's stuff
Other researchers have turned their attention to the collaborative localization of the User Interface of wiki engines. TODO: AD to find and review the article about this. This sort of work has also been done by practitioners in the TikiWiki community (Need reference here).
Bey et al., turned their attention to linguistic resources that can be used to help communities of translators (NEED REFERENCE). Our work is very different in that it focuses on the tools and processes for collaboratively growing multilingual content. We assume that the community is able to use other external terminological and lexical ressources to resolve linguistic difficulties. TODO: Talk about how some researchers looked at how these linguistic resources could themselves be built in a wiki way: Désilets et al (WikiMania paper, and Aslib paper), some of the Multilingual Computing papers, maybe others.
Outside of academic circles, practitioners and wiki communities have also experimented with collaborative translation.
Wikipedia, the world's largest and most famous wiki site, publishes content in several languages, and has an active community of translators. However, there are very few tools to favour synergy between different linguistic communities. Each language version of Wikipedia is mostly an isolated linguistic silo. It is very difficult to know for example, which changes to an English page have been translated to French, which ones are awaiting translation, and which ones have been discarded as irrelevant for a French audience.
Other sites tackle translation more explicitly. For example, TraduWiki (www.traduwiki.org) supports collaborative, sentence by sentence translation of content available under Creative Commons. Similarly, dotSub (www.dotsub.com) supports collaborative translation of text subtitles for movies. Both of those sites however assume that the content being translated has reached a final stage and will not change once translation has started.
Finally, World Wide Lexicon offers libraries to edit the content of a website in place. To be translated, every piece of content must be given a unique identifier. By switching the website's interface to translation mode, any visitor can contribute a translation to a text block. Content edition is made in context and can be applied to any kind of textual content. The project website can also be used as a translation repository. No content evolution is considered by the translation model.
- MediaWiki has some features in it, any others? (see Bibliography of Translation the Wiki Way, ... PmWik, for instance?)
NOTE FROM AD: I think we are underselling the CLWE innovation here. Maybe what is said at the end of the intro is a better description of what the main innovation is
The primary innovation in the way CLWE handles the content synchronization is that it does not need to analyze any of the content. In fact, it keeps track of the original atomic changes made to the page and how they propagate to other linguistic version. From those translation relations between the pages, the correct text difference and other values can be obtained afterwards.
History
SideMenu
Latest Changes
No records to display ...more
Search
Log In
Upcoming Events
No records to display