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

[methodover]

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.

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

[TheAceOfHearts]

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

[calcifer]

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