Created attachment 48704 [details] [review]
patch for intltool-merge.in.in, intltool.m4 and intltoolize.in

I attached the patch for .desktop and .directory.

Confirming this: yes, that's my plan, and thanks on working on it! I'll look it
in more detail later on.

We should also note that going this route we're actually making intltool-update
a system binary (i.e. it's not only a build utility which would be used when
building source code, but it must reside on a system which is going to get such
installable packages).

Or it should at least be inside a package, but I don't know if all package
formats would support that.

This seems like the wrong approach for doing this. Is just not merging
translations into the files, and putting the tranaslation domain in the file
instead, and then just using the gettext APIs to get the strings, really that
expensive? Surely execing perl and everything would be much more expensive.

I would highly prefer to avoid using intltool as anything other than a
build-time dependency of packages.

Created attachment 49167 [details] [review]
Obsolete of #48704

Fixed a typo.

The patch also can specify the translation domain with the argument instead of
putting it:

% env TEXTDOMAINDIR=/usr/share/locale ./intltool-merge -d -u gucharmap.desktop
-l ja_JP.UTF-8,fr_FR.UTF-8 --merge --domain gucharmap

Could you evaluate which direction may be acceptable?

I'm sorry for revising the example:

% env TEXTDOMAINDIR=/usr/share/locale ./intltool-merge -d -u gucharmap.desktop
-l ja_JP.UTF-8,fr_FR.UTF-8 --merge --domain gucharmap --tag Name,Comment

Do you have any updates? 
Do you mean the similar way is about to be made in intltoo-update instead of
intltool-merge? I don't understand that point.

I think to use gettext is a valid way to prioritize locale directories, e.g.
ja_JP.UTF-8 -> ja, /usr/lib/locale -> /usr/share/locale. gettext doesn't export
those logics likes libraries.

I'm saying, wouldn't it be better to have the panel, or whatever is reading the
.desktop files, to load the translation domain, and just do gettext (string)
instead? Merging things into the desktop files after they've been installed by
the packaging system makes it quite difficult for the packaging system to be able
to keep track of those files, as the file changes with every translation install
or removal.

Could you clarify what is better to merge things, you think? I don't understand
the point you're saying the just merging.

I thought three options and I'm pushing the third way in this bug.

Option 1. Change GNOME APIs.
 o Option 1 is to change GNOME libraries to use .mo files. 
   I omit the details because now we are talking about intltool.

Option 2. Update multilingual files with .po files durling the installation.
 o Option 2 is to use intltool during the installation and change multilingual
files dynamically.
 o Preparation:
   /usr/share/applications/hoo.desktop <---------+--+
   /usr/share/applications.in/hoo.desktop.in -->-+  |
   /usr/lib/bonobo/servers/hoo.server               |
   /usr/lib/bonobo/servers.in/hoo.server.in         |
   [...]                                            |
   /usr/share/po/de.po -->--------------------------+
   /usr/share/po/ja.po

Option 3. Update multilingual files with .mo files durling the installation
 o Option 3 is to modify intltool and use it to change multilingual files with
.mo files.

Option 1. Change GNOME APIs.
 o GOOD
   1. Don't mind 3rd party's integration into GNOME.
   2. Easily mantain and have the testings for UI messages because we can
concentrate .mo files and don't need to merge base files with our ones.
   3. Consist process between Sun and Community.
 o WRONG
   1. Community needs to accept the patches because we hardly maintail the
patches in Sun internally.
   2. Community don't mind to separate l10n contents if they want English
messages, they can configure the parameter LC_MESSAGES=C with the user level.
   3. For 1 of 6 multilingual files; i.e. .xml file, we need to convince each
maintainer because we don't have the standard APIs for .xml translation.
   4. YaST2 problem still there. [1]

[1] SuSE YaST2 doesn't use GNOME APIs so this solution cannot be applied.

Option 2. Update multilingual files with .po files
 o GOOD
   1. Community does not need to change anything.
   2. Easy implementation.
   3. Can implement for YaST2.
 o WRONG
   1. Installation time is one hour.
   2. Need to install l10n source files(.po). They are not necessary for users.
   3. Need to install base source files(.desktop.in). They are not necessary for
