Translate Toolkit & Pootle

Tools to help you make your software local

User Tools


Discuss a translation

From 2180:

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.

https://bugzilla.mozilla.org/show_bug.cgi?id=627913

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.

Orientation

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.

Angle of attack

A few different models of thinking about this. We ended up going with Igor's model.

Blog 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.

Advantages:

  • Complete separation (no idea why that is an advantage, but I don't know what else to write here)

Disadvantages:

  • The target can change and the comments won't make sense any more. If our view interleaves target change history it might help.
  • Not sure what to export. The last one? It might be an answer to a previous comment like “I agree”, which wouldn't make sense in the exported file
  • We have comments and discussion and (depending on permissions) also suggestion. These are a lot of “auxiliary actions” not relating to translation.

Igor's history model

Igor suggested that the current model be maintained:

  • A unit has a simple, single text comment field.
  • A translator can add a new comment.
  • The previous one is kept in the history.
  • We show the comment history on demand, just like we do for targets

Advantages:

  • Parts of this is already implemented
  • Changes and comments about them can be presented chronologically, which would help in understanding what the comment related to at the time.
  • It is obvious what to export for offline use

Disadvantages:

  • Not obvious how to remove a comment. Providing different interactions for adding a comment and clearing the current comment might be confusing.
  • It seems to be two very different things: discussing and suggesting
  • Some comments make most sense in a situation of “Keeping state”. A comment that says “This accelerator clashes with foo”, needs to be removed when the issue is fixed, and might be confusing if it is not.
  • To show the complete discussion, we have to query a very big table.

Suggestion model

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.

Advantages

  • This allows more easily for work towards the final goal (with the goal being a target and associated comment.
  • It is obvious what to export
  • It is obvious what to do in upload/import (comment changes can just go into suggestions in case of conflict).
  • It contains proper attribution (who did it).
  • Users don't need translation rights to contribute.

Disadvantages:

  • This doesn't not allow for real discussion, and “accepting” a comment removes it from the list of comments (and replaces the current one).
  • We don't currently store a time stamp.
  • It seems to be two very different things: discussing and suggesting

UI

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:

The default view

With history expanded

Questions/Issues

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-01 ”” “cow” target
2012-01-05 ”” “I like it” comment
2012-01-07 “What do we do?” “translate it!” comment
2012-01-09 “cow2” “cow3” target

We might show this as this (reverse chronological):

Date value field
2012-01-09 “cow3” target
? “cow2” target
2012-01-07 “translate it!” comment
? “What do we do?” comment
2012-01-05 “I like it” comment
2012-01-01 “cow” target

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.

Possible solution

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:

  • Italic text
  • Greyed our text
  • Human readable ranges: Between 5-10 days ago, About 5 days ago, Last month,

then this becomes less of an issue. Some examples with these ideas:

January 2012 “cow2” target
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.