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)