Structured glossary

Fragment of a discussion from Talk:Terminology

I actually wrote my Bachelor's thesis about using Omegawiki to help interface translation. The result was shortly put that it is not worth the hassle.

Nike17:03, 16 April 2011

That is a pity. Assuming that you wrote in Finnish, which I do not even rmotely read, it is likely useless to ask for a copy?

Without research, and putting the question of writing definitions aside (possibly following the Ambaradan approach (briefly: If you do not have definitions, number them and wait for texts to be written later - possibly forever) but doing crude disambiguations (such as "File <menu item>" versus "File <name or container of data>" where required), I am believing that a multilingual collections of terms can speed up translation processes. At least they could be used as an additional kind of translation memory. Since having been involved in a machine translation project both as a learner and a programmer when I was a student, my belief has "some" practical background :-) thus I would sincerly be interested to understand what lead you to the conclusion that, Omegawiki would not be helpful enough.

I agree, it would not help, unless properly coordinated and prepared, and this would have to be an extra step in the workflow, which had to take place ideally before translations begin, and would require access to programmers / developers / designers knowledge, and as a byproduct provide more and better message documentation.

Would you recommend feeding TWNs glossary data, if we collected any, to Omegawiki? Provided someone wanted to do that, of course.

Purodha Blissenbach20:26, 16 April 2011

Basically it would be lot of effort for very little gain:

  1. OmegaWiki doesn't currently contain nearly any of the DefinedMeanings we need
  2. Even when it does, they have definitions in less than ten languages by average, usually including those languages which need it least.
  3. OmegaWiki lacks pretty much all high level term management functions (splitting, merging, changing terms)
  4. Proper integration would be a lot of work. Message annotation is slow and difficult and OmegaWiki is not helping us in this process.
  5. If we basically need to build our own terminology from scratch, why make it complicated and use OmegaWiki, which is not integrated in twn in any way
Nike08:25, 17 April 2011

Agreed with all you write.

I've been looking into several projects and programs doing what we do here, i.e. the "translation" part of localizing software. Only OmegaT works with glossaries, but I do not know about any free glossaries related to the kind of terminology we need, so that needs research.

We must perspectively look into building or own glossaries. Good is that they can be very specific. I doubt :-) references to usage contexts such as "Mediawiki extension 'Socialprofile'" would be accepted in more general wordbook projects. They are however in Ambaradan, and maybe in Omegawiki, should we choose to automatically share collected data.

Let's see, what I am going to find, while doing some glossary related tests and research anyways in the future. I shall report.

Purodha Blissenbach18:35, 21 April 2011