Differences

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

--- developers:spec:history_of_changes [2012/06/08 16:00]
friedelwolff model spec
+++ developers:spec:history_of_changes [2012/06/29 10:39] (current)
dwaynebailey
@@ Line 39: / Line 39: @@
 ==== Translator ====
- - Why is this string the way it is now?  Why is this string fuzzy?
+  - Why is this string the way it is now?  Why is this string fuzzy?
- - I translated this but the translation hasn't been kept. Who made that change?
+  - I translated this but the translation hasn't been kept. Who made that change?
- - Show all changes to my translations in some project since I made them
+  - Show all changes to my translations in some project since I made them
- - See if something was reverted to learn from it.
+  - See if something was reverted to learn from it.
@@ Line 88: / Line 88: @@
   - knowing which unit is affected
   - seeing which fields changed or their values
-  - (maybe) multiple related changes, if the creation_time of them is not the same (test?)
+  - multiple related changes, if the creation_time of them is not the same https://code.djangoproject.com/ticket/16745
 Comments:
@@ Line 94: / Line 94: @@
 New model:
-    creation_time       = DateTimeField(auto_now_add=True
+    creation_time         = DateTimeField(auto_now_add=True
-    translation_project = ForeignKey('pootle_translationproject.TranslationProject'
+    translation_project   = ForeignKey('pootle_translationproject.TranslationProject'
-    submitter           = ForeignKey('pootle_profile.PootleProfile'
+    submitter             = ForeignKey('pootle_profile.PootleProfile'
- remove?    from_suggestion     = OneToOneField('pootle_app.Suggestion'
+  remove? from_suggestion = OneToOneField('pootle_app.Suggestion'
-    unit   = OnetoOneField('pootle_store.Unit'
+    unit                  = ForeignField('pootle_store.Unit', null=True, on_delete=models.SET_NULL)
-    field  = # see below
+    field              = # see below
-    old_value = TextField( which can be empty
+    type               = # see below
-    new_value = TextField( which can be empty
+    old_value             = TextField( which can be empty
+    new_value             = TextField( which can be empty
+**.field** will be one of a list of enumerated integers corresponding to source, target, comment, state to know what changed, or a string with some kind of pseudo Django field specifier, like pootle_store.Unit.target or pootle_store.Unit.state.
-.field will be one of a list of enumerated integers corresponding to source, target, comment, state to know what changed, or a string with some kind of pseudo Django field specifier, like pootle_store.Unit.target or pootle_store.Unit.state.
+**.type** will be one of a list of enumerated integers corresponding to the type of submission that this was. Possible values include
+  * None (normal interactive submission or no information available)
+  * Revert (someone used the revert functionality in the UI)
+  * Upload
+  * Merge
+  * Update from templates
+  * VCS update
+  * Batch manipulation
+  * Automatic manipulation (bots, autocorrect, etc.)
+Some of these are not possible with the current GUI yet, and for some the proper type might not be set correctly. For example, we don't currently create submission objects for each unit changed in an upload, for example.
 This model will allow for:
@@ Line 115: / Line 127: @@
   - Better stats on what exactly a user contributed (?) - the diff can say what was added, but this is probably not useful.
   - Should allow tracking changes to translation_projects (description, files, etc.) but I'm not sure we should go this route.
+  - distinguishing between reverts and other types of changes
 This model will not allow for:
   - tracking changes to suggestions
   - tracking changes to projects or languages
-  - distinguishing between reverts and other types of changes
+  - multiple related changes, if the creation_time of them is not the same (see above)
+==== UI ====
+As a start, probably only the history of target text of a single unit will be implemented.
+=== Single unit history ===
+This should be accessible from the translate page. The link should be somewhere out of the way, since this is unlikely to be used frequently. An alternative is to be grouped with the "report bugs" link, but this clutters to the toolbar of the source text.
+A simple view will open in a fancybox containing a single column table. Each row contains the next/previous value for the target. We do diff highlighting from the previous version. In future, we should support revert/restore actions from here.
+For interactive editing, the old_value of a target should always correspond with the new_value of a previous submission, therefore showing it in two columns is unnecessary. In case of an upload, VCS operation or similar, the change won't be tracked per unit, and we won't have the information anyway. The old_value from a Submission might be useful, and we know where it fits in (right before the editing time) so we can simply give it an extra row in that case (if it isn't equal to the new_value of the previous entry). However it won't be easy to indicate the effect of uploads/VCS operations. We know when uploads happen, but we don't know what changes they introduce, or even which units were affected at the time.
+{{:developers:spec:pootle-history-1.png|}}
+Dwayne suggested the following, which combines several elements associated with the unit, and provides the user with a way of choosing what to see.
+{{:developers:spec:history-simple-db_mockup.jpg?600|}}
+Some ideas on IRC from Igor (edited for flow):
+I'm not very keen on hiding human suggestions/amagama suggestions and history behind tabs, because the first two should be visible as these are one of the main tools for translators. History is something that I'd like to see on demand. If we have tabs, this will mean that people will have to constantly switch between two.  I would like to see TM and suggestions always, too, and the best thing to see them together to be able to find the perfect source to work with.
+He also added: If there is "history mode" which might be useful as a default view on queries like "what changes happened to my strings since last week?", then we can maybe activate that mode by default when we enter the translate page from such a link/entry point (with a parameter).
+History would be available with a single click on a link somewhere near 'Add comment', or, if the comment already exists, below the comment box area. If we sort history by having most recent edits at the top, it will be logical to have the comment area above the history, so that when you add a comment, it will appear at the top of the history (and same applies to translations).
+julen: Take into account that with the work in bug 2180 there might be more than a single comment per unit.
+iafan: yeah, we will keep an interleaved history of comments and translations. Probably this means that the current comment box might need to go away (i.e. there's no reason to "edit" a comment). You will just add a new one and the last one is which will be displayed by default
+Igor's proposed layout is: history (on-demand by default), then suggestions, then TM results. history = translations + comments. I'd display the last comment (if any), the way we do now, but not allow to edit the last comment, just add a new one. So translation unit always shows current (latest) translation the way it is now, and one (latest) comment. All other is 'history' and can be expanded on demand. I'd also display e.g. last five history entries, with the option to 'show more',  like we do for context rows.
+Based on these ideas, and a further discussion in IRC, the idea was raised to combine more of the elements, with maybe only the history being shown on demand, or when in a certain review mode (which is maybe activated by clicking on a link that tries to answer some of the questions above relating to change history). Depending on implementation issues, some of the suggested changes might not be easy/possible, but let's ignore that for now.
+So here is a rough mockup of what things could look like if combined (not quite what Igor proposed):
+{{:developers:spec:combined_history.png|}}
+=== First implementation ===
+{{:developers:spec:history_hidden.png|The default view}}
+{{:developers:spec:history_shown.png|With history expanded}}
+== Feedback (Dwayne) ==
+  * Use [[http://twitter.github.com/bootstrap/javascript.html#buttons|Checkbox buttons]] or maybe [[http://twitter.github.com/bootstrap/components.html#navs|Pills]] instead of the link with Hide and Show logic.  Make it easy to group things that are on or off.
+  * We seem to waste a lot of vertical space.  We could regain some if we:
+    * Drop the title e.g. "History" and "amaGama server".  These could be distinguished using row colour or info to the right of the line. If row colour matched the button colour that would also work, might look garish though.
+    * Lose the gap between rows. This wastes quite a bit of space. Would mean doing somthing with alternate row colouring though.
+    * Moving the history (and future discussion) on/off toggles into the same row as "Add comment" and special chars.
+  * Lose the tooltip for the person who made the change.  It means mouse navigation, I'd prefer it to be visible all the time. Bottom right makes sense or to the right on the row with the gravatar.
+  * Missing date/time info in the history
 ===== Links =====

User Tools

Differences

Page Tools

Navigation