2012/3/25 Mikel Artetxe <[email protected]>
>>>> I think we should leave 'reducing start-up time' for now, as its not
>> neccesarily a task that has anything to do with embedding. Sorry.
>>
>
> Well, maybe I can work on it, the only thing that I meant was that right
> now I wouldn't really know how to accomplish it. And I don't want to accept
> something unless I am confident that I can do it...
>
Perhaps other mentors have an opinion on this:
Is it OK to schedule 'investigation', 'work on', 'try to' stuff in a work
plan without clear promises of working code?
My opinion is: Yes, as long as there is some kind of deliverable, for
example a written description on what was tried out and what was found out
so others could use it as base for future work on that area.
> but an Android app would require more time (although I have experience
>>>>> on mobile development for iOS I haven't developed anything for Android,
>>>>> but
>>>>> it shouldn't be too difficult for me to learn it, I guess).
>>>>>
>>>>
>>> Fine, as long as the scope is embeddability, and not making
>>> sophisticated GUIs.
>>>
>>>
Perhaps we could simply set some time aside to look at 'mobile
embedability' without specifying a mobile OS.
> 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.
> 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.
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.
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.
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 really bombed your plan, but we have 2 weeks to collect the pieces :-)
>
> 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 :-)
--
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
