4 ms·

Due to the high number of regional languages, most startups simply start with the English version of their product (if the product is not primarily aimed at the

by geff82 9y ago

Due to the high number of regional languages, most startups simply start with the English version of their product (if the product is not primarily aimed at their home country). So Google in France would have been in English first and French second.

ensiferum 9y ago
That would never have worked.if you want to enter the French market you need a French product.
flexie 9y ago
Would it? 18 years ago? I doubt it. Google itself is really not as good in other languages as in English, even today. Could French google in 1999 have become world class in a non-native language?
mattmanser 9y ago
AFAIK, and IANAL, in France, you'd still need to support 2 versions from day one: https://en.wikipedia.org/wiki/Toubon_Law https://en.wikipedia.org/wiki/Toubon_Law I just internationalised a UK startup to enter other EU markets, since doing so it has been a non-trivial amount of extra work just to keep it up. Not immense, but definitely a drag. There's all sorts of little extra cognitive overhead once a product supports two languages. Button widths, text lengths, layouts, email layouts, normalised date formats, even icons (for example we'd used a £ icon to indicate paid). We use SendWithUs templates, and now we have to upload all the translations too as part of a deploy. And that's not even counting the extra time to do the translation, upload it, etc. Silly little things that a lot of programmers use without thinking, like basic date formatting like "ddd HH:mm", you simply can't do that any more. You need to agree shared formats and they don't always fit as you'd like them to, or quite convey the info you want them to. For example recently I'd have loved to say "Today 9:15", "Tomorrow 12:15", "Thu 14:15" or "Next Week", just for one specific place. But then you need to create a function to perform l10n on that and suddenly you're adding a big bit of extra functionality and you end up falling back on the shared .ToL10nDateTime() even though it's objectively worse at conveying the info you need to convey. We've got a bunch of work in Alpha at the moment that's English only because we were under such time pressure to deliver it for one client. The time to insert all the place holders and do the client-side i18n meant we've parked it all to get the functionality out of the door for that client. Even though it will take more time in the long run. As I understand it, a hypothetical French startup equivalent would be breaking the law by doing that.

by geff82 9y ago

ensiferum 9y ago

That would never have worked.if you want to enter the French market you need a French product.

flexie 9y ago

Would it? 18 years ago? I doubt it. Google itself is really not as good in other languages as in English, even today. Could French google in 1999 have become world class in a non-native language?

mattmanser 9y ago

AFAIK, and IANAL, in France, you'd still need to support 2 versions from day one: https://en.wikipedia.org/wiki/Toubon_Law https://en.wikipedia.org/wiki/Toubon_Law I just internationalised a UK startup to enter other EU markets, since doing so it has been a non-trivial amount of extra work just to keep it up. Not immense, but definitely a drag. There's all sorts of little extra cognitive overhead once a product supports two languages. Button widths, text lengths, layouts, email layouts, normalised date formats, even icons (for example we'd used a £ icon to indicate paid). We use SendWithUs templates, and now we have to upload all the translations too as part of a deploy. And that's not even counting the extra time to do the translation, upload it, etc. Silly little things that a lot of programmers use without thinking, like basic date formatting like "ddd HH:mm", you simply can't do that any more. You need to agree shared formats and they don't always fit as you'd like them to, or quite convey the info you want them to. For example recently I'd have loved to say "Today 9:15", "Tomorrow 12:15", "Thu 14:15" or "Next Week", just for one specific place. But then you need to create a function to perform l10n on that and suddenly you're adding a big bit of extra functionality and you end up falling back on the shared .ToL10nDateTime() even though it's objectively worse at conveying the info you need to convey. We've got a bunch of work in Alpha at the moment that's English only because we were under such time pressure to deliver it for one client. The time to insert all the place holders and do the client-side i18n meant we've parked it all to get the functionality out of the door for that client. Even though it will take more time in the long run. As I understand it, a hypothetical French startup equivalent would be breaking the law by doing that.