Restructure codebase for, and document how to do, end user translation

[davelab6]

I also want to highlight as a separate issue what @gufmar said in #69 about translations; I think that is the # 1 advantage of putting a libre license on the websites and hosting them on Github (where you can have quality control via pull requests, vs a wiki where you don't)

Since Cardano is aimed at the next billion internet users, translations to "smaller" languages like Malayalam will be important, and I expect local language activists in each linguistic community will be happy to help - if your infrastructure makes it frictionless for them to do so.

However, this requires repos like this to be set up with localization in mind. A project I started that is structured this way, using the Github Pages jekyll CMS, is https://github.com/fontforge/designwithfontforge.com - root directories for each language by tag name, and an /index.html that redirects to the english index page.

That's just a hobby project, so the documentation about how to contribute translations could be better.

Something more sophisticated could be done (using http://zanata.org etc) but restructuring the current repo is a lightweight way to get started :)

[FranckChevallier]

Hello @davelab6 , I was thinking about the same translating project for Cardano. I could help to translate in French if needed. Let me know.

[gufmar]

Ready for first steps on German and Italian translation.

[FranckChevallier]

Hello @gufmar,
I could not help in German and Italian since I am French.
Cardano deserves better than Google Translate :-)

[gufmar]

@FranckChevallier
Oh, I didn't mean you. I'm ready like you to contribute in my native language. The question is if we should simply start to write down our translations and push them in a temporary translations/[lang] directory, in the hope that sometime someone will use it for the public website. Or wait, until @davelab6 's suggestion became implemented.

BTW: (spoiler) Deepl.com IS much better than gtrans.

[FranckChevallier]

@denisshevchenko will probably have an opinion. But I like the idea to start and see.

[gufmar]

From what I can see the current cardano.org website is based on wordpress but is not using a dedicated multi-language plugin. e.g. WPML. So this seems generally not adequate for a repository-based elaboration and translation. hopefully, we can see a more international website soon.

[tomasvrana]

@gufmar @FranckChevallier @davelab6
cardano.org is supposed to move from WordPress soon. Ideally to Github pages as most IOHK sites. ...
cardanodocs.com is already Github pages Jekyll based site and is only matter of making the repo public so anyone can fork it then.

Will turn to our support with that. Thanks

[tomasvrana]

@gufmar @FranckChevallier @davelab6
https://github.com/input-output-hk/cardanodocs.com already is public repo ... you're free to fork it and do your thing.

[gufmar]

@tomasvrana ok done. you can see the first introduction (index) file translated.
https://github.com/gufmar/cardanodocs.com/tree/master/_docs/de

Before I begun I enhanced the includes and added a German flag. I haven't verified it's correct appearance as I haven't at hands a running Jekyll instance.

Regarding flags it would be easier if you already have a complete collection of uniform png files for future other languages. The current format with rounded corners with a semitransparent background is not easy to imitate even if it looks good in the current design.

[gufmar]

if you official IOHK guys could give some feedback if this fork is considered useful, I would continue.
In yes we should define if @FranckChevallier and @davelab6 should do their own fork or start editing the /_doc/[xx] subfolder.

[jonathancross]

@gufmar You might have better luck submitting a simple PR for the first language...
¯\_(ツ)_/¯

[gufmar]

That was my intention, but so far I have only translated the first page (...index.md).
Before I invest more time in the rest, it would be very useful to see a small sign of God that a PR is accepted.
Official feedback in other social channels was that they can only accept messages where at least one of their employees can read and check the correctness.
I can understand such a reasoning. And it would probably not be appropriate to send a PR just for this first page.