choosealicense.com
choosealicense.com copied to clipboard
github
Internationalization / i18n / multilingual site
Would love to see about baking in I18N support to choosealicense.com proper. See #67 and #62
We already have the bulk of the strings in a single file (_config.yml), so it should just be a matter of abstracting out some of our variables, as far as I can tell.
Would love to take this on starting in August if there's interest. Would be a great exercise to set a standard for Jekyll L10N, and can iterate on some of the lessons learned form https://github.com/CMSgov/healthcare.gov.
@parkr any interest? @dhcole any insight / words of wisdom?
It's really good! I hope 'choosealicense.com' support I18N. It is very valuable work for open source beginner!
This looks like a great candidate for use of the _data directory proposed by @benbalter in https://github.com/mojombo/jekyll/pull/1003.
Just using subdomain?
A quick and simple (maybe not very elegant approach) is just using subdomains (with separate repositories) .
For example:
- Korean:
http://ko.choosealicense.com - Chinese:
http://zh.choosealicense.com
Thus, we only need to make sure that:
- Translated sites and main site should link to each other.
- github/{lang}.choosealicense.com has the proper CNAME file (and the related DNS Zone configurations)
Done.
And in future we can switch to a more elegant solution once Jekyll has better support of I18N.
It'd be way easier to handle if everything were in one repo and simply to ship every translation under /LOCALE/ (e.g. /en/, /ko/) with pages for each. It's a lot of duplications, but right now it is the best option, given that Jekyll has no means of handling this.
@parkr Yeah, I'm kind of leaning towards that approach. @benbalter seem good to you?
How about using URI separation? (http://choosealicense.com/{lang})
Fo example :
- Korean :
http://choosealicense.com/ko - Chinese:
http://choosealicense.com/zh
Ok, just need someone to send a PR with at least one translated language. :)
@liks79 It seems that some js files assumes resources are located in the root directory, thus simply moving all translated files to a sub directory will fail. I cannot speak javascript. If you've finished Korean translation, please @me, so I can just use your modifications.
@Haacked @benbalter @parkr @liks79 I have made a base for translations, please review my pull request.
@weakish @Haacked @parkr @benbalter
#131 It is a good reference implementation for I18N. I'll try to apply it for translation for Korean.
But, I am afraid too that copying HTML files...
Hi, I would like to contribute to the implementation of I18N. You need help?
I am web developer from Brazil. Here not lot speak English for this reason many people have benefited from the translation.
I can start and send a PR?
Hi, I would like to contribute Traditional Chinese(Taiwan) version of this great site!
- The issue is not a technical one but one of keeping stuff up to date.
- To have languages you will need tagged revisions of the page. Then you can link a revision (and available translation).
- It will also slow down revisions. So I'd rather see the dust settle more around what the site should actually show.
I'm very interested in making this happen but have yet to digest the various possible approaches. Self-assigning for now as a reminder to do that digesting.
In https://github.com/github/choosealicense.com/network/members I noticed a couple translations through forks published on separate websites:
- https://github.com/webfatorial/escolhaumalicenca.com.br - http://escolhaumalicenca.com.br/
- https://github.com/mickaelandrieu/choisirunelicence - ~~
http://www.choisirunelicence.com/~~ https://mickaelandrieu.github.io/choisirunelicence
Glad people were motivated to do this and totally fine if they want to run their own sites, but probably a pain to keep up to date (if they want to do that).
Jekyll plugin https://github.com/untra/polyglot seems to generate copies of an entire site, including collections (as used here for /licenses/), under /{language-code}/ for each language configured, without any duplicate source files. I haven't looked deeply, but it seems to be the only Jekyll i18n plugin that does this -- others seem to require a file for each page for each language -- as would something not using any plugin, as prototyped in #131.
Using a plugin would mean switching to using the gh-pages branch for the rendered site, because we couldn't use GitHub Pages to do the rendering. This may be a price worth paying.
The Jekyll no-plugin i18n solution being worked on in https://github.com/github/open-source-guide/pull/295 for a related site may eventually be applicable here. Watch that if you're interested.
@mlinksva any updates? I'm interested in this issue for translating into Korean. If anyone can suggest a right way to make this I18N, we can do it together.
@lqez thanks for the ping! I was waiting to see a completed and deployed translation of github/open-source-guide to dig into how that is done and see whether it is the best way forward here. Looks like there's one that is close.
If you're super eager to get started and don't mind maybe reorganizing things later, feel free to fork the repo and translate everything in place like a couple others have done (fr and pt-BR) mentioned above.
@mlinksva @benbalter Hi, thanks for you amazing job. We wanted to do the exact thing you have done in Persian until i saw your website so we planned to do the localization only and get a domain (thanks to you). As you know the problem is the lacking of translation files and making the forked repository update, So is it possible for you to give us a more accurate deadline for adding support for I18n? Thanks in advance :+1:
@JafarAkhondali thanks, really appreciate your interest. 🎉 Unfortunately, the most accurate statement about a deadline is that there isn't one. I do promise to look into whether we can copy the mechanism being used for opensource.guide translations once a completed one is deployed.
Another way to help now, other than forking and translating in place, which I admit isn't ideal, would be to do an advance evaluation of the mechanism described at https://github.com/github/opensource.guide/pull/295
@mlinksva Sorry for late response, I've read your provided link, They use Crowdin to sync GitHub with Crowdin using a CLI script but we don't that anymore since crowding created Integration with GitHub. I've also found another reference for multilangugae website in Github pages with Jekyll. So using these two i almost created a multi language page but lack of experience in Ruby & Jekyll turned me down. Here is what i did:
Before beginning, I think(not sure) it's better ta rename all translateable files from file.extension to file-en.extension
- Create a project in crowdin
- Integrate project with Github
- Choose branch, and config files to translate, here is a sample config for this project(It's not accurate, just for the test)
- Translate a file, then go to Integration tabs and press Sync now to sync project with github. It'll create a PR for translation files. With crowdin all translators can help translations easily.
- Use this guide to configure a multi language website.
Ran across recent Spanish translation not in forks network: https://github.com/Eligelicencia/eligeUnaLicencia
Micro-update: @bkeepers pointed out https://github.com/electron/electron-i18n (internationalization for another GitHub-maintained site) to me ... I haven't gotten around to see what it would take to set up that arrangement for this project yet, but it's on my list to evaluate. Thoughts and hints welcome.
Another micro-update: some translations of opensource.guide are now live (scroll to the bottom at that link for a chooser) using a simpler approach than referred to above http://mikemcquaid.com/2018/02/14/translations-with-rails-and-jekyll/ is a personal blog post about how it was done and why.
I hope to see whether this approach will work for choosealicense.com soon, but as usual any thoughts welcome.