Add command to check for differences between local and upstream strings

[Michael Federczuk]

A command which exits with a code of zero when the local strings are up to date with the upstream, or with a code of nonzero when there are changes to the strings that haven't been fetched yet.

I'd have two ideas how this could be implemented:

• reverse engineer the strings file that is already downloaded and compare between it and the upstream (though that would kinda defeat the purpose of only needing to download all strings if there is a difference + parsing the strings file might be quite a hassle)
• keep a "last modified" date field on the upstream and also download and save it in the strings file (just like there is right now the texterify_timestamp), and compare these two dates if an update is necessary

[Christoph Werner]

Hello,

thanks for the feedback. 🙂
That would be a nice feature to have.

The first way to implement this, as you suggested, would be a a huge amount of work, because this would mean, aside from the file content parsing with Ruby on the backend, it must also be implemented with JS on the frontend side.

Texterify already stores the last time a translation has been updated so checking if a string has changed since the texterify_timestamp would not be a big deal (although this must not automatically imply that the content of the translation has changed, e.g. changing a translation and then reverting to the old translation).

How would you like to use this command?

[Michael Federczuk]

My use case would be a Git commit hook that notifies me when there are string changes.

Using a hook to download the strings right away is unfavorable for a number of different reason.
It may lead to a broken build when a string that was used in the application got removed and fetching all strings every time when committing is just annoying.

In regards to the problem of "last modified may not mean difference in translation", this could be solved by using a hash of all strings instead.
When the strings are fetched, the backend also generates a hash of all strings, which gets sent alongside the strings and then gets saved locally.
Then, when checking for updates, the hash is re-generated on the backend and gets compared to the locally saved hash.
Alternatively, the hash may also be stored on the backend, but then it will need to be re-generated every time a string is added/updated/removed.