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.