Re: gnome-applets string freeze breakage

[Christian Rose <menthos gnome org>]

fre 2005-04-01 klockan 03:18 +0800 skrev Davyd Madeley:
> > > The priority of this string is very
> > > low (ie. you should never see it), it was added because in the
> > > current tree it would simply fail silently. We were also in a rush
> > > to get it backported and to try and get some testing before next
> > > week's release.
> > 
> > What I don't understand is why this fix (the added error message) is
> > considered important enough to be in the same patch as the memory leak
> > and location name i18n fixes.
> > If this error message is not at all important, then why is it in the
> > same patch with a lot of crucial fixes? It appears that this situation
> > would have been more manageable if the fixes were seperated into several
> > patches that could have been prioritized differently. To me, it seems
> > like the only reason this added error message was backported at all was
> > because it happened to be in the same patch.
> 
> It shouldn't have been backported. I should have noticed it when I
> approved the backport. However I didn't, basically because I suck.

Ok, don't worry. We all make mistakes. I'm more concerned with people
who commit unapproved stuff although they already know at that time that
they will be breaking freezes. That's what really worrying me.


> > > If this is unacceptable, then we will remove the string. However, I
> > > hope that you can see why we think this patch is in fact quite
> > > important, and that you have pity on us for only being mortal.
> > 
> > I'm sorry, but I haven't been convinced that this added error message is
> > essential to have in the gnome-2-10 branch. I certainly understand and
> > share your opinion about the other fixes in the patch; the memory leak
> > fixes and the translated names fixes. Those do indeed fix important bugs
> > and can be classified as essential.
> 
> Without wanting to tell the translators how to do their job. I don't
> see how having the string marked for translation is necessarily a
> bad thing. The string is not likely to ever be user visible, but if
> translators want they can translate it. Hence, the only thing it
> will affect is people's 100% ratings. Without being in on the
> culture, is this an issue?

The problem is that translators don't have any reliable way to
prioritize messages or otherwise classify them, other than prioritizing
on a module level. Either a message is marked for translation and in the
pool, or it is not. There's no inbetween. All messages end up in the
pool that is "the messages for module foo" or the superset "the messages
for GNOME 2.x". Translators deal with these (large) pools by counting
the messages in them, and keeping track of this status. Counting is the
only way to know.
There's simply no good way to know how "important" any message is or how
visible it will be to end users, without actually having to examine the
message, carefully inspecting the code using it, or asking the
developers who produced the message. But even then, the best you can do
is only to make a mental note about it -- the tools cannot prioritize
the messages for you. Either the message is there, or it's not.

As a consequence of this, the only way to be sure you have translated
all important messages, is to have translated *all* messages. If you
know you're at 100%, you can sleep well; otherwise, you don't really
know what important messages are there in the remaining percentage that
you haven't had the time to translate yet.

That's why we have string freeze. It's not because developers and
maintainers in the past always did add big and important translateable
messages that would get shown in big capital letters on the desktops of
all users on the day before release day. No, most developers, even back
in those days, realized that that would be a bad® thing to do.

It was because every now and then in the weeks and days before and after
the actual release, dozens of developers and maintainers would think
that adding one or two or maybe ten harmless messages, that would only
get shown to the user every other Sunday that had a full moon, would be
no big thing. So they did that. As a consequence, translators were
continuosly swamped with a never-ending stream of "harmless" messages
even at release times.

The problem was that, every now and then, some few developers would add
even important messages at those times. Those message additions would
naturally go undetected among the "not harmless" ones. If I as a
translator would know (and be able to remember) that I had 146
untranslated messages yesterday, how would I know that if today's count
is 147, that this added message is important or not important? The
answer is "I don't", that is, without taking the time to inspect the
message, but then I have to spend almost as much time as I would have in
order to translate the message in the first place.

Heck, the count of untranslated messages can even *remain the same*, and
there be still danger. If a developer removes a message, but he (or
another developer) adds another, important, message, then the count
remains the same, and translators with untranslated messages wouldn't
know. Only the translator who previously had 100.00% translated messages
would be able to reliably detect such a thing.

The only way to resolve this and make it manageable for translators is
to restrict *all* message additions or message changes that affect the
message counts, even additions that may in themselves seem harmless
enough. By doing that, the translators who are luckily enough to be at
100.00 percent can rest assured that they are actually on top of things,
and that things aren't going out of control.

I hope this clarifies the situation a bit -- translators usually aren't
the number-fixated, statistics-obsessed, unreasonable string-freeze-
shouting anal retentive bastards they appear to be -- they simply just
want control over their situation, a situation that has been shown to
quickly get out of control otherwise.


Christian