i18n using opensource.guide solution

[matbrgz]

Hello,

Close issue #68

Acording to github/opensource.guide#295 Guthub Pages does not support jekyll plugins. So I search at opensource.guide and try to do same.

• Structure for localizing strings (_data/locale/zz.yml)
• Update all strings in the markup
• Figure out structure for translating the guides themselves
• Tests for missing and unused localization strings
• Add locale switcher on the site
• Docs/process for translating the twitter cards
• Complete one translation to make sure the infrastructure is sufficient
• Document the translation process in CONTRIBUTING.md

[matbrgz]

Your site is having problems building: There was a YAML syntax error on line 27 column 3 in _data/locale/en-US.yml: could not find expected ':' while scanning a simple key. For more information, see https://help.github.com/articles/page-build-failed-invalid-yaml-in-data-file/.

licenses: The content of this site is licensed under the <a href="https://creativecommons.org/licenses/by/3.0/"> Creative Commons Attribution 3.0 Unported License</a>

How to add HTML on this yml file?

[mlinksva]

@MatheusRV the string contains : so needed to be quoted. Done in b66c349

Thanks for starting on an implementation of this approach! 🙇

There's one thing that I'm not enthusiastic about, and that is replicating license texts and metadata for each language. I think it's unavoidable given the Jekyll plugins available on GitHub Pages to have a file per license for each language, but maybe the metadata and texts could be moved so that the files in _licenses for each language would be nearly empty?

[mlinksva]

Few other notes based on glancing again at opensource.guide and this PR:

• there are also individual pages (like no-permission.md) that probably would need to go in a new collection, like the _articles one in opensource.guide
• some portions of those pages, the super ugly code in appendix.md in particular, would need to be moved to includes so as not to be duplicated across translations
• it probably makes sense to have existing language not be in a en-US subdirectory to minimize redirects
• many of the tests will need to be modified based on final changed directory structure
• a script to start a translation would probably be useful, since it is going to involve creating a bunch of nearly empty files

[matbrgz]

I could translate to pt-BR

[mlinksva]

@MatheusRV cool I'll definitely ping you about pt-BR for the first translation.

Just one other note, opensource.guide eventually implemented an even simpler approach in github/opensource.guide#543 which we'd probably want to follow.

I'm probably going to open a new PR as a bunch of things need to change, but will keep this open until I do, and thank you very much again for getting it started (of course if you have the inclination, feel free to try a new PR taking into account all my rough notes above).

[matbrgz]

Yes, thank you very much, I'm going to try to help as much as possible, I'm still learning about jekyll, but I'm enthusiastic myself, I'm writing my graduation monograph about this tecnology. I'm also trying to get into Github Campus Expert ..

You could be more didactic when it says of the changes so, I could not understand very well .. I'll try to sort with commits in that same PR.

[mlinksva]

@MatheusRV thanks for continuing to work on this! I hope to get back to getting it into shape for shipping soon.

I see that you translated one license text (AFL-3.0) as a sketch. I hadn't planned for license text translations to be in scope, as some licenses have official or semi-official translations, and in general license tooling doesn't know how to deal with them -- a couple references on that in #527 (comment) -- I wouldn't suggest translating more license texts here as I'm not sure what we'd do with them at this point.

[matbrgz]

I was really confused about the translation of the license. That would be a problem. We can keep the license in the original language until there is an official translation. I will reverse this change.

[wizardbyron]

Is there anyone working on this ?

[matbrgz]

Is there anyone working on this ?

Not yet, no time at this moment

[1jionni]

@

[Andre601]

If this (or a different aproach) gets realized could I help with making a translation to german.

Just two things tho:

• How would it go about the license text? I believe it should stay in the original language (English) unless there's a official translation I suppose (if there is one would I need links to those then as I don't want to assume certain meanings).
• Is the grammar important here? I speak the Switzerland version of german which has some minor, yet important changes like no "ß" and probs a few other minor changes, so there could be conflicts with other people's version...

Other than that would I offer myself for the task once it's available to do. 👋

[mlinksva]

@Andre601 license texts would not be translated. The main reason I haven't moved forward with this is some reorganization is required, likely separating the license texts from the metadata, some of which would be translated, and I just haven't made the time for it. I shall in the fullness of time.

As to how differences among varieties certain languages are handled, I'd guess however they are in other website translations. I don't recall seeing separate Swiss German translations on other sites, but happy to be wrong about that.

[Andre601]

As to how differences among varieties certain languages are handled, I'd guess however they are in other website translations. I don't recall seeing separate Swiss German translations on other sites, but happy to be wrong about that.

(Man I completely forgot this here)

The sad truth is that the german from Germany is used most of the time, which is fine as reading the text isn't as bad as writing it.
It's just sad that most sides go with that version and don't bother looking into alternatives to make their sites a bit more personal if you get what I mean.

[ny030897]

_data/locale/pt-BR.yml

[ny030897]

_licenses/pt-BR/afl-3.0.txt

[Dioliode]

DioX