perils of internationalisation

[Carlos Ribeiro]

At 11:11 25/05/01 +0100, Robin Becker wrote:
>A reportlab user reports setting LANG=greek and then finds the output of
>reportlab to be unreadable by acroread. After viewing the output I see
>that my floats are coming out with , instead of . for the decimal point.
>
>Are there any ways to control the decimal point character locally for
>functions like sprintf etc or must I write a special purpose output
>formatter? Alternatively should I whine at acrobat or do something else.

I've had the same problem with MS Excel. All PCs at my company use 
Brazilian Portuguese localization. When I try to import text files from the 
Unix world, first I have to filter all numeric values. Dates also exhibit 
the same problem - D/M/Y format versus M/D/Y format.

While I understand that this problem is inherently connected with 
internationalization issues, it's not an excuse for braindead software. We 
should have some option to change localization temporarily for some 
application, either as a software option, or a OS feature. However, this is 
a *big* job that nobody seems to want to do.

Another take would be to have some way to change localization on a per file 
basis. Can you imagine having problems to run Python scripts for a similar 
reason?


Carlos Ribeiro