Generated l10n.json files - should they be gitignored?

[JWaters02]

So every time I build the project, these two generated localisation files from the repo, bundle.l10n.json and poeditor.json are changed not just for the changes I have made, but from other people's changes too. Since these files are already version controlled on the repo, unless people commit these generated file changes in their PRs (which they don't, so I don't), there will always be stashed changes.

So what is the reason for these files either not being gitignored or not being updated in PRs?

Thanks!

[t1m0thyj]

The l10n files should be updated in PRs, as part of the pre-publish step in the PR template:

• The pre-publish command has been executed:
  • v2 and below: yarn workspace vscode-extension-for-zowe vscode:prepublish
  • v3: pnpm --filter vscode-extension-for-zowe vscode:prepublish

I think the team has noticed that the order of l10n terms in the generated files differs depending on whether they are built on Windows or MacOS. This could explain why you're seeing the files always changing.

As it's kind of annoying to have the files always change, it would be nice to investigate sorting the l10n terms so that json files are generated consistently on all platforms - this just hasn't been a priority yet.

[JWaters02]

The l10n files should be updated in PRs, as part of the pre-publish step in the PR template:

I thought that part of the PR template is just to check that the pre-publish step compiles and checks everything OK. It does not mention anything about having to commit the l10n files, so perhaps it should? Or somewhere else in the contributor docs?

I think the team has noticed that the order of l10n terms in the generated files differs depending on whether they are built on Windows or MacOS. This could explain why you're seeing the files always changing.

Interesting - I saw during the demo some of you use macos, while I use windows. The order of various parts of the file does indeed change for me. By committing the hunks that re-order themselves (but are not actually part of the change), I imagine it would induce more merge conflicts. So perhaps I could only commit the hunks that matter in the PR?