Thread:Support/Structured glossary/reply (3)

My as of yet very superficial view of Extension:SemanticGlossary is that it adds markup to MediaWiki that you can use to annotate terms and abbreviations thus that: While the latter can likely be overcome somehow with disambiguation techniques, I doubt, it would currently be acceptable for
 * hovering the mouse cursor over them may show a textual annotation or explanation,
 * terms and their annotations can be viewed as (sortable?) lists via a special page,
 * Semantic Mediawiki Web and queries can be used on them,
 * it looks like not being able to ideally deal with ambigous terms (such as "blow" being both several verbs and several nouns, think of wind, boxing, fuses, misfortune, doors and windows, noses, glass, eggs, saxes and trumpets, bubbles, and many more)
 * most translators to annotate their translations with it,
 * developers to add likewise annotations in either messages or message documentations,
 * minor: twn would need to strip annotations from messages on export.

SemanticGlossary can of course be used to develop a glossary or thesaurus of terms, up to a complete (monolingual) dictionary. Another project doing something similar is Omegawiki, only that Omegawiki has a whole lot of additional goals, and is multilingual. At the moment, I see several drawbacks, none of them prohibitive though:
 * I doubt that Omegawikis database would be very helpful to us at the moment lacking many of the needed terms, but we could find ways to supply them.
 * Omegawiki proper is geared towards all sorts of terminology, and we would have to find a way to mark very specialized terminologies, such as that of a specific extension of a specific piece of software. Not a software problem, but one of labour and proper coordination and preparation.
 * We do not have an interface in Extension:Translate querying Omegawiki, even less so updating Omegawiki, and wether or not the latter would at the moment (already) be accepted by Omegawiki needs to be found out.
 * Omegawiki at the moment has no way to deal with "ad hoc" translation relations. It needs at least one verbal description of a concept (term) in one language to be able to start relating translations to it. While this may well turn out be be beneficial to us, it is most often not easily done. And it should be done well! As experience shows, one can easily spent half an hour, or even two hours, figuring out a good and comprehensible definition / description / explanation of a term. A good translator is not necessarily a good definition writer.
 * Supplying definitions would likely be a separate step in twns workflow.
 * Translating them, though not neccessary from a strict technical and egoistic perspective, would mean additonal labour and require additional translator skills, apart from the ability of translating interface messages.

A somewhat similar project and inspired by Omegawiki is Ambaradan. It can do with and without definitions / descriptions / explanations. Unlike Omegawiki, it can be configured to only use local strorage with and without data exchange with the rest of the world. Otherwise, I cannot really say much about it at the moment, since all my knowledge is more than 2 years old and theoretical.

Google Translate glossaries are pretty simplistic. They can be multilingual, wich may come handy for us. They can handle ambiguities in a "many to one" fashion (i.e. quasi-synonymes) but not vice versa in one glossary. If I understand that right, they are supplied with each translation request, so it would not be feasible to have very large ones. They appear great to supply limited nonstandard terminology for the current translation context.