3 ms·

> "...we found that .xlf files made up almost 70% of the total number of files. These .xlf files are generated... they are never manually edited by engineers...

> "...we found that .xlf files made up almost 70% of the total number of files. These .xlf files are generated... they are never manually edited by engineers..." First thought is why not to zip/tar away all of these "convenience" files per generation and add a line into build/install script to unpack them after checkout? Additionally, add the .xlf into .gitignore to exclude them from untracked. Noone cares to diff them as long as their contents is consistent with the checkout. Text compresses quite efficiently so this should not introduce any unreasonable build/install delays.

haizzz 4y ago
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...
- GeneralMaximus 4y ago
  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?
  - klysm 4y ago
    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.
- zoomablemind 4y ago
  >...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.
- jeffhuys 4y ago
  The entire workflow could remain the same while tar/zipping goes on in the background...

haizzz 4y ago

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...

GeneralMaximus 4y ago
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?
- klysm 4y ago
  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.
zoomablemind 4y ago
>...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.
jeffhuys 4y ago
The entire workflow could remain the same while tar/zipping goes on in the background...