13

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.

Rook
  • 19,947
Jimmy Collins
  • 1,328

8 Answers8

9

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.

Walter
  • 16,136
  • 8
  • 59
  • 95
6

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.
4

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.

Berin Loritsch
  • 46,426
3

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.

David Thornley
  • 20,310
2

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.

petteri
  • 121
1

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.

user281377
  • 28,434
1

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.

Guy
  • 111
1

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.

Lennart Regebro
  • 2,275