users.
   4. Separate Sun's supported 15 languages only by default. Other 72 languages
are included in multilingual files of base packages because of the installation
time.
   5. Possible installation bugs/problems and not a stable installation.
   6. When add any .desktop files after install our multilingual packages, it
will be English messages.
   7. Need to add new l10n packages to create multilingual files.

Option 3. Update multilingual files with .mo files
 o GOOD
   1. Acceptable installation time, 10 - 18 minutes.
   2. Community does not need to have big changes for the integration but
intltool only.
   3. Have the flexible options, i.e. Community accepts the patch, Sun base
build keeps the patch in the future or our l10n packages has the command specially.
   4. Have the stepped integrations after you give Go; ,desktop, .icon, .keys,
.server, .kbd, .shcemas and etc.
   5. Can implement for YaST2.
 o WRONG
   1. Still want to reduce the installation time as much as we can.
   2. Separate our supported 15 languages only by default. Other 72 languages
are included in multilingual files of base packages because of the installation
time.
   3. Possible installation bugs/problems and not a stable installation.
   4. When add any .desktop files after install our multilingual packages, it
will be English messages.
   5. Need to add new l10n package to create multilingual files.
   6. Need to confirm if the implementation does not break any specifications.

Yes, I agree it's quite difficult for the implementation but the main problem is
one; When our translation packages are added, we need the option to update the
multilingual files. Basically we install translation packages after all base
packages are installed so after we install the translation packages which
include .mo files, we will install one additional package in this option and the
package updates all multilingual files at the postinstall stage so the update
change is one time basically. At the moment, we need the option to udpate
multilingual files and we can consider the actual implementation for the
installation separetelly.

Using gettext() call on English strings is hard, since while it might work for
.desktop files, we also have .schemas (ok, this one is easy too), .xml,
.server,... files to worry about. XML is particularly hard, and we already have
the logic in intltool to do that for developers.

Takao: you summarise the situation quite well.

