>
> 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.
>
>
> Yeah, turning all of that into a superblank and letting Apertium deal
> with it. Would that be feasible?
>
If I'm not wrong it would require writing a new formatter (same as
TextFormatter<http://apertium.svn.sourceforge.net/viewvc/apertium/branches/gsoc2012/artetxem/lttoolbox-java/src/org/apertium/formatter/TextFormatter.java?revision=38326&view=markup>,
but turning those tags into superblanks as you say) and integrate it with
the rest of lttoolbox-java, including the Translator API class so that we
can call the proper function from the plug-in and let it do all the work.
So it wouldn't be trivial, but it is definitely feasible.
> Thanks a lot for such a quick turnaround! I look forward to the Apertium
> filtering. You'll have about 100 users for the OmegaT plugin in our
> Translation Technologies course at Universitat d'Alacant. That will ensure
> a lot of feedback!
>
That sounds really good!
> Is there a webpage or a wiki page that explains how to "export" language
> pairs for use with Apertium Caffeine and the OmegaT plugin?
>
Not really. But, just in case, I would like to remark that the JARs used by
Apertium Caffeine, the OmegaT plug-in, the new apertium-viewer, the Android
app that Arink is developing as well as the ones launched through Java Web
Start are actually exactly the same files. They aim to be something like
"universal packages" that would work with many different programs in any
OS. They can even be opened by any Zip program, extract the proper files
and run with the local installation of C++ Apertium. This is why I wanted
to discuss the best way of creating and, in particular, maintaining them in
SVN.
As for your question, the same instructions that I explained and were under
discussion in that other thread I started would apply in this case as well.
Quoting myself:
The solution that I have been (and I'm still) working on comes in form of
> two bash scripts, each one to carry out one of the tasks (you can find them
> here<https://apertium.svn.sourceforge.net/svnroot/apertium/branches/gsoc2012/artetxem/>in
> my branch):
>
> 1) apertium-pack-j offers an easy way to generate the packages. It
> requires to have lttoolbox-java (the one in my branch, not the one in
> trunk) and android-sdk installed, and their location must be specified by
> setting the LTTOOLBOX_JAVA_PATH and ANDROID_SDK_PATH environment
> variables. After that, you can simply run it passing the path to the mode
> files for which you want to generate the package as argument, and a
> ready-to-use package would be created by the script. For instance, the
> following command would create a ready-to-use package for the
> Esperanto-English language pair named apertium-eo-en.jar in my machine:
>
> LTTOOLBOX_JAVA_PATH="/usr/local/share/apertium/lttoolbox.jar"
> ANDROID_SDK_PATH="/home/mikel/developer/android-sdk-linux"
> ./apertium-pack-j /usr/local/share/apertium/modes/eo-en.mode
> /usr/local/share/apertium/modes/en-eo.mode
>
> As you can see, I simply specify the correct location of lttoolbox-java
> and android-sdk in my machine, and pass the location of eo-en.mode and
> en-eo.mode (the main modes that correspond to the Esperanto-English
> language pair) as argument to apertium-pack-j.
>
As I said, the dependency of the Android-SDK can be eliminated if we
install dx.jar together with lttoolbox-java.
It still crashes if I click on the ambiguity option...
>
> $ java -jar /tmp/apertium-caffeine.jar
> java.lang.StringIndexOutOfBoundsException: String index out of range: 0
> at java.lang.
> AbstractStringBuilder.charAt(AbstractStringBuilder.java:191)
> at java.lang.StringBuilder.charAt(StringBuilder.java:72)
>
> at
> org.apertium.lttoolbox.process.FSTProcessor.generation(FSTProcessor.java:1372)
> at org.apertium.lttoolbox.LTProc.doMain(LTProc.java:240)
> 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.apertium.caffeine.ApertiumCaffeine$12.run(ApertiumCaffeine.java:275)
> at java.lang.Thread.run(Thread.java:679)
>
> Perhaps it would be a good idea to leave this option out for stability...
>
Jimmy identified the problem yesterday but it hasn't been solved yet:
Sorry, this is a different error:
>
> char ch0 = sf.charAt(0);
>
> This also needs a null check, but javac doesn't like
> char ch0 = (sf != null) ? sf.charAt(0) : '';
> and
> char ch0 = (sf != null) ? sf.charAt(0) : (char) Character.UNASSIGNED;
> isn't the same thing, though it doesn't look like it would matter in this
> case.
>
> One for Jacob, I think.
>
I've looked at the code and I agree with Jimmy that
char ch0 = (sf != null) ? sf.charAt(0) : (char) Character.UNASSIGNED;
or even something like
char ch0 = (sf != null) ? sf.charAt(0) : '\0';
would work in this case. We don't have an empty character so we have to use
some trick like that, but let's see what Jacob says...
------------------------------------------------------------------------------
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
