Please don't file separate bugs, one big one with all problems of the
same kind will do.

Note that the string mentioned is not a user visible string. I've
never really understood why we have to mark these strings (blurbs of
properties) as translatable. Maybe it's because of glade. But I am not
really sure.

Anyway, I will pester jrb to get him to make up a nicer string (: (my
second attempt at this string would prolly fail too :)

I think in general:

 - If the string is inherently unclear, it should be fixed
 - If the string involves technical terms that are hard
   to understand for translators, comments next to the
   property are generally wrong, since the same term
   might be used in many, many places.
 - Maybe we need a 'docs/glossary-for-translators' where
   we can provide detailed explanations of some of the
   hard terms that occur in property strings.

I've wanted for a long time to split GTK+ translated strings
into two domains:

 - One for user visible strings
 - One for developer strings

To allow translators to first translate the user visible
strings and get GNOME working, then worry later about
GUI builders.

So, you have say _() and D_(). But that would be a huge
amount of work, so we'd have to find a volunteer.

And, actuallyl, I would generally prefer separate bugs unless
the problem is clearly the same for multiple strings. Bug
reports with multiple issues in them get really hard to deal
with.

I'm putting this bug on the 2.4.0 milestone, but I don't
have a good sense of what the concrete action is here, so
that may not be appropriate.

Owen, why do we need two domains to mark strings as user-visible vs. 
developer-visible ? Wouldn't it be enough to develop a convention for 
putting a standardized comment next to the string, e.g. /*GUI*/ for 


user-visible strings, and have xgettext extract those to the .pot file 
?




I guess marking only the user-visible strings would be less work, 
since most of our strings are just error messages, right ?

Regarding that glossary idea, I don't think we need to hide it in some 
cryptic text file in docs/. Why not simply add a glossary to the api 
reference ? most of the the technical terms which are problematic in 
translations probably also occur in the api reference...

Actually, you're right, it would be very useful to have
a glossary in the GTK+ API reference explaining "mnmenonic"
"model column", etc.

My thought was that perhaps translators needed *more* 
explanation that GTK+ developers, but on second thought,
that's not really a sustainable idea.

The reason for having two domains is largely so that
automated statistics can show:

 GTK+ UI strings: 100%
 GTK+ property documntation: 13%

Rather than the combined number. It is also, I think,
a lot easier for translators to just go through and 
translate all 100 strings in one file, then to worry
about going through 1100 strings looking for comments
/* GUI */.

Here is the beginning of a perl script to replace _() by P_() 


(and Q_() by QP_()) only within g_param_spec_* (). It doesn't try to 


be very clever, but it may already be good enough to sort out the GTK+ 
strings.




my $replace = 0;




while (<>) {


    if (!$replace) {


	if (m/g_param_spec_[a-z]*\s*\(/) {


	    $replace = 1;


	}


    }


    if ($replace) {


	$_ =~ s/_\(/P_\(/g;


    }


    if ($replace) {


	if (m/\)\);\s*$/) {


	    $replace = 0;


	}


    }




    print $_;


}

I've done the first half of this now; property blurbs and nicks are
marked with P_() instead of _() now. I have adjusted the xgettext
invokation in po/Makefile.in.in to also look for P_. 

Remaining to be done: 

- set up a po-properties directory
- adjust the definitions of P_() in gtkintl.h gdkintl.h and
gdk-pixbuf-18n.h to use a different domain
- adjust the xgettext invokations in po and po-properties so that
_() goes to po, P_() goes to po-properties
- split the existing po files
- inform gnome-i18n@gnome.org

Ok, split the the translation domain now. The property nicks and
blurbs are now in the po-properties directory in the gtk20-properties
domain.
I've filed bug 131808 to track the glossary issue. 

It seems this change doesn't play nicely with intltool, which is a
major problem from the translator side of things. It seems the pot
file name used by intltool-update won't be the correct one in
po-properties, and nor will the messages be.

intltool-update has a --gettext-package argument to tell it the name
of the pot file. And what business has intltool updating the messages
? Thats the job of the xgettext invoking rule in po-properties/Makefile,
isn't it ?

Translators use intltool and so does the translation status pages. If
it doesn't work with intltool, that needs to be fixed.

Danilo has hopefully fixed this now.