2012/3/27 Mikel Artetxe <[email protected]>
>
>>> Week 7-8: Adapt and extend the previous application so that it can work
>>> with several language pairs. This could be achieved by having a JAR per
>>> language pair and the main JAR executable that makes use of them or by
>>> integrating everything on a single JAR executable that is able to modify
>>> itself in order to add or remove language pairs from it (I am not sure
>>> about which approach would be better).
>>>
>>
>> I'd prefer to avoid modifying JAR files.
>> It's a ZIP file. If people wants several pairs in the same ZIP file they
>> can use ZIP.
>>
>>
>>
> I don't know if I have correctly explained my idea. In fact, this idea of
> the self-modifying JAR file aimed to be a solution for an easily
> maintainable system that you defend. It is true that, after all, JAR files
> are nothing but renamed ZIP files, so anyone could manually modify them in
> order to get the language pair that they want. But this wouldn't be the
> easy way of doing things from my point of view. My idea would require the
> user to first manually compile the language pair (I guess that this step is
> inevitable), then run the JAR executable and select the .mode file (or the
> directory) of the language pair compiled, and the JAR would automatically
> modify itself to be able to translate this language pair (or create another
> JAR file for that specific language pair, if you prefer). After that, it
> would be possible to distribute the JAR executables generated this way (it
> would be interesting to have a wiki page for them, for instance), so that
> anybody with the only requirement of having JVM could run them. I could
> create an executable for every language pair that apertium currently
> supports and create a wiki page with them. And with this system anybody
> could update or extend it in a very simple way, I guess.
>
Lets put people in two rough groups:
1) Apertium core developers. They are each maintaining 2-5 of the 20-30
language pairs that gets updated once in a while (lets say a release once a
month, on average). They are used to use makefiles and scripts.
2) All opthers. Occational users of Apertium and newbie developers.
Anything involving requiring 1) to use a GUI to maintain stuff is NOT
good. They will want to put stuff in makefiles and scripts to automate it.
Not because they hate GUIs (OK sometime I think that perhaps they hate GUIs
as well :-), but its just much faster to invoke 'make' than to locate and
invoke a GUI, pointing and clicking etc etc.
My hunch is that group 2) will very seldom need your fine GUI, and if they
do, they will survive just fine using WinZip. If they ask 1) they will be
instructed on how to use command line tools.
SO: Im sorry, I wasnt clear in my wording:
Easily maintainable means doable from command line. A script somewhere that
updates alle the JAR language pairs that need to be updated and
uploads/synchronizes the file tree on some download server.
We have some binary stuff in SVN (look for big files in dir 'webspace' in
the SVN tree - no-one remembers how to maintain this stuff but luckily
there is a makefile or update script somewhere I don't remember).
Another place would be on the download servers of Sourceforge, if we can
find out how to script upload and download from their servers.
If you really really want to make a GUI on this, fine, OK. But I'd expect
it to not been usen very often and I'd only spend limited time on it. And
as command line script for group 1) I think a makefile/shell script is more
adequate.
Any others have comments on this?
> OK. Let's take about 2 or 3 weeks to work on mobile embeddability (with
> "work on" I mean "investigate" or "try to" without a clear promise of
> getting a working app as you suggested in your email, that is, see what
> problems arise, try to solve them and definitely do something in which
> future work could be based).
>
Super
> By the way, getting the different libraries that Apertium C++ is dependent
> on included in an iOS app is not too complicated. In fact, I successfully
> got to compile apertium for iOS solving all the dependencies. Everything
> worked correctly in my prototype app up to the transfer step, in which
> something was failing (the translations that it was giving were empty
> strings, and I wasn't able to find out why).
>
That sounds great!
I'd suggest that we put aside some time to diverge a little from
lttoolbox-java and see if we can embed lttoolbox as well.
> You then updated the wiki and I saw that the "Apertium on your mobile"
> task was mainly focusing on Android, so I definitely gave up and start
> focusing on this other project idea.
>
I wasnt aware that you had already done work on porting the C++ code iOS.
Sorry about that!
My own experiences are with Android and I am in general biased towards open
source platforms (and I would be unable to mentor iOS stuff). One could
probably argue endlessly about each platform's qualities etc. But we should
set some time aside for iOS and of course we should following the path that
you judge is most feasible.
Jacob
--
Jacob Nordfalk <https://plus.google.com/114820443085046080944>
http://javabog.dk
Android-udvikler og underviser på
IHK<http://cv.ihk.dk/diplomuddannelser/itd/vf/MAU>og
Lund&Bendsen <https://www.lundogbendsen.dk/undervisning/beskrivelse/LB1809/>
------------------------------------------------------------------------------
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here
http://p.sf.net/sfu/sfd2d-msazure
_______________________________________________
Apertium-stuff mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/apertium-stuff
