Difference between revisions of "Java port of Apertium runtime"

From Apertium
Jump to navigation Jump to search
(Created page with '<pre> This opens a new discussion: A "Java port" of Apertium, enabling use on - Windows, - J2ME/Android phones, - web pages (applets), - desktop application, - Java server a…')
 
Line 1: Line 1:
⚫
A "Java port" of Apertium would enable use on
<pre>


⚫
This opens a new discussion: A "Java port" of Apertium, enabling use on
- Windows,
- Windows,
- J2ME/Android phones,
- J2ME/Android phones,
Line 12: Line 11:
AFAIK we havent seen anyone embedding Apertium in a desktop application. Currently Apertium is usable in a local subdir but installation isnt trivial to an end user, but note that 'embedding' something isnt the same as 'using a locally installed version'.
AFAIK we havent seen anyone embedding Apertium in a desktop application. Currently Apertium is usable in a local subdir but installation isnt trivial to an end user, but note that 'embedding' something isnt the same as 'using a locally installed version'.


Having a packaged easy-to-use version of Apertium ready for embedding MT in a larger program would be so cool I havent got words for it.
Having a packaged easy-to-use version of Apertium ready for embedding MT in a larger program would be very cool.
Ideally should a self-contained Apertium JAR file, only dependent on JRE and/or a JAR file per language pair.

⚫
An "embedding" approach is to use a client stub to an [[Apertium web service]], but there can be reasons why people prefers to have things installed locally (we don't need to repeat them here).


⚫
Of course an answer here is "web service", but there can be reasons why people prefers to have things installed locally (we don't need to repeat them here).


Missing for a complete port of apertium in java is tagger, piping/modes, interchunk/postchunk and format handling.
Missing for a complete port of apertium in java is tagger, piping/modes, interchunk/postchunk and format handling.


Any thoughts on this?


Af I see it:
Af I see it:
Line 26: Line 26:
- Format handling: I'd say that it would be OK just to be able to handle normal text.
- Format handling: I'd say that it would be OK just to be able to handle normal text.


--[[Special:Contributions/110.44.113.254|110.44.113.254]] 08:19, 14 March 2010 (UTC)
Jacob
</pre>

Revision as of 08:19, 14 March 2010

A "Java port" of Apertium would enable use on

- Windows, - J2ME/Android phones, - web pages (applets), - desktop application, - Java server applications.

The last 2 is relevant as, for example an OpenOffice.org plugin should be platform independent to be maintainable.

AFAIK we havent seen anyone embedding Apertium in a desktop application. Currently Apertium is usable in a local subdir but installation isnt trivial to an end user, but note that 'embedding' something isnt the same as 'using a locally installed version'.

Having a packaged easy-to-use version of Apertium ready for embedding MT in a larger program would be very cool. Ideally should a self-contained Apertium JAR file, only dependent on JRE and/or a JAR file per language pair.

An "embedding" approach is to use a client stub to an Apertium web service, but there can be reasons why people prefers to have things installed locally (we don't need to repeat them here).


Missing for a complete port of apertium in java is tagger, piping/modes, interchunk/postchunk and format handling.


Af I see it: - Interchunk/postchunk I could do in very short time, so I could mentor this - Tagger: The C++ code is there and some has already been ported to Java (lttoolbox parts), probably someone could port it relatively easy, if someone understanding tagger would co-mentor that part. I'd say its not necessary to port tagger training, just the core (bigram) tagging during translation. - Piping/modes isnt too hard. - Format handling: I'd say that it would be OK just to be able to handle normal text.

--110.44.113.254 08:19, 14 March 2010 (UTC)