
Ask HN: Do you internationalize/localize your apps? - gt5050
Hi HN,<p>We are in the process of building a reporting tool that would be mostly used by sales &#x2F; marketing executives to monitor ROI.<p>This is not a consumer facing product rather a B2B product.<p>We are unable to decide whether to internationalize&#x2F;localize the application or not.<p>Here are the two approaches we are thinking<p><i>1) Launch English only for now, but plan for localization in the future</i><p><i>Pros</i>:<p>Make the product accessible for a larger market<p><i>Cons</i>:<p>Long term maintainence cost (translation would be needed for every new screen-string pair)<p>Seems a bit like premature optimization<p><i>2) Dont internationalize at all, given that this is not a consumer facing product</i><p><i>Pros:</i>
Simplify development and maintainence over long term, not having to deal with I18N<p><i>Cons:</i>
Loose out on new audience who would like to use the software in their own language<p>What approach would you recommend?<p>Also HNers whose first language is not English,<p>1) Roughly what percentage of software you use has option available for your language<p>2) Do you prefer to use software in your language if there is an option available<p>3) Does not having your language impact productivity while using the software.<p>Thanks!
======
methodover
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.

~~~
rschoultz
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.

~~~
dotancohen
Parent is spot on. Just to drive to point, I completely agree with points 3-5,
on point 2 I would demand only ISO 8601, and regarding point 1 my weeks would
absolutely have to start on _Sunday_. The UI _language_ is almost not even a
consideration.

Now let me add point 6: Proper RTL support in user-entered strings and data.

~~~
TheAceOfHearts
The ISO 8601 calendar week starts on Monday. I'd be interested in reading why
it's such an important point for you, though. I'm an American and having the
week start on Monday makes absolutely no difference to me.

~~~
dotancohen
In my language we call Sunday "First day", we call Monday "Second day", and so
on until Saturday which is called "Day of Rest". Additionally, our work week
starts on Sunday.

------
throwaway2016a
I've found adding it to an app after the fact to be much more work than just
doing it up front.

But with that said, doing it up front even if it is less work than doing it
later, is still way more work than not doing it at all. And if your app is in
English your TAM is likely huge and you won't need to expand international for
quite some time.

It's more than just localizing your app. You also need to do the same with
your sales, support, and billing.

What do you do when you get a customer support request in a language your app
supports but no one on your service team speaks? How do you get the customers
in the other languages?

Also, what differences in laws regarding data protection / privacy / terms of
service are you getting yourself into?

If you're charging a fee, do you need a bank account in the foreign country to
charge the fee in local currency? If you do, what laws and regulations are you
required to follow to get that bank account? What about tax? The US doesn't
charge tax on services but many places do.

~~~
hrktb
To note, all of these are not mandatory and can be done in steps as it becomes
interesting to do.

You can start by having multi language support on most user facing screens, as
long as you make it clear that it’s mot full support and you only accept help
requests in one or some of the languages.

Same with sales structures, making deals in english is doable, as long as the
end user product supports their language.

Some people won’t go into internationalisation because it’s too costly to do
it in full. I think it’s ok to do it peacemeal and along the way. Most user
will prefer to have some vs nothing.

~~~
throwaway2016a
> To note, all of these are not mandatory and can be done in steps as it
> becomes interesting to do.

I agree with your point in general but would like to add a disclaimer. Local
legal requirements if you target a specific non-domestic audience are
mandatory. Sure you can skip that part and hope you fly under the radar but I
wouldn't personally take that risk.

------
jacalata
Your pros and cons for option 1 are wrong. You don't incur the long term cost
of translating all strings just by making your software localizable - you
incur it by releasing localized software. (Same for making it accessible to
the larger market). It should say something like "pro: reduces future cost of
deciding to release in other languages. Con: may be extra work". And how big a
con that is depends a ton on what technologies you're using and whether your
current plan is to just hardcore strings everywhere.

------
toast0
I think you could do a bare minimum and be ready to do more work to finalize
it later if there's demand. If you think there's a good chance there won't
ever be demand, then maybe it's not even worth this.

I think the bare minimum would be gettext style string marking, which is
generally gettext("english string") in the source; other string marking
techniques may provide a better localization, but this one is easier. Also,
try to follow general guidelines for creating strings so they're likely to be
localizable. Gettext's guidelines[1] are decent. You don't actually need to
use gettext -- you can make a 1 line function or macro that just passes
through the english text as is for now. Even if you don't mark strings, at
least thinking about string guidelines will help for the future.

If you ever decide to come localize in the future, at least you won't have to
markup all the strings, and hopefully you won't have done a lot of "string
math" which is painful to unwind. You'll still have a big amount of work to
test and fix any strings that were missed, but you'll be a lot farther ahead.

