Pau Giner has made designs for this. Can you link them here?

Yes, i know. This notice for the future, and for the another users, who want to report the same problem.

This isn't an enhancement, its a regression since this feature used to be available. A user sent me translations and I was unable to attribute them properly because there was no edit summary field.

I too have already found myself several times in a position where I would earlier have explained a modification to a translation by means of an edit summary, but was prevented from doing so by the new interface.

Edit summaries are an essential element of collaboration on MediaWiki wikis (not just because of the legal issue pointed out by Legoktm; see e.g. https://meta.wikimedia.org/wiki/Help:Edit_summary#Recommendations ), so I am curious about the rationale for removing them in this case - any pointers to the previous discussions that lead to this decision?

It has not been removed, rather it has not yet been implemented.

In order to make out UI fluent, we wanted to make it to focus in the main task (translation). Providing the summary field in a way that is too prominent has a cost for the process. In addition, most of the time the rationale for edits in the translation context is clear. So we need to make sure that we are providing the option for an edit summary only when it makes sense, and in a way that does not compete in attention with the main translation field.

In order to fulfil the above goals, the design for the summary field were made: http://upload.wikimedia.org/wikipedia/commons/d/d5/Translate_Extension_translation_summary_design.pdf

The above document shows an existing translation that the user is modifying. When the user modifies the text of an existing translation, the option to provide a change summary appears.

(In reply to comment #6)

The above document shows an existing translation that the user is modifying.
When the user modifies the text of an existing translation, the option to
provide a change summary appears.

This is not acceptable. Users want to comment also new translations, this would require a dummy edit to do so. In the meanwhile, translators are adding edit summaries to qqq.

(In reply to comment #7)

(In reply to comment #6)
This is not acceptable.

I totally agree. Sometimes a first translation is so "heretic" in the first place that you want to prevent others from changing it by providing explanation.

In Greek portal we have a glossary with talk pages for every word and we strongly insist in adding edit summaries with links to talk pages where a good explanation should be, whenever needed. Keep in mind that in Greece we constantly fight over language matters for centuries! http://en.wikipedia.org/wiki/Greek_language_question

Despite that, edit summary is in the core philosophy of every wiki and it should available everywhere, even in the smallest, tiniest, silliest editable thing.

mr.heat wrote:

(In reply to comment #7)

This is not acceptable.

I agree. Being able to providing a reason for an edit is a major feature of a wiki. See my longer comment in the forum:

http://translatewiki.net/w/i.php?title=Thread:Translation_UX_feedback/Where_is_the_summary_line_in_the_new_interface%3F

Other users agree:

http://translatewiki.net/w/i.php?title=Thread:Support/Where_is_edit_summary%3F

(In reply to comment #9)

(In reply to comment #7)

This is not acceptable.

I agree. Being able to providing a reason for an edit is a major feature of a
wiki. See my longer comment in the forum:

http://translatewiki.net/w/i.php?title=Thread:Translation_UX_feedback/
Where_is_the_summary_line_in_the_new_interface%3F

Other users agree:

http://translatewiki.net/w/i.php?title=Thread:Support/
Where_is_edit_summary%3F

Omg, this bug is still not fixed :O :( FYI You can enjoy the old interface by adding &tux=0 to the end of a translation url.

Could this be considered for an increased priority? I think tis would substantially increase the interaction possibilities between translators and therefore increase overall translation quality.

I just experienced an exemplary case:

• I made a new translation with a small change compared to source language (since this would have been uncommon in the target language).
• Another user changed it to fit source language again not knowing my intention (due to the lack of an edit summary)
• I didn't like the changed version and translated again in a different way (at this point not realizing the valid intention of the other user)
• In the end the other user contacted me on my talk page and told me why the translation was changed the way it was changed.
• I then saw the issue with my initial translation and was able to finally fix it in a satisfactory way

If there would have been edit summaries probably after the second edit the translation would have been finished without ever having to discuss it on my talk page.

chrisipk wrote:

(In reply to Pau Giner from comment #6)

In order to fulfil the above goals, the design for the summary field were
made:
http://upload.wikimedia.org/wikipedia/commons/d/d5/
Translate_Extension_translation_summary_design.pdf

The above document shows an existing translation that the user is modifying.
When the user modifies the text of an existing translation, the option to
provide a change summary appears.

From looking at that design it seems to me that the user is required to click the "Provide change summary" link (button?) to actually get the text input box. Is there any real reason why this additional click should be required? IMHO the box should simply be there so it can be accessed by tabbing. Why make the user change the translation via keyboard, then switch to the mouse, click, and then switch back to the keyboard to enter the summary?

Sorry if this is not the right place for this comment. I could not find any other page that discusses this design.

I wonder why this was not implemented in the first place. However, having this will be a huge improvement!

Change 288907 had a related patch set uploaded (by Glaisher):
Allow providing edit summary for translations through tux

https://gerrit.wikimedia.org/r/288907

Should the edit summary input be in the language of the target language or should it be in the regular default of Special:Translate (the "dir" and "lang" attribute, to be specfic)? I'm not sure what would be appropriate here and what is more useful for translators so would appreciate some feedback from real translators.

I'd say that in most cases the edit summary (comment) will be in the target language. According to my experience from translating to German that this is how it is done there, i.e. German language comments.

At least for me this feature should make it possible to tell why a specific translation was revised. Currently I go to the version history of the respective system message to get to its wiki page and do a classic page edit including my edit summery. This is a bit tedious.

In T48924#2309427, @Glaisher wrote:

Should the edit summary input be in the language of the target language ...

Experience tells: I varies. It may be the main wiki language (English) for some multilingual wikis. Often, it is the target language of the translation, rarely th source language.

To be honest, I tend to the complicated solution to let authors specify the language, with sensible defaults, as above.

In T48924#2309508, @Purodha wrote:

Experience tells: It varies.
Often, it is the target language of the translation, rarely the source language.

Indeed! On translatewiki.net for example, all Greek translators summarize in Greek. But sometimes there would be edit summaries by bots or devs in English.

So, the best is target language as default edit summary language plus the ability to change it if needed.

In tux=0 I summarize translations in target language usually, but sometimes in English (e.g. if I need to complain about something bad in the source or its tagging, or if I am providing attribution for something copypasted).

Well, that's when I am actually translating. If as a TA I go through translations fixing them after retagging, I primary use English.

Perhaps it's okay to leave lang and dir unspecified then. I think browsers are able to guess ltr/rtl and maybe also spell checking based on the text written in the field.

I'm not sure how a UI would look like for how to change the language for summary without adding too much complexity and clutter to the interface so I removed the lang and dir attribute from the input for now. Unless others feel that it is a blocker for the initial implementation, I think this is okay; we can file a new enhancement task to discuss that and get it done in a separate patch.

Change 288907 merged by jenkins-bot:
Allow providing edit summary for translations through tux

https://gerrit.wikimedia.org/r/288907

Great, already used this. Thank you so much!