Re: GTK+ string addition

[Christian Neumair <chris gnome-de org>]

Am So, den 29.02.2004 schrieb (null) um 22:05 Uhr +139083320:

> Ar 29/02/2004 am 16:42, ysgrifennodd Owen Taylor:
> > Sorry folks, another GTK+ string addition:
> > 
> > Sun Feb 29 16:35:23 2004  Owen Taylor  <otaylor@redhat.com>
> >  
> >         * gtk/gtktextview.c: Add a error-underline-color style
> >         property.
> > 
> > Added two strings related to wavy-red underlines for spelling/etc.
> > 
> >   P_("Error underline color"),
> >   P_("Color with which to draw error-indication underlines"),
> >                                                                
> > It's a po-properties string, so not user visible except for 
> > GUI builders.
> 
> Given that we've taken the step of splitting up GTK's strings into the
> "gtk+" and the "gtk+-properties" domains, would it be appropriate to
> move the "gtk+-properties" into the "extras" section? My understanding
> is that those strings are not generally user-visible, which suggests to me
> that they should not be counted as part of the core GNOME desktop.

In my opinion they still belong to developer-libs and therefore to the
core developer platform since they are distributed with GTK+, even if
this doesn't affect the desktop at all. We can't simply seperate gettext
domains out from packages they belong to.

> Given gtk+-properties strings' status, what should the freeze policy be
> for those strings? The same as the rest of GTK? Or should
> gtk+-properties be treated more liberally?

Nope, string freezes are valid for all core modules, not only domains of
translators' interest. Separating out these strings into a separate was
an accommodation for translators to reflect the strings' priority. If we
loosed those ties, we'd end up having GConf strings and friends
scattered around over various domains.

regs,
 Chris