If you’ve read part one of this topic, you’re ready to look at the two main types of presentation-level adaption : re-skinning and localisation. The end-result for this phase of activity is fairly simple:
1) To arrive at a new version of the application that looks like, and behaves like the old one, but with all presentation-level assets externalised, and…
2) The application accomodates a new set of external assets flawlessly, when those external assets are changed.
Once this is achieved, the possibility of localisation now exists.
Skinning an app
Re-skinning an app consists of:
– changing fonts
– changing the design of ui elements, which include:
– changes in shape
– changes in colour
– changes in layout
– typographical changes (font changes, changes in spacing, leading etc)
– content changes
– replacing images and other embedded elements
– changing copy (text)
A little armchair thinking will reveal that localisation is a superset of reskinning. That is to say all localisation jobs will require reskinning of some sort.
It follows then that any localisation effort cannot commence without first making an application re-skinnable. As per conventional wisdom in the industry, presentation layer assets should generally be separated from any data or flow of control. An application that is not in this state, before it can be localised, needs some development (and probably design) time set aside in order to:
– trawl through the code, identifying presentation level assets
– stripping said assets out of the codebase
– refactoring the code to request those assets as needed.
– last but not least, refactor the code so that a different set of external assets can be incorporated with ease.
I would call this process ‘skinning’ — kind of like peeling an orange with a knife… you don’t want to take any of the flesh off, just the skin. I like to think of re-skinning as the application of a different / new skin (imagine if you could take the skin of a perfectly peeled grapefruit and stick it on your peeled orange… it would then look like a grapefruit. Okay so the analogy is thin…)
Localisation of a software application means supporting different locales. A locale consists of such elements as:
– a specific time-zone
– specific country or region
– a specific language (and perhaps variants thereof)
– a set of conventions about formatting, syntax and grammar (examples would be currency symbols, or the fact of writing right-to-left instead of left-to-write in some locales).
– input settings (notably keboard layout)
Conventional approaches to localisation
The first and most obvious task to tackle is the issue of displaying the correct language. Having prepared the application for reskinning (above), there should now exist somewhere:
– a complete text dump of all the copy in the application (“the copy deck”).
– a complete dump of all graphic assets in the application. These shouldn’t really have any text, except in extreme cases. All text should be in the copy deck.
Together, these 2 sets of assets are the ‘skin’ of the app, and you would do well to have a single, simple, friendly, human-readable ‘locale file‘ that defines all these assets. If you’re *really* cookin’, your app will read that same file in when it’s looking for assets.
It is a simple matter to hand over the copy deck to a translator; for open source or community projects usually that translator is you and me. But in most real life software projects, a professional translator will need to be contracted (or failing that, the client may also be able to provide translations).
At this point everything seems hunky-dory, doesn’t it? Not so fast…
Managing the locale assets and metadata
Managing and synchronising all variants of the copy decks, images and other presentation-level assets, in all relevant locales, for the lifetime of the application in question (especially if that application is still evolving) takes quite a bit of doing. Revision control (i.e. checking into cvs or svn the same way you would with application source files) is a possibility. However it is done, these assets need to be versioned; suffice it to say that these will be the most shape-shifting entities you will ever meet. (There’s a strange co-evolution between the sales teams’ sales pitch and the clients desires once the adaptation games begin). You will also find that the number of configuration items in your application increases considerably.
To help maintain control over the zoo of localised wildlife you will need not just revision control but intelligent naming conventions and directory structures. Ideally, a full SCM (software configuration management) process should be established if one does not already exist.
The last and final piece of the management jigsaw lies with the client. The client has to be gently introduced to your shiny new (hopefully friendly and usable) locale files. In a process akin to getting a fearful child to come up and pet a snarling rottweiler, you are responsible for making the client understand that the locale file is their friend, and that all edits and changes should be made there, and that it’s Godly formatting rules should be obeyed unquestioningly. Good luck (you’ll need it).
Why the client and the locale file(s) should be encouraged to become fast friends
If you play your cards right, the client will do most of the gruntwork for you during a round of adaptation. And so they should – it’s their content that’s being swapped in for the old, after all, and it helps give them a sense of ownership. You shouldn’t abuse this privilege though… they’re not paying you so that *they* can reskin their own app. But you get the idea.
Secondly, this approach gives the client a lot of control of the content in their own variant of the app. This is incredibly useful if an at-startup / realtime mode of adaptation is used (often the case with web applications). This means if something needs to change at the presentation layer, the client can handle it themselves, reducing your organisation’s role to one of a helpful guide. It’s better than getting your developers to use precious development time sodding about with content. It is also the rationale behind every CMS that exists out there.
Next, in this short series, I hope to the types of customisation and structural adaptations that tend to ‘plague’ localisation projects.