As discussed earlier, localisation generally depends on skinability. Often too, localisation will require a deeper level of adaptive behaviour: This is the role of customisation. In fact, localistion projects are often hybrids (blended localisation *and* customisation projects).

In what follows, remember that the topic is about retroffitting the adaptations needed to support localisation. In brand new projects, a lot of these issues can be planned for and dealt with differently. In a retroactive scenario however, these are some of the issues that come up during customisation: Continue reading →

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.
Continue reading →

Sooner or later, a modern software app will need to spread its wings and go global, making itself available everywhere – or failing that, at least available in lots of different countries. Or failing that, available to lots of different regions. Or clients. No matter what the type of spread is, the inevitability of catering to different sets of end-users means that software needs to be built with some kind of customisation in mind right from the start.

But what if you you’re retrofitting such adaptive behaviour to an existing application? Before you get bogged down in the quagmire of international language codes and glyphs from utterly alien fonts, understand the larger picture (adaptation) that your efforts need to be a part of… Continue reading →