At 17:12 26/04/01 +0000, David LeBlanc wrote:
>Looking at this from a broader perspective, in light of the move towards
>Unicode, isn't internationalization (i18n) and localization (l8n - L18n)
>going to become a more pervasive issue? From radix specifiers ("." US,
>"," European) to date formats and beyond, global acceptance of Python is
>going to be somewhat dependent on idioms familiar to a particular group
>IMHO.
A similar issue is already happening with VB. In the brazilian edition of
the Office suite, the library functions got their names translated. Note
that I dont think that this is a good idea, but I see the reason behind
Microsoft's choice. They expect that the users should be able to write
macros for their Excel worksheets, and what is better than naming the
functions in the native language of the user?
The same applies to importing/exporting data to/from applications. Date
formats and comma/period issues cause lots of problems. Sometimes we get
text files (log dumps from some equipment, for example) that are formatted
using US localization. To import this files in Excel, you have to change
the locale to US, import the file, and then change it back to Brazil. (Of
course, I solved my problem using a Python script to convert notations, but
the example is still valid for the majority of users).
A complete solution for this problem is very far, far away. There are two
pieces in it:
1) the internal data format needs to be locale-independent;
2) locale information needs to included in the file, either as:
a) as a permanent attribute of the file, preserved in backups
or downloads.
b) in some place on every file header, including text files.
Carlos Ribeiro
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4