Skip to content
This repository has been archived by the owner on Jan 15, 2024. It is now read-only.

How to put the default language in a subfolder? #86

Open
klaasnotfound opened this issue Jan 27, 2017 · 10 comments
Open

How to put the default language in a subfolder? #86

klaasnotfound opened this issue Jan 27, 2017 · 10 comments

Comments

@klaasnotfound
Copy link

klaasnotfound commented Jan 27, 2017

This is a fantastic plugin - thank you so much for creating it!

One thing that I was unable to figure out is how to configure the plugin so that all the languages (including the default language) end up in a subfolder.
Suppose I have languages ["en", "de"]. English is the default and put into the root folder. However, for consistency I would like to have the English content in the subfolder en/, just like the German content, which resides in de/.

Is this possible?

@efkawu
Copy link

efkawu commented Jan 27, 2017

Good question, I have got the same issue.

@klaasnotfound
Copy link
Author

klaasnotfound commented Jan 30, 2017

Since the plugin doesn't seem to support this, I have hacked together a basic solution. I had to learn some Ruby (and the basics of Jekyll plugins) first, so it's probably not the prettiest approach. But it's working.

To use it, you need to install the plugin manually. If you were using the installed version of the plugin before, be sure to remove the old plugin gems entry from your _config.yml, otherwise you're invoking two versions of the plugin and will see errors. Then replace the jekyll-multiple-languages-plugin.rb in the lib folder with this code.

The modified version does three things:

  • The default language (the first one in the languages array) is now put into a subfolder, just like the other languages. The script respects the exclude_from_localizations entry and puts these assets into the root folder of your _site.
  • Because all the languages now reside in their own subfolder there is no central index.html, which is a bit inconvenient. The script therefore (by convention) looks for a file called base.html in the root folder of your project. If that file exists, it becomes the new index.html of your _site. You can use base.html to do detect the browser language and redirect the user to the right subfolder. I have provided a minimal working example here.
  • I also needed to use custom collections. The original plugin currently doesn't support translating permalinks and namespace links for collection documents (see other issue), so I fixed this.

In a nutshell, when using the modified plugin you should be able to run jekyll build on a multilingual site with custom collections and end up with a properly built _site that has each language in its own subfolder, an index.html that does redirects (provided you have a base.html file) and the ability to use the {% tl ... %} and {% tf ... %} tags with correctly localized permalinks.

Note: The modified plugin is currently incompatible with the original (I had to remove and alter some code that relied on the default language being in the root folder), which is why I didn't crate a pull request. As of now, I don't have the time and/or Ruby/Jekyll expertise to reconcile the two approaches, but I'm hoping some of the more experienced contributors can pick it up from here. A basic flag in the _config.yml (e.g. default_lang_in_root_folder) could indicate whether to use one solution or the other.

@Etua
Copy link

Etua commented May 29, 2017

Definitely in need of out of the box solution. I'd like to use this feature however I don't want to mess with configuring gems manually.

@Paludis
Copy link

Paludis commented Jun 28, 2017

Same issue here. For consistency I want all languages in their own subfolder.

@aumars
Copy link

aumars commented Jul 17, 2017

@klaasnotfound I panicked when I found out that the plugin couldn't support GitHub Pages, you saved me! You should continue fixing the issue and maybe make a pull request.

@klaasnotfound
Copy link
Author

@aumars Yeah, that would be the right thing to do... Unfortunately I currently don't have the time or Ruby skills to work on it.

I forgot to mention that I wrote a small blog post on how to use the modified plugin:
http://www.klaasnotfound.com/2017/02/16/proper-multilingual-site-with-github-pages-and-jekyll/

It provides a bit more detail on how to set up a new site and what to watch out for when using GitHub Pages and i18n.

@mstfacmly
Copy link

@klaasnotfound While I wasn't able to use the plugin, your solution did provide me with what I needed to get a translated website fully working. Thanks!

@mkamensky
Copy link

I solved this by symlinking the destination root directory to the default language. I do this with a hook:

Jekyll::Hooks.register :site, :post_write do |site|
  default = site.config['default_lang']
  next unless site.config['lang'] == default

  puts "Linking default language '#{default}':"
  require 'fileutils'
  FileUtils.cd(site.dest, verbose: true) do
    FileUtils.symlink('.', default, verbose: true)
  end
end

@antwal
Copy link

antwal commented Jun 15, 2019

hi i have tested but not working with collections or with paginate-v2 plugin; is possible fix it without use base.html? Thanks

@maesitos
Copy link
Contributor

work around for this issue:

Include two times the default language in _config.yml

languages: ["en", "en", "es"]
defaultLang: en

I recommend to include the canonical url in the HTML header to avoid duplicated content:

<!-- CANONICAL -->
{% if page.namespace %}
  {% if site.lang == site.defaultLang %}
    <link rel="canonical" href="{{ site.url }}/{{site.defaultLang}}{% tl {{ page.namespace }} {{ site.lang }} %}" />
  {% else %}
    <link rel="canonical" href="{{ site.url }}{% tl {{ page.namespace }} {{ site.lang }} %}" />
  {% endif %}
{% else %}
  {% if page.url == "/" %}
    <link rel="canonical" href="{{ site.url }}/{{site.lang}}" />
  {% else %}
    <link rel="canonical" href="{{ site.url }}/{{site.lang}}{{page.url}}" />
  {% endif %}
{% endif %}

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants