i18n: Translation system ideas

[xaur]

I got some ideas for the translation system while scanning DCRDEX Git history for the status dashboard. Just wanted to share it somewhere, feel free to close at any point if nothing can be reasonably implemented.

1. Document which branch to translate.

Most translations were made in master and then ported to release-*, but recently one was first submitted to a release branch and then ported to master. I see a room for confusion here. It may be worth updating the Localization and Translation to instruct translators which branch to checkout and translate (and rely on maintainers porting to the other one), or do both.

2. Put each language in its own file(s).

It is hard to follow Git history for a specific language translation when multiple languages live in the same file in locale_ntfn.go and locales.ts. git log for these paths shows each change in each language (including English) and also in the extra code sitting there. The locales/*.go files are much easier to track because each file has only one language and no extra processing code.

Originally I missed this to determine how up-to-date the translations are, but placing English strings separately from other languages and code also simplifies tracking changes in English strings using normal Git/GitHub tools. Translators could potentially see what exactly they need to sync (sometimes only tiny diffs).

3. Extract translations into JSON files.

Originally adopted in Decrediton, storing translations in simple key-value .json files allowed to build a GUI assist tool:

It guides you through English strings that need to be (re-)translated and shows diffs of what's changed (most helpful for spotting small changes in large strings like in the screenshot above). The same method was recently adopted by dcrweb, proving it can serve more than one project.

In DCRDEX strings are currently stored in .go and .ts files. This is easier to consume from the code side (esp. where the strings are wired to code's constants or enums), but harder to fit into the tool above.

It was mentioned in Matrix that there are challenges to arranging strings this way in DCRDEX, but maybe someone will have an idea how to overcome them. For example, write a small tool to generate .go files with proper const->string mappings from .json files. Or generalize the new checker tool to compare arbitrary .json maps.

[vctt94]

I can work at suggestions 2/3. For notifications, at locale_ntfn.go I guess it will be more trick, but I can see what can be done

[buck54321]

@vctt94 We need to discuss this on Element before moving forward.