Re: dogtail-devel i18n module proposal

[Dave Malcolm <dmalcolm redhat com>]

On Tue, 2005-10-11 at 17:27 +1000, Lawrence Lim wrote:
> Hello,
> At the moment, dogtail assume locale to be en_US. Hence, if the scripts
> is invoked in non en_US locale, the script will fail. The design of
> dogtail, allow us to the overcome this issue easily with python
> gettext. 
> 
> Hence, I would like to contribute by creating an i18n module which will
> handle the switching of locale and include patches to the existing
> wrappers and examples.
> 
> Be looking forward to your feedback.
> 

IMHO this is a great idea!  There are Python bindings for gettext, so
that it ought to be doable.

There may be some difficulties from making it work 100%, but I think it
can be good enough.  The "translation function" mapping from
untranslated strings to translated strings isn't always invertible.
Specific issues:
(i) printf-style format strings (e.g. "%d Unread Messages" and similar);
these could be turned into regular expressions which let you match
against strings that could have been formed by expanding the format
strings
(ii) cases where source A is translated to B in one context and to C in
another e.g. in Evolution, "Forward" relating to an email, and "Forward"
meaning a button in a wizard; these will typically have different
translations.  We could provide hints in the script, I suppose
(iii) probably more examples...

Zack had a patch that added regex support to name matching, but I think
I may have killed in a refactoring (sorry Zack!).  At first I though it
might be worth generalising the string matching parameters to the search
functions (Node.findChild(), Node.child() etc etc) so that they can take
one of:
(i) string objects
(ii) compiled regular expression objects
etc

But now I think it might be better to assume that scripts are written
for the default locale, and have the framework automatically finds
translations on the fly, so that e.g. this API call:

click('OK')

which is internally interpreted as 
findChild(name='OK')

would be interpreted (possibly in pseudocode here) as:

findChild(pretranslatedName='OK')

which could be interpreted by first looking in all relevant .mo files
for the string [1], finding things it can translate to in the current
locale.  If none, then maybe you've got an untranslated string, and
maybe should raise an exception? (I'm not sure about this)

You'd then do the recursive search in findChild, and the various
predicate subclasses would need to be patched to support comparing the
reported name of each node against the expected translation.

That's how I see this as working, possibly.  These are my thoughts,
anyway...

[1] how to determine the relevant mo files is non-trivial.  You could
require scripts to manually list them; maybe we could do something
clever live doing an RPM/Apt lookup on the package, and finding .mo
files in the package and all packages it depends on (recursively).

BTW, one of my working copies has a patch that grabs all user-visible
strings in the UI.  Could we write something that checks the whole UI
looking for untranslated strings, and would this be useful?


Dave