Write every application as if localization is project requirement

Posted: January 17, 2017 in Programming
Tags: , ,

Vast majority (if not every) good development practice is established based on empirical studies and personal experience. One of those is “YAGNI“, as we do tend to develop more functionality and over-engineer a solution for a problem that does not exist. However, it seams that “You aren’t gonna need it” does not apply to localization.

Localization is well known problem of adjusting user interface and interaction with system based on its current geographical preferences which includes, but not limits to, current timezone, formats of date/time/currency as well as language (not programming language – a human language) in which interface communicates with a user.

If application is intended to be used only in one geographical area within one country, localization problem does not exist, and according to “YAGNI” principle, you should not implement localization support.

However, last few years – that just does not apply. Localization used to take noticeable, extra effort in development, but now – it is, more or less, piece of cake. Implementation of localization barely increases development time, if any! Of course – having in mind that you are using a tool/framework that has good support for it, and majority nowdays do.

So, here is a list of benefits, based on experience of my team when it comes to implementing localization in project that does not requires it:

1. A client is being a b***h

We had a client who molested us with his own customized date/time formats and currency formats, and of course, changing of mentioned trough time. That had to stop, so we implemented a standardized way of displaying date/times and currency based on locale trough whole project and  refused to change anything. We shielded our actions with ISO standards that are related to locale standards. Eventually, he accepted and left us alone.

2. A client is being a b***h

We had several clients that molested us with constant changes of sentences used in interface. Localization helped us with that a lot! Since we are using XLIFF and/or simple key/value pair in YML files for providing sentences in application interface (a dictionary), every request for changes in interface sentences results in sending a translation file to a client. If he wants, he can change anything anytime, without yanking our chains. You would be surprised how clients are less eager to ask for changes when that involves their effort.

3. You never know when your application will cross borders of current working country

We are working on application that has been in constant development for 4-5 years now. I remember that we predicted that that project would die in first year of exploitation. We were soooooo wrong, it turns out that it had been quite successful. Support for right-to-left localization, among others, has been requested as well, since we are going to hit those markets in a few months.

And have you any idea how hard, time consuming and boring is to work on localization of application that has been built without localization support? You have to go trough every template and every controller (controller fires flash messages) and extract messages for localization.

4. Reusability

If you intend to extract a component/module/bundle from project, you will extract component with localization support already implemented.

Surely that increases reusability value of your component, right?

5. Project forks

This is somewhat edge case, but it can happen (at least, it happened to us few times, while we are aware of people having similar issue), namely, you can build a software that is intended for one client, but your sales team manages to re-sell the software to other clients as well.

Problems emerge when every of those clients want a certain level of customization. There are several strategies how to approach project and codebase management in those scenarios, our go-to solution is to have a “core” application and then make a fork of it for each client (git is our tool that we use). We do a project sub-split as well, but key idea here is in forks.

Now, customization always includes interface customization and that can be easily tackled with localization support already implemented via dictionaries, which can decrease amount of merge conflicts. Or, if you use, per example Symfony, where there are configuration/dictionary cascades, merge conflicts, at least when it comes to interface localization can be as low as nothing.


So, in short, whether you are going to need it or not, write your applications with localization support. That feature is too cheap to implement and it can save you from a lot of headaches in the future.


Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s