Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

When working on a software project or a website, do you develop with localization in mind?

By this I mean e.g.

  • Externalizing all strings, including error messages.
  • Not using images that contain text.
  • Designing your UI with text expansion in mind.
  • Using pseudo-translation to test your UI's early in the process.
  • etc.

On projects you work on, are these in the 'nice to have' category and let the localization team worry about the rest, or do you have localization readiness built into your development process? I'm interested to hear how developers view localization in general.

share|improve this question
3  
L10N->localization ... let's use proper english here, shall we? –  Rook Dec 30 '10 at 15:02
11  
@Rook - It's a common industry abbreiviation and is contained in 'The American Heritage® Abbreviations Dictionary' - so I'd like to hear your definition of 'proper English' (note the capitalization of 'English' :-) ). –  Jimmy C Dec 30 '10 at 15:04
5  
@Rook And it's spelt Localisation too ;) –  Rowland Shaw Dec 30 '10 at 16:15
2  
@Jimmy C - Not in Black's, not in Longman's, not in Oxford's, not in Merrian's ... (and believe it or not, I took the trouble of checking all of them just to be sure). But plainly, it just ugly and doesn't resemble a word (not sure on this one, but I'm pretty strong on that words don't have numbers). –  Rook Dec 30 '10 at 17:30
4  
@Rook: It is a numeronym abbreviation. Same a i18n for "internationlisation" and g11n for "globalisation". Are they ugly? Maybe, maybe not. Fact is, they are in common usage. –  Andy Dec 30 '10 at 17:53

8 Answers 8

up vote 10 down vote accepted

I work for a large Fortune 500 company and we always start out with localization in mind. Our projects are usually only for the US, but too many times over the years, we'll write an app for a client and then someone else will see it and say "hey, that would be an awesome fit for country X". Then next thing you know is you're going through the code adding localization. It really doesn't take any more time to build the app with it from the beginning, so we just do. Plus the added benefit is that when a client does come to us and ask for their app to be in (pick your language), we hand them a file and tell them to get it translated to (pick your language) and we're done.

share|improve this answer
    
True. But for personal projects, I don't. Just English. –  kadaj Dec 31 '10 at 7:15

Answer: Yes. Although in the environment I work (Python/Zope/Plone) it's very easy to localize strings afterwards, so I skip that if it isn't a requirement from the start.

But I store text in unicode objects, etc.

So, yes. I make sure my applications are reasonably easy to localize and even if not localized will work in an international setting. Not doing so is a mistake, as the effort needed is small, and the benefit great.

share|improve this answer

Sounds that people are taking l10n efforts pretty lightly. Especially when using English as a original language, it's easy to ignore the fact that other languages normally require even 30-40% of more space for text. This requires translators to use abbreviations that are not that easy to understand which is of course bad for user experience.

share|improve this answer

I write android applications, and localization is pretty straight forward using java style string files. Almost zero effort for full internationalization on all Android languages.

share|improve this answer
    
It's true that newer platform technologies have been designed with localization in mind. In my experience with iOS, it's a simple enough procedure to localize these types of applications. –  Jimmy C Dec 30 '10 at 16:26

Most of my clients require only one language, and in fact specify that one language. Therefore, we don't spend time localizing the application. However, that doesn't mean we can completely ignore other languages. So we stick with the basics:

  • Use Unicode everywhere. It's 2k10, there's no excuse not to.
  • Design for some elasticity in the layout. Even with all English, different fonts have very different screen footprints at the same point size.
  • Keep application functions/data modeling out of the view layer

Personally, when a potential localization language is fundamentally different from the one the application was designed in there's alot more going on than the simple selection of text. While text replacement helps and will allow a company to get a "quick and dirty" implementation in a new location comparatively earlier--it doesn't solve the fundamental differences in the way users in the other language think.

I've studied Japanese, and while I can only consider myself a rank beginner in that language, I know enough that there are some concepts that there isn't a direct translation for. There are different ideas of what makes something useable. While the big major concepts might be similar, it's the details that really makes a difference with users.

In order to truly address the needs of a very different culture, you need a whole new face for your application. That's why Model/View/Controller separation becomes even more important. As long as the application functions the same way, the view portion can be completely replaced. When that happens, someone is planning on paying some real money to tackle the problem properly.

