Note increased blockchain size

[STRML]

The blockchain is now over 55GB - gave this number a bump on the download page so users aren't surprised by it.

[laanwj]

Would be better to parametrize this, so that it doesn't require an update to all the translations every time.

[MarcoFalke]

Duplicate of #1225? @harding I remember you already created a parameter for this. Am I wrong?

[harding]

Yes, unfortunately the parameter can't be used in the translation strings because both are used as (basically) variables. I think the best way to go about this is to break the translations up into two parts and put the chain size between them. E.g.

{% translate text1 %} {{site.text.chain_size_in_gb}} {% translate text2 %}

[louisjc]

We could replace "20GB" with "chain_size_in_gb" in each translation and then use the replace liquid filter.

{% translate notesync | replace:'chain_size_in_gb', '60GB' %}
OR
{% translate notesync | replace:'chain_size_in_gb', site.text.chain_size_in_gb %}

[jonathancross]

Feel free to use my regexes to find all the crazy variations: #1225

[jonathancross]

Please Note: this PR is missing 5 language files such as ar.yml.

[laanwj]

A friend of me just got confused due to this. IMO wey need to merge #1225 or this one soon, and if we can't parametrize it, it would be better to overestimate a bit (say 80GB for instance) than underestimate so that it is a valid maximum for a while...

Another thing that confused him is that the download itself is not the limiting factor but the CPU and disk i/o-intensive processing that goes on for all the time in the background. May be nice to mention this.

(mentioning pruning would be nice as well, but doesn't change the amount that needs to be download/processed, the main thing that surprises people is how long their pc takes to validate)

[Cobra-Bitcoin]

I merged #1225. Closing this now. I agree with @laanwj that we could do much better to improve communication about the initial download/set-up process associated with Core.