4 ms·

That's common. 18 hits in: http://www.thefinancials.com/Default.aspx?SubSectionID=curformat http://www.thefinancials.com/Default.aspx?SubSectionID=curfo... Wr

That's common. 18 hits in: http://www.thefinancials.com/Default.aspx?SubSectionID=curformat http://www.thefinancials.com/Default.aspx?SubSectionID=curfo... Writing code is not that tough in Europe - just use a proper i18n library.

davidw 11y ago
> Writing code is not that tough in Europe - just use a proper i18n library. Not even having to think about that initially is sure handy for US startups. You can get pretty big without worrying too much about other languages and all the confusion that entails.
- chinathrow 11y ago
  True - until you go north and need a french translation ;)
  - davidw 11y ago
    Spanish is probably more likely in the US, depending on the market you're addressing.
  - logfromblammo 11y ago
    English, Spanish, French, Portuguese, and to a lesser extent Dutch will get you pretty much the entire western hemisphere. They all use the same alphabet, all read left-to-right, and are all SVO word order--except for Dutch, which is SOV/V2. Also, a US company will need a Spanish translation before it even considers French. Anyway, the point is that it is a lot easier to half-ass internationalization and localization for both of the Americas and the Caribbean than it is in Europe and Asia. That is just indisputably true. European coders must get that correct starting from version 1.0, whereas Americans can blithely ignore it for years.
ars 11y ago
> Writing code is not that tough in Europe - just use a proper i18n library. That only goes so far - the actual code you write has to use decimal commas. You can't even export, say a list of numbers, and then directly copy that in to your code. Or for example: Use SQL to print a list of numbers to use for testing queries. If you used i18n, all the numbers would have decimal commas, so you can't combine them with a comma to make a list. So you have to turn off i18n, print your list, and make sure it's off when you use that list in a subsequent query. Any European programmers here? Do you simply leave i18n off for all low level tools? And just use it for customer facing code?
- untog 11y ago
  Huh? That's not the case at all. Numbers are represented the same way as in the US throughout your code, your just put it through an i18n library when presenting it to the user. It's really not as difficult as you're making it out to be.
  - ars 11y ago
    > when presenting it to the user. That's what I mean - sometimes the user is you, i.e. the programmer, and you have to put those number back in the program - but of course you have to convert them first. > It's really not as difficult as you're making it out to be. Not ever having done it, I will take your word for it.
- kpil 11y ago
  Yes. Minor haggles occur when importing numbers into code , but all good tools can export to whatever format. Typically the internal representation is not related to the external format. But yes there are bugs in (American) programs sometimes that forces you to run them in the C locale. Typically they serialise something and fails parsing it back...
- imtringued 11y ago
  I'm not sure what's so difficult to understand about calling a function like parseInteger(userEnteredNumber, defaultLocale) on user input and then calling something like formatInteger(numberToBeOutputted, defaultLocate) on numbers that will be shown to the users. Programming languages already have a fixed representation for decimal numbers that will be used regardless of the user locale which is generally always with a dot for the decimal seperator and often there are no thousand seperators.

davidw 11y ago

> Writing code is not that tough in Europe - just use a proper i18n library. Not even having to think about that initially is sure handy for US startups. You can get pretty big without worrying too much about other languages and all the confusion that entails.

chinathrow 11y ago
True - until you go north and need a french translation ;)
- davidw 11y ago
  Spanish is probably more likely in the US, depending on the market you're addressing.
- logfromblammo 11y ago
  English, Spanish, French, Portuguese, and to a lesser extent Dutch will get you pretty much the entire western hemisphere. They all use the same alphabet, all read left-to-right, and are all SVO word order--except for Dutch, which is SOV/V2. Also, a US company will need a Spanish translation before it even considers French. Anyway, the point is that it is a lot easier to half-ass internationalization and localization for both of the Americas and the Caribbean than it is in Europe and Asia. That is just indisputably true. European coders must get that correct starting from version 1.0, whereas Americans can blithely ignore it for years.

ars 11y ago

> Writing code is not that tough in Europe - just use a proper i18n library. That only goes so far - the actual code you write has to use decimal commas. You can't even export, say a list of numbers, and then directly copy that in to your code. Or for example: Use SQL to print a list of numbers to use for testing queries. If you used i18n, all the numbers would have decimal commas, so you can't combine them with a comma to make a list. So you have to turn off i18n, print your list, and make sure it's off when you use that list in a subsequent query. Any European programmers here? Do you simply leave i18n off for all low level tools? And just use it for customer facing code?

untog 11y ago
Huh? That's not the case at all. Numbers are represented the same way as in the US throughout your code, your just put it through an i18n library when presenting it to the user. It's really not as difficult as you're making it out to be.
- ars 11y ago
  > when presenting it to the user. That's what I mean - sometimes the user is you, i.e. the programmer, and you have to put those number back in the program - but of course you have to convert them first. > It's really not as difficult as you're making it out to be. Not ever having done it, I will take your word for it.
kpil 11y ago
Yes. Minor haggles occur when importing numbers into code , but all good tools can export to whatever format. Typically the internal representation is not related to the external format. But yes there are bugs in (American) programs sometimes that forces you to run them in the C locale. Typically they serialise something and fails parsing it back...
imtringued 11y ago
I'm not sure what's so difficult to understand about calling a function like parseInteger(userEnteredNumber, defaultLocale) on user input and then calling something like formatInteger(numberToBeOutputted, defaultLocate) on numbers that will be shown to the users. Programming languages already have a fixed representation for decimal numbers that will be used regardless of the user locale which is generally always with a dot for the decimal seperator and often there are no thousand seperators.