Hi HN,<p>We are in the process of building a reporting tool that would be mostly used by sales / 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/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!
Tech lead of a smallish/medium saas startup here.<p>A couple years back sales convinced the CEO to internationalize for a European expansion... Starting with Turkish of all things.<p>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.<p>Don't do i18n until you have found product market fit, IMO.
I've found adding it to an app after the fact to be much more work than just doing it up front.<p>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.<p>It's more than just localizing your app. You also need to do the same with your sales, support, and billing.<p>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?<p>Also, what differences in laws regarding data protection / privacy / terms of service are you getting yourself into?<p>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.
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.<p>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.<p>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.<p>[1] <a href="https://www.gnu.org/software/gettext/manual/html_node/Preparing-Strings.html#Preparing-Strings" rel="nofollow">https://www.gnu.org/software/gettext/manual/html_node/Prepar...</a>
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)<p>Now, what you should absolutely DO is make sure your system doesn't break with foreign names/data/locales<p>Locales to test: RTL locales (Arabic and Hebrew for the most part) and maybe Turkish (the infamous dotted capital I)<p>Names: Chinese, Japanese, Russian, Latin Extended (ñ, œ, ø, á, é, etc), even names in English can break stuff (O'Brian)<p>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.<p>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.<p>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.<p>[0]: <a href="https://www.i18next.com/#" rel="nofollow">https://www.i18next.com/#</a>
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).<p>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.<p>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).<p>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.<p>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.
As someone with over 10 years of professional experience in g11n, I must point out few things.<p>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.<p>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.<p>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.<p>To answer your specific questions.<p>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.<p>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.<p>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.
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.<p>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.
Short version - if you have to ask the question, then the answer is no.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
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.<p>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?<p>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.<p>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.<p>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...
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).<p>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<p><button>Sign Up</button><p>I simply write<p><button>{{ 'Sign Up'|trans }}</button><p>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.<p>I think (but not 100% sure) that it will be the same in southern and eastern Europe.<p>Northern Europe should be different, they're usually better at learning English.
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.<p>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<p>do you have a large customer who can fund the internationalization?<p>is there someone who would most certainly become your customer if you internationalized?<p>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.