Request for feedback about Apertium

Jump to navigation Jump to search

Request for feedback about Apertium

Hi translators! We provide machine translation suggestions using Apertium here. It has a feature that if the source language (i.e. English) is not supported by Apertium, it looks for translations to other languages and see if any of them is supported by Apertium, and using that language instead of English to create a suggestion.

We have received multiple complaints about this feature and are considering to remove this feature.

Before removing this feature, I want to know from you whether you find this alternate source language feature useful. Since most language pairs supported by Apertium do not include English, this would remove most translation suggestions from Apertium.

So let us know, should we remove it, keep it, or limit it to some languages only?

There is also a task in Phabricator about this:

Nike (talk)12:13, 15 August 2022

Personally I like the Apertium translations – the ones suggested to me are usually Swedish → Norwegian Bokmål. It is not perfect, but it usually gives good suggestions, and for short messages my translations often end up exactly (or almost exactly) like what Apertium suggests.

Jon Harald Søby (talk)12:36, 15 August 2022

I have a positive view of it, overall. An English → Hindi pair doesn't exist, so a fallback with mixed Hindi and Urdu words are suggested to me, which is not perfect, but has still given me some good suggestions so far. Personally, it doesn't affect me since Google Translate is now supported and its suggestions are much more accurate than Apertium.

~Saurmandal १९:५५14:25, 15 August 2022

You do not have permission to edit this page, for the following reason:

The action you have requested is limited to users in the group: Users.

You can view and copy the source of this page.

Return to Thread:Support/Request for feedback about Apertium/reply (3).


In my case as an en-ja translator, Apertium and its zh-ja translation suggestions are very handy. Basically, translation in zh gives me hints what context the source language (eg. en) holds. But still need to be cautious as some wording holds quite contrasting meaning/different context between ja and zh.

  • Zh-hant and ja share writing system, but not grammar, for over 1,400 years.
  • Actually, it is zh-hant, or traditional Chinese writing system or 漢字.

I can guess what a sentence written in simplified Chinese, or "zh" means, but still I sometimes have to look up digital dictionaries/thesauri as they are not always visually identical to its ja cousin and requires extra work to read. :)

Please don't apply DeePL at least for en-ja and ja-en translation. For Google, I know its shortcoming and how to fix, but with DeePL, it outputs silky smooth sentences mixing in contextual error. That is very hard to proofread.

  • the translator/proofreader circle on ja-Wikipedia has been suffering with direct DeePL output: So much errors annoying those cleaning up the mess. We are seeing more users with good intention, happily dropping new articles that they fabricated with DeePL: too innocent to care about the baseline, you copy-vio by input directly to wikis when you use DeePL.
  • It outputs, I am talking about in en-ja language pair, more than often as making the "x is y" context into "x ISN'T y", and that is very disturbing. As its output looks very smooth otherwise, sometimes very easy to slip the proofreaders' attention.
Omotecho (talk)11:59, 16 August 2022

It sometimes does not do the correct translation so sometimes you may say "refrain from using Apertium in this message group".

Cigaryno (talk)13:35, 16 August 2022

Repeating my experience at As an en-es translator, Apertium is usually just bad and their translations make absolutely no sense many times. I'd love to see it removed for Spanish.

MarcoAurelio (talk)11:35, 17 August 2022

Just an example out of many. The proposed Spanish translation for MediaWiki:Parsoid-stash-rate-limit-error by Apertium is as follows:

Stashing Falló porque límite de índice estuvo superado. Complacer probar otra vez más tarde.

That is just eye-breaking horrible and makes no sense at all.

MarcoAurelio (talk)15:17, 21 August 2022

Hi, I translate EN -> FR and I do no longer rely on Apertium and sometimes it makes me laugh. A lot of errors of syntax, words not translated, mistakes... I understand it is not easy to translate automatically and I was explained from Apertium that they uses steps of intermediate languages to have the result. So I get rid of it and translate on the flow, and sometimes I use Google Trad but that means that the EN form is not clear enough (ex: Where is the subject?) or appears ambigous depending on the culture I have. Google Trad remain the best for me, very clever to solve gramatical trick FR has. I agree with @MarcoAurelio.

Christian 🇫🇷 FR (talk)18:03, 17 August 2022

Sometimes, its translations can be pasted and corrected (usually, when the MediaWiki message is shorter). Sometimes. But I fear that some users will unwillingly abuse by the machine translation, pasting the translation without correcting it.

NGC 54 (talk)22:51, 18 August 2022

I mostly remember it offering inconsistent translations into Afrikaans, which doesn't make any sense when translating to Dutch. It also mangled formatting and never showed up consistently. The existing Google suggestions are miles ahead of whatever Apertium is doing and almost always present. I wouldn't be sad to see it go, at least for Dutch.

Mainframe98 talk09:47, 26 August 2022

I don’t think anyone should use machine translations as-is anyway (at least for longer messages). As for the question itself, I think that for Russian having translations from Ukrainian and Belarusian is helpful sometimes, since you can see how someone else interpreted a message if its text is not clear to you.

stjn[ru]13:34, 26 August 2022