Automatic translations update sometimes exports useless .po files

Bug #515051 reported by Emilien Klein
10
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Launchpad itself
Triaged
High
Unassigned

Bug Description

Imagine a project that is being translated and that has automatic updates set. The translator translates X number of strings. The following night, his strings are successfully exported to the specified bzr branch. But sometimes (and only sometimes), the next day another export will occur, but with no useful changed information, as the only modifications are the metadata lines "PO-Revision-Date" and "X-Launchpad-Export-Date".

Here are several examples:
http://bazaar.launchpad.net/~itt-devs/issuetrackertracker/main/revision/197
http://bazaar.launchpad.net/~itt-devs/issuetrackertracker/main/revision/196 (for cs and it, note that for cs "Last-Translator" also gets modified while I never modified a string in cs, maybe another bug or reason for this new export?)
http://bazaar.launchpad.net/~itt-devs/issuetrackertracker/main/revision/190 (fr)
http://bazaar.launchpad.net/~bashareteam/bashare/main/revision/124 (cs)

I suspect there might be something odd going on in the code that detects changed translations (related to bug #407590 ?). Or might it be that the dates get updated after the first export, and that on the next run it thus appears as if there occurred a new change after the last export?

Looking at rev 196 and 197 of issuetrackertracker (first 2 examples), you will see that:
rev 196 occurs at 2010-01-30 04:44:12
rev 197 sets "PO-Revision-Date: 2010-01-30 05:46+0000", which is indeed after the last export.

Why is this revision date later? Would it be related to an automatic import, that would have taken place 1 hour after the template being exported to the branch in rev 196?

Revision history for this message
Emilien Klein (emilien-klein) wrote :

After re-reading my bug description, I kind of have the feeling that it could be related to the automatic imports that happen after each commit...

Revision history for this message
Emilien Klein (emilien-klein) wrote :
Revision history for this message
Emilien Klein (emilien-klein) wrote :
Revision history for this message
Emilien Klein (emilien-klein) wrote :
Revision history for this message
Данило Шеган (danilo) wrote :

I believe it only happens because of bug 362848. Are there any cases where Last-Translator doesn't get updated as well?

(FWIW, it gets updated because actual last translator has chosen to hide their email address; I've described how it needs to be fixed in a comment #3 on above bug)

Revision history for this message
Emilien Klein (emilien-klein) wrote :

Examples of commits where the Last-Translator doesn't get updated (from the list already in the previous comments):

- http://bazaar.launchpad.net/~itt-devs/issuetrackertracker/main/revision/204
- http://bazaar.launchpad.net/~itt-devs/issuetrackertracker/main/revision/201
- http://bazaar.launchpad.net/~itt-devs/issuetrackertracker/main/revision/196 (for italian)
- http://bazaar.launchpad.net/~itt-devs/issuetrackertracker/main/revision/197

I don't agree with the status of duplicate, bug 362848 is about translators that have chosen to not to publish their email address, this is about Rosetta exports that are unnecessary because they only change date values (like "PO-Revision-Date" and "X-Launchpad-Export-Date"). As I stated in my first comment, "I kind of have the feeling that it could be related to the automatic imports that happen after each commit..." Данило, have you thought about this possibility?

Please remove the duplicate status, unless you really believe it is.

Revision history for this message
Данило Шеган (danilo) wrote :

Indeed, it's not a duplicate. I am looking into why it's happening.

tags: added: code-integration
Changed in rosetta:
status: New → Triaged
importance: Undecided → High
Revision history for this message
Данило Шеган (danilo) wrote :

Our code to detect when no update is needed is in a big need of improvement for the case where the same branch is used for import and export.

It gets out of the loop if it all runs at about the same time every day (which it usually does), but with r203 it finally exported and committed a translation only at ~1700UTC (instead of around ~0500UTC). Such delay probably happens from time to time with some of our processes putting more load on the database lately.

Still, it should be fixed not to depend on the time it ends up finally running and the time of the last commit in this way.

Revision history for this message
Данило Шеган (danilo) wrote :

Probably the simplest solution to this problem is to not update PO file header and date_changed unless at least one translation has changed as well.

Revision history for this message
Данило Шеган (danilo) wrote :

This is either a duplicate of bug 490668 or the other way around.

Revision history for this message
Emilien Klein (emilien-klein) wrote :

Yeah, the 2 bugs might well be describing the same problem...

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.