Change Details

**Warning**: This task is preliminary, based on all the prototype feedback received until August 22nd 2016. However, the request for feedback is still ongoing, hence the task is subject to change. **Task**: The text field on the left hand side of the new edit merge screen (see T143823) should be changed as follows: - The textfield has the last common edit of the conflicting changes as the base. - It then shows the user’s changes in one color, the conflicting changes in another. - The way changes are shown is similar to how Word does it: - Additions are marked in the respective color - Substractions are crossed out - Sentences that have been changed/substracted by the other party are included in the change chunk, but without any highlighting - Both changes are introduced by a header „TODO HEADER“. These headers are not copyable, everything else is - All of this would ideally implemented without the use of javascript TODO WHICH COLORS DO WE PICK? See also the mock: TODO **Background**: This is part of fulfilling wish #1 of the German-speaking community wishlist 2015 (T139601). The solution is a result of on-wiki discussion and Wikimania 2016 sessions and testings, as well as feedback we received to the prototype.

**Warning**: This task is preliminary, based on all the prototype feedback received until August 31st 2016. However, the request for feedback is still ongoing, hence the task is subject to change. **Task**: The text field on the left hand side of the new edit merge screen (see T143823) should be changed as follows: `Show Diff View` - The textfield shows the diff of both versions - The diff algorithm is exactly the same as it is currently implemented. The only difference is that it is not displayed side-by-side but above each other - Both changes are introduced by a header: - Header texts: //Your change// and //Currently published// - These headers cannot be copied. Everything else can. `Include not changed text` - All text that has stayed the same in both versions is printed in the textfield as well. The diff parts always appear at their appropriate position in the text. `Coloring` - The changes introduced by the user, the headline for the user's changes and the "you" of the subtitle all have the same background color. The color should be the same that is used now in the diff view. - The changes of the published version, its headline and the "currently published version" of the subtitle all have the same background color, too. The color should also be the same that is used now in the diff view. - The "currently published version" of the subtitle of "Editor to be published" should also get the same color background All of this would ideally be implemented without the use of javascript. **Mock**: See also the [[ https://meta.wikimedia.org/wiki/File:Edit_Conflict_-_Mock_with_js_(as_of_August_2016).pdf | mock]] for a general idea. **Background**: This is part of fulfilling wish #1 of the German-speaking community wishlist 2015 (T139601). The solution is a result of on-wiki discussion and Wikimania 2016 sessions and testings, as well as feedback we received to the prototype.

**Warning**: This task is preliminary, based on all the prototype feedback received until August 22nd31st 2016. However, the request for feedback is still ongoing, hence the task is subject to change. **Task**: The text field on the left hand side of the new edit merge screen (see T143823) should be changed as follows: - The textfield has the last common edit of the conflicting changes as the base.`Show Diff View` - It then shows the user’s changes in one color, the conflicting changes in another. - The way changes are shown is similar to how Word does it:The textfield shows the diff of both versions - Additions are marked in the respective colo- The diff algorithm is exactly the same as it is currently implemented. The only difference is that it is not displayed side-by-side but above each other - Substraction- Both changes are crossed outintroduced by a header: - Sentences that have been changed/substracted by the other party are included in the change chunk, but without any highlighting- Header texts: //Your change// and //Currently published// - Both changes are introduced by a - These header „TODO HEADER“. These headers are nots cannot be copyable,ied. eEverything else is - All of this would ideally implemented without the use of javascriptcan. `Include not changed text` TODO WHICH COLORS DO WE PICK?- All text that has stayed the same in both versions is printed in the textfield as well. The diff parts always appear at their appropriate position in the text. `Coloring` - The changes introduced by the user, the headline for the user's changes and the "you" of the subtitle all have the same background color. The color should be the same that is used now in the diff view. - The changes of the published version, its headline and the "currently published version" of the subtitle all have the same background color, too. The color should also be the same that is used now in the diff view. - The "currently published version" of the subtitle of "Editor to be published" should also get the same color background All of this would ideally be implemented without the use of javascript. **Mock**: See also the [[ https://meta.wikimedia.org/wiki/File:Edit_Conflict_-_Mock_with_js_(as_of_August_2016).pdf | mock: TODO]] for a general idea. **Background**: This is part of fulfilling wish #1 of the German-speaking community wishlist 2015 (T139601). The solution is a result of on-wiki discussion and Wikimania 2016 sessions and testings, as well as feedback we received to the prototype.