Now, I actually like the idea except for one thing. Instead of using command
line "gettext", it's quite simple to read the MO files themselves (parsing them
is easier), and put them in a translation cache. So, adding a single option to
use MO files for input instead of PO files would make the implementation much
easier (we would not need to worry about specific implementations for each of
the file types, since they already exist), and more likely to be adopted.  (MO
files are documented in GNU gettext manual: I have C#
[http://kvota.net/hacks/gettext-sharp/] and PHP [php-gettext] implementations,
Python has one itself since 2.2, etc.)

Basically, here are my recommendations:
- make "create_translations_database" read either PO files or MO files
- add options for reading different MO files (domain, domaindir/localedir,
languages)

With this, we might even be able to dump the PO parsing stuff from
intltool-merge, since we'd have .gmo files (MO files) in "po" subdirectory already.

Of course, the problem remains that "intltool-merge" would then have to be
installed on systems just for installing packages, but I guess that's a problem
we can live with since distributors wouldn't have to use it unless they want to
provide language packs.

Using po files seems excessive. It means that we then need to also install the
po files to the system, so that they can be used at runtime. I don't like that
option.

However, updating the files at runtime from either the po or mo files, means
that the contents of the file, and its md5sum will change. This would break
verification of those files by the package manager, as it would think that they
changed, and it would break the way patches against packages are created (only
including changed files), as the desktop file, or any translations of its
contents, may not have changed. The desktop file will be "different", but the
translations won't necessarily be, so it's easier to end up with mismatched
versions of things.

So, is there any particular reason that you just don't include all the
translations by default? I'm not aware of any Linux distributions that split the
translations out into different packages for each individual module. AFAIK, this
only really affects the Solaris packaging, no?

There are a lot more issues to consider, than just the fact that you want to do
something a certain way, because that's how it has always been done. As Danilo
stated, we have a lot more files than just desktop to worry about as well. I
don't understand what you mean by the YAST2 problem, either. Can you explain
what any of this has to do with YAST?

I would like a good solution to this problem as well, but I don't want to rush
into it, because you have something that works for Solaris. It needs to make
sense for everyone.

Just a note: Ubuntu also ships language packs (.deb's containing all MO files
for a single language), since only a dozen or so languages are included on the
first CD.

However, if one goes for the solution I proposed, we get more improvements such
as using MO files instead of PO files (why should we parse PO files in intltool,
when msgfmt has already done that for us, and even checked their integrity?),
and not too many complications in other code (basically, instead of any *_po_*
functions, we need corresponding funcs for MO files).

Also, regarding MD5 sum checking and similar: if distributor takes this
approach, the file installed is then .desktop.in (note the .in part), and
.desktop is generated from it and installed MO files. I'm not sure how package
management systems usually handle such situations (during "package configuration
step"?).

There is one big problem with this approach that I see.  Different software
sometimes uses different (even slightly incompatible, mostly due to bugs)
versions of intltool, and merging might give unpredictable results for software
not tested with version of intltool-update on the system.  Though, we can assume
that intltool is now CBF -- Completely Bug Free(tm), so we're probably ok :)

Created attachment 50735 [details] [review]
Use MO files to construct cache

Just for the kicks of it (and to prove how parsing MO files simplifies
intltool: look at how shorter new create_translation_database is :), I did what
I proposed.

This means that such intltool-update is able to read MO files correctly (it
currently reads all *.gmo and *.mo files in PO_DIR, which is not what we want,
but I'll explain below).

Basically, to get this to what Takao wants, all we need is to introduce
'domain' parameter, and inside gather_mo_files use a different glob (something
like "$PO_DIR/*/LC_MESSAGES/$DOMAIN.gmo").

But, we get support for all the existing merging formats without any further
changes.  What's else, it could be made optional (i.e. keep the current PO
parsing code, and use command line option to switch between the two), and the
size of this patch is increased only due to me renaming "po" functions and
variables in several places to "mo" variants.  Basically, only
"create_translations_database" is completely rewritten, and gathering function
is changed to look for MO files.

Also, I introduce a bug in that MO files encoded using something other than
UTF-8 are mishandled (this MUST be resolved before patch is even considered,
probably using ":encoding" pragma when opening and reading a file).

Danilo: I'll look at your patch, and go back through all these comments soon,
and think about it a little more. It'll take me a couple of days though, as I'm
currently very busy with other things. However, your last 2 comments have
sparked my interest in how this will interact with packaging systems, so I want
to think about that a little more, and see what the best way to do that is. :)

Great, Danilo for the implementation. 
I confirmed your patch works fine for the merging. I don't have C# compiler on
Solaris but I could understand why gettext is heavy.
I agree to switch mo and po is easy for the maintain and like the simple
implementation. 

However my concern is the installation time. If I could not use the $DOMAIN
names, probably I would need to copy/symlink the .mo files, e.g. 
# cp /usr/foo/locale/*/LC_MESSAGES/$DOMAIN.mo ../mo
# LC_ALL=C ./intltool-merge ../mo gcalctool.desktop.in gcalctool.desktop -d -u
I don't check actual time with this way, yet but I'm afraid the copy effects
time but I'm not sure.

How about exporting the environments parameres, $PO_DIR and $DOMAIN.gmo?
if ($PO_DIR == null) PO_DIR = ./po;
if ($DOMAIN == null) DOMAIN = *;
glob "$PO_DIR/$DOMAIN.gmo"

Yes, we know the md5sum will be different. It need to be considered however we
have the several references, e.g. scrollkeeper updates yelp files dynamically.

OK, let's try summaries for our problems.
As I noted at first, the main problem is semi-translations. Currently base
pacakges include multilingual files and our l10n packages include .mo files.
Installer provides the options for languages. If users don't install all
languages, unnessary .mo files are not installed but multilingual files are
always installed then GNOME desktop shows semi-translation. We need to provide
the options to update multilingual files. After the installation is completed,
if users want to unstall l10n packages, multilingual files also needs to be udpated.

Why do We Need to Separate Multilingual File
 o Users want to display English messages but use locale resources; i.e. Fonts,
input methods.
 o Provide the langues options in the installation for users
 o Reduce disk usage
 o Translation process for .desktop files of 3rd party's applications
 o Sun's packages are categorized [1]

[1] ${base-package}, ${base-package}-share, ${base-package}-root,
${base-pacakge}-devel, ${base-package}-l10nmessages-ja,
${base-pacakge}-l10ndocument-ja

YaST2 issue is the 3rd party's isssue, i.e. Our l10n team manages GNOME
translations. we can get .pot files from source tarballs but GNOME desktop
provides menus for all applications; Java, Mozilla, StarSuite and etc they have
the .desktop files but the translation process/companies are different. Then
once 3rd parties applications are integrated into GNOME desktop. it causes
semi-translations. Our l10n team cannot handle the problem so we need to send
translations for each teams/companies. So we need to update .destop files.

Then we need the option to update .desktop instead of .desktop.in. Could you
also think it?
I think the primary task is .desktop and .server files (and .schemas).

My original patch also provides the option to merge/unmerge translations of some
languges only but it would not be needed because as I checked the installation
time, I think the seeking time is cost in .desktop file which languages are
already inserted so I think it is faster to unmerge all languages and update all
languages. So could you also think to unmerge the translations?

Thanks much for your helps.

Takao, as I said above, patch is not complete, but it's now very easy to extend
to get what you want.  Yes, we'd need --domain option to provide us with
$DOMAIN, but we can use PO_DIR as a base for locale lookup.  We can then either
switch our glob search depending on whether $DOMAIN is defined, or we can
introduce another option like --use-global-translations which would do it.

Now, MO files will generally always be installed because they are needed for
other UI elements (there are some exceptions such as gnome applets
Locations.xml, but package management systems could install them if they found
it would benefit them).

So, controlling which languages are going to be merged into resulting .desktop,
.schemas, .xml, .server,... files is done through package management: whatever
MO files are there will be used.

I.e. imagine I installed language-pack-de for Nautilus. My system would then
have /usr/share/locale/de/LC_MESSAGES/nautilus.mo and
/usr/share/somepath.in/nautilus.desktop.in.  Now, when I install
language-pack-sr, it would provide /usr/share/locale/sr/LC_MESSAGES/nautilus.mo,
so when post-install in the language pack does
  intltool-update --domain=nautilus /usr/share/locale
/usr/share/somepath.in/nautilus.desktop.in /usr/share/applications/nautilus.desktop
resulting nautilus.desktop would contain BOTH de and sr translations. If I later
remove language-pack-de, "post-uninstall" in it would have to run the same
command, and nautilus.desktop would be left with only an "sr" translation.

What else do you need "demerging" for?

Of course, this is not yet implemented in the above patch (I was just lazy to
add another option, and you've already did that in your patch, so they could be
combined).  If you want to test this without adding another option, just
hard-code "$PO_DIR/*/LC_MESSAGES/yourdomain.mo" inside a gather_mo_files.

This is simple, and lets packagers handle all the work (where to install .in
files, make it possible to have only a select set of languages, etc.), thus also
being very flexible, yet not affecting intltool in major ways (i.e. we don't
have to maintain a lot more code).

Danilo,

OK, I see your point.
My suggested fix uses .desktop instead of .desktop.in because I hardly expect
the install path of .desktop.in. Normally our l10n process does not need to
build tarball. To get .pot file is to extract the tarball and just invoke
'intltool-update --pot'. But to get the install path, we need autoconf/automake
at least and probably 'make install'.

1. Many hard coded implementations.
I could get all *.in files from base tarballs but the installation path is not
clear. Actually I tried to create the parser for Makefile.am but failed because
the installation path is not determined by one Makefile.am. e.g. $datadir is
determined by other Makefile.am, configure.in and .spec files.
so I got the installation path from 'rpm -qlp *.rpm' and pkgmap of packages but
I needed to get *.in from base tarballs. e.g. the translations of .schemas.in.

2. Cannot expect the installed extensions from *.in files.
e.g. gedit has *.gedit-plugins file and the *.in file is .desktop file. The
similar implementations are in evolution, gnome-applet, gok and etc. It is
possible to be failed installation.

3. Hardly convert *.in.in to *.in files.
e.g. *.server.in.in files include @LIBEXEC@ parameter and it is determined by
.spec file or Makefile.am

4. Cannot expect which multilingual files are installed.
e.g. Evolution and *LDAP*.server and *NoLDAP*.server and it is determined by
--enable-ldap or --disable-ldap of .spec file. It means even if I identified the
files, it is possible to be changed.

What do you think?
I think the option to treat .desktop is good.

> 1. Many hard coded implementations.
This doesn't really matter. At the point where you want to merge languages into
the desktop files, the files are all already installed to the filesystem. Surely
the postinstall script knows where the files in the packages are. It better,
anyway, or you have other problems.

> 2. Cannot expect the installed extensions from *.in files
These aren't really much of an issue either. The intltool-update command will
take the input and output files, which can have different extensions anyway. It
doesn't just automagically strip the .in. It may seem that way under normal
conditions though, as the Makefile rule is something like %.desktop:
%.desktop.in: foo.

> 3. Hardly convert *.in.in to *.in files.
We don't need to worry about this at all. The transition from .in.in to .in is
done at build time by the project's makefiles and as previously stated, the
necessary files to do the merging will already be installed.

> 4. Cannot expect which multilingual files are installed.
Again, this is not a problem. The merging is done by the postinstall scripts of
the locale-specific packages. If you don't know what options you are building
the software you are packaging with, in the packages you are building, then
perhaps there are other issues in the release engineering process that need to
be dealt with.

The feature you are requesting is specifically for distributors like Sun,
FreeBSD, Debian, Novell, etc... The only major concern is how to deal with
everything in such a way that it works for all of those distributors, and also
does not break building from tarball and just doing "make install" without a
DESTDIR specified, but then again, we should be able to handle that easily. The
gconf and scrollkeeper stuff has --disable-foo options to configure with to
disable the postinstall stuff, for installing to a DESTDIR. And, we will need to
know which tags are marked for translation anyway, which is in the .in files,
and not the .desktop file.

Yeah, I agree with Rodney: in any decent package management system, you'd
already "know" all these things or you wouldn't have usable packages at all.

Also, there are some cases where "de-merging" is simply not possible or is
unpredictable (such as .xml files), and we simply can't use that.

This approach is simpler, imposes nothing on the packager (they can choose their
own paths for everything--you can even NOT install .in files if you put them in
language packs, but this is really up to the packager to choose: I'm just
throwing ideas out), works for all the files intltool-merge supports otherwise,
and doesn't make a guarantee that it will do what it can't.

Sorry for the late response.
To be honest, I'm convinced your mentions. Yes, you are right.

But my concerns are painful because we want the simple build environment to get
the install pathes.

But your suggestion is really simpler for intltool. Could you start to the
implementation?

However I still hope some workarounds without .desktop.in :). e.g. to have --tag
option 'Name', 'Comment'.

