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,861
  • 9
  • 53
  • 96
Jimmy Collins
  • 1,328
  • 9
  • 15
  • 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 Collins Dec 30 '10 at 15:04
  • 5
    @Rook And it's spelt Localisation too ;) – Rowland Shaw Dec 30 '10 at 16:15
  • 1
    @Rowland - Guess it depends on where you are, it's spelt with a 'z' in US English, but here in Europe we use an 's' - A perfect example of a localization issue :-) – Jimmy Collins Dec 30 '10 at 16:19
  • 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
  • 2
    @Andy - "Common"? No. Maybe they're used more often on the internet, but far from "common" in life in general. Show me the number of books/letters/most things published which will have that "thing" printed instead of a word ... but then again, English language thanks to the internet&online methods of communication is going to hell anyways, so ... (And IMHO, yes, they do look ugly.) – Rook Dec 30 '10 at 18:20
  • 2
    @Rook: Certainly not something Joe Public is going to run into in life in general agreed, but in the context of programming and development (which is the context that the OP was made) they are in common enough usage to be recognised by most, if not all, in this field. – Andy Dec 30 '10 at 18:34
  • @Rook - those four dictionaries are well and good, but do you also feel the same about words that are contained in the Jargon File (http://mcaf.ee/52b3c) - most of these aren't contained in these dictionaries either - does that mean we should not use them? Anyway, this isn't the best place for this discussion, that's what http://english.stackexchange.com/ is for. – Jimmy Collins Dec 30 '10 at 18:54
  • @Jimmy C - Mostly, yes. Look, it's not that I'm against adding new words or anything, but at some point you gotta take a path - the "conservative" ("very well") or the "modern" one ("'key" :). On the 'net nowadays, anything goes for a word, and if it has that "cool factor" kids will start using it (most of whom don't know how to express themselves properly anyways), and to put long story short ... that is a good way to ruin two thousand years of english language in fifty years, since it flatters the uneducated, and does not motivate one to – Rook Dec 30 '10 at 19:26
  • learn proper language use. If you allow anything into a language then anything will go for a language. I have a classical background (not in english, though ;), don't mind writing long words when the need arises, and for some reason can't stand those "things" like the given above. Call it personal preference. But, to each his own. How about we start bringing this slowly to an end? – Rook Dec 30 '10 at 19:26
  • Absolutely fine by me. I agree with what your saying regarding some of the words being used today on the Internet. But, I just don't think that numeronyms fall into this category - interestingly enough 'W3C', 'WW2' and 'G8' are also classed as numeronyms - http://mcaf.ee/62ad8 – Jimmy Collins Dec 30 '10 at 19:42
  • 2
    Might be common, but I've never seen l10n, i18n, or g11n anywhere ever before in my life. Somehow I missed the 1337 bus, I guess. – Anthony Pegram Dec 31 '10 at 01:45
  • Yes, even if it is a small development, because I always think the pain it would be to do it all after. – dukeofgaming Dec 31 '10 at 02:40

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,158
  • 8
  • 58
  • 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
    Really? which tools allow this? – David Weiser 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 Collins 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: http://www.foss.kharkov.ua/products/easy_localizer/index.htm (I will add them for reference in my answer) –  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. –  Dec 30 '10 at 15:20
  • @Pierre 303: What about using pseudo-translation early in the development cycle to catch these issues before the builds are even released to QA - http://mcaf.ee/4dfec? CodeRush looks really cool by the way. – Jimmy Collins Dec 30 '10 at 15:26
  • @Jimmy: Interesting page! But I never needed that in ten years. Looks like an overhead to me. ASCII limitation problems still happen but they are usually very easy to fix today. Regarding size of the words, as I said earlier, it's impossible to know in advance if you will need the space or not. –  Dec 30 '10 at 15:34
  • @Pierre 303 - I agree, but pseudo-localization has been used effectively where I work and has hugely reduced these types of UI bugs, so I guess I'm a bit biased in my opinion ;-) – Jimmy Collins Dec 30 '10 at 15:40
  • @Jimmy: We are all biased ;) This is why this site is great. We can share our certainties ;) And most of the time, nobody is right ;) –  Dec 30 '10 at 15:51
  • The big thing with i18n, from my point of view, is having all strings in some sort of string table. As far as I know, there's no automatic tool to do that. – David Thornley Dec 30 '10 at 22:40
  • @David: with CodeRush for hardcoded strings and simply double click on Localizable property in Visual Studio to automagically move all labels and controls positions and size into the form resource file. It's all automatic. I do it all the time. –  Dec 30 '10 at 22:59
  • Precision (can't edit my comment above): with CodeRush for hardcoded strings in the code, right click on the string and select **move to resource file**. For an entire form simply specify **yes** in the **Localizable** property in Visual Studio to automagically move all labels and controls positions and size into the form resource file (no need for CodeRush for this). It's all automatic. I do it all the time. It is fully standard. –  Dec 30 '10 at 23:07
  • @Pierre 303: Thanks! You mentioned "form"; does this work for Visual C++? The really big programs are MFC. – David Thornley Dec 31 '10 at 02:13
  • @David: it has been a long time since I started a Visual C++ project (more than 10 years)! That was nice ;) Yes it works, I added a form and it has the same "autolocalizable" feature, but the project became a CLR compatible application. I guess that's not what you asked. You wanted a pure C++ MFC app right? However, it comply with my definition of "recent technology" ;) –  Dec 31 '10 at 11:29
  • @Pierre: Whether I want a pure C++ MFC app or not, I've got a few. Programs that are in heavy use and vital to the enterprise are, in my experience, written using technology you wouldn't necessarily write them in any more. Anyway, CodeRush says they support C++, so I'll look into it. Thank you! – David Thornley Jan 01 '11 at 20:02
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
  • 45,784
  • 7
  • 87
  • 160
  • +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 Collins 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
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,238
  • 2
  • 55
  • 82
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
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,352
  • 5
  • 75
  • 130
  • 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 Collins 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 Collins 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 01 '11 at 20:04
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
  • 3
  • 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 Collins Dec 30 '10 at 16:26
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,265
  • 13
  • 17