Sunday, June 26, 2005

The reason for not too many definitions on European wiktionaries

People from the English wiktionary in particular often say that the European ones are only full of stubs as they lack in definitions, synonyms, antonyms etc.

I was thinking about this today as I thought there must be a reason and yes, there is a very obvious reason.

When you live in an English only world most of all you do not need to know other languages to communicate since many people in the world speak enough English to be able to communicate.

When you live in Italy, Spain, France, the Netherlands etc. instead the need of communication with other languages is much higher and this leads to a completely different perception of wiktionary. People see it as help during their everyday communication and since communication in Europe is made of translations you have plenty of translations and less defintions.

People add to wiktionary what is important for them from their cultural point of view and not from the other's point of view.

There are also other reasons.

Some time ago I also had an interesting conversation with Dave from the Ido wiktionary ( People on the discussion list were reacting strange to their uploading huge translation wordlists. But: why did they? For the Ido language these lists and the possibility to have them searchable is one of the most important things. There are lists online, but you need to search in different places and you cannot add. So having wiktionary and being able to add in particular translations for them is very important.

What we should consider with any project: people add what is important for them, what they would like to find and so it is quite clear that translations are a huge part of that.

Definitions are important, of course, but they are just a part of the existing contents and not the main thing for everyone.

Personally being a translator what I need most are of course translations. Another thing that would help a lot are images. One example for technical translations: time ago we translated a CAD-Software and within this software we had long lists of different screws, bolts, etc. Sometimes we needed quite a long time to figure out which one was which one in which language. A dictionary with multiple translations showing the screws etc. would have helped a lot.

So please: from now on consider translations as important as they really are - and those of you who can add photos and images: add them at commons and link them to wiktionary as well.

Consider also: language students often use wiktionary - so create soundfiles ad add them - it helps them to learn a language.

Sabine Cretella

Wednesday, June 22, 2005

SUN's XLIFF Translation Editor compared to OmegaT

I just wanted to try it out ... and I had huge problems - the SUN tool does not work like it should according to the manual.

Here are my experiences/is my opinion:

Definitely: OmegaT is better than Xliff translation editor - the SUN tool is much too immature - I had to create a project us-EN to DE to be able to load the text-file (it was not possible to create a project with Italian as source language). Soft returns are not interpeted well (at least the title was mixed with the first sentence of the text). Generally speaking the segmentation does not really work well - there's no way to join segments to be able to work on a normal sentence. SUN should take OmegaT for their localisation work and hepl with internal segmentation + spellchecking + creating a glossary function - the SUN tool lacks even in this (glossary tool). So much money invested for that tool ... but how to tell this SUN? What I prefer is the way the translation units are shown in the SUN-Tool, but all the rest does not make me happy at all. A combination of both would be great.

Coding files with the XLIFF filter was not possible even if a "normal" file (I tried files of version 1.1 and 2.0beta). Something I can easily do with OmegaT - it opens OOo-files without an external conversion tool and therefore it is much easier to handle than the XLIFF Translation Editor.

Being presented as a "SUN inhouse tool that is used" I expected it to be much better and now I feel a bit disappointed ...

Definitely there is a lot to do - and combining forces would be the best thing to my opinion.

One thing has to be considered: the license the two tools use are different - but this should not be a hurdle I believe if people really want to co-operate.

Sabine Cretella