Re: dogtail-devel i18n module proposal

[Ed Rousseau <rousseau redhat com>]

On Tue, 2005-10-18 at 19:05 -0400, David Malcolm wrote:
> On Tue, 2005-10-18 at 16:34 -0400, Ed Rousseau wrote:
> > On Thu, 2005-10-13 at 00:34 -0400, Dave Malcolm wrote:
> > > On Tue, 2005-10-11 at 17:27 +1000, Lawrence Lim wrote:
> 
> [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.
> 
> 
> Err.... haven't you just reinvented app maps?
> 
> /me runs....
> 
> 

Yes and no. In the case of translation you really *do* want a broken out
mapping. We want to encourage a data driven testing approach to cut down
on rework. This means generalized scripts that suck in specific data to
run. For the framework, writing the at-spi wrapper works because 1) We
know the boundaries and it works well enough, 2) A failure does not
necessarily mean a script needs to stop running and 3) In most cases in
the procedural API we know what we are looking for (a widget label
name). Tied with the additional maintenance needed for cross app
testing / system testing - I think my argument against an app map
approach is defensible. (Besides they give me a rash).

For translation / internationalization issues I don't see how an on the
fly approach will be the best way *at this time*. I do not trust the .mo
files enough (as well as the inversion questions) to have it be a run
time operation. I think the translation will need vetting by a human to
define the confusing cases or to work around untranslated strings
without killing the whole script. Having autotranslation work on a data
file that can be vetted and edited by a human seems the best way to get
a quicker solution up and running that will work pretty well.

Ed