I don't think there is currently any way to know if something has been merged back in or not, and whether or not it may be used from source. Some applications extract strings for translation from XML, but do not merge them back, instead parsing the XML and then translating strings with gettext () internally when necessary.

I don't think msgcomm can really help with this. It's usefulness seems to be related to reducing duplicate messages in translations, for example, pt and pt_BR.

However, it would be nice if this reduction were somehow possible, so I'll confirm and set it to a low priority enhancement.

you should be able to something like the following:

1) create a po including the xml and schemas and similar sources

2) create a pot file not including them

3) do a msgcomm --more-than=1

Here is how to do this, assuming you have your POTFILES.in list split into two parts: POTFILES.strip, which contains xml files, schemas files and anything else where the translations get merged back and don't have to land in the .mo, and
POTFILES.keep for everything which needs to land in .mo

Then you create a pot file from the .keep list:

mv POTFILES.in POTFILES.in.orig
mv POTFILES.keep POTFILES.in
intltool-update --pot > keep.pot
mv POTFILES.in.orig POTFILES.in

And when generating .mo files, you merge the .po with keep.pot:

msgmerge foo.po keep.pot > foo.po.keep
msgfmt -o foo.mo foo.po.keep

Here is the hack I did in our evolution spec file for now:

# strip unneeded translations from .mo files
cd po
grep -v ".*[.]desktop[.]in[.]in$\|.*[.]server[.]in[.]in$\|.*[.]schemas[.]in$"
POTFILES.in > POTFILES.keep
mv POTFILES.keep POTFILES.in
intltool-update --pot
for p in *.po; do
  msgmerge $p evolution-2.24.pot > $p.out
  msgfmt -o `basename $p .po`.gmo $p.out
done

And just to give an idea of the amount of savings that can be had this way: the evo rpm shrinks by ~10%, from 41M to 37M

Note that this call:
  msgmerge $p evolution-2.24.pot > $p.out
will update the "POT-Creation-Date" part of the pot file, so it should be saved from the original file, and restored, to avoid multilib conflicts (eg. files would be different because of the different time of the build).

Also worth pointing out that bug 568845 is about going the other way, ie keeping the schema translations in .po files, and instead stripping them out of schemas and gconf databases.

I think removing translations from the multi-lingual files(.desktop, .schemas..) can reduce the more sizes than removing translations from the mo files.

Also if we keep the translations in the multilingual files, the UI messages are not handled by LC_MESSAGES.
e.g.
% env LC_CTYPE=ja_JP.UTF-8 LC_MESSAGES=en_US.UTF-8 foo

Applications are expected UI messages are English but the collations are localized with the above example.

Currently we use intltool to merge the translations to the multilingual files but there is no tool to demerge the translations from the multilingual files.
If we use the translations from .mo files, it's easy to remove .mo files.
Ideally it would be great if both this way and bug 569829 could be handled.

intltool has switched from the GNOME to the launchpad.net infrastructure nearly three years ago: https://mail.gnome.org/archives/gnome-i18n/2009-April/msg00275.html
The intltool product in bugzilla.gnome.org has been deprecated and closed for new bug entry since April 2009.

I am now closing all remaining open reports about intltool as NOTGNOME as part of GNOME Bugzilla Housekeeping.

Reporter: If the problem that you reported here is still valid in a recent version of intltool we kindly ask you to report it again to https://bugs.launchpad.net/intltool/ so the intltool developers get notified about it.