>
> Mikel Artetxe has explained that the OmegaT plug-in doesn't work for
> language pairs that depends on programs that aren't a part of
> lttoolbox-java. Six language pairs depend on the Constraint Grammar
> package and are thus excluded, one of them is apertium-nn-nb. But sv-da
> doesn't use any constraint grammar, thus I concluded that sv-nb (Norsk
> bokmål) wouldn't need one either. And would come to real use, by real
> translators, using OmegaT. If the pair cannot be used, I don't see any
> need to develop it.
>
While what you state is true right now (i.e. the OmegaT plug-in doesn't
work with language pairs that use CG), that doesn't necessarily mean that
it will never work with them (and the same applies for any program based on
lttoolbox-java such as Apertium Caffeine or the Android app). I mean, all
this stuff is new... the OmegaT plug-in wasn't even in my initial plan for
GSoC! I think (and hope) that this will keep evolving in the future.
It seems that, from your point of view, it wouldn't make sense to work on a
language pair that wouldn't be supported by the current OmegaT plug-in. I
announced the plug-in practically yesterday so, from that perspective, all
the work done so far would have been, in principle, completely useless in
the moment it was conceived... If all the Apertium developers had thought
that way, nothing would have been done so far, so the OmegaT plug-in itself
would be inconceivable! All in all, I have absolutely no idea about the
linguistic facts that are under discussion here, but I really think that
you shouldn't base your decision on what the OmegaT plug-in does right now.
Being said that, I've been thinking about how we could support Constraint
Grammar in lttoolbox-java (and, consequently, in the OmegaT plug-in), and I
think that we could consider 3 different alternatives:
1) Invoke it as an external program. Note that lttoolbox-java can already
deal with that. In fact, apertium-viewer is now built on top of
lttoolbox-java, and it still works with language pairs with external
dependencies. As for the OmegaT plug-in, it works with resources compressed
in a JAR, so directly invoking cg-proc wouldn't work for it. We would need
to extract the required resources to a temporary directory and invoke it
with the correct parameters, which is not currently supported, but it
shouldn't be too difficult to implement. The disadvantage of this approach
is that the user would need to install the Constraint Grammar package in
his machine as usual, so the solution wouldn't be portable at all. For
instance, this wouldn't work under Android.
2) Create a Java interface for CG using JNI. That should guarantee certain
level of portability (it could even work in Android). It would reuse all
the source code from CG, and the user wouldn't need to install any external
program to make it work. That sounds good, but I think that it might happen
to be more complex and problematic than what it seems. For instance, just
looking at the installation instructions I see that it depends on some
external libraries, so things start getting more complex...
3) Develop a Java port of it. Probably the best solution but, obviously,
the hardest one to implement...
If people think that it would be useful, I could implement solution 1)
quite easily. That would serve to make the OmegaT plug-in work with
language pairs that depend on CG (although the user would have to install
CG manually). Solution 2) and, especially, 3), would require much more
work. I might work on it some day, but don't expect anything (it is
definitely not in my plans for the near future)! But, who knows, somebody
else could also work on it, and perhaps it might be an interesting project
for future GSoCs...
Besides, will this alternative work "out of the box", i.e. without any
> modifications to Apertium or the Apertium plug-in for OmegaT?
>
The Apertium plug-in for OmegaT is built on top of lttoolbox-java. So if
what you propose would work with lttoolbox-java, it would work with the
plug-in as well. lttoolbox-java is a Java port of lttoolbox and apertium,
so if you don't go beyond that, your work would be compatible with it
without any problem. But I insist that, from my point of view, you
shouldn't look at this to take the decision...
------------------------------------------------------------------------------
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
