Thank you for your feedback Mikel! I've fixed some of the issues that you
have found (the new version is already uploaded):
*Apertium Caffeine*
>
> Apertium Caffeine is a small, user-oriented Apertium client, similar in
> concept to apertium-tolk, but which has some great advantages over it:
>
> - It doesn't depend on anything external and is written in Java. This
> means that it is completely platform-independent (it can work on Linux, OS
> X as well as Windows) and its only requirement is a Java VM (i.e. you don't
> need a separate installation of Apertium or its language pairs). Since Java
> uses UTF-16 internally, we shouldn't be having any encoding problem
> neither.
> - It manages language pairs within the app. In other words, you can
> install, uninstall and even update language pairs from the app itself in a
> simple, user-friendly way.
>
> 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...
*Apertium plug-in for OmegaT*
>
> This is something that some of you suggested in the other thread and I
> have implemented as a proof of concept of how easy can lttoolbox-java be
> integrated in bigger Java projects. It shares most of its code with
> Apertium Caffeine, including the ability to manage language pairs within
> the app and, of course, it works offline.
>
> The source code can be found
> here<https://apertium.svn.sourceforge.net/svnroot/apertium/branches/gsoc2012/artetxem/apertium-omegat/>,
> and the ready-to-use JAR
> here<https://apertium.svn.sourceforge.net/svnroot/apertium/branches/gsoc2012/artetxem/apertium-omegat.jar>.
> If you want to try it, simply copy the JAR to the plugins directory of your
> OmegaT installation. The next time that you launch OmegaT, you will see a
> new option at Options -> Machine Translate called "Apertium (offline)",
> which has to be checked to activate the plug-in. If you want to configure
> the plug-in or manage language pairs, go to Options -> Apertium settings.
>
>
> 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!
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.
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...
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!).
> 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!
> 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...
> 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).
------------------------------------------------------------------------------
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
