Re: dogtail-devel i18n module proposal

[David Malcolm <dmalcolm redhat com>]

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


[snip]