I have for a while tried to get the Apertium+Omega-T working for sme-smn, > but with no results. My last attenpt (and bugfix from one of the involved > developers, thanks!!) brought me to the point where I got a window telling > there was a path problem. >
If you tell me what the error message is I can look and try to fix it. Nobody said anything so I assumed that the fix worked. > What I would like to see is first and foremost work on the > Apertium+Omega-T (or similar) platform(s), set up as a **web-based** > service, so that users may download the program, and set up the MT service > with paths (preferably by choosing languages from a menu, evt. having a > menu referring to a dynamic list of language pairs). I thought that it was already possible to use web-based Apertium in OmegaT without any plugin (and, if it is not, it would be very easy to develop such plugin). The main point of having an offline plugin were 1) privacy, 2) confidentiality (apparently some translators can't use web-based services because of confidentiality agreements), 3) not depending on a permanent Internet connection and 4) being able to create packages and use any language pair no matter if it is released or not. It is funny that the OmegaT plugin has apparently become the most popular thing from my GSoC project, because it wasn't even in the initial plans. It was mainly conceived as a proof-of-concept of what could be done using lttoolbox-java as a library. I am quite satisfied with the Apertium+Omega-T platform as it is, the only > problem is that it does not work for the languages I work with. And when I > cannot get it work, the actual translators will not make it either. What > they need is a setup that saves their time, where they may either take the > MT sentence offered, or translate for themselves, and where, and this is > **very** important, the program fixes formatting, pictures, etc. for them. > The sad thing is that we have all this, we just do not see to it that it > works. > > I know there is a subset of the Apertium languages for which one is able > to just click and download. This is fine, for the ones that work with > those. I am also not against fixes that makes it possible for anyone with a > working commandline version of any Apertium pair to use it in Omega-T. On > the contrary, that would be great -- for me, as a developer. But that will > be irrelevant to the language community and their translators. What they > need is the possibility to use a web-based MT input, just like for the > Wikipedia Content Translation. > > During Google Code bids I have always favoured projects geared towards > concrete language works, although I have seen that there always have been > plenty of programmers applying with lot of interest but less of relevant > language knowledge. > > This is their time. Here, I really would like to see some input. The > difference between saying that something __is__ useful and that something > __could be__ useful is simply to big to be ignored. > I agree with you. As Tino pointed, we were talking about turning the Mitzuli project into something wider for all the frontends Apertium has. I won't be able to be a mentor this summer though, so I have removed my name from the project ideas page in the wiki. Mikel
------------------------------------------------------------------------------
_______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
