Avoid automatic translation commits that don't contain translation changes

Asked by Alkis Georgopoulos

We configured our project to use launchpad for translations.
Our ldm.pot file is more than one year old:
> http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/files/head:/po/
> [View ldm.pot] ldm.pot 1394 2011-07-13 04:47:23 UTC 1.9K

Yet launchpad thinks it was changed yesterday, so it pushes new .po templates for it:
> http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/revision/1475#po/el.po
> 10 "POT-Creation-Date: 2013-01-27 04:33+0000\n"
> 10 "POT-Creation-Date: 2013-01-28 04:34+0000\n"

Could we somehow stop that from happening?

It's working fine in some other of our projects, like e.g. in

Question information

English Edit question
Launchpad itself Edit question
Jeroen T. Vermeulen Edit question
Last query:
Last reply:
JTV could you advise here please.
Revision history for this message
Jeroen T. Vermeulen (jtv) said :

This is an intltool project, right? I think what's happening is that your template is being updated automatically every time your codebase changes. An automatically-generated template is not written to your branch, but it is written to the database, and your PO files are being updated accordingly. It would be nice to be able to detect that the template is unchanged, and skip unnecessary updates, but it's been fairly low on our priority list.

Automatic template generation is rarely used and not well-advertised because we only did it for one type of project setup (recent intltool) and it has proven brittle in practice. But I do think it's a very nice feature. If I am correct, when you add or change a translatable string in the source code, the new string(s) will show up automatically in the translation UI!

In fact we wish we could make that the normal mode of operation, but it would be a lot of work: provide more visibility, suppress unnecessary updates, export the updates back to a translations export branch if any, and support more diverse project configurations... Adding that much complexity to an already complex system is not always worth what you get.

Revision history for this message
Alkis Georgopoulos (alkisg) said :

Thank you jtv, and sorry for the late reply,

The situation in http://bazaar.launchpad.net/~ltsp-upstream/ltsp/ldm-trunk/files/ was that we had a po/ldm.pot template in the source tree:

Upon building, intltool created a slightly differentl ldm.pot:

At the end of the build process, removed ldm.pot.

I tried to completely remove ldm.pot from the source tree, but launchpad keeps doing daily commits.

If we keep ldm.pot in the source tree,
and make intltool produce exactly the same ldm.pot,
then our problem will be solved?

Does launchpad ignore the .pot file date and maybe a few of its headers,
or does it need to be completely untouched from the previous times that launchpad saw it?

Finally, any hints on how to tell intltool to keep ldm.pot instead of erasing it?

Thanks a lot,

Revision history for this message
dobey (dobey) said :

For the record, intltool does not automatically update the .pot file. the intltool-update command only generates the pot file when it is told to. Generally this is done by running "make update-po" inside the po/ directory. If it happens only when you run "make check" in your source, then this may be the cause. The intltool Makefile.in.in requires the pot file to be able to run its checks. If the build system thinks the pot file is out of date for some reason, then the pot file will be regenerated.

Generally, files generated automatically during the build, should not be stored inside the VCS. This is true for the .pot file as well as config.guess, Makefile, and similarly generated files, when using intltool and autotools.

My understanding of why Launchpad commits translations back into a projects trunk, when it has been so enabled to do so, is that it happens daily, if any of the translations have changed on Launchpad. This means that if you are using Launchpad for translations, and someone translates a string in your project every day, then every following day there will be a commit of the .po files to the project tree. I agree it would be nice if Launchpad limited this to only the translations that actually changed, by I think it currently simply exports all translations, when this happens. This will result in all .po files being committed to the tree when a change happens.

I would recommend not storing the .pot file in the bzr tree. However, it seems to me that the .pot file being regenerated or not, is not directly related to your issue of having Launchpad commit translations to your tree. You can stop Launchpad form doing so, by reconfiguring usage of translations in Launchpad for your project.

Revision history for this message
Alkis Georgopoulos (alkisg) said :

Hi dobey, thank you for your comment,

in comment #2 I mentioned that we tried what you suggest and launchpad still did the usual daily translations commit, even though no new translation strings existed at all.

The specific launchpad commit was:

You can see there that only the launchpad export headers were changed in the .po files, and that at that point we didn't have ldm.pot in the bzr tree.

I think that launchpad should not commit .po files to the branch in that case, when nothing has changed.

Revision history for this message
dobey (dobey) said :

@Alkis, yes that is correct. As I stated, Launchpad committing translations to your tree isn't about the .pot file changing, but the translations on Launchpad being changed.

If you go to https://translations.launchpad.net/ltsp and click "View all languages" underneath the list of languages, you will see that some of them were changed yesterday, and thus would be the likely culprits for the commits Launchpad made to your branch today. I'm not sure of a quick/easy way to determine what actually changed in those translations that would have caused Launchpad to do the export and commit, but afaict, that is the reason why it was done.

By your own admission, the .pot file was not in the branch at the time, and thus the .pot file itself, nor intltool, could have been the reason for the export and commit, for revision 1532. I'm not sure what exactly the problem is (I don't have the privileges necessary to go poke at the db and logs directly), but it seems like intltool is totally unrelated to this issue. And it looks like this is a bug, but someone will have to examine the server logs and/or db, to confirm what exactly is causing the export.

Revision history for this message
Alkis Georgopoulos (alkisg) said :

Hi again dobey,

you were looking at the wrong page, there were no newly translated strings for any language yesterday in

Our ltsp project doesn't suffer from the launchpad "daily translations commits" issue,
while our ldm project (which uses intltool) does suffer.

Revision history for this message
dobey (dobey) said :

@Alkis, ah. But you'll notice on that page, it explicitly says the automatic synchronization is configured to export daily to lp:ltsp/ldm-trunk.

So clearly that is why it is exporting daily there. I'm not sure why the lp:ltsp export is behaving differently. But clearly this has nothing to do with the .pot file, nor with intltool. It however, does seem to likely be a bug in Launchpad itself.

Revision history for this message
William Grant (wgrant) said :

As discussed on IRC, it *is* to do with the POT changing. Launchpad autogenerates POTs for projects that use intltool. Alkis, did you have any luck with the intltool stuff we discussed yesterday?

Revision history for this message
dobey (dobey) said :

@wgrant OK. But the only two options to "solve" that in the project itself, are to a) not use intltool or b) not have Launchpad export translations automatically to the branch.

It seems that if Launchpad is both always generating a new pot file daily, *AND* using the fact that it changed as a reason to export translations, that is the problem. It needs to not export translations when it generates an "updated" template every night.

I also still highly recommend not including the .pot in the source tree in bzr, as it is automatically generated.

Can you help with this problem?

Provide an answer of your own, or ask Alkis Georgopoulos for more information if necessary.

To post a message you must log in.