Allow discussion/commenting on translations

Daniel, we plan to implement a field for each translation item, where you can explain why you translated something in a particular way. Is that what you're looking for?

I'd certainly like that.

Is there any update on this?

Can we expect to see this comming? I'd really like such a feature!

Is there any update on this?

I would be a really nice feature, that will improve the overall quality of translations.

Web IM is the best choice ....

I hope to know who is translating/reviewing a specific package's translations .

This feature would be *extremely* useful. I'm sure most translation teams have specific procedures for proofreading translations. The way we (Danish translators) do it, someone writes a translation, then submits it for proofreading. The proofreader writes comments, and the translator then implements the proofreader's suggestions. This cannot be done at all using the web interface, so our procedure right now is to work by downloading and uploading entire po-files - which is the way every other project (GNOME, TranslationProject, KDE...) is handled.

Writing an email or IM to the translator could technically work, but then it's much more effective to write comments directly to the translations and just send an email saying 'Hey, could you make corrections according to these comments?'

Even if the proofreader changes the suggested strings as necessary and then incorporates them (which might be a more realistic procedure in Launchpad's case given how easy it is to make "hit-and-run" translations), many translators would still want to know why their translations were "rejected" (which is as far as I know the only thing they'll see if we insert a single comma before accepting the string).

It should be noted that "discussion" and "commenting" serve very different purposes in practice.

1) Discussing a translation suggestion before it is accepted. This corresponds to discussing it over a mailing list. Typical examples: "This would sound better if you split it in two sentences", or "Could you make sure that this word is used consistently throughout the module?" These become irrelevant after the string(s) has been accepted.

2) Commenting on a translation. This corresponds to the comments supported by the gettext po format. Examples: "I've checked the source code, and this is the correct translation even though it looks weird", "This term is explained on en.wikipedia.org/...". These comments help people save time, and prevent things from breaking because someone e.g. applies the standard convention in a special case where it shouldn't be. Also, these comments are permanent and can help different translators at a later time.

This should be done using the "translator comment" feature in gettext, both when importing and exporting. The comment would need to be stored with each TranslationMessage.

UI-wise this can only be incorporated in a future redesign of the trnaslate page.

You could do it like in MediaWiki's translation tool: add a special language code "qqq" where any text can be entered and edited to explain how ressources are used, what they mean, in which context it will be used and formatted, or if the same term to translate has several meanings in English but need separate translations...

This can also be used to add comments or caveats in the translations, that application developers will be able to read as well.

Then allow displaying this language code like other additional "language". In Mediawiki translation, this addition was extremely useful to help developers documenting their ressources and to allow bug reporting to application developers, so that they could split or reorganize their ressources.

Here is a description of the kinds of comments that are necessary in order to facilitate minimal communication between translators, coordinators and developers/packagers.

 * Developers/packagers should be able to write a comment for each template, which will be easily visible to translators when translating. This could be used e.g. to put a link to upstream, or (importantly!) stating if this is upstream.
 * Members of a translation team should be able to write a comment for each template, visible to translators of the same language. This would be equivalent to (and can be implemented using) the po-file header comment. This could be used to write down special rules/glossary and other info pertaining to that template.
 * Developers should be able to write a comment for each individual message visible to all translators (this is already supported in terms of the gettext comment feature, so nothing to do here)
* Translators should be able to write a comment for each individual message, visible to all translators of the same language (this is also equivalent to the gettext comment feature, but launchpad lacks an UI to make use of it).

This does not properly facilitate an efficient *discussion* of translations as the editing takes place, but it's an excellent start and should be simpler to design/implement than a "proper" discussion feature.

So who thinks this is important? Is there something that can be done to help getting some or all of this accepted and in the works? Maybe create some blueprints? I can't imagine that anyone reading this who has ever tried to translate would not consider this one of the most important prospective features. At some point in the future I'm willing to help develop this.

This is far too complex, all these goals are usually achieved with 2 types of comments, generic and language-specific.
And translators should also be allowed to edit the generic comment, as it's often the translator that investigates the context for a specific source term, so he should be able to share it with all languages by editing the (unique) generic comment.

The generic comment and the language-specific comments should be implemented in the web site systematically, there should be no comment template for the project managers to configure, or other complexities which can only prevent the comments from happening. It's really a basic feature, at least for the generic comment, if you need to prioritize things.

Right now, I know I have provided "risky" translations, i.e. translations that might be totally wrong, just because no context or mean of communication is provided on the web site. So I just hope that the "reviewers" (who will be just as clueless as I) would be able to spot and fix them if necessary.

The bug has been opened since 2005 and nothing happened since?
This does not encourage me from contributing to projects using Launchpad.

Indeed the single most important task is to implement support for standard gettext comments. Priority has been designated as "low" which is a serious mistake. This specific shortcoming makes Launchpad an inferior tool, causing massive waste of time not to mention a large number of errors.

I filed bug #970414 and had seen #211, but not this one.
This bug is from 2005 and not enough translators can have given their voice - the lack of a comment field is very impeding the quality of the translations. The review process hurts and a lot of suggestions never gets accepted or improved.

There are several suggestions on what to make of this bug report.
Personally I back Matthew's initial comment above:
"Daniel, we plan to implement a field for each translation item, where you can explain why you translated something in a particular way. Is that what you're looking for?"

The way I see this implemented could easily be done: add a textfield with write access to all registered users.
Debian DDTSS, a web interface for doing translation of package descriptions, has a comment field like this. Although the DDTSS is on its way to get replaced, the comment field is one of the great assets of DDTSS.

In DDTSS all comments gets wiped out as soon as a translation is reviewed. Also the comment field is just a textfield where everyone can edit. Though something more avanced would be of help at times, a simple editable field would be of great help in itself.

I have attached a screenshot of Debian's DDTSS web interface and the comment field in action - for those who don't know how it works. In the comment field a reviewer have suggested using another term for "all major browsers", which has been followed by the translator. The comment itself didn't need to be kept forever in this case, but improved the quality and built consensus among translator and reviewer.

This is certainly a tool of the cloud, will equip the local language contributors to interact easily and promptly. My bad, never heard of this, though I'm a member in launchpad since 2005.

This old bug/RFE has not changed since long.
During that time, Translatewiki.net has implemented it and used it in many translations (in fact the "qqq" is most often used, but each translation unit also has a talk page, rarely used)

10 years later... And still not solved.
Launchpad is SOOOOO late to add this essential feature that translators need to communicate or disambiguate the semantics.
This is a SEVER problem as we see now too many wrong translations throughour Ubuntu that are difficult to locate and developers never realize how their source translation packages are so ambiguous.

Every other platform has this feature. Please look at what is in Translatewiki.net : the "qqq" pseudo-locale is very helpful and absolutely NOTHING forbids Launchpad supporting this pseudo-locale where (instead of providing a translation) translators and developers could post some comments that would greatly improve a quality or offer a return from translators back to developers so that they disambiguate their packages or fix their untranslated items (many applications are slicing sentences by assuming the same order as English, or forget the context where in Englihs the same word is used for an infinitive verb, or an adjective, or an imperative or a noun... The result in actual translations is extremely poor, and frequently misleading !

If someone urgently needs this feature, might want to self-host or ask hosted.weblate.com for adding your project.