What's all the fuss about "edit source"?

Update: 15 January 2015
This is now possible for all file formats except for ITD, updated in Studio 2014.
SDL Trados Studio 2011 SP2 has introduced “edit source”… but only for Microsoft Word and Microsoft PowerPoint file formats at the moment.  For Freelance Translators this is a welcome addition because it has been one of the most heavily voted for ideas on the SDL Ideas site.  However, is this enough and why haven’t SDL introduced this before?  This is fast becoming a topic for much debate on the public forums and Facebook pages so I thought it warranted a little insight into the problems of introducing “edit source”.
First of all… here’s how you do it in Studio SP2.  In your active segment the default shortcut is Alt+F2 or use the right click menu:

The source segment, if it’s allowed will then add an orange square around it:

If you can’t activate this and you have SDL Trados Studio 2011 SP2 then this will be because the project has locked it down, or the filetype is not supported yet (only Word and Powerpoint at the moment).  If it’s locked down then you can make it available here:

But this option may also be grayed out if your Client has sent you a Project Package and locked this down.  Now, why would this be locked down and why have SDL always been so cautious about this feature?  If you read these sort of comments you do wonder why, although it’s not all one way traffic?

• “SDLs assumption that projects shouldn’t be modified is based on the utopic idea projects material comes clean and ready but reality is translating companies often allocate projects in a very messed up way that require lots of changes and modifications for the translation to be workable.”
• “In fact, it’s technically possible to open the SDLXLIFF in a decent text editor (let’s say, Notepad++), then make the desired changes and reopen the modded file in Studio”
• “Very important feature to prevent garbage from getting stored to the TM.”
• “If this gets introduced, any changes to the source text should be marked up.”
• “Good idea. Would allow the proofreading of the source text at the same time. But this would have to be also linked to a user-rights setting. If you translate in-house you may correct the source text. If you give the text to an external translation company you may prefer them not to be able to modify the source text.”
• “I agree. In particular it should be possible to delete extraneous formatting tags in the source.”
• “and add the possibility to export the changed original file hopefully with an added notice in a separate file for information about the change.”

The comments above are all representative of the things we often see mentioned when this subject gets discussed.  They are mostly valid in their own right and when not part of a larger localization project.  We had an interesting discussion on this in the Studio Beta Forum when this was first introduced, so I’ve taken some of this material to provide a little insight into why we need some controls irrespective of the technical difficulties that need to be overcome so that editing the source will not adversely affect the ability to save the target file when the translation is complete.
Whether or not source editing can be supported in the first place to some degree depends on how such changes flow through the translation supply chain, and particularly back to the content owner. If you change source segments (which includes merges, corrections, etc.) the question is how such changes are then processed further, and flow back into the original source.  In addition, how such changes can impact the current localization project.
For example, if you correct a typo in a source segment, what effect does this have on all the other translations (into other target languages) which may be under way and which are branched off the same source file? Are other translations invalidated because of the source change? Who decides?
What if two translators apply conflicting changes to the same source?
How is the original source content being updated? How are authoring workflows affected?
If the source is living in some CMS (Content Management System), does the “localization owner” have permissions at all to update the source? Or does this need to be communicated to the authoring team separately, triggering reviews and some completely different workflow, and potentially re-translation? What are the involved costs? Are such changes better “shelved” for the future than applied right away?
The impact of source changes on the overall authoring and localization supply chain and associated workflows may be considerable.  Many content owners may rather accept “locked source” (and spelling errors in the TM), than have to address the issues which may arise from changes to the source as part of the localization workflow.  It’s hard to quantify the problem (how often it occurs and what the costs are), but if it’s a “one in a hundred” kind of situation, the added value of downstream source changes may not justify the required upstream workflow changes and cost impact.
We did introduce comments (full segment and sub-segment) in Studio to implement a formal, effective way to communicate required changes upwards in the supply chain so they can be addressed in a way that minimises the overall impact in a Project where these changes would be undesirable.
Notwithstanding this I often wonder where the value in correcting a typo really is.  Does having a “clean” TM outweigh the benefit of not getting a 100% match the next time you receive an updated document to translate and the author didn’t correct the source?  You now have to handle the same segment again instead of getting the target translated automatically.
Perhaps a better way to handle the typos is to correct the Translation Unit using the edit capability in the Translation memory window and then save the original again so you have them both?  Perhaps this is too lengthy a workaround?  This way you would at least get the best of both worlds.
Perhaps the real value with “edit source” is in being able to “redo” the source segments that have been split as a result of a misplaced “hard break” so that they appear as a single segment.  This still won’t give you the leverage on an updated document but it will allow you to translate this correctly where elements of the sentence are the other way around in the target language.
What is clear is that without proper communication of the change the translator could be creating considerable additional work for their customer.  So if you know you might be working as part of a larger localization project then changes made with notepad++ directly to the sdlxliff or through using a different tool that allows changes to the source should be undertaken very carefully and preferably only after discussion with the end client.