I made another comment as well though tldr is these xlf files are translations tied to texts in code so we can't simply ignore them from the repository. The changes have to be kept so that if we say revert to a certain commit, all the translations match with the texts of headers, buttons, etc...

>...The changes have to be kept so that if we say revert to a certain commit, all the translations match with the texts of headers, buttons, etc...

The mentioned .zip file is to be kept in the repo. Instead of a whatever number of individual .xlf files per generation, these would get zipped together (say, 'assets/xlf.zip') before the commit and the resulting .zip added to the commit.

Similarly, when reverting or on a checkout, it's the .zip that gets checked out and then the .xlf files are unpacked.

The packing/unpacking could be done by the same process that handles the .xlf generation (??build).

Also this may be automated by git-hooks, though it's more natural to handle the packing of assets during the build stage.

Could these translations be moved to another repository? Maybe they could be published as a separate NPM package that devs could install if they needed to look at the translations?

Then you get the annoying problem of having to push an update to that repo and wait for the new version before you can merge changes into the new repo which use the new version. It’s tightly coupled, so they should be co-located.

The entire workflow could remain the same while tar/zipping goes on in the background...