Thanks.

Well, implementation is almost done, I just need to get around to polishing it
for inclusion (changes for adding --domain parameter are really trivial ones :).

As for --tag and .desktop files, I really, really wonder why do you care so much
about just the .desktop files?  Half of the other GUI elements would be
untranslated (GOK has half of the UI in .xml files generated by intltool, XML
files are used for display all over the desktop, .schemas would be untranslated,
etc.).  Besides, if you really want just a .desktop translation merger, I can
hack one up in Python in no time: it doesn't have to be in intltool at all (and
it would be even simpler if it wasn't).

I certainly don't want to make intltool work for .desktop files in any way
different from other files (since that might encourage packagers to take a
shortcut and only ship localised .desktop files, while the other not-so-visible
UI elements might end up untranslated ;).

In case of miscommunication, I don't want to treat .destop only but also .xml,
.schemas and etc without .xml.in, .schemas.in and *.in. From above reasons, I
hardly associate installed files; hoo.desktop, .xml with build sources;
hoohoo.desktop.in, .xml.in, .xml.in.in. I think we need to hardcode some file
associations or create a parser for Makefile.am/configure.in/.spec.
I also think it is not a good point to install build source *.in files.

The solution is to update all multilingual files on the installed image but not
on build sources.

How about the workaround is --tag for .desktop, .xml, .server, .kbd?
Yes, .schemas is the exception to need .schemas.in but my understanding is most
files can be specified the translation tags.

