Translations: variablize chain size in translation strings

[harding]

I noticed in #1508 @Mirobit was pointing out (perhaps adjacent to the main issue) that different strings in different languages related to the Bitcoin Core datadir size have different values because they were translated at different times. Since we already have a variable for that which we use elsewhere on the site, I decided to add that to the translation strings.

I also found a couple places in the full node guide that could use this variable (we already used it in the top of the document, but some sections were added later that didn't use it).

Preview: http://dg0.dtrt.org/
HTML diff of the site from before these commits to after them: http://dg0.dtrt.org/diff.html

I reviewed the above diff (at the console) and didn't see any broken changes because of a typo nor any unexpected changes because of the additional Liquid template interpretation in the Translation plugin. However, if anyone else has time to verify, that would be useful.

[wbnns]

@harding Heya! Thanks for doing this - did get a chance to check if this would affect anything on Transifex or if any changes need to be made there to prevent conflicts when the strings get updated?

[harding]

I have not looked at Transifex. It was my understanding that we had not imported from there in a very long time (more than a year), so I didn't want to make this contingent on that.

If we're going to resume Transifex string imports, I can remove the changes to the non-English languages and you can push just the en.yml file to Transifex so that the change filters down to the translated YAMLs when they next get re-translated. (Or if you're going to focus on Transifex for a limited subset of languages---e.g. es, fr, de---I can remove the string update from just those languages so the translators make the change but keep the update for the other less-maintained language so that we're not giving out bad info on the chain size.)

Let me know and I'll make the appropriate change and regenerate the preview and diff.

[harding]

Another option, if Transifex imports are still a while a way but still something we definitely plan to get back to, is that I can reorganize this PR into one commit for en.yml and one commit for the other languages---and then when it comes time to start importing Transifex translations, the "other languages" commit can be quickly reverted so that there are no conflicts. (It would still be good to push en.yml upstream to Transifex sooner than later in that case.)

[wbnns]

Ok, got it. Yeah, you're right, Transifex hasn't been updated in a while, but since there are years of work that have been put into it and it still gets updated regularly by translation contributors we definitely do need to get to it (any help would be most appreciated!). Here's a high level overview of the process if you have time to assist in conjunction with this PR:

1. Use the transifex CLI client to download latest translations (including en.yml) from Transifex
2. Diff bitcoin.org's en.yaml against Transifex yaml to review changes
3. Identify English strings we don't want translators to re-translate from scratch
4. Identify which translations had those strings reviewed (usually translations near 100% reviewed)
5. Manually update en.yml with the English strings we don't want re-translated
6. Review together
7. Once reviewed, push this to Transifex using the transifex CLI client (this re-uploads en.yml, and all translations - transifex commands for all of the above are in https://github.com/bitcoin-dot-org/bitcoin.org#update-english-strings)
8. Go to transifex to manually set those strings are reviewed for the translations you noted sooner
9. Upload the latest en.yml from bitcoin.org manually (any additional changed strings will have to be retranslated)

Basically, we should work to reduce changes sent to Transifex, because translations don't scale well (but are obviously still very important to us because we have so many international users and non English speakers who use the site). Small stuff can escalate into large work, and small errors can turn out to be big. For example, there are currently approximately 73 languages in our Transifex translation project, so a single erroneous change could cause 73 translators to do 73x the work. That would of course multiply by the number of changes that are made (in this example I'm just talking about one).

We also don't want translators to have to start over on work they've already done.

[harding]

That sounds like a separate issue from this, right? I'm happy to make this PR as compatible as possible with future translation updates, but I'm not available to do those updates myself (sorry, I've tried in the past but it didn't feel like a useful match for my skills and interests.).

Let me know if I'm misunderstanding you about that being a separate issue and you think I should close this PR if I'm not willing to do translation updates.

[wbnns]

@harding Yeah, it's a separate issue and no worries - feel free to just focus on this part if that's what you're interested in. 👍

Maybe just only update the English string in your PR instead of all of the other ones as well, and don't push it up to Transifex since there are some other manual steps that need to be done first to avoid the issues I described above.

Thanks again for the help!

[harding]

@wbnns as requested, I reduced the change set to just the en.yml file and the English full node guide. I've updated the preview and diff links from the OP. Please let me know if any there are any other changes I should make. Thanks!