Internationalize The Repo!

[hAbuMustafa]

Hello there.
It's really tempting to see the idea and the structure of the project. Something that I've been wishing I had when I started learning web-dev.
It's true that almost all programming languages are written in English, but this repo is about education. And education should be Universal.
So, my pitch is to restructure this repo a little, to provide internationalized repo, that can be implemented to an API later in the future.
And, let's be honest here, explanations in your mother tongue are way more efficient, and clear when it comes to really absorbing the knowledge.

I suggest we go down with one of three structures:

1st: Embedding Localizations (in the same file)

This can be the easy way of doing it. Because, let's face it, the English term will be the reference anyway. The term the user will be searching for.
But, the contributor can add a new section containing the same two ways of explaining it, but in his own language.

Pro's for that are:

• Maintainers are only focused on the same repo.
• Implementing an API will be more straightforward.

Con's for this approach will be:

• Maintainers are unable to really tell if the internationalized version of the term is correct or explained well.
• Overcrowded pages with translations you don't intend to read.
• Harry experienced too many hard-to-relate-to pull requests.

2nd: Tagging Term .md Files With Language Suffix

This way can seem less clunky to implement. And relatively easy to implement since current repo is still small.
We can simply suffix the current .md files with the ISO 639 two-letter language codes, in small case (e.g. api-en.md). and then, a contributor to his language can make another file with the same name, but with the language code of the language he translates/localizes to (e.g. api-jp.md).
Then, the contributor links the language version in the README (e.g. [APIs](/Glossary/A/api.md) ([JP](/Glossary/A/api-jp.md), [AR](/Glossary/A/api-ar.md)))

Pro's to This

• More organized folders. Although still overcrowded.
• Ability to assign maintainers for every language.

Con's to that:

• More cluttered README.
• Languages array can be randomly sorted, since they will grow by time.

3rd: A Glossary For Every Language

The preferred approach to me, to move the current glossary to a EN folder, along with its README as the index. and craft a new folder with its README index for every language to be added later.

Pro's to this:

• This is the most effortless approach.
• Allows for even implementing a folder for every dialect if needed (by using code pairs of language-country, like en-us, from the ISO639-ISO3166 respectively)
• Ability to assign maintainers for every locale, who will watch for a single folder for changes.
• Easiest way to implement an API later when needed.

Of course a maintainers.md file will be a must-have, to make every locale maintainers announced.

That's all I have.
Let me hear your thoughts.