Re: [Pythoncard-users] internationalization

>From: "Kevin Altis" <al...@se...>
>
>Part of the point of resource files is that someone other than the coder
>should be able to translate the various menus, fields, buttons, labels,
>strings used in dialogs, etc. to another language increasing the target
>audience for a program. As part of the PythonCard framework and
>documentation we can provide guidelines for writing programs that are easier
>to internationalize by providing conventions to follow.
>
>I would like to have at least one sample that deals with
>internationalization issues. I don't expect to completely solve this issue
>in one pass, especially since we don't have complete Unicode support for use
>everywhere.
>
>The relevant module in Python is locale:
>   http://www.python.org/doc/current/lib/module-locale.html

Be carefull, as far as I know, localisation in Python is available 
for Unix/Linux plateform, but does not work well for other.
One of the main mechanism is the gettext module based on some default 
Linux behavior with a really diiificult portability...

Main Internationalisation norms are:

ISO 639 for name of languages
ISO 3166 for name of country
RFC 1521, 1766, 3066 for MIME supporrt wich deal with caracter 
encoding and language support.


>It would be relatively simple for the
>framework to check the users locale when it starts up and use the
>appropriate resource file.

I don't know of any portable code to do this yet.

>  The user code would of course have to use the
>right string, date, and number formatting to work transparently. The user
>code would not have to maintain a separate set of handlers or names
>referencing resource objects since the names such as 'menuFileExit' are ids
>never seen by the user, only by the user code.
>
>For example, if we used country codes, we might have:
>
>minimal.rsrc.py
>minimal.fr.rsrc.py

Sorry, 'fr' (lower case) is a language code. It have to be completed 
by the country code in some circumstances...

>language is not the same as their country, so using a language identifier
>might be a better choice. In fact, we probably need to deal with language
>and country independently.

It will be neede for full internationalisation. And it will be a nice 
start to get these features as early as before 1.0 instead of waiting 
for a 1.1 International version as is usual in the commercial 
software market...

>If someone could volunteer to help chase down relevant internationalization
>issues, help with doing an international PythonCard sample, that would be a
>great help. This is not an area of expertise for me, but I know it is
>something we have address at some point and I would like to get it on the
>radar now rather than later.

I can be of some help on this matter. But I have a limited amount of 
PythonCard and programming expertise, and time is a really limited 
resource (as for many others).

I did a first shot at an international module. I know that it is 
broken right now. I am already trying to fix it to enhance the 
language suppport issue. But if you want to give it a try....

http://francois.granger.free.fr/MacPython and then download numToWord 
according to your plateform.