This was scrumdo story 152
Users want to be able to leave more complex comments than the simple single comment approach we use in Pootle now. However, they specifically don't want a discussion board.
The users should be able to add comments with not much limitation. Thus we might want to distinguish between comments and discussion. This could be a panel implementation like you see in Wikipedia i.e you change to the Talk page. Some way to post comments to a cross-lingual discussion would be useful. The format then is simply one of convention, the user choose how to use Markdown syntax to flesh out their comments.
Further feedback from the bug reporter:
The simplest implementation would be when every user can make a single comment in its own comment field with a time stamp to see the chronological order of the (last change of) comments.
(Friedel suggested): If we just support a list of comments with the name of the user who made each comment, would that support what you have in mind?
Yeah, that would be fine.
Doing something simple is justified so that we keep the focus on translation. We never got the impression that many strings receive comments, so that would support the case for something simple (at least visually).
Maybe the only improvement needed is support to have more than one comment in order to keep what different people say separately identifiable. It is possible that even among strings that will get the comments, there isn't likely to be a lot of discussion, so threaded discussion isn't really needed, although a case can probably be made for it. Maybe it is enough to just support a list of comments with the name of the user who made each comment. This could maybe be very free form (similar to how a signature is used on MediaWiki).
Currently we export the translator comment in files for offline translation. If the comments become structured, we need to think what the offline export should look like.
On file upload, we need to think what we'll do with comments in the uploaded file. Any difference we want to make between overwriting uploads, merge uploads, suggestion only uploads. Would the comment field trigger a conflict, etc.
A few different models of thinking about this. We ended up going with Igor's model.
In this model, the comments are associated with a specific string, but are completely unrelated to the content of the blog post / target. Mostly they are only ever added. The blog post / target can be edited at will, and comments might not make sense when that happens.
Comments are probably stored completely separately, and probably only ever added to.
Igor suggested that the current model be maintained:
Since some work done on terminology projects a while ago, we are able to store comments for suggestions. This way a suggestion can contain either a target, a comment, or both.
The UI will likely be combined somehow with the interaction design coming out of the design for history of changes. Two of the sketches/mockups:
Here are some first implementations:
We are interleaving the change history of two fields (target and comment). This is attractive in that it shows a timeline of contributions, whether they are translations or discussion. Because of uploads or VCS actions, the change history might not be a true reflection of each step in a unit's history. We keep the ordering in the database, so submissions should be in chronological order. If the current contribution's old value doesn't correspond with the previous contribution's new value, we know that the current contribution represents the first contribution after such a gap in the history. In such a case, we show the old value to help fill in the gap. Since we don't know in this case when the change was made (say an upload) that introduced the unrecorded submission, we can't add a date. If we only show target history, this is fine, since it is in chronological order anyway -- we just don't show a date. However, since we interleave the changes of two fields, this dateless submission could now be placed out of historical order, since we simply show it right before the change for which we have the date available.
Hypothetical, chronological, timeline (date, submitter, old_value, new_value, field)
|Date||old value||new value||field|
|2012-01-05||””||“I like it”||comment|
|2012-01-07||“What do we do?”||“translate it!”||comment|
We might show this as this (reverse chronological):
|?||“What do we do?”||comment|
|2012-01-05||“I like it”||comment|
In this case, we wouldn't know if the change of target (“cow” → “cow2”) happened before or after the comment change on 2012-01-07. Even if we consider the dates of all the surrounding elements, we can only say that it happened somewhere between 2012-01-05 and 2012-01-09. The two entries with unknown dates might have happened as part of the same upload on 2012-01-06, for example.
Simply state that we don't know when it happened. e.g. this is then visually displayed as something like:
|Between 2012-01-05 and 2012-01-09||“cow2”||target|
If we use other cues like:
then this becomes less of an issue. Some examples with these ideas:
|6 months ago||“cow2”||target|
I'm not sure what the cost would be of determining those dates. Might raise the issue that we want to store a real date or date range in the table to help performance.