[Pythoncard-users] PyCard, L18N and resource editor : a proposal

[Fred P. <fr...@di...>]

Hi PyCardistas,

Recently there has been some activity on the list about future 
directions for the resource editor, an alternative implementation 
being tested, etc. This somehow woke me up and prompted me to dig up 
some old ideas I had last year about PyCard and L18N ; these were 
discussed on and off with Kevin last year in idle chitchat through 
the mail, but I thought I'd take the time to sum it up a bit better 
and float it by the list to see what people think.


Rationale : 

IMHO Pycard is a developer's dream when it comes to building multi-
language apps easily, and making them easy to manage for users too, 
thanks to the resource file scheme.

However, in my experience, localization of any moderately successful 
open source app is mostly (and best) done by international users 
themselves. For this to work well, the localization scheme must be 
utterly simple, requiring no special tools or developer skills (
unlike gettext and others).

I myself maintain French versions of two such packages (the SciTE 
editor and the ELOG weblog server). Both authors have made it really 
easy : edit a text file, find the new strings for the new version at 
the end (singled out by a #comment), type in the French equivalents (
using the trivial syntax "english string" = "french string"), mail 
back to author. I probably wouldn't take the time if it were more 
trouble than that ;-)

In this respect I believe that the present state of things in PyCard 
can be improved : it is easy for the developer to create and 
distribute localized apps, but delegating translations to users 
involves having non-developers edit Python code - or at least data 
structures.

This is error-prone for people not familiar with Python syntax ; 
moreover the items to be translated are potentially all over the 
resource file -- even I, maintaining English & French versions of my 
own stuff, sometimes manage to forget some ;-)

The proposal below, in a nutshell, is to improve on this by 
transparently modifying the resource editor (and, of course, the 
resource loader in the PyCard engine) by moving everything that might 
need to be translated in the 'strings' section of the resource file 
dictionary.


Proposal :

For the developer, the resource editor continues to work just as it 
ever did (barring further improvements, of course:). One still places 
widgets on the background, and defines properties for them just as 
before. The difference is in how the editor writes out the resource 
file : whenever the attribute is a string (or list thereof), instead 
of directly assigning that to the property, it makes up a normalized 
variable name, and also creates the corresponding entry in the 
'strings' section.

To illustrate, instead of the typical resource file code :

{'stack':{'type':'Stack',
          'name':'Minimal',
    'backgrounds': [
    {'type':'Background',
          'name':'bgMin',
          'title':"myPyCardApp - a Pythoncard app demo",
          'position':(220, 220),
          'size':(700, 500),
          'statusBar':1,
          'visible':0,
          'icon':'images/droopy.ico',

         'strings': {
         'errFileNotFound':'* File not found ! *',
         },

         'components': [

{'type':'Button', 
    'name':'exitButton', 
    'position':(375, 335), 
    'size':(290, 30), 
    'label':'&Exit myPyCardApp', 
    'toolTip':'Shortcut : [Enter]', 
    },
(...)

... you would have something like this :

{'stack':{'type':'Stack',
          'name':'Minimal',
    'backgrounds': [
    {'type':'Background',
          'name':'bgMin',
          'title':"bgMin_title",
          'position':(220, 220),
          'size':(700, 500),
          'statusBar':1,
          'visible':0,
          'icon':'images/droopy.ico',

         'strings': {
          'bgMin_title':"myPyCardApp - a Pythoncard app demo",
          'exitButton_label':'&Exit myPyCardApp', 
          'exitButton_toolTip':'Shortcut : [Enter]', 
          'errFileNotFound':'* File not found ! *',
         },

         'components': [

{'type':'Button', 
    'name':'exitButton', 
    'position':(375, 335), 
    'size':(290, 30), 
    'label':'exitButton_label', 
    'toolTip':'exitButton_tooltip', 
    },
(...)

The resource loader would also be backward-compatible : it would 
check if the string for an attribute is its normalized variable name, 
and then substitute the string value if present ; else it would just 
use the string as before. The resource editor could convert existing 
resources from old to new format in the same way.


Benefits :

Now everything that is potentially translatable in a resource file is 
in one single data tructure, the 'strings' dict.

For the developer, that makes it easier to create and maintain 
several versions of his own resource files.

For the user who volunteers in helping out for a particular language, 
getting started is much less daunting, especially if the strings dict 
is written out at the end of the resource file with some comments for 
direction ; there could even be a little sample in the standard 
PyCard distribution with a GUI to create a new resource from an 
existing one, making things even more bulletproof (this app could be 
created now, but it would have to be maintained in sync with the rest 
of PyCard by the core developer(s) - with the proposed change, it 
could be done once and for all).

Comments welcome - Thanks for your attention,
fp