Live data from Hacker News

Ask HN: Do you internationalize/localize your apps?

news.ycombinator.com

31–40 of 52 posts

Re: Ask HN: Do you internationalize/localize your apps?

#31
Tech lead of a smallish/medium saas startup here.

A couple years back sales convinced the CEO to internationalize for a European expansion... Starting with Turkish of all things.

It was a terrible waste of resources. We were still trying to find product market fit, and internationalization is a tricky, labor intensive problem. It's not just a matter of putting in hooks for internationalized strings in your code -- that's the easy part. It's setting up a great localization process that's the hard part. And even if you do a great job at building out that pipeline, it's a massive drag on the speed of developing new features. Every change needs to go through localization.

Don't do i18n until you have found product market fit, IMO.

Re: Ask HN: Do you internationalize/localize your apps?

#32
As someone with over 10 years of professional experience in g11n, I must point out few things.

First and foremost i18n is not about extracting strings to make application translatable. Before you actually do that you should think what actual markets you will be targeting. Actually, even by your rough description of what your application will do, I can tell you that the major will be cultural fit. You may think that people tend to do business roughly the same way all other the world. And nothing could be farther from the truth.

Should you ever want to sell it outside US, you should think how to suite your target users' needs. And this is much more related to behaviors / workflows than to translation.

By the way, I don't care that much if something is translated, what I care most is how things like date, time and currency is presented. This is crucial; I can't comprehend dates like 4/11 quickly.

To answer your specific questions.

1) Frankly, I have no idea about percentage. Personally I tend to use English versions if that's possible as Polish translations tend to be horrible. Well, it is usually result of concatenating strings which does not allow for re-ordering the sentence, but still.

2) I already answered to some extent. I actually prefer everything to be in one language (be it my native Polish or English). Having part of UI in English and part translated is really irritating. And as I said, following local formats is much important.

3) This depends on your user base. In case of Poland, I believe financial / marketing people will use so many English terms that untranslated app would be easier to grasp. Should you follow local formats (or allow to change them in user preferences), that is.

Re: Ask HN: Do you internationalize/localize your apps?

#33
do this with a sales first mindset

do you have a large customer who can fund the internationalization?

is there someone who would most certainly become your customer if you internationalized?

otherwise it's a very hopeful use of your valuable engineering resources.

Re: Ask HN: Do you internationalize/localize your apps?

#35

Tech lead of a smallish/medium saas startup here. A couple years back sales convinced the CEO to internationalize for a European expansion... Starting with Turkish of all things. It was a terrible waste of resources. We were still trying to find product market fit, and internationalization is a tricky, labor intensive problem. It's not just a matter of putting in hooks for internationalized strings in your code -- th…

> Starting with Turkish of all things.

Your specific situation aside, if I was localizing an app for the region, Turkish would be one of my first picks (after German maybe), based purely on number of native speakers.

I used to work on mobile games and Turkish was always among the first few locales to be released.

Re: Ask HN: Do you internationalize/localize your apps?

#37

Tech lead of a smallish/medium saas startup here. A couple years back sales convinced the CEO to internationalize for a European expansion... Starting with Turkish of all things. It was a terrible waste of resources. We were still trying to find product market fit, and internationalization is a tricky, labor intensive problem. It's not just a matter of putting in hooks for internationalized strings in your code -- th…

Having built and used internationalised and localized applications for many years (answered no when asked by Netscape at the time whether I18n domain names were important), my advice is:

I18n, not that important. I.e. likely your target audience is familiar with English. L10n, more likely to be needed for the ability to use a service.

As a European user, I need at least: (1) Have weeks count as starting on Mondays. (2) Have ISO-8601 / rfc3339 date and timestamps. (3) Decimal point and (4) 1000 number separators localized, time zone indicators, (5) UTF-8 support.

Re: Ask HN: Do you internationalize/localize your apps?

#38

The solution is: Build support for translations into your code and only offer English as language. You can later add additional languages without having to replace every hardcoded text with a translation ID. The most basic version of how it works: Where you want your translated text, put a function, e.g. called “T” that takes a string as argument and returns a string. The function uses this argument (translation ID)…

This is an extremely naive way to look at i18n. Especially for UI’s, it’s much more difficult. Dynamically formatted strings, sentence direction, capitalization, etc. aren’t solved by what boils down to a key-value map.

Re: Ask HN: Do you internationalize/localize your apps?

#39

I'm German and I hate half assed i18n. Often the translation is done poorly, E.G. the word "open" has two different meanings when translated to German, depending on if it's used as a verb or adverb. I especially used to hate the translation for git, because I couldn't understand it, since they even translated all the core concepts like "branch" into "Ast". It seems like it's better now, but there are still errors whi…

> One tip: if you use dates, please use YYYY-MM-DD and not MM/DD/YYYY. The first format is universally understood, the second one almost always trips me up since we use DD.MM.YYYY in Germany.

Usually, datetime stringification takes a locale, and uses the formatter for that locale. Doing i18n by picking one "universally-understood" format, rather than just giving each user the format colloquially familiar to them, is rather uncommon.

Re: Ask HN: Do you internationalize/localize your apps?

#40
I wouldn't do any i18n or l10n. It increases complexity and it's very expensive. It's also difficult to get things right unless you have someone familiarized with the target audience's culture.

Also, isn't CSS support for RTL languages kinda iffy? I've noticed that in newer versions of the spec they've begun using start/end rather than left/right, which I'm guessing is meant to help when creating bidirectional interfaces. But how well supported are these changes?

My first language is Spanish. No idea what percentage of my software supports it since I never check. I always prefer using English. Not having a Spanish option has zero impact on me.

I'd be interested in hearing arguments from the pro-i18n/l10n side. I actually have lots of questions about why certain things should be supported at all. For example, why should we support +10 different calendars instead of making everyone use ISO 8601?

Post reply on HN