Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tx pull does not overwrite by default #233

Open
xrmx opened this issue Jun 5, 2018 · 7 comments
Open

tx pull does not overwrite by default #233

xrmx opened this issue Jun 5, 2018 · 7 comments

Comments

@xrmx
Copy link

xrmx commented Jun 5, 2018

It looks like tx pull does not overwrite by default as calling it i get:

tx INFO: Skipping 'fr' translation (file: readthedocs/locale/fr/LC_MESSAGES/django.po).
...

Is it expected? If so i don't understand what --disable-overwrite is supposed to do:

  --disable-overwrite   By default transifex will fetch new translations files
                        and replace existing ones. Use this flag if you want
                        to disable this feature
@akien-mga
Copy link
Contributor

akien-mga commented Jul 23, 2018

I've been having this issue for years, and I think it's due to my local files in Git having a newer timestamp than their Tx equivalent (e.g. if I ran git pull in my local clone after the latest changes have been made in Tx, my local files will have a newer timestamp than the Tx files, even though they might not have all changes from Tx).

For example, with tx-client 0.13.4:

$ tx -d pull -l fr
<snip>
tx DEBUG: Adding to new translations: set()
tx DEBUG: Pulling languages for: {'fr'}
tx INFO: Pulling translations for resource mageia.drakx_share (source: libDrakX.pot)
tx DEBUG: Using file fr.po
tx DEBUG: Remote time is 1506189480.0 and local 1532333236.0
tx DEBUG: Local is newer than remote for lang fr
tx INFO: Skipping 'fr' translation (file: fr.po).
tx INFO: Done.

@m-aciek
Copy link

m-aciek commented Mar 16, 2019

@akien-mga what was you workaround for this then?

@rffontenelle
Copy link

@akien-mga what was you workaround for this then?

tx pull -f to force the download disregarding its remote/local time.

I can reproduce this issue in version 0.13.6, Arch Linux 64-bit.

@rffontenelle
Copy link

For what is worth, this is the function the compares the remote and local timestamp. Not sure what is the solution for it, though.

@m-aciek
Copy link

m-aciek commented Dec 30, 2019

In my opinion there are two strategies that could improve current behaviour:

  • Checking git log for each file and looking up date of last modification from there.
  • Doing content comparison for files.

@m-aciek
Copy link

m-aciek commented Dec 30, 2019

This issue is potentially duplicate of #22.

@kevr
Copy link

kevr commented Jan 11, 2022

* Doing content comparison for files.

100% agree; a hash to rule the world.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants