Differences

This shows you the differences between two versions of the page.

--- developers:spec:discuss_a_translation [2012/06/22 16:04]
friedelwolff
+++ developers:spec:discuss_a_translation [2012/07/03 08:29] (current)
dwaynebailey A possible solution to the missing data scenario.
@@ Line 10: / Line 10: @@
 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).
@@ Line 21: / Line 34: @@
 ===== Angle of attack =====
-A few different models of thinking about this:
+A few different models of thinking about this. We ended up going with Igor's model.
 ==== Blog model ====
@@ Line 34: / Line 47: @@
   * The target can change and the comments won't make sense any more. If our view interleaves target change [[history of changes|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.
@@ Line 51: / Line 65: @@
 **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
@@ Line 62: / Line 92: @@
 {{:developers:spec:combined_history.png|}}
+Here are some first implementations:
+{{:developers:spec:history_hidden.png|The default view}}
+{{:developers:spec:history_shown.png|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.

User Tools

Differences

Page Tools

Navigation