Ask HN: Do you internationalize/localize your apps?
51 comments
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.
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.
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.
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.
I don't think I've been properly differentiating between internationalization and localization, if I'm understanding your usage correctly:
Localization means doing things like displaying days and times in a friendly way to the particular user? I.e. 24 hour clock vs 12 hour, order of month/day/year in dates. Whereas internationalization is total translation?
I've been using the two terms interchangeably.
And indeed we've noticed what you've noticed: Translation isn't that important. Businesses are using us even in places where English is not the predominant language. Localization however has been really important - it's a nice customer experience to display dates and times in a manner familiar to you.
Localization means doing things like displaying days and times in a friendly way to the particular user? I.e. 24 hour clock vs 12 hour, order of month/day/year in dates. Whereas internationalization is total translation?
I've been using the two terms interchangeably.
And indeed we've noticed what you've noticed: Translation isn't that important. Businesses are using us even in places where English is not the predominant language. Localization however has been really important - it's a nice customer experience to display dates and times in a manner familiar to you.
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.
Now let me add point 6: Proper RTL support in user-entered strings and data.
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.
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.
I'm generally in favor of killing off legacy systems and values if it means improved global consensus. Migrating to something new might bring a bit of initial discomfort but the result is worth it. As an American, I've given up or replaced a reasonable number of conventions with which I was brought up.
With possible exceptions for certain historical or scientific context, everyone should use ISO 8601. This means the week starts on Monday, you write the date as [YYYY]-[MM]-[DD], and using 24-hour clocks. Switching to 24-hour clocks was the hardest change for me, but I eventually got used to it.
I disagree with you that decimal mark and number separators should be localized. Resolution 10 of the 22nd CGPM [0] made declarations on both points, and their declarations have been supported by various standards bodies. Apparently ISO 80000-1:2009 is also in agreement, although I haven't been able to access the document to confirm. There is clear consensus that you should use a small space as the number separator. The decimal mark is a bit trickier since either comma or point are allowed. However, based on the following consideration from resolution 10: in Resolution 7 of the 9th General Conference, 1948, it is stated that "In numbers, the comma (French practice) or the dot (British practice) is used only to separate the integral part of numbers from the decimal part". One could argue that since we're using English we should just follow the British practice, so it's most reasonable to exclusively use the dot as the decimal mark and request that others stop using the wrong symbol. There's no good reason to support two symbols.
Unsure what you mean by time zone indicators. Could you clarify? On the subject of time zones though... Dealing with scheduling across multiple time zones with varying DST behavior and moving observers can be really tricky to get right.
People that don't use UTF-8 are just bad. It's fine to continue accepting input documents with other encodings, if only to make it easier for people to transition away from that. But don't encourage them by supporting saving or exporting documents with different encodings!
[0] https://www.bipm.org/utils/en/pdf/Resol22CGPM-EN.pdf
With possible exceptions for certain historical or scientific context, everyone should use ISO 8601. This means the week starts on Monday, you write the date as [YYYY]-[MM]-[DD], and using 24-hour clocks. Switching to 24-hour clocks was the hardest change for me, but I eventually got used to it.
I disagree with you that decimal mark and number separators should be localized. Resolution 10 of the 22nd CGPM [0] made declarations on both points, and their declarations have been supported by various standards bodies. Apparently ISO 80000-1:2009 is also in agreement, although I haven't been able to access the document to confirm. There is clear consensus that you should use a small space as the number separator. The decimal mark is a bit trickier since either comma or point are allowed. However, based on the following consideration from resolution 10: in Resolution 7 of the 9th General Conference, 1948, it is stated that "In numbers, the comma (French practice) or the dot (British practice) is used only to separate the integral part of numbers from the decimal part". One could argue that since we're using English we should just follow the British practice, so it's most reasonable to exclusively use the dot as the decimal mark and request that others stop using the wrong symbol. There's no good reason to support two symbols.
Unsure what you mean by time zone indicators. Could you clarify? On the subject of time zones though... Dealing with scheduling across multiple time zones with varying DST behavior and moving observers can be really tricky to get right.
People that don't use UTF-8 are just bad. It's fine to continue accepting input documents with other encodings, if only to make it easier for people to transition away from that. But don't encourage them by supporting saving or exporting documents with different encodings!
[0] https://www.bipm.org/utils/en/pdf/Resol22CGPM-EN.pdf
> 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.
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.
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.
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.
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.
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.
> 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.
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.
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.
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...
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...
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?
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?
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.
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.
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/#
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/#
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
> 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.
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.
You're right. This tip was meant to be used in non-localized UIs.
I often use "D MMM YYYY" (e.g., "5 Nov 2017") in my UIs when it is practical as I think it is the easiest to read, unambiguous date representation, at least amongst English speaking humans.
I'll use YYYY-MM-DD internally, or in places where sorting is important (e.g., as part of file names).
I'll use YYYY-MM-DD internally, or in places where sorting is important (e.g., as part of file names).
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?
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?
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...
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...
> 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.
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.
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. :)
I don't think I have the raw data anymore. They don't let you keep that sort of thing when you leave. :)
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.
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.
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.
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.
<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.
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.
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.
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.
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.
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.
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.
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.
Also, if you want to land a governmental bid to provide software for some department, it might even be a legal requirement.
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.
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.
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.
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.
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.
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.
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.
The stuff I work on uses Qt, which makes internationalisation a breeze.
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.
You’re missing some useful data that would make this decision easier.
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.
We could launch English only for now, making sure that the application is ready to be internationalized in the future.
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.
Most people understand business-english. If your team is English-speaking, chances are, you will have much much higher chance of succeeding there.
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.
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.
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.
We are in the process of building a reporting tool that would be mostly used by sales / marketing executives to monitor ROI.
This is not a consumer facing product rather a B2B product.
We are unable to decide whether to internationalize/localize the application or not.
Here are the two approaches we are thinking
1) Launch English only for now, but plan for localization in the future
Pros:
Make the product accessible for a larger market
Cons:
Long term maintainence cost (translation would be needed for every new screen-string pair)
Seems a bit like premature optimization
2) Dont internationalize at all, given that this is not a consumer facing product
Pros: Simplify development and maintainence over long term, not having to deal with I18N
Cons: Loose out on new audience who would like to use the software in their own language
What approach would you recommend?
Also HNers whose first language is not English,
1) Roughly what percentage of software you use has option available for your language
2) Do you prefer to use software in your language if there is an option available
3) Does not having your language impact productivity while using the software.
Thanks!