Hi Mikel:

Thank you for your feedback Mikel! I've fixed some of the issues that you have found (the new version is already uploaded):
Cool!

    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.

    _*Apertium plug-in for OmegaT*_



    The menu appearde but this one crashed on me: I think the problem
    is that I had a previous installation somewhere else (they use the
    same .java/.userPrefs/org/apertium/ . I remove these.


They now use independent preferences, so we shouldn't have that problem anymore.


    Then on launching OmegaT I get a dialog that may be confusing for
    some, as it does not identify itself as an Apertium warning. It
    should...


Now it does!
I'll take a look. Thanks a lot!


    It kindly asks me to decide where to install itself, and where to
    install language pairs. Then I open a project, mark "Apertium
    offline" in the Machine Translation options, and it crashes.

    java.lang.IndexOutOfBoundsException: Index: 13, Size: 7
        at java.util.ArrayList.rangeCheck(ArrayList.java:571)
        at java.util.ArrayList.remove(ArrayList.java:412)
        at
    org.apertium.lttoolbox.process.State.nodeStatePool_get(State.java:101)
        at org.apertium.lttoolbox.process.State.copy(State.java:145)
        at org.apertium.lttoolbox.process.State.copy(State.java:158)
        at
    org.apertium.lttoolbox.process.FSTProcessor.analysis(FSTProcessor.java:857)
        at org.apertium.lttoolbox.LTProc.doMain(LTProc.java:287)
        at org.apertium.pipeline.Dispatcher.doLTProc(Dispatcher.java:259)
        at org.apertium.pipeline.Dispatcher.dispatch(Dispatcher.java:333)
        at org.apertium.Translator.translate(Translator.java:305)
        at
    
org.omegat.plugin.machinetranslators.ApertiumTranslate.translate(ApertiumTranslate.java:62)
        at
    
org.omegat.core.machinetranslators.BaseTranslate.getTranslation(BaseTranslate.java:64)
        at
    
org.omegat.gui.exttrans.MachineTranslateTextArea$FindThread.search(MachineTranslateTextArea.java:128)
        at
    
org.omegat.gui.exttrans.MachineTranslateTextArea$FindThread.search(MachineTranslateTextArea.java:103)
        at
    
org.omegat.gui.common.EntryInfoSearchThread.run(EntryInfoSearchThread.java:95)


I'm not sure if I have correctly identified the problem, but it is probably fixed now.
I will test it again, to see what happens.


    There is one thing that could be easily solved. Víctor Sánchez
    (cc-ed) maybe can help you. When one uses the Apertium webservice
    from inside OmegaT, we avoid translating the tags (<u0>, etc.).
    Some minor changes were made to the code that calls Apertium as a
    webservice (you'll easily find them, but if not, I can help) and
    some changes were made in the webservice itself (Víctor can help
    here). I think it is a matter of using some regular expressions to
    hide these in some way...


I guess that you are talking about this <http://omegat.svn.sourceforge.net/viewvc/omegat/trunk/src/org/omegat/core/machinetranslators/ApertiumTranslate.java?revision=4434&view=markup>. I might be blind, but I haven't been able to identify the relevant piece of code there...
You're right. Most of the work is done at the Apertium server when it receives format=omegat.

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.

    You should consider sending a message to the OmegaT list. I can
    help here, as I am subscribed. I think this is very, very
    important! And perhaps you can get OmegaT people to help with some
    of the issues.


I will do it then!
Excellent.

    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.

    Please, note that both are still under development, so you might
    find that some stuff is not working as it should. Most notably,
    the maintenance of online language pair packages is being
    discussed in another thread, and we haven't taken a definitive
    solution yet, so both apps are currently using some testing
    language pairs that I keep in my branch.
    Nice. We should solve this.


Yes. We should probably create a new directory in SVN and start creating and uploading packages for every language pair. The question is how to maintain it in long-term: we could integrate my script in the makefiles of each language pair to make things easier (although the dependency of Android-SDK and lttoolbox-java can still be a problem for some people), but we would still need the implication of every language pair developer in Apertium (or some responsible to take care of the whole maintenance).
This deserves a deeper thought. Any ideas?

Mikel

--
Mikel L. Forcada (http://www.dlsi.ua.es/~mlf/)
Departament de Llenguatges i Sistemes Informàtics
Universitat d'Alacant
E-03071 Alacant, Spain
Phone: +34 96 590 9776
Fax: +34 96 590 9326

------------------------------------------------------------------------------
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

Reply via email to