>
> 'As usual' I wanted to add several language pairs into the same JAR file.
> That would be cool.
> But it isnt possible, as transfer_classes and classes.dex doesent have
> language pair specific file names.
>
Yes, that's true. I think that the biggest problem here is classes.dex,
which cannot have a different filename unless we write our custom
ClassLoader for Android (presumably extending DexClassLoader). We talked
about this and, if I'm not wrong, concluded that it wasn't worth it.
As for transfer_classes, even if the directory doesn't have a language pair
specific name, you can still place your transfer classes there. The only
problematic scenario would be when two different classes that correspond to
different language pairs have the same name but, if I'm not wrong, they
always have language pair specific names (well, .t*x files have language
pair specific names and the name of the transfer classes is derived from
them), so we shouldn't have any problem regarding it.
You could also create your own directory and/or freely modify the Jars
internal structure as long as the mode files reflect that hierarchy. What's
more, if the Jar is processed by lttoolbox-java as a Zip rather than
through a ClassLoader (which is done always except in Android and Java Web
Start, in which it is not technically possible), you can place your files
at any place inside the Jar, without having to touch the mode files, and it
should still work.
Please note these executable JAR files are not 'really' meant mainly for
> direct execution. The embedded interface is just a small program for users
> to get startet with Apertium in a simple way and to play with a language
> pair in an easy way. The main purpose for the JAR/ZIP files it to be used
> as plug-ins in other programs.
>
Got it.
We probably need a very simple example client application for the desktop
> as well: One that fetches a list of available pairs, lets users download
> them (or simply opens a browser showing the directory with JARs), opens a
> (downloaded) pair JAR file, and starts using it.
>
OK. I will work on it then! I will try to document it properly (perhaps
write a tutorial in the wiki or so) so that other developers can use it as
a starting point to write their own programs that use lttoolbox-java.
This simple example client could be used as an example for how a OmegaT
> plugin could be coded for Per Tunedal.
> (perhaps Apertium-viewer is too complicated, but it could probably copy
> the simple example client code).
>
> You could also actually DO the OmegaT plugin, but please note that there
> are other usages, for example OpenOffice/LibreOffice and
> http://www.jubler.org/ .... so I dont think the plugin should really be
> inside each language pair.
>
The reason why I mentioned the idea of working on an OmegaT plugin was
because Mikel Forcada first and Per Tunedal later showed interest on it,
and I've spent some time working on it today (as I told you, I don't really
know where to concentrate my efforts now, if it's time to switch to iOS...
now the simple example client that you have suggested me will be my
priority, but I really need to discuss with you which direction should my
project take now). In any case, I agree that it would be possible to
develop plugins for many programs, and so making them part of each language
pair wouldn't make much sense.
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
