>
> OK. This would be my very first draft of the work plan:
>>
>> Week 1-3: Adapt lttoolbox-java so that it can directly work with embedded
>> files without the need of copying them to a temporary directory.
>> Week 4: Make an API class that easily allows the translation of an
>> embedded language pair. Work on a demo JAR executable usable from the
>> command line that would make use of it with a specific language pair.
>>
>
> I'd set some time aside to understand the MT engine. Read some articles,
> choose 2-3 language pairs, compile them, change them, see how stuff works
> under the hood. Add some words that are missing to a language pair of your
> choice.
> Use apertium-viewer or something else that lets you see what happens at
> each stage.
>
>
As Jimmy points out in his reply, I would say that this would have to be
done at the community bonding period. In fact, this is something that I
have already done to some degree: as I told you, my initial idea was to
work on an iOS port of apertium, and I even worked on a prototype (that
only worked partially, then I decided to work on this other idea), which
served me to learn about the different steps involved in a translation. Of
course, if my proposal is finally accepted, I will be working on further
understanding how the MT engine works, but this would be done at the
community bonding period as I have said before.
>
>
>> Deliverable #1: The above mentioned JAR executable.
>> Week 5: Work on an API class that allows access to the intermediary
>> translation stages.
>> Week 6: Make a small user-oriented Swing application for a specific
>> language pair (something similar to apertium-tolk). The idea is that any
>> user with the only prerequisite of having JVM installed could download and
>> run it by just double-clicking it.
>> 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'd prefer one JAR per language pair and I'd prefer that it would be
> directly executable as-is from the command line.
> We have already established that it only add 200kb to the JAR. If we embed
> a small swing app, like Apertium-tolk then it should be really small and
> simple, of course.
>
> People that doesent want to the extra bloat or want to collect several
> pairs in one JAR can use a ZIP tool to remove bloat or collect pairs. JAR
> file structure should support this, of course.
>
> An unzipped JAR should also be usable by Apertium-C++. We don't ship
> downloadable compiled pairs ready to unzip and use. Everyone needs to
> compile them themselves. Embedability is also about that (ease of getting
> started).
>
> I'd like us to host ready-to-use pairs and I'd like you to think about how
> we could do that, make a list discussion about it and set something easily
> maintainable up for language pair binaries. Open source is not always about
> coding, its also about setup and organization of stuff.
>
>
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.
Isn't this easily maintainable? I think that it would at least be easier
than requiring to manually modify JAR files... What would be your
alternative?
>
> Deliverable #2: The Swing application developed on week 6-8.
>> Week 9-11: Integrate everything with apertium-viewer so that it can work
>> with the JAR files of the above mentioned Swing application.
>> Week 12: Suggested "pencils down" date: write documentation, test
>> everything...
>>
>> To tell the truth, I am not really sure about it (probably too few things
>> to do and not very well specified...). What's your opinion? Any suggestion?
>>
>
> I think it's well enough specified, but theres probably too much time set
> aside for Swing stuff. Keep the Swing stuff really really simple.
>
Yes, you are right. I will take it into account.
> More time for tests on J2ME, Blackberry, Android, ios (we might conclude
> that xmlvm.org is really really easy to get java port converted to
> objective-C and much easier than to get the different regexp and XML
> libraries that Apertium C++ is dependent on included in an objective-C or
> the inverse), applets, servlets would be welcome.
>
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). In any case, my experience with mobile
development is mostly limited to iOS (of course, I would be working hard to
learn about the rest of the platforms that you mention during the community
bonding period and the program).
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). 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.
> And perhaps you also set too much time aside too much time for making APIs
> (or add 'with a demo client' to the text), provided that there is already
> an API you should follow the spirit of. See for example
> http://wiki.apertium.org/wiki/Apertium_web_service#Javascript_library.
> (Googling I found this one as well:
> https://github.com/rmtheis/apertium-translator-java-api )
>
OK. I will have a look of them when I have time.
>
> OK, I really bombed your plan, but we have 2 weeks to collect the pieces
> :-)
>
That's nice! As I mentioned, I wasn't really sure about my own plan, so it
is always good to have this feedback in order to improve it. I will be
updating the working plan according to all these.
>
>>
>> Yes. This is way I have added it to the work plan. In any case, is there
>> anything that I should work on regarding the coding challenge or do you
>> consider it finished?
>>
>>
> I think you have convinced everyone that you can - and will - do stuff,
> and you can make qualified decision, so yes, coding challenge is finished
> :-)
>
Thank you!
------------------------------------------------------------------------------
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