Any suggestions are appreciate.

No. The .in files will be installed. The final files will be generated from
those. The --tag is not needed. Everything will already be marked for
translation. I don't see any reason to have to implement that in two completely
different ways. If you want to do this, then the .in files are no longer
sources, but instead, the resulting installed files, that will generate the
final desktop, schemas, etc... files. I think schemas might just be better to
split out into multiple files, rather than merging in. Then the packages can
just contain gnome-terminal-he_IL.schemas for example, and can just update the
gconf schemas when that package is removed. It seems much simpler than having to
merge/unmerge and install/remove the entire set of schemas for an app, every
time a language is added or removed. I don't think it makes sense for us to be
modifying files that are owned by the package directly.

Takao: it's almost impossible to do for .xml.in files.  Well, maybe not
impossible, but very hard.  There are cases where you can't tell what is
actually localised, and what should be treated as original string in .xml file
(I implemented parsing, and we've gone through tens if not hundreds of corner
cases which lead to inconsistent and buggy behaviour when we KNEW what
tags/attributes we want extracted [they start with "_"]: it's much harder when
we don't know which are those but need to detect them).

Rodney: how are .schemas going to be installed is really up to the packager, and
we shouldn't enforce any policy, IMO. We can offer both options in a very simple
manner, so I guess we need not worry about it as long as both are possible.

As for installing .in files, we don't need them in default installs unless we
start fully supporting ALL_LINGUAS variable in intltool as well (we don't
respect it for merging, though only respective .mo files are installed: this
comes from gettext support): they will be installed by software packages (or, as
I said, they can be included in language packs: it's really up to packagers to
choose).

Thanks very much for the suggestions. I could understand .xml.in is very hard.
I almost agreed with your suggestions but please give me time a little.

I would like to think how to get the install pathes. One idea is to change
intltool.m4 internally, e.g. "INTLTOOL_DESKTOP_RULE='%.desktop: %.desktop.in cp
$< [$]@'" and .spec file renames those files, e.g. "mv %_datadir %{_datadir}.in".

I'll reply this asap.

So. We cannot change the intltool makefile rules to just copy the .desktop.in
file to .desktop, and have spec files rename those back. This has to work for
source installs as well, not only for RPM.

What we would need to do for source, is just automatically merge everything
during "make install", if DESTDIR is set, or possible if --disable-i18n-merge or
something was passed to the configure script, if we want to allow that as well.

Apologize for the long dispatching.
I put some queries to internal staffs but I could not get proper agreements.
One reason is when we do upgrade installations, it causes several problems by the implementation to update translation contents during installations.
Another reason is since some of our staffs are changed the responsibilities, the discussion is delayed.

So at this moment, could you close this bug?
If necessary, I'll reopen this bug again in the future.

I'm very sorry for the troubles.

I see no reason to close the bug. It is a general problem that we need to solve. I will lower the severity though, to Enhancement. I wish to keep the bug open though. And I will retitle to reflect that we need to do it for more than just .desktop files.

Agreed: and I think the patch is a pretty good step towards that goal.  I plan to pick it up soon enough (basically, the boring bits are left over: deciding what command line parameters to use, implementing them and deciding on where to put .in files [though, we can also leave this to packagers, but then it wouldn't work for source installs; not that it made too much sense, since you'd have all PO files in source installs, so we'd just need to support ALL_LINGUAS variable instead).

Created attachment 80386 [details]
Another solution: update .desktop files without .desktop.in

I've thought another solution. i.e. it's to prepare the binary by multilingual files; .desktop, .xml, .schemas, .server, .scm, .kbd and etc.

I prepared .desktop part at the moment.
I'ld like to get your feedbacks. Thanks.

To use attachment:
% cc gnome-update-desktop.c -o gnome-update-desktop `pkg-config --libs --cflags glib-2.0`
% mv gnome-update-desktop.conf /usr/share/gnome-update-desktop
% ./gnome-update-desktop --help
% ./gnome-update-desktop -o a.desktop /usr/share/applications/gedit.desktop
% mkdir test
% ./gnome-update-desktop -O test /usr/share/applications/*.desktop

As this is a binary file, the performance is very very good.
I think we need a sysadmin tool instead of a build tool, i.e. don't have to install .po files and .desktop.in files.

If I use the original solution; enhanced intltool-update, the installation time takes four hours.
If I use this another solution, the installation time takes 30 seconds.

How about starting a new project? or adding the tool in the existent projects? e.g. desktop-file-utils @ freedesktop.org

Created attachment 80387 [details]
gnome-update-desktop.conf for #80386

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.