Refactored "Statistics" page to make it more i18n friendly

[erciccione]

The numeric values in the Statistics page needed to be manually added for all languages, this results in an updated page in English, but all other languages are obsolete. This PR removes the need to update each language every month (which is unsustainable), now it's enough to only change the number in the english yml file, the other languages will pull the data from there.
I also added generic time references (last month instead of July), to remove the need to translate every time the name of the past month (also unsustainable).

The only downside is that is assumed the data in the statistics page (the english version) will be updated each month, but this seems to be happening anyway.

Opening as WIP because for this to be merged two strings need to be translated in all the available languages: Last month and As of last month. Please provide the translation for: Spanish, German, Portuguese (pt-pt) and zh-cn.

[m52go]

@erciccione thanks, this is certainly better. This manual updating is far from ideal but I'll try to get stats updates out promptly after the end of each month so the page remains accurate.

It seems like the precise translations we need are Through last month and As of last month, right?

@huey735 what's the best way to do this? Simple question on Slack?

[m52go]

Shoot, I hit "mark as ready for preview" by mistake...@erciccione please switch it back to 'draft' if you can (I don't see a way to do it on my end).

EDIT: I just added [WIP] to the title instead.

[erciccione]

It seems like the precise translations we need are Through last month and As of last month

Changed.

@huey735 what's the best way to do this? Simple question on Slack?

I think that would be enough. I would do it myself, but i guess would be more effective if a known face does it :)

please switch it back to 'draft' if you can (I don't see a way to do it on my end).

I cannot witch back to draft apparently, [WIP] will do it.

[m52go]

I would do it myself, but i guess would be more effective if a known face does it :)

For me it's more about a native speaker getting the phrases right for the languages in question.

[huey735]

@m52go @erciccione
The strings_en.yml must have the same keys/variables as the other languages' .yml files. strings_en.yml is what's fed to Transifex to output the translated versions. There are two ways to go about these changes.

1. We can put only the "stable" strings like "pTotalTrades: Total Trades" on the strings_en.yml file and leave the "unstable" strings, the figures, on the stats.html file. And @m52go would regularly update only the stats.html file.
2. The other way is to have all English strings in the strings_en and in the other languages' .yml files.

I favour option 1.

@huey735 what's the best way to do this? Simple question on Slack?

Yes, for that I think we can do it quickly through Slack. But I think that the better work flow is to have the changes done to the English pages and strings_en.yml, merged so that Transifex can fetch the changes and then download the translations when they're done and merge them.

[erciccione]

The strings_en.yml must have the same keys/variables as the other languages' .yml files.

I changed the logic behind the Statistics page to achive this. Now a snippet is included in all stats.html files which will call includes/statistic_data.html. The numeric variables are hardcoded and picked up by the various languages, so @huey735 will have to change the values from there. This should solve the transifex problem, since the values in the .yml files are now the same for all languages.

I think the better work flow is to have the changes done to the English pages and strings_en.yml, merged so that Transifex can fetch the changes and then download the translations when they're done and merge them.

Since the translations to be made are very easy and will take only few minutes, i suggest to ask directly to the translators on slack and then implement their translations to this PR. Merging, pulling on transifex, waiting translators to submit their work and them push it here requires time and in this case is better to just go the manual way.

Also, how is bisq.io deployed? Directly from GitHub? if this is the case, merging and then waiting for translators on transifex should be out of question, since the website would have mising strings.

[erciccione]

I just wanted to reiterate that the way translations are manged right now is very hard to scale and maintain, we need to find a better solution.

[huey735]

Merging, pulling on transifex, waiting translators to submit their work and them push it here requires time and in this case is better to just go the manual way.

Yes, the process I described there is for strings in general. But for this PR I agree with you. As soon as we agree on it we can just ask the translators for for the translations and pass them onto you.

I just wanted to reiterate that the way translations are manged right now is very hard to scale and maintain, we need to find a better solution.

A possible path forward is to have all the English strings in a en.yml file and then have the pages fetch them like the translated pages do now. I'm not certain that that scales better but at least it seems simpler. It's the method bitcoin.org uses. I have yet to grasp at all the details and I think it involves a more intrusive redesign of the website structure. Which I'm not fit to do.

[erciccione]

As soon as we agree on it we can just ask the translators for for the translations and pass them onto you

Perfect, thank you. I guess we all agreed to use Through last month and As of last month. I also asked some help to the translators of the Monero Localization Workgroup (i coordinated the internationalization of the Monero project for some time), i think some of them will be happy to give a small contribute to bisq :)

A possible path forward is to have all the English strings in a en.yml file and then have the pages fetch them like the translated pages do now

This is similar to how we do with the getmonero website, with the help of a jekyll plugin. I will investigate this option and then open an issue to discuss its implementation.

[m52go]

Also, how is bisq.io deployed? Directly from GitHub? if this is the case, merging and then waiting for translators on transifex should be out of question, since the website would have mising strings.

The Bisq website is hosted by Netlify. Merges on GitHub trigger a Netlify build script, which automatically builds and deploys.

I will investigate this option and then open an issue to discuss its implementation.

Would be great! I assumed translations would be a messy/manual to some extent no matter what, but any improvements would be welcome.

[m52go]

@erciccione really appreciate the refactoring. But what do you think about making month-specific variables for each language? That way, the text can always be correct, even if the numbers are updated a couple of days late.

When an update happens, the person making the update can simply switch all the pTotalDate references to pTotalDateAugust (for example).

[erciccione]

• Rebased
• Adapted to Update stats page for august #225
• added and adapted French
• Added translation made by the Monero Localization Workgroup (Refactored "Statistics" page to make it more i18n friendly #221) and Bisq contributors

Ready to go

[erciccione]

But what do you think about making month-specific variables for each language?

@m52go I thin that would be overkill. This way of showing statistics is not great anyway and i think sould be changed soon with something that pulls and show the statistics directly (using github or openhub API maybe?). I would just leave this as it is and merge it, after we can think to a better way to deal with this, but i would still avoid to create a variable for each month.

[m52go]

Looks good to me. Just 1 missed translation, which I noted with a suggestion.

[m52go]

ACK