tx client misses translation updates when used with version control

[amoskvin]

Currently, tx relies on files' timestamps when deciding whether to pull the latest or not. When used in conjunction with version control such as git (with the translations are stored in the repository), this mechanism breaks since files that are updated have the date of the checkout, not the date that they were originally created.

This creates a problem. Consider this timeline:

1:00: Alice creates a translation for 'widget'.
2:00: Bob pulls translations and puts them in git.
3:00: Alice modifies the translation for 'widget'.
4:00: Charlie makes a clone of the git repo.
      The new 'widget' translation now has a timestamp for 4:00.
4:15: Charlie does "tx pull -a". Since the 'widget's timestamp is 4:00
      but the server timestamp is 3:00, it does not get updated.
4:30: Charlie publishes a release, missing Alice's updated translation.

A workaround for this is to use the -f switch, which results in all the translations being re-downloaded. For us, this takes over 30 minutes(!) on a decent-speed connection.

[jmphilippe]

Yep, I face the same issue. This is a bit annoying because I put the files downloaded from Transifex onto our SVN repository. I finally had to always use the --force flag of the tx client, then I wrote a dedicated script that compares the messages of each downloaded file to messages from the previous version of that file in order to not commit files in which only the date has changed…

Cheers,
JM.

[cheesegrits]

Is there any likelihood of this changing? It basically makes Transifex unusable for my project, with about 12,000 translation files.

What would be useful would be a "changed-since" arg to the pull. That way I could specify the date of my last project build.

I had hoped to overcome this using the txgh gateway, and do continuous integration between git and tx, but as Transifex webhooks only fire when a translation hits 100%, that makes it equally ineffective.

[vinniejames]

This still has not been resolved? If thats the case this should at least be clearly documented in the setup instructions.
We have nearly 6,000 files in our repo which takes nearly 3 or 4 hours, minimum, to do a full pull

[m-aciek]

As a dirty workaround you might want to change timestamps of files basing on commit timestamps on them, using this script: https://gist.github.com/jeffery/1115504.

[m-aciek]

As @rffontenelle noticed, Project._remote_is_newer is subject to tweak.

It should fetch "POT-Creation-Date: YYYY-MM-DD HH:mm+0000\n" line from local file and make comparison basing on it.

We could introduce --use-git-timestamps flag and when it's on fetch local file timestamp from latest commit on it. (.git/FETCH_HEAD timestamp == file timestamp means fresh git clone, but fresh git clone is only one of possible cases).

[rffontenelle]

If one chooses to implement a verification for newer using the message catalogs' Gettext headers, I recommend PO-Revision-Date header instead of POT-Creation-Date, because a Gettext file might have same POT-Creation-Date (means no news in the POT file) but with new translation contribution, and therefore newer PO-Revision-Date.

[sergioisidoro]

I think this can be closed :)