Ask HN: Do you internationalize/localize your apps? • Hacker News Board

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

#41

Post by dotancohen » Sat, Nov 04, 2017, 8:33 PM UTC

rschoultz wrote: post #37

methodover wrote: post #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 -- 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. (…

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.

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

#42

Post by Strom » Sat, Nov 04, 2017, 8:36 PM UTC

tqkxzugoaupvwqr wrote: post #27

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)…

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.

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

#43

Post by anotherevan » Sat, Nov 04, 2017, 9:26 PM UTC

rmetzler wrote: post #25

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…

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

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

#44

Post by ufmace » Sat, Nov 04, 2017, 10:44 PM UTC

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.

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

#45

Post by TheAceOfHearts » Sat, Nov 04, 2017, 11:52 PM UTC

rschoultz wrote: post #37

methodover wrote: post #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 -- 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. (…

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

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

#46

Post by TheAceOfHearts » Sat, Nov 04, 2017, 11:58 PM UTC

dotancohen wrote: post #41

rschoultz wrote: post #37

Earlier quoted context omitted.

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. (…

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.

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.

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

#47

Post by methodover » Sun, Nov 05, 2017, 3:29 AM UTC

rschoultz wrote: post #37

methodover wrote: post #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 -- 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. (…

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.

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

#48

Post by dotancohen » Sun, Nov 05, 2017, 6:46 AM UTC

TheAceOfHearts wrote: post #46

dotancohen wrote: post #41

Earlier quoted context omitted.

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.

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.

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

#49

Post by rmetzler » Sun, Nov 05, 2017, 7:44 AM UTC

derefr wrote: post #39

rmetzler wrote: post #25

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…

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

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

#50

Post by drwu » Sun, Nov 05, 2017, 10:24 AM UTC

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.