What if you could directly edit the copy on the staging server of a website and have it transparently save your changes in the background without messing with PO files, SVN access, etc
You’d eliminate lots of problems that localizers have… and provide a richer, fun editing environment.
Like any idea worth building… I found out it’s already been invented A few months back when I pitched this idea to Stas Malolepszy, he mentioned that Gandalf already thought of the idea and built a prototype.
I’m realizing that this has been sitting in my TODO list for too long and I’m better off doing a brain dump in this blog post. Here’s my take on the idea:
Keep po files as the backing store
Work as much as possible with existing gettext tools
Use direct object manipulation for the UI – pick strings directly from page, see live updates
Let localizer view a web page and pick a string to translate
Display an editor widget that sit on top of or beside the page
Display the msgid and msgstr. In practice this is the English String and the Localized version.
As they type, redisplay the page with their updated translation
Provide a revert button
Provide a save button. Save persists this string back to the po file server which commits the change to SVN.
PO LiveEdit at 10,000 feet
PO Enhanced HTML – In PHP or other web code, instead of making calls to gettext methods, a set of wrapper methods would be used which add metadata to the HTML output. This would basically add the msgid to a span tag that surrounds the output of the msgstr. This would extra metadata wouldn’t affect the display, but would capture the semantics of a localized string.
Old PHP code
<p><?= _(‘Be the Difference’); ?></p>
<p>Fai la differenza</p>
New PHP cde:
<p><?= _w(‘Be the Difference’) ?></p>
<p><span id=‘md5_58cbc46092296cbe517d748685f52838’>Fai la differenza</span></p>
PO Edit Client - This editor would use the msgid or some other token (such as the md5 hash of the msgid) from the enhanced html, to retrieve the information for an individual string and display it for editing. The comments, English translation, and Current localization string would be displayed. The editor would be aware of the current locale which is a page. It would be a live editor where changes would be reflected in the web page as you type.
PO Edit Web Service – The server manages the collection of messages.po files for a web application. It’s provides read and write access to the PO Edit Client, one string at a time. It manages commits to SVN and conflict management.
So three are three components to build… PHP gettext wrapper libraries, which are pretty trivial and produce the enhanced metadata in the HTML, a Server and a Client which lives within the browser.
Either a stand-alone python server using Stas and Zbigniew’s [https://wiki.mozilla.org/Silme Silme library], or integrated into an existing web based L10n tool like [http://en.wikipedia.org/wiki/Pootle Pootle], it would provide a REST web service for editing po files by locale and msgid.
The client can be built as either:
Addon – Firefox/Fennec Extension
Pure JS has the benefit of working with any browser (Safari on iPhone, IE 6 in corporate dungeon, etc). It has the negative affect of introducing L10n only code that you wouldn’t want to push to production. It adds another integration point to every app.
The Addon has the benefit of being totally isolated from the specific web application’s codebase, which makes for easier adoption. The client would have the ability to use the PO Edit WS without any same-origin policy limitations. Downsides are that it’s requires Firefox or Fennec and it is an extra step for localizers.
Either way, a simple textarea will be a good start for a prototype. Localizers will be loosing any features of their current text editor (say POEdit), but they will gain rich “preview”. For a prototype, the addon route could be built out of an existing extension, such as Jetpack Slidebar or Ubiquity pageLoad command, since it’s a more rapid development env.
The devil is in the details, here are some design decisions.
By default, does this introduce a new requirement for a L10n preview environment? Or is the web application in a testable state? Adding String metadata changes the web application and invalidates it for QA, unless you ship this metadata in the production version also. The ‘right’ thing to do would be to introduce a localization step into the SDLC, but this might lower adoption. Or you could focus on making the implementation of the String metadata really light weight, so it would have minimal overhead and not need an additional phase, since it could ship to production and other applications can invent new uses for this metadata.
Exposing hard to reach state: Many strings are hidden behind a hard to reach sequence… such as error messages. A common practice in web app development is to expose every part of the app through testing hooks. Many large applications grow these features through time, such as allowing testers special query string parameters for each error condition to simulate the error. Another example is web apps with emails; provide urls so that each email is a click away w/o actually running through the registration process. These kinds of hooks would make translation easier and you’d have to list them somewhere so it’s easy to find them all. These become a requirement for a live web editor, unless you make the user jump through steps to reach all the states of the UI.
Out of Scope(?) but on the Radar
A real-time synchronization between the client and server would be ideal, so that multiple localizers could see who was editing a string and to reduce conflicts. Mike Morgan and Fred have suggested Bespin which is a freaking awesome idea.
If we had a web based live editor for translating sites, this could be a huge win for localizers and the people of earth. Translating a website is one of the most painful and dangerous workflows I’ve seen. You know we have an amazing community, if they are willing to put up with the draconian toolchain we have today. Throwing everything out, is simply not an option, but if we can make a small evolutionary improvement towards a live preview edit workflow which hides revision control systems and text files…
There are plenty of sticky corner cases and whiz bang features one can dream up, but I think building a prototype for this is a tractable problem. I did some brainstorming with Fred this morning and he had lots of other cool ideas and good observations on how this would work in practice.