Re: dogtail-devel i18n module proposal

[David Malcolm <dmalcolm redhat com>]

On Wed, 2005-10-19 at 12:27 -0400, Ed Rousseau wrote:
> 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.
> 

Good answer.


A way of taking this forward might be to try coding up:
(i) the "find the mo files" approach based on package dependencies
approach I mentioned earlier in the thread
(ii) the "give me a list of all visible strings in an app" patch
and then:
(iii) see how well they correspond in real-world examples, and what
problems/issues would arise with the on-the-fly thing...


I'm currently more optimistic than you are about the on-the-fly
approach, so I guess the steps above would give us a better handle on
how optimistic we ought to be.  This might be because I'm looking at
this from more of a grey-box/white-box perspective (as a developer
looking to write regression tests for code I'm familiar with).


(I'd love to try this at some point, though I'm currently doomed with
other non-dogtail issues)