Folks:
some comments and clarifications:
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).
It was already there before the Apertium-OmegaT plugin. I don't know the
webservices they use, but the functionality is there. In principle, any
pair offered through the API should work fine in OmegaT.
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.
The rationale behind using an online plugin is clear and I share it
completely. And rather than a proof-of-concept, it is a great product
for translators. I have used it to translate political material from
Spanish to Catalan at incredible rates (say, 2000 words per hour).
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.
We teach our students computer-aided translation and machine translation
and they carry out a 10,000-word project (in groups of 4) using OmegaT
and the available plugins.
For those who use OmegaT to produce publishable documents with the help
of machine translation, it would be great to have a plugin that supports
as many languages as possible. I would favour any GSoC project going
towards that goal.
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.
Well, my take is completely different here. A locally-installed,
general-purpose, free/open-source computer-aided translation tool such
as OmegaT allowing you to use both machine translation and your
translation memories to produce new material is far more powerful and
responsive than any ad-hoc web interface (unless it is tightly bound
with a great product such as Wikipedia) and, in fact, such a tool is
what many professional and volunteer translators would choose to use if
(a) they knew about it and (b) they got decent support for the languages
they work with.
In fact, using Apertium and OmegaT you can even give an indication the
quality of each target word in a translation hypotheses coming from the
translation memory, without actually presenting any MT output to the
translator (see http://www.dlsi.ua.es/~mespla/edithints.html).
You can also log the work of the translator with a plugin
(https://github.com/mespla/OmegaT-SessionLog) and mine the log file to
assess the effect of MT in translator productivity.
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.
Improving Apertium language pairs and making them work in all platforms
and webservices is crucial, I agree.
Cheers
Mikel
--
Mikel L. Forcada (http://www.dlsi.ua.es/~mlf/)
Departament de Llenguatges i Sistemes Informàtics
Universitat d'Alacant
E-03071 Alacant, Spain
Phone: +34 96 590 9776
Fax: +34 96 590 9326
------------------------------------------------------------------------------
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
