Multilingual Collaborative Websites


Due to the nature of the web, people from different nationalities can reach websites. Large websites and portals usually have the content available in multiple languages. On a static website or where the content is tightly controled by a maintenance team, the content can be updated as the changes are made by the team dedicated to it.

When it comes to a collaborative websites where any user can add content, the translation process becomes much more complicated. Since the modifications can be done at any time and the author of the modifications probably can’t translate in all languages, the pages which are supposed to contain the same content end up having huge differences. A good example of this is Wikipedia, which is a great website with tons of content, but sadly, most of the content is only available in english. It’s not rare to see a page where the english version contains 10 printed pages of content while the french version barely has one.

The rest of this post contains more details about the problems and ideas to improve those websites.

One of the most basic step would be to allow people to join mailing lists for given pages and accept to maintain them. This way, the very first person to do the translation for a page could accept to maintain it and recieve notifications on changes. The problem with this is that not all changes can be important. Someone might simply have corrected a typo or restructure a phrase to make it more readable. Those kind of changes don’t need to be applied in translations and the dedicated maintainers might not appreciate to be notified for so little.

Simply having a flag to indicate if the change is important or not could solve this problem. I have seen a wiki application where the modification can be indicated as major or minor, which is a good idea but the interface did not force the users to use it, so no one did. I also believe the terms major and minor are not descriptive enough. Where is the limit? The basic change levels I can think of are the following:

  1. Typo
  2. Rephrasing
  3. Correction
  4. Improvement
  5. New Content

The solution relies on the fact that the editor flags his changes properly. If not used correctly, it ends up being useless. It’s mandatory to have the user select the type of modification he does. The best way to do it is to have a drop list or radio buttons with not default values selected and require an option to be selected. Of course, the user is free to select anything if he wants to, but if you trust him enough to write content, you should trust him for this detail. It’s also a good thing, as for everything, to document those levels and give even more precision than their name so they are understood. Explaining the purpose of the modification level flag might also not be a bad idea.

There is also a problem about the fact that the entire translation process relies on a single master version from which multiple translations are made. It’s common to see english as a master version and it’s not a bad idea since most people actually understand it. It’s impossible to always use the same language for all primary versions: a german scientist (totally random) might simply want to contribute his thesis and he wouldn’t do it if he had to translate it himself. This is simply an example of why you need to have any version as the master, but it leaves a problem because not everyone can translate from german.

Of course, at some point, a good english translation will be completed and most other languages will be able to translate from it. From that moment, the the master copy would need to move from german to english. Now what if the original author decides to contribute more information on the topic? Does he need to write it in english? In the best world, anyone should be able to contribute from any language as if it was the master version. How is it possible to keep track of the notification list and avoid recieving a notification 5 times because the same change has been applied in multiple versions. Most importantly, how can you be sure the version you are looking at is the most up to date?

A change of level 3 and above should be represented by an entity at the document level, not the translation level. The actual changes in the document should be bound to those higher level entities. This way, if a new change is applied on a document, a new entity would be created and if the change is applied on an other translation, it would only be bound to it. This way, it would be possible to list the status of all the translations and see which ones are complete or what is missing. Notifications would only be sent when a new change entity would be created.

In the user interface, it should be very clear to the user that the version he is looking at is as complete as it can be or not. In the case the version is incomplete, the translations where those changes are applied should be listed and the user should actually be able to see the diff generated by the change. Other than being very friendly for the user and giving him the additional information he needs, it’s also a good way to propose a contribution. On the other hand, some serious ergonomy work has to be done to keep the interface usable and efficient.

Special thanks to Marc Laporte, TikiWiki project leader, for the original discussion on the topic a few months ago.

2 thoughts on “Multilingual Collaborative Websites”

  1. For your information, as tikiwiki can be a candidate for that. tikiwiki1.10 (future version) has the notion of contribution. Each change you do in a wiki page (and some other objects) must specify a mandatory contribution type. An easy developpement will be to do notification on contribution type.
    Not so far to have a good translation notification system

Leave a Reply

Your email address will not be published. Required fields are marked *