prepare a base for i18n

[weakish]

Simply move translated pages to /LOCALE/ will cause:

• broken links
• broken images

This is because:

• The default layouts assume resources are located in the root
  directory.
• In content pages, some links link to the root directory also.

This commit fix the above problems and add a example of /LOCALE/,
i.e. /en/, which can be
used as the base for i18N.

See #68

[haacked]

Got a screenshot of what the breadcrumb looks like with this change? Also, English should be the default language. What would I see if I visit http://choosealicense.com or http://choosealicense.com/about with this change?

[weakish]

@haacked For Demo, See http://weakish.gitcafe.com/en/

What would I see if I visit http://choosealicense.com or http://choosealicense.com/about with this change?

I didn't touch these pages.
They are the same with before.
You can check http://weakish.gitcafe.com and http://weakish.gitcafe.com/about, etc.

I hope /en/ can be used as a base for translation.

[haacked]

So in the English case, we'd have to duplicate every change we made. I'm not a fan of that. Jekyll has a new Data Files feature. I wonder if it wouldn't make more sense to leverage that somehow. For example, have translations in a data file and figure out a way to pipe them into existing templates.

I'm totally ✋ 👋ing here as I haven't really thought this through. But copying HTML files is going to be a royal pain because the content changes a lot!

[weakish]

@haacked Data Files is for customizing templates, not for content of pages.

I am afraid that copying HTML files cannot be avoided, since Jekyll itself does not support i18N.

We can make a script to automate this, though.

[haacked]

Data Files is for customizing templates, not for content of pages.

Sure, but couldn't we use it for content? Nothing prevents that, right?

[benbalter]

I am afraid that copying HTML files cannot be avoided

That's not an option. That'd be a maintenance nightmare.

Since Jekyll itself does not support i18N.

Let's fix that.

@parkr what do you think about adding an i18n tag or similar? Thinking out loud, but this would be the ideal workflow:

• In _data have a yaml file for each non-primary language. Call it es_i18n.yml or something.
• In your templates wrap translatable strings with the i18n tag, e.g., {% i18n %}Some string{% endi18n %}
• At build time, Jekyll would create parallel versions of files for each language, e.g., /es/index.html
• Non-translated strings get passed as is
• No idea how to do posts (yet)

[serieznyi]

This is main issue about translate site to other languages? I am very interested in translation site to Russian. Realties have any shifts in establishing mechanisms to transfer?

[liks79]

@serieznyi I agree with you. I have tlanslated old version of this project. But I'm holding now. Because there are no explicit solution until now. I hope find a way for I18N.

[benbalter]

Would still love to see this happen, but don't know that we have a clean path forward and may need to wait until Jekyll-core (or perhaps a Jekyll plugin) adds support. Commented over in jekyll/jekyll#1809 to hopefully see that happen.

Specifically, I'd love some mechanism by which we wouldn't have to change everything (e.g., a site would work out fo the box), but where a translation existed, it could generate that translation, falling back to the default language. Put another way, any current Jekyll site should be ready to translation with the addition of a language, not through abstraction into, e.g., footer_en_EN.html.

[jamiefolsom]

+1

[stuartpb]

What about the text of the licenses themselves? Are there official translations of the MIT license?

[bkeepers]

@weakish thanks for all the work you put into this. It seems like this is stalled. Is there anything we can do to push this forward? As @stuartpb asked, are there official translations of licenses?

[weakish]

@bkeepers

It seems like this is stalled. Is there anything we can do to push this forward?

IMO the possible choices (to avoid copying duplicated pages) are:

1. Use separated domain for each locale, for example, fork github/choosealicense.com to github/kr.choosealicense.com with the CNAME kr.choosealicense.com for Korean.
2. Switch other site generator with nice i18n support, e.g. Pelican.
3. Put all the content of current choosealicense.com into en.choosealicense.com, and turn choosealicense.com into a landing page linking to several languages, like Wikipedia.
4. Wait for Jekyll to have nice i18n support (less likely to happen).

As @stuartpb asked, are there official translations of licenses?

AFAIK, only Creative Commons have official translations.

[bkeepers]

@weakish Thanks for all the work you put into this. It seems like there is not a great path forward right now. That issue along with the lack of official translations makes it seem like this isn't likely to move forward right now. I'm going to close this for now. We're happy to reconsider if someone is interested in putting in the work to make this happen, but it's not a priority for us right now.