Related to this. Some locales store comments in their l10n files. Once we have adding and displaying comments implemented, we should be able to display comments from l10n files, too. AND - keep them in l10n files while serializing them.

(In reply to Matjaz Horvat [:mathjazz] from comment #3)
> Related to this. Some locales store comments in their l10n files. Once we
> have adding and displaying comments implemented, we should be able to
> display comments from l10n files, too. AND - keep them in l10n files while
> serializing them.
It turns out there aren't many local comments in l10n files, see bug 1293040.

(In reply to Matjaz Horvat [:mathjazz] from comment #6)
> Do you mean the check how many local comments are present in Danish files?
Yes. I have no way to tell at the moment, and I feel like you had a way to check it.

There are 11048 strings in Danish Firefox Nightly (50) as of this moment.
2897 of them have comments:
* 2663 of those are the same as in source files
* 213 of those are different than in source files (see different.txt)
* 21 of those don't have matching comments in source files (see unmatched.txt)
Quickly going through the list of different and unmatched comments, they seem to be the consequence of source comments being changed or removed.
I haven't found a single comment that looked like an actual locale specific comment.

We do not comment in the files. We use Bitbucket when proofreading, and we can write comments in Bitbucket. Being able to comment and offer up suggestions is paramount when proofreading. The alternative would be use e-mail, as Artem wrote at the top of this page, and e-mail is not very practical. At the moment we use e-mail when proofreading files that is not in Mercurial and it is much more cumbersome to do it that way.

Perhaps I should elaborate on the need for comments:
The comments should be displayed as a thread in order to have a discussion amongst the translators. Like:
- I am not sure about what the meaning of this string is. (translator1)
-- I believe "file" is not a computer file but the action to file something. (translator2)
-- If you look at the bug, you will see it is a computer file (translator3)
--- OK, thanks. (translator1)
It should be possible to subscribe to notifications by e-mail when there is a new comment. The e-mail should contain a link to the file and the string with the comment in Pontoon to make it easy to answer.
The comments could be places under a tab next to History, Machinery, and Locales.
It would be nice if it would also be possible to comment on the file level, like if there is a new function mentioned in several strings in the file. Discussing that on the file level would be more logical than discussing it in several strings.

I am also interested in being able to leave comments in target strings for other translators (is this is the right bug?).
For Catalan I sometimes leave comments in strings that I translate myself. They are normally added in strings that are not translated in the "usual" way for Catalan. For example:
\firefox\browser\chrome\browser\browser.dtd.po
># Traduït com "Oblida" perquè hi ha problemes de gènere (ha de concordar tant amb "minuts" com amb "hores") - jordis
>#. LOCALIZATION NOTE: (panicButton.view.mainTimeframeDesc, panicButton.view.5min, panicButton.view.2hr, panicButton.view.day):
>#. The .mainTimeframeDesc string combined with any of the 3 others is meant to form a complete sentence, e.g. "Forget the last: Five minutes".
>#. Please ensure that this remains the case in the translation.
>#: panicButton.view.mainTimeframeDesc
>msgid "Forget the last:"
>msgstr "Oblida:"
>
># Traduït com "Els darrers cinc minuts" perquè hi ha problemes de gènere ("Les darreres dues hores"... - jordis
>#: panicButton.view.5min
>msgid "Five minutes"
>msgstr "Els darrers cinc minuts"
>
># Traduït com "Les darreres dues hores" perquè hi ha problemes de gènere ("Els darrers cinc minuts"...) - jordis
>#: panicButton.view.2hr
>msgid "Two hours"
>msgstr "Les darreres dues hores"
These comments are important because a subsequent translator/reviewer would feel compelled to "fix" that translation that looks wrong. Only the comment gives information about why it was translated that way.
Other comments deal with terminology used in that string.
I think it is important to be able to leave comments in the translations and it is feature that we had available in Pootle.

Here's a quick take on how the UI could look like without adding much clutter to the History tab:
https://invis.io/QEE6504ZP
Notification would be sent to translation author and users mentioned in the comment (@ triggers user selector popup).
On longer term, we could also autocomplete MQM issue types (@ triggers issue type selector popup) and even make them required if the translation is edited or rejected.

Looks really interesting. A few questions:
* Do you plan to add a "Unread comments" when viewing notifications?
* Translator should see comments on their strings, managers should see comments on all the strings.
* Should comments have more than two states (read, unread)? I'm thinking: if user A comments to report a potential issue on one of my strings, and I read the comment and forget, that alert is lost. For example, the states could be: open (i.e. needs action), closed (discussion is done), read, unread.

:flod
ad3. e.g. The Confluence from Atlassian uses word "resolved" instead of "closed".
:mathjazz
Do you want to support nested threads in comments or do you plan to keep flat structure?
Also, do You want to have direct links to comments/threads? That could be useful for e.g. notifications.

(In reply to jotes from comment #19)
> :mathjazz
> Do you want to support nested threads in comments or do you plan to keep
> flat structure?
Translation comments are not a core feature of a translation tool, so I'd like to avoid adding complexity and keep the structure flat. That's also why the UI proposal from Comment 16 can display comments as nested against the translation.
> Also, do You want to have direct links to comments/threads? That could be
> useful for e.g. notifications.
Agreed.

(In reply to Francesco Lodolo [:flod] from comment #17)
> * Should comments have more than two states (read, unread)? I'm thinking: if
> user A comments to report a potential issue on one of my strings, and I read
> the comment and forget, that alert is lost. For example, the states could
> be: open (i.e. needs action), closed (discussion is done), read, unread.
Do we need to account also for non actionable comments, e.g. "I translated TV as X because…"? That would require yet another state, or a different type of comment. This one feels like a comment, the rest of the bug more like a discussion.

My suspicion is that most comments will be non-actionable. Even comments like "This is inconsistent, here's a fix" are not actionable per se - the possible suggestions are.
So we could add a "Report an issue" checkbox for actionable comments and only those would then be resolvable.

Right, I forgot that comments are not bound to a string, but to a specific item in history.
So, the way I see it:
* There are comments associated to a string, that could be added, edited or removed (e.g. "this is used in this context, be aware of X").
* There are discussions associated to a specific entry, and those can be actionable. The other interesting point is when to show these: should I get a notification for a comment in a string that was already rejected?

(In reply to Francesco Lodolo [:flod] from comment #23)
> * There are comments associated to a string, that could be added, edited or
> removed (e.g. "this is used in this context, be aware of X").
These belong to bug 1361318 (as a locale specific comment).
> * There are discussions associated to a specific entry, and those can be
> actionable. The other interesting point is when to show these: should I get
> a notification for a comment in a string that was already rejected?
I think you should. The comment might oppose your decision to reject the entry for example.
(In reply to jotes from comment #24)
> :flod, mathjazz
>
> What do you think about a button for translators/managers to mark a comment
> as an actionable?
> That could work as a "todo" list.
That's what I meant with the "Report an issue" checkbox.