>
> I have tried this and it works great! It is an excellent idea.
Thank you!
> It would also be nice if you could provide a pointer to where the Java
> sources are...
>
It simply consists of lttoolbox-java with some extensions and adaptations
that I have been working on. You can currently find it
here<https://apertium.svn.sourceforge.net/svnroot/apertium/branches/gsoc2012/artetxem/lttoolbox-java/>in
my branch, but we will be moving it to trunk when its finished.
Is android-sdk free software? I hope so! I couldn't determine it from
> the contents of android-sdk_r20-linux.tgz.
>
Yes, it is. Look here <http://source.android.com/>. It mostly uses the
Apache license, but some parts (like the Linux kernel) use GPLv2.
In any case, the android-sdk is only used to convert the transfer classes
from standard Java bytecode to Dalvik bytecode, which is what Android uses.
So, actually, only dx.jar is required (which is part of the android-sdk and
takes only about 1MB) to perform the conversion. This way, it would be
possible to keep dx.jar somewhere and offer it to download instead of
making everybody install the android-sdk.
Would there be a way to automatically keep these pairs updated with the
> latest release or with the subversion version? That would be great!
>
That's precisely what I wanted to discuss.
The solution that I'm proposing would semi-automatize the task of keeping
the pairs updated. It would only require Apertium developers to run those
two scripts whenever they want to update a given language pair, and the
scripts would do all the work. This is why I say that this is something
that would involve the whole Apertium community and wanted to discuss it
with everybody.
Alternatively, if you consider that this is a heavy task and it would be
hard to involve every language pair developer, we could set one (or
several) responsible of maintaining all the language pair packages and
submitting periodical updates (let's say once or twice a month). The task
could be easily automatized by a script, so it would be simple to carry
out. I offer myself to do it. The advantage of it is that it wouldn't
bother the rest of Apertium developers; the disadvantage that updates would
be periodical, so they wouldn't always reflect the last state of the SVN
sources.
I think it would be nice if you could maintain a wiki page with all
> these explanations.
>
I'm trying to explain my work and show my progress in
this<http://wiki.apertium.org/wiki/User:Mikel/Embeddable_lttoolbox-java:_Progress>wiki
page. Once we adopt a definitive solution, I will create a wiki page
explaining all this.
I am assuming that HFST-based language pairs don't work, am I right?
>
I'm afraid you are... As I have said, the whole stuff basically consists of
an extended lttoolbox-java, so everything that is compatible with it will
work, and everything that is not compatible with it won't work.
------------------------------------------------------------------------------
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