[1]
[https://www.gnu.org/software/gettext/manual/html_node/Prepar...](https://www.gnu.org/software/gettext/manual/html_node/Preparing-
Strings.html#Preparing-Strings)

------
raverbashing
As it's a B2B app, I don't think there's a pressing need to localize. It might
be interesting though to keep things localizable (not only for I18N reasons -
documentation and testing come to mind)

Now, what you should absolutely DO is make sure your system doesn't break with
foreign names/data/locales

Locales to test: RTL locales (Arabic and Hebrew for the most part) and maybe
Turkish (the infamous dotted capital I)

Names: Chinese, Japanese, Russian, Latin Extended (ñ, œ, ø, á, é, etc), even
names in English can break stuff (O'Brian)

Dates: does it work with DD/MM/YY or YYYY-MM-DD and keeps consistent?

------
alexbecker
When I worked on Google AdWords, i18n was a huge deal despite it being a
business-facing product. More than half of the revenue came from outside the
US. I'm not sure what percentage wasn't in English, but it had to be large. I
regularly got users filing bugs against me in Easter European languages or in
Arabic (these seemed to maximize buggyness * number of users). So there is
definitely money to be made selling to non-English speaking businesses,
especially when the competition isn't.

That being said you need to actively pursue international sales for this to
work, and i18n software is only a part of this. If you aren't making the
effort on the sales side it probably isn't worth it on the engineering side.

------
icc97
If you use a lowly PHP MVC framework, you'll get I18N pretty much for free.
It's just a customised echo / print statement. Same for any Django, Rails app.
So if what you're using is more difficult than that I'd question what you're
using to build your app. Admittedly React is pretty far behind for doing I18N.
i18next [0], seems quite promising for that.

The app I built had no need for languages for the first 3-4 years. Then
suddenly a foreign client comes in (ours is translated into Spanish,
Portuguese, Russian and Chinese) and you've got a ton of code written.

[0]: [https://www.i18next.com/#](https://www.i18next.com/#)

------
GuiA
Have you validated your MVP? (ie acquired enough initial users to know that
this is a viable business idea, and commit the next few years to it).

If not, then do not worry about internationalization at all, and do just
English. Validate your MVP first. At this stage, you’re trying to find people
who have a pressing, immediate problem to solve - and even if some of them are
not native English speakers, it shouldn’t be too much of a deterrent because
your product will still be a godsend to them.

If you have already validated your product, or when you have done so, but it
is not immediately clear what languages besides English you should pursue,
then I would recommend still picking a second language to make sure that your
codebase has basic, initial support for multiple languages. If you are not in
a primarily anglophone country, or members of your founding team are native in
another language, then pick that one (it’d be dangerous to pick a language you
have no familiarity with, as a team, because high quality translators are hard
to find, and translators who can work with your designers to address more
subtle cultural details are close to impossible to find).

This won’t solve all your problems - for instance if you support English and
Spanish out of the box, but a few years later you realize you need to support
Hebrew, you’ll likely have work to do to support a right to left script. But
at least your codebase will have initial support for more than one language,
which will make the effort a little less insane.

------
tqkxzugoaupvwqr
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) to look up the actual
translation in a map.

~~~
Strom
Unfortunately that's only a partial solution. Some languages produce much
longer text than English, either by using more words or just longer words. If
you design the UI with only English text lengths, then you'll still need to
redo the UI layout. Similar problems for languages which aren't read from left
to right like English.

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

------
r-s
I generally do internationalize apps that I build right from the start. The
cost for switching at a later date I have found to be very significant.

I do not however localize them until its needed. Often working with
translators and ensuring the quality of the localized application is not a
huge priority in the beginning.

~~~
brlewis
I believe you, but my experience is different. IME i18n and l10n are a lot of
work even if you plan on them from the beginning. For projects I've worked on
it wouldn't save that much effort to architect for i18n up front. I would go
with just one language until product-market fit, then assess whether it's
worth internationalizing/localizing.

------
ufmace
Short version - if you have to ask the question, then the answer is no.

More fully, what's your customer acquisition pipeline like? How many people on
your team are fluent in another language? If the answers are "we don't know
yet" and "none, except I think one guy speaks a little X", then I18N is the
last thing you should be thinking about. You have access to a plenty big
market just working in English, figure out how you're going to get customers
and what they want first. Establish yourself as a viable business. Get as many
customers as you can with your English-only app.

Once you know how to get English-speaking customers and what they want, you
can at least make a reasonable estimate on what will be required to get
international customers. You should already have some English-speaking
customers in any country worth targeting for a more directed sales effort.
That'll at least give you a starting point for people to talk to to figure out
how to service those customers better and what you might need to change to
operate more effectively in that country. This may include actual good
translations, units and date handling, any cultural differences, legal and tax
compliance, accepting foreign currency for payments and how to handle that,
etc.

------
51Cards
This may not be a fair answer but being based in bilingual Canada has made
localization a defacto process. We only support English, French, and have
recently added Spanish so languages like Cantonese would be a challenge yet.
That said it forced us to learn to structure applications with that in mind
from day 1 and I'm quite glad we don't have that refactor process still ahead.

------
rmetzler
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 which
are not translated, so the screentext is mixed German and English.

In the software I maintain I hate translations, because all the time project
managers forget that I need the texts in two languages. Also there's never the
perfect time to do the texts, since you almost always have to change the UI
and all translations.

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.

~~~
derefr
> 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.

~~~
rmetzler
You're right. This tip was meant to be used in non-localized UIs.

------
TheAceOfHearts
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?

------
lj3
I don't i18n. It's a good amount of work for little benefit. I've only seen
one industry capture metrics on i18n usage and that is (was?) the social games
industry. All of the findings I saw pointed to the fact that even
international players would prefer to play the game in English rather than
their native language. I believe there's two reasons for that: to better learn
English and to avoid the bugs and layout flaws that come with blindly
internationalizing an app.

If you have enough customers to warrant an international version of an app, it
might be worth it to completely redesign the UI around the new audience. The
language used applies constraints and makes assumptions that may not be true
in other languages. And then there are the culture differences...

~~~
Kiro
> All of the findings I saw pointed to the fact that even international
> players would prefer to play the game in English rather than their native
> language.

Would love to see that. In Clash Royale there's a bug that makes it show what
language your opponent is using and English is not even in majority.

~~~
lj3
What's the most used language? And does that language have its own UI layout
or is it just crammed into the English language UI?

I don't think I have the raw data anymore. They don't let you keep that sort
of thing when you leave. :)

------
codewardenh
Honest answer - we don't. In markets, even with global corps using our
platform English is the business Lingua Franca. The clients usually expect
their users to work in English. Works for us.

------
apeacox
I used to add i18n on rails apps only when needed, because it forced to create
a decent yaml schema for translations (how/where to put keys in the right
namespace can be hard).

Instead, Elixir/Phoenix uses gettext, you wrap strings with a gettext call,
then you run a task and it generates all the files ready for translation. This
means I can still use a main language and translate it if needed, without
touching the codebase.

------
waibelp
For all new projects I always use internationalization. Instead of writing
something like

<button>Sign Up</button>

I simply write

<button>{{ 'Sign Up'|trans }}</button>

That way I don't need translation files (EN is default). If translation is not
found the "key" is returned which is fine. Once the app is ready I call a
command to create my language files and simply translate them.

------
askafriend
Can you quantify the revenue impact? Do you know your userbase at all?

You’re missing some useful data that would make this decision easier.

~~~
gt5050
We havent yet released the product, so we dont really have metrics around
usage from international users.

We could launch English only for now, making sure that the application is
ready to be internationalized in the future.

~~~
tehlike
That's what i'd do. launch, get feedback.

Most people understand business-english. If your team is English-speaking,
chances are, you will have much much higher chance of succeeding there.

------
ryandrake
Like others here, I always recommend to internationalize right away, but
localize later only if/when you need to. Internationalization is like
portability and testability--if you do it from the start, it's much, much
easier than if you try to cobble it in later when your project is huge.

------
ggg9990
You should launch without it, but with a framework to do it when necessary,
i.e. Keep your strings file in one place at a minimum. You may find it
necessary sooner than you think. For example, many governments and academic
institutions cannot legally purchase non-localized software.

------
andy_ppp
Yes, add translation keys at a minimum now, no one wants to spend time in the
future trying to i18n a product after the event, especially one that is
constantly being worked on and improved and your playing catch up. It should
literally cost you nothing to do as you go along.

------
davchana
Indian by nationality here, so English is just kind of my first language; but
not completely. I would always prefer software, apps, websites in English
rather than my own Punjabi/Hindi language. Reason, I learned/always-used
computers in English.

------
jmnicolas
I'm French. Most (99.9%) of my countrymen (and women ;-) won't bother with
something that is not translated.

I think (but not 100% sure) that it will be the same in southern and eastern
Europe.

Northern Europe should be different, they're usually better at learning
English.

~~~
icebraining
Same here. I've worked in B2B SaaS companies that had clients in Belgium,
Portugal, Spain and the Czech Republic, and decent localization (both
translations and date/currency formats) was crucial to get our clients. This
has been true from two-person companies to multi-million euro companies.
Unless you have no real competition, I would advise against ignoring it.

Also, if you want to land a governmental bid to provide software for some
department, it might even be a legal requirement.

------
herbst
I usually just create things in english. If I then decide to ad other
languages it defaults to English and I don't have to worry about having
everything translated instantly. The other way around wouldn't work.

------
antaviana
If your short-term, addressable and referenceable market can use your product
in English, I would focus on releasing as soon as possible, without
distractions. You need to ensure you have product-market fit.

------
drwu
Depends.

For instance, in the scientific or some high-tech branches even for some IT
topics, there are sometimes no official translations of the new ideologies.

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

------
je42
don't forget that full internationalization also includes taking care of
layouting issues i.e. words that are longer in other languages. Characters
that are higher. Right to left text.

------
jjuhl
The stuff I work on uses Qt, which makes internationalisation a breeze.

