El dj 06 de 02 de 2014 a les 00:31 +0100, en/na Mikel Artetxe va escriure: > > A related question for Mikel: > > > How much work would it be to make Mitzuli support HFST and > VislCG in > translators ? Would it be enough work to make a GSOC project > do you > think ? It's a really sought-after feature here (in Tromsø). > > If I’m not wrong this is something that has already been discussed in > the past. There are basically three options: > > > 1.- Use Apertium web service for these pairs. This is something that > Mitzuli will soon be doing. The obvious disadvantage is that this > would only serve for online translations (and seeing that Apertium web > service has been down for so long, relying too heavily on it doesn't > seem like a good idea neither).
I don't really like this option. Some of the pairs aren't available in the web service either (e.g. sme-nob, kaz-tat). > 2.- Try to use the existing code of CG and HFST in Android through the > NDK. It should work, and it wouldn’t probably be too hard, but I guess > that it's not the most elegant solution. The whole point of > lttoolbox-java as I understand it is to provide a full > easy-to-integrate Java port of the Apertium runtime, and this approach > would basically involve turning it into sort of a Frankenstein. > Moreover, it would only serve for Android and not for Desktop (so no > Apertium-Caffeine, Apertium-OmegaT etc.). > > > 3.- Port CG and HFST to Java (it seems like the latter is already > done, right?). The advantages are clear, and the only disadvantage > would be having to actually do (and maintain) it. The only thing to do for HFST would be to implement the "hfst-proc" tool using the Java API. We don't need the compilers etc. This is probably a month's work for a good programmer. (The C++ one took 3 months for an excellent coder, but that was without a reference implementation). The question is CG. There is a C library for vislcg, and as far as I know the code is very portable, and I think it has been used inside Java before. I think writing a runtime for it would be too much work for a GSOC project, but I think, given some effort it could be included and in a way that doesn't require calling a C binary directly. Perhaps a combination project of getting all the tools (Mitzuli, Apertium-Caffeine and Apertium-OmegaT) working would make a good project. > I don't know about the internals of CG and HFST, so I can't really > judge which would be the best way to go and whether it would be a > suitable GSoC project or not. I would say that option 2 would be far > to little for a whole GSoC, but it might be an interesting part of a > bigger project. Option 3 would be awesome for me, but it would > probably be asking too much for a GSoC. What do people that know about > the code of these tools think? Agree that (2) would probably be too little, perhaps with a few more tasks it could be enough. Good question :) F. ------------------------------------------------------------------------------ Managing the Performance of Cloud-Based Applications Take advantage of what the Cloud has to offer - Avoid Common Pitfalls. Read the Whitepaper. http://pubads.g.doubleclick.net/gampad/clk?id=121051231&iu=/4140/ostg.clktrk _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
