Re: gtk+ translation domain split done

[Matthias Clasen <maclas gmx de>]

On So, 2004-01-18 at 21:16 +0800, Abel Cheung wrote:
> On 2004-01-17(Sat) 23:46:20 +0100, Matthias Clasen wrote:
> > I've committed my changes now.
> > 
> > The .po files in gtk+/po are reduced to 1/3 of their previous size.
> > Please notice the new .po files in gtk+/po-properties.
> > 
> > I tried to be careful, but please tell me if something breaks due to
> > this split.
> 
> Is P_() used anywhere other than gtk+? If it's so perhaps it may be
> worthy to let intltool-update aware of P_() macros too. Is the attached
> patch enough?

Hmm, I've looked at the translator documentation and what intltool-
update does a bit more, and your patch won't help for GTK+'s 
po-properties. The problem is that we explicitly don't want to have
_() and N_() marked strings in po-properties, and we don't want to have
P_() marked strings in po. So if you make intltool collect P_() and
translators use intltool for both po and po-properties, we'll get the
same strings in both directories, which is wrong. Intltool would have to
be made clever enough to pick up the xgettext args from Makefile.in (and
it should also pick up the GETTEXT_PACKAGE from there...)

If intltool can't be made clever enough, then translators have to be
clever enough to use xgettext directly for po-properties (shouldn't be
too hard: 
  xgettext --files-from=po-properties/POTFILES.in \
           --output=po-properties/gtk20-properties.pot
)

Either way, making intltool collect P_() would be harmful, since it
would interfere with the desire to *not* include P_() marked strings in
po. As things stand, intltool has problems for po-properties, but works
for po. Making it collect P_() would make it useless for both.

Matthias