Re: dogtail-devel i18n module proposal

[Ed Rousseau <rousseau redhat com>]

On Thu, 2005-10-13 at 00:34 -0400, Dave Malcolm wrote:
> 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. 
> > 
> 
<snip>

> 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...
> 

Agreed ... <snip>


> 
> 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.
> 

I have thought about how to do this a bit and think the way to do this
1st drop is *not* at runtime. There are too many opportunities to blow
up and that would tank the script run. I think we can help automate the
translation and generation of script data for data driven translation
testing.

This would require a number of things. More structure for data driven
testing (which we need to do anyway), the recorder (which we need to do
anyway) and a way to translate. Dave your translation approach seems
pretty sound but by putting the the process focus on script development
time rather than script run time, we should avoid costly blow ups that
tend to plague automated testing when one attempts to get too fancy. :)

Anyhow I need to cogitate and whiteboard this a bit more but I think a
system by which we can have the recorder automatically variablize a
script a record time would be cool. Depending on the output format of
the generated variable script data - a second process would translate
the strings used to the target language. Collisions or missing strings
would show up and have to be resolved by the author. The calling script
would then be hacked to load the proper variable data based on locale
and bada-bing! One script with variable translation data with the proper
data selected dynamically at run time.

There are some hitches with this approach to be fleshed out for sure but
I think it makes setting up for translation testing easier while
protecting against the high amount of runtime failures and additional
debug associated with the dynamic approach.

> 
> 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?
> 
> 

I think this would be quite useful.

Ed