Re: request for freeze breakage - gok

[Bill Haneman <Bill Haneman Sun COM>]

On Wed, 2004-09-08 at 21:51, Christian Rose wrote:
> ons 2004-09-08 klockan 13.51 skrev Bill Haneman:
> > On Wed, 2004-09-08 at 12:34, Murray Cumming wrote:
> > > > module: gok
> > > > maintainers: David Bolter, Bill Haneman
> > > > bug: http://bugzilla.gnome.org/show_bug.cgi?id=152086
> > > > patch: http://bugzilla.gnome.org/attachment.cgi?id=31390&action=view
> > > >
> > > > We've discovered that our gok-with-references.schemas.m4 file is busted.
> > > >
> > > > This doesn't matter for a casual install from tarball or cvs, but
> > > > matters if a developer or translator decides to update the schemas.in
> > > > file (as per the somewhat buried directions) however it means that 17
> > > > strings are erroneously going unmarked; fixing the m4 file will cause
> > > > the strings to become marked.
> > > 
> > > What will the user experience in this case? Or, what does the bug look
> > > like in practice?
> > 
> > 1) User who does 'make install': no build impact, but 17 strings go
> > untranslated for end users.
> > 
> > 2) User/maintainer who manually runs m4 (as documented in
> > gok-with-references.schemas.in): build breakage and/or runtime breakage
> > after manually regenerating the .schemas.in file.: GOK won't run
> > afterwards.
> > 
> > #2 is not a common case; by that logic, fixing the macro is both
> > low-risk and low-urgency.  But since it's a build-ish scenario, we
> > thought release-team should be informed of the issue.
> > 
> > Personally I think there's no harm in fixing the macro, since in
> > scenario #1 the change to the macro will have no effect, since the
> > patched file isn't touched at all, and in scenario #2 we go from 'very
> > broken' to 'missing a few translations'.
> 
> How visible are these untranslated strings?
> 
> If they're not very visible, I think I'd lend against punting it for now
> (2.8.0) and revisiting the issue for GNOME 2.8.1, since it's quite a lot
> of messages for being this late in the game.

I am not sure I follow you here.  What we've requested, and gotten
approval for, in 2.8.0, is to fix the m4 macro.  Only a distro or hacker
would ever notice, plain "make install" is unaffected.  This course of
action leaves 17 not-terribly-visible strings untranslated.

The strings affected appear as values in dropdown lists in the GOK
settings dialog, in the 'Feedbacks' and 'Actions' notebook pages.  They
are rather redundant, at that:

"Switch 1" 
"Switch 2" etc. through "Switch 5", then "Left Mouse Button", 
"Right Mouse Button", "Middle Mouse Button", "Mouse Button 4" and
"Mouse Button 5", etc.

so the translation effort is probably not big.  But it would mess with
the translation stats for folks who are aiming for "100%" if we make a
point of marking the strings now.

Our proposal wouldn't mark the strings for "make install", the strings
would only get marked as part of a manual m4 re-generation of
gok-with-references.schemas.in from gok-with-references.schemas.m4.
So there would actually be no translation impact for anyone other than a
distro or hacker who chose to manually re-gen, until we ourselves re-gen
the .schemas.in file and commit the change back to CVS.

Our suggestion is:

1) fix the macro now, but leave the old .schemas.in version in CVS; this
would keep the strings un marked in the tarballs.

2) re-gen the .schemas.in file from the fixed m4 macro *after* 2.8.0, so
that the new strings appear in plenty of time to translate for 2.8.1.

#2 violates string freeze, so of course we could not do this in the
gnome-2-8 branch without approval from the i18n team :-)

regards,

- Bill


> 
> 
> Christian
>