Hi Trond, As I have some experience of both translation and of using OmegaT, I just want to point out some issues:
1. Translators are very often explicitly forbidden to use all kind of web tools due to strict confidentiality enforced by the client company. 2. The Apertium plug-in to OmegaT has the great advantage over e.g. Google Translate that it's run locally. BTW an other advantage is of course that its free - using the Google api will be quite expensive in the long run. Unfortunately, the translation quality is presently far better using Google Translate. Yet, using Apertium is an interesting option for translators working in the proliferating commercial market. Making the OmegaT plugin a web service would certainly make it less interesting for translators. Finally, I agree with your reflection: > 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. Yours, Per Tunedal On Sun, Mar 6, 2016, at 21:22, Trosterud Trond wrote: > > As one of the people working hard for some of the Apertium projects in > the nursery catalogue, I find it a challenge to convince people in the > language communities that this whole entreprise is a good idea. Since the > usage scenario is translation for text production, and not gisting, I am > dependent upon two things: > > - high quality output (which obviously I and my team are responsible for > ourselves), and > - translation programs to support translators in their work. > > For the last type, there are two candidates for Apertium: The Wikipedia > content translator, which is great, and has the functionality I want (see > below), but is only for Wikipedia translation, and the Apertium + Omega-T > program setup. > > 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. > > Anoying as this showstopper is, that is not the point of this letter, it > is only a symptom of the neglect the issue has. My point is that the good > translation programs we build within the Apertium framework are not put > into use (and hence looses the opportunity to much developmental feedback > from users and communities), since we do not have platforms for their > use. > > Prompsit uses Apertium, this I think is fantastic. But they have their > own priorities, and most of the language pairs we work with are outside > those priorities. > > 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 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. > > Trond > ------------------------------------------------------------------------------ > _______________________________________________ > Apertium-stuff mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/apertium-stuff ------------------------------------------------------------------------------ Transform Data into Opportunity. Accelerate data analysis in your applications with Intel Data Analytics Acceleration Library. Click to learn more. http://makebettercode.com/inteldaal-eval _______________________________________________ Apertium-stuff mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/apertium-stuff