share|improve this answer
    
+1 for sticking to the basics and your point about Unicode. Also, you make a good point about 'alot more going on than the simple selection of text'. This is especially true when localizing applications for languages which are written Right-to-Left (such as Arabic or Hebrew), where the whole UI needs to be mirrored. –  Jimmy C Dec 30 '10 at 16:23
    
From a useability standpoint, simply mirroring the UI may not be the best option. You may have to reorder some elements to comply with local conventions and reduce the learning curve for your users. Serious internationalization/localization projects need to consider the impact on users in that locale. If they don't the app just won't receive the adoption that the marketers were hoping for. –  Berin Loritsch Dec 30 '10 at 17:47

Usually, I add internationalisation later when I need it, even if I know from the beginning that I will need it. With the languages I'm using, it's not terribly diffult to do it in a separate phase, and I can keep one cumbersome aspect out of the early constructive phases.

share|improve this answer
2  
Not sure this is the best approach - what if you get requests for some languages that may be troublesome, maybe some double byte languages like Japanese, Korean etc.? –  Jimmy C Dec 30 '10 at 15:32
1  
Jimmy C: Currently, for the kind of project I'm working on, support for European languages like English, German, French, Spanish, Polish etc. is enough. I just don't know enough about Japanese and other "troublesome" languages (e.g. writing directions etc.) to make all the necessary preparations in the software; and it doesn't make any sense to spend large amounts of time and money for something that probably never happens anyway. BTW, double byte is not our problem, we use Unicode everywhere :D –  user281377 Dec 30 '10 at 15:44
    
It makes sense it that scenario I guess. –  Jimmy C Dec 30 '10 at 15:47
    
You really don't have to know much about Arabic and Japanese to prepare for internationalization. There are general guidelines that are usually good enough. If you're supporting multiple European languages, and using Unicode, you're likely most of the way there. –  David Thornley Jan 1 '11 at 20:04

I think that was important 10 years ago. Recent technology solved the problem.

I live in a country where there is 3 national languages, and only one of them is a minority.

To understand problems that could occurs because of that, it's like having the west part of US speaking a (very) different language than the east part. Think that in the center of the country, population is somewhat merged, and so you must use both language everywhere.

Having 4 languages in desktop applications and websites was and still is very common (3 national languages + English). It's sometimes an obligation.

I was localization aware because I have been conditioned by my environment. So yes, few years ago, I was worrying about it.

Now I don't care much about localization because latest IDE tools allows you to convert any static application into a fully localized one very easily.

Tools I use with Visual Studio .NET:

  • CodeRush, a Visual Studio plugin that allows you to move hard coded texts into resource files.
  • Easy Localizer, extract labels in an Excel file in which you add all additionnal language, then merge back in your resource files.
share|improve this answer
4  
Really? which tools allow this? –  David Dec 30 '10 at 15:08
    
What about things like text in images, and using strings like (for example) 'Your High School' in forms which may not be understood in certain locales? A developer still needs to be aware of cultural differences. –  Jimmy C Dec 30 '10 at 15:11
    
In Visual Studio, I use a tool from DevExpress named CodeRush. There is also another tool I use to translate an entire application at once: Easy Localizer: foss.kharkov.ua/products/easy_localizer/index.htm (I will add them for reference in my answer) –  user2567 Dec 30 '10 at 15:11
4  
good tools, but there's more to it than that - screen layouts, for example, may have to change because of different label lengths; database lookup values will need to be translated; etc. –  Steven A. Lowe Dec 30 '10 at 15:17
    
@Steven & JimmyC: no silver bullets here. Just good tools that remove most complexity. Please note that I noticed a pattern with years of working on localized applications: You can't know in advance how much size a given word or sentence will take in the languages you don't know. Believe me they can have very different sizes. You adjust your interfaces & layouts during your testings. –  user2567 Dec 30 '10 at 15:20

We've done it as needed: customer-facing stuff is now all done with i18n in mind, since we've expanded our markets, and some internal stuff is now i18n-capable, so the employees who use that need not speak English.

So, we did it on an as-needed basis, as a startup.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.