Preparing for GitLocalize to manage translations

[nichwall]

In order to prepare for using GitLocalize for managing server translations, the following steps need to take place:

• Rename the strings from %lang%.json to %lang%/strings.json because GitLocalize does not like a flat file structure (without adding the entire repository
• Delete strings which have not been translated yet (matches English version)
• Change supplant to fallback to English if the translation does not exist and use the new naming scheme
• Write script to copy translations between repositories
• Set up GitLocalize

If GitLocalize is decided on, the following steps should be taken:

• Link repository to GitLocalize
• BEFORE adding languages, set the project path in the Settings (it's a pain to get GitLocalize to scan the repository properly if you add languages before fixing the path)
  
• Add languages (Overview tab)
• Add "Translation FAQ" to the website and "How to Contribute" on this GH readme. Maybe make an announcement on Discord too. I was thinking of making a thread for people to coordinate since there will probably be multiple people who want to work on per language

Once users who want to help link their GH account to GitLocalize, they should be added as a Moderator (https://docs.gitlocalize.com/understanding_roles.html) so they can open PRs to GH. If a user does not want to use GitLocalize, they can still open PRs like normal, but they will not be able to just look at the %lang%/strings.json file to find English lines because they will not exist until they have been translated (since some languages will use the same words as English)

Once this first pass of updating the missing translations for the server is finished, the translations will be copied to the app repository using the included script to help keep the two repositories in sync. will diverge since there is not a lot of overlap beyond the basic book, podcast, and ABS strings, and the UI is updated separately.

[nichwall]

This PR does not move the Gujarati translations to a subfolder since there is an open PR for it at this time and I didn't want to cause any merge conflicts.

After merging the following PR, the file should be moved to gu/strings.json
#2293

[Dr-Blank]

This PR does not move the Gujarati translations to a subfolder since there is an open PR for it at this time and I didn't want to cause any merge conflicts.

I have marked the PR ready to review, so you can move it once it's merged. I will add more translations later.

[nichwall]

I have marked the PR ready to review, so you can move it once it's merged. I will add more translations later.

Awesome, thanks for doing that! GitLocalize hasn't officially been decided on yet (since advplyr has been busy with adding oauth with Sapd, and just real life stuff). It may still be a few days, but it definitely makes the transition easier when everything can switch at the same time. :)

[nichwall]

Wrote a script to help keep the server and app strings from diverging.

Any English key/value pairs which are identical in both the server and app will have their translations copied (if missing in one repo). If the English value does not match, the translated string is not copied in case of name collisions.

Any missing translation files will be copied between repositories (like if a language only exists for one repo). Any keys in the translation files which do not exist in their corresponding English resource file are removed (in the case of server/app specific strings). If the string is later added to the second repository, running this script again will copy the translation from the other repository (since both have the English key and one repostiory is missing the translation)

The script does not perform any git actions. The script supports multiple resource files per language (in case they are split at a future date, such as for aria-labels or something else).

Edit: to clarify, the English resource files are never modified or copied, they are the "source of truth" to add/remove translation strings for managing with GitLocalize.

[nichwall]

The script should now be ready. I tested it under various conditions:

• missing languages in either repository
• English strings being edited and translations being deleted/missing from one repository
• New English strings

The script displays when files are copied from one repository to another, and then prints out a pretty table to help sanity check a diff for the commit for all of the languages.

It feels a little silly to have a standalone Python3 script in the strings directory, but I don't know where else to put it so it's handy. I was planning to also put it under audiobookshelf-app/strings just so it could be run from either repository, but not sure if that's worth it.

[nichwall]

Example output from a test set.

[nichwall]

Marked this as a draft since I think the only real benefit of this PR at this point are the instructions to switch to GitLocalize and my Python script to sync translation strings between the server and app repositories. (Don't want to clutter the commit history of this PR with rebasing and merging string changes from other translation PR and upstream changes)

After further research, it looks like the strings already fall back to English if the key doesn't exist in the translation file (based on screenshots recently shared in Discord). I still haven't gotten the dev container to get past server initialization to test this myself.

If you want me to rebase and merge everything for a clean PR I can do that, but it will be simpler to just have you perform the move files and remove duplicate keys for GitLocalize so you can time it with whenever you do the other PRs and don't need to wait for me @advplyr

[nichwall]

EDIT: not trying to pressure the merge, just don't want to waste your time waiting and I won't have much time for the next few days

[nichwall]

This PR is now outdated and should use the new GitLocalize attempt.