Re: Fix in screenshot applet

[Christian Rose <menthos gnome org>]

lör 2004-03-06 klockan 18.53 skrev Luis Villa:
> > Not terribly visible (we can probably assume that many standalone
> > desktops won't have a ~/public_html/), and we're so late in the string
> > freeze it's almost string permafrost times. After 2.6.0 material, IMHO.
> > 
> > Please bring this up for discussion again after 2.6.0 and we can then
> > have a look at it again at that time.
> 
> This is a little weird to me; you're saying that it's better for it to
> be translated in zero languages than to be translated in !100% of the
> languages? I can understand not changing strings at this point so as not
> to throw away work that has already been done, but why block those
> translators who do want to do the work from doing it?

See
http://lists.gnome.org/archives/gnome-i18n/2004-February/msg00158.html.

Basically we want to limit all kinds of string additions and string
changes at this point, since there's no way for a translator to
technically distinguish between a message that in code occurs once every
seventh full moon, or one that will be plastered all over the desktop in
centimetre high bold block letters. They're all the same in the
translation status, which at this time should only be changing by
translators translating more of the existing messages, and nothing else.

Allowing all kinds of string change or string marking requests on the
grounds of "it's not a common message and if it's marked the few
translators who have the time can translate it" is a slippery slope.
Since our only forms of controlling the string freeze and the statuses
of the translations is by the statistics on the translation status
pages, it would soon become difficult for translators to keep track of
all the string freeze exceptions needing attention -- high priority
messages needing attention are undistinguishable from low priority
messages needing attention.

In the past there has been occasions where translators have missed some
important new messages needing attention because of a slew of
unimportant ones also being given the green light at the same freeze
times. We don't want that to happen, and hence it's IMHO better to
refuse unimportant or uncommon messages from being marked in the freeze,
so as to avoid a situation where important and very visible messages
that also need marking and translator attention would fall below the
radar.

In this specific case, I'm however still open to hear more motives for
why this is a very visible message and why it couldn't wait until after
2.6.0. That would be more useful than using the "marking it won't hurt
anyone" mantra; a mantra that completely fails to understand how
translators use the translation status pages for scheduling their work.
The translation status simply ain't Bugzilla with its many keywords and
fields for prioritization... ;-)


Christian