On Mon, Aug 20, 2012 at 9:49 PM, Per Tunedal <per.tune...@operamail.com>wrote:
> Hi Mikel,
> I'm sorry, I didn't explain properly.
> I referenced to the so called "modes" of different language domains,
> e.g. "economic" language as opposed to "standard" language:
> <e r="RL" a="eleka" alt="eco"><p><l>de<b/>valeur ...
> <e r="RL" a="eleka" alt="std"><p><l>précieux ...
>
> as previously described by Jimmy O'Regan for the pair es - fr.
>
Now I understand you. If you look at the modes.xml file of apertium-fr-es
here<http://apertium.svn.sourceforge.net/viewvc/apertium/trunk/apertium-fr-es/modes.xml?revision=12625&view=markup>,
you will see that there are specific modes for it (eco-fr-es and
eco-es-fr), so when the pair is compiled their respective .mode files are
generated. So my assumptions were correct, and you can include these modes
in a package as usual (look
here<http://wiki.apertium.org/wiki/Language_pair_packages#Creating_language_pair_packages>for
instructions).
Is the OmegaT plugin compatible with it? In principle, it is. The only
problem is how it could detect that it has to use this specific mode.
Currently, the mode to use is selected according to the source and
destination languages that were set for the OmegaT project. And eco-fr
cannot be selected as a source language, so the OmegaT plugin would never
use it. But it is still compatible, as renaming the mode to mislead the
plugin and force to select it would work. If people consider that native
support for this sort of variants would be useful, it would be possible to
extend the OmegaT plugin for it. In the meantime, you can use this hack.
I simply inferred that it might be a problem if the "alt-tag" would have
> multiple uses (for the same language pair): a) indicate language variant
> e.g. Norwegian bokmål as opposed to Norwegian nynorsk b)indicate
> language domain e.g. "economic"/"astronomic" or what ever domain as
> opposed to other domains or standard language. Maybe I've missed
> something that's obvious to you others.
>
I guess that this question is not specific to the OmegaT plugin but applies
to Apertium in general. I don't know if that's possible or not (reading
Fran's answer it seems that there are better approaches, anyway), but if
that would work with standard Apertium, it would almost certainly work with
the OmegaT plugin too.
In any case, my advice is: don't worry about making your work compatible
with the OmegaT plugin, we will worry about making the OmegaT plugin
compatible with your work instead. Just try to make the best you can using
standard Apertium tools, and forget about the OmegaT plugin until you are
done with it. Look at it this way: the developers of all the 24 language
pairs that are currently supported weren't concerned about making their
work compatible with the OmegaT plugin... the OmegaT plugin didn't even
exist when they were working on it! But now that it exists, they are
supported, aren't they? After all, it is the OmegaT plugin which has to
adapt to Apertium as a whole, and not the other way around (and the same
applies for Apertium-Caffeine or the Android app).
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Apertium-stuff mailing list
Apertium-stuff@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
