Keep i18n text in sync more consistently

[ybnd]

As new features are added, we typically provide i18n text in English first and use yarn sync-i18n to synchronize these changes to the other translations. If we don't do this, other languages won't always fall back to English if a key is not defined -- you can see this on the https://demo7.dspace.org/profile page:

• The SSR HTML does not contain some of the keys required for the "Researcher profile" section
• When browsing in another language, users will see the "raw" i18n keys pop up first, when CSR complete they will be replaced by English text.
• To see this more clearly: open the page with JavaScript disabled -- the i18n keys will stay up

To deal with this issue more consistently, we should either run this synchronization more often or make DSpace less dependent on it -- here's two potential solutions:

1. Create a new script to check i18n sync, and let it run as a CI step

   • We'll be notified when the files go out of sync, and we'll be able to address it immediately
   • If this is too "noisy" on a per-commit level, we could consider running it periodically or before a release
   • It would be perfect if we could run this only before a PR is merged, but I don't think this is possible with GHA

2. Combine translation files during build-time

   • For each non-English language, we could generate the "final" i18n file here as follows:

     {
       ...english,	   // use English keys by default
       ...translation,  // overwrite with translated keys where applicable
     }

   • Then DSpace could continue working in the same way as before even when i18n files are out of sync, and keeping them up-to-date would be less urgent

[alanorth]

Yes I agree. I recently looked at the i18n situation and had some ideas too:

1. Our i18n files are not using any explicit JSON5 features and can be parsed using jsonc tooling instead. I plan to make a PR for that, but it involves a messy rename of all our *.json5 files to *.jsonc.
2. Our ESLint configuration should be updated to include i18n files so that a consistent style is enforced there. I already created Update ESLint configuration for json5 files #2317, but it would be affected by JSON5→JSONC proposal above.

[tdonohue]

As suggested by @artlowel in #2464 (review) , one way that we might think about this automatic "sync" would be to create a GitHub Action which automatically runs anytime the en.json5 file changes, runs the sync-i18n script & generates a PR of the corresponding changes to other json5 files.

The behavior would be similar in nature to our automatic "syncing" between main and dspace-7_x branches via this action: https://github.com/DSpace/dspace-angular/blob/main/.github/workflows/port_merged_pull_request.yml This action will automatically create a "port" PR whenever a PR is merged that has the label port to [branch]. The branch the PR is ported to is the one specified by [branch].

However, syncing i18n files would likely require the creation of a custom GitHub Action, as we want this automatic PR creation to trigger based on merged changes to a specific file (en.json5) and then to run a custom script (yarn sync-i18n) prior to automatically creating a PR.