>
> Cool. Works like a charm. A minor quibble: I said I wanted it installed
>> in /tmp and it decided that every file in there was an already installed
>> language pair. Perhaps a regex identifying language pairs by name would be
>> very helpful.
>>
>
> I now look at the file extension to filter JAR files. I think that it
> should be enough. It would also be possible to look at the whole filename,
> but this would make manually installed pairs unusable unless they are
> properly named...
>
> The standard style is apertium-[a-z][a-z][a-z]?-[a-z][a-z][a-z]?.jar I
> think it would be no problem for your program to require that.
>
Yes, but the JARs online follow a different naming convention so that we
can know the exact modes they contain without downloading them (that is,
simply looking at their name). For instance, en-eo,eo-en.jar is used
instead of apertium-eo-en.jar, expressing that the contained modes are
en-eo.mode and eo-en.mode (so, in this case, the program could conclude
that the language pair is bidirectional even if it hasn't downloaded it
yet).
In any case, I've updated both programs so that they look for the following
pattern, accepting both naming conventions:
return
name.matches("([a-z_]+-[a-z_]+(,[a-z_]+-[a-z_]+)*).jar|(apertium-[a-z_]+-[a-z_]+).jar");
> The code that carries out the translation in the plug-in can be found
> here<http://apertium.svn.sourceforge.net/viewvc/apertium/branches/gsoc2012/artetxem/apertium-omegat/src/org/omegat/plugin/machinetranslators/ApertiumTranslate.java?revision=39499&view=markup>from
> line 56 to 66. The function is really simple, so it should be easy to
> apply the necessary changes there (if we know what this necessary changes
> are!).
>
> I'm sure Víctor can tell you. It's a matter of catching and escaping the
> <> tags generated by OmegaT so that their name does not get translated.
>
So, basically, what we need is to not translate anything between <> tags,
right? For instance, if we have something like "Ez dakit <zer arraio>
idatzi", we should avoid translating "zer arraio"... is that all we need?
If so, it shouldn't be too hard to achieve.
It is important to note that these settings as well as the installed
>> language pairs are shared with Apertium Caffeine, which means that, if you
>> install, uninstall or update a language pair, the changes will be reflected
>> in both programs. This is a design decision that I took, but it would be
>> simple to make them independent if you prefer it.
>>
>> Oops I hadn't read that. I think it would be nice to have separate
>> options, yes.
>>
>
> Now they are completely independent. But this could be problematic in some
> special cases: if the same directory is chosen for both programs, they
> would conflict and we would probably get a strange behaviour...
>
> You could, perhaps, add some kind of file that says which (OmegaT or
> Caffeine) is using the directory, and announce the conflict when the other
> one tries to use it too.
>
Done! The (already uploaded) new versions do that check.
------------------------------------------------------------------------------
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
