Translations keep disappearing

As nothing was designed to operate like that, here's my guess: strings that disappear are probably "almost identical" (i.e. a typo, punctuation or spacing is different) to a human, yet it's not to a machine. Thus, these translations don't get reused, especially since LP drops fuzzy translations (because they sometimes give very bad results). This happens very commonly with PO files generated from documentation (long paragraphs, etc). We'd like to improve this part of LP, but we still haven't had the time to do it.

If this is not it, it's a pretty strange bug, and it'd help us if you can have those translators point us exactly at the message (URL would be perfect) that they translated and which later disappeared. Please re-open the bug once you have more details.

As far as I can tell, the only thing that changes within the .po files is line wrapping within the msgid strings. That shouldn't make any difference, should it?

I'll get the translators to indicate the missing strings here as comments.

This happened to me for Ubuntu Manual.

I had translated about 700 strings/texts and then, after one update, all disappeared. If it was the case of such typos as referred in the first message, I don't believe it'd make sense to remove ALL the translations, right? Or did every single one of them had minor changes?

I have to say this only happened to me in the Ubuntu Manual project. I've translated some other projects in Launchpad and it never happened to me, so I could agree it is probably some problem in Ubuntu Manual's settings while importing translations, or something like that. Anyway, don't you have any other idea that could make this happen?

For me it seems just normal. When a string changes, the translation ist lost. The point is, the manual is under heavy development so far, so it's normal, that a lot changes right now. I'm maintaining the german translation, there are some translations lost, but not all. Don't think it's a bug.

Hi Daniel,

If it were just a few strings, I'd agree with you, it was "normal" (though I don't think it's good for a translation system that can suggest translations based on the same strings on other projects, not to be able to make a suggestion of an already-submitted translation, but that's another case, and I agree it can be somewhat difficult to make it happen), but all of them were removed, so the problem was another. I have to say that such event hasn't occurred recently (only one or another text/string goes missing), but if the first event can't be justified, who can say it won't happen again?

Oh, we agree we should have better string similarity based suggestions. It's just non-trivial to implement so hasn't been done yet.

Josh, line wrapping in msgids is irrelevant if it's done according to the rules of PO file syntax. For example, the following are identical strings:

  msgid "Something " # single space at the end
  "good"

and
  msgid "Something"
  " good" # single space at the beginning

However, this string is different
:
  msgid "Something " #single space here
  " good" # and another here

as is
  msgid "Something \n" # newline after space
  "good"

I don't know how po4a handles such changes in your source format, but if it's XML, I'd advise trying out xml2po (from gnome-doc-utils) instead and seeing how that works for you. It's designed to be very sane when it comes to XML handling for translations. Though, looking at the messages, I guess you are using LaTeX, but that'd need investigation.

Bruno, it's very interesting. Can you let me know of the approximate date when it happened? Did you translate directly in Launchpad[1] or did you upload a PO file? If you uploaded a PO file, do you remember what options you used for that ("updated translation" or "imported translation")?

[1] Eg. on https://translations.edge.launchpad.net/ubuntu-manual/main/+pots/ubuntu-manual/pt/

Not a bug. Launchpad/rosetta was never designed for such active development.

Everything will be fine after the writing freeze on the 31st March.

Marking invalid in Ubuntu Manual.