Fuzzy translations in PO files are not shown

Reported by Torsten Bronger on 2009-12-06
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Undecided
Unassigned

Bug Description

If you merge a PO file with an updated POT file, the result may contain many "fuzzy" translations due to typos fixed in the POT, or new strings which are similar to old ones. However, these fuzzy translations are not exposed in Rosetta. Instead, the translator has to translate the string like a completely new string.

Curtis Hovey (sinzui) on 2009-12-29
affects: launchpad → rosetta

This is a conscious design decision since standard msgmerge feature works only in a very limited set of circumstances. With a tool like Launchpad it was found to do more harm than good.

The proper way to implement it is to have a good algorithm (probably word or tri-gram based):
https://blueprints.launchpad.net/rosetta/+spec/rosetta-fuzzy-merge

Changed in rosetta:
status: New → Won't Fix
Torsten Bronger (bronger) wrote :

We are talking about different cases.

I only suggested that the work that *gettext* has already done, namely taking an existing translation and marking it as "fuzzy", should be propagated to Rosetta. Currently, the translation is simply dropped -- which is very discouraging for the translator who has to regenerate the translation from his own backup. And typos in msgids are frequent.

You mean probably the case that the PO file contains no fuzzy tag, but the msgid has changed for a translation which was made in Launchpad. Then, I can understand that Rosetta refuses to decide which translation is the best one.

But look at https://help.launchpad.net/Translations/YourProject/ImportingTranslations at the bottom "How Launchpad prioritises imported translation strings". If the imported string has precedence and it is tagged as "fuzzy", Rosetta should somehow expose it to the translator. I see no possible harm then.

Hi Torsten,

El dc 07 de 04 de 2010 a les 07:35 +0000, en/na Torsten Bronger va
escriure:
> We are talking about different cases.
>
> I only suggested that the work that *gettext* has already done, namely
> taking an existing translation and marking it as "fuzzy", should be
> propagated to Rosetta. Currently, the translation is simply dropped --
> which is very discouraging for the translator who has to regenerate the
> translation from his own backup. And typos in msgids are frequent.
>
> You mean probably the case that the PO file contains no fuzzy tag, but
> the msgid has changed for a translation which was made in Launchpad.
> Then, I can understand that Rosetta refuses to decide which translation
> is the best one.
>
> But look at
> https://help.launchpad.net/Translations/YourProject/ImportingTranslations
> at the bottom "How Launchpad prioritises imported translation strings".
> If the imported string has precedence and it is tagged as "fuzzy",
> Rosetta should somehow expose it to the translator. I see no possible
> harm then.
>

It thought I'd quickly share these two links from the translators list,
in which Danilo explains in more detail the rationale behind this
decision and a workaround to recover the fuzzy translations from the PO
file if wanted:

https://lists.ubuntu.com/archives/ubuntu-translators/2010-April/003473.html
https://lists.ubuntu.com/archives/ubuntu-translators/2010-April/003476.html

Torsten Bronger (bronger) wrote :

Thank you very much for the links! I think the real discussion should proceed on this mailing list, so I make only two comments regarding this bug here:

Please note that built-in support for fuzzy translation merging in Launchpad, and passing fuzzy tags from the original PO file are different things! This seems to be mixed up in the discussions and bug reports frequently. My bug report suggests the latter.

The only thing in the discussion which is related to my bug report is that exposing the fuzzy translation in Launchpad could confuse translators. Well, it doesn't make the translation page easier but losing the translation is much worse!

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Related questions