kurtsson / jekyll-multiple-languages-plugin

I18n support for Jekyll and Octopress
MIT License
922 stars 203 forks source link

Referencing another language not yet loaded during build gives empty result #206

Closed figgles closed 10 months ago

figgles commented 11 months ago

TL;DR: Looks like language resources are lazy loaded during <% t %> or building the site for that language and that makes directly referencing site.translations[ xyz ], where xyz is a language that has not yet been processed, give an empty string. This only happens with jekyll build; using jekyll serve works correctly.

There are two ways to fix this in my opinion. First is to just load all of the languages once and get rid of the lazy loading scheme. Second, allow users to specify a language as an argument to <% t %> and let it handle lazy loading. However, given that site.translations is an officially supported method, I think the former is better. Below are steps to reproduce the issue plus context:


I'm generating a language switching bar. I loop through the list of languages and print their names in the translated native language, i.e. Spanish becomes español.

<ul>
  {% comment %} Generate a li/a pair for each language code configured in the site {% endcomment %}
  {% for langcode in site.languages %}
  <li><a href="{% translate_link example {{langcode}} %}">{{site.translations[langcode].lang_name}}</a></li>
  {% endfor %}
</ul>
#_config.yml
languages: ["en", "es"]
#_i18n/en.yml
lang_name: "English"
#_i18n/es.yml
lang_name: "español"

When running jekyll serve, the output is correct:

<ul>
  <li><a href="/en/index.html">English</a></li>
  <li><a href="/es/index.html">español</a></li>
</ul>

When running jekyll build, the first language, English, has a missing translated name:

<ul>
  <li><a href="/en/index.html">English</a></li>
  <li><a href="/es/index.html"> </a></li>
</ul>

In both cases (jekyll build and jekyll serve), the generated pages for Spanish (second language to process) are correct because by then, both English & Spanish translations have been parsed, indicating it is a load-order dependent issue.

I might be able to code a PR for the first case (preloading all languages) as I will need to work around this issue for myself. Let me know if this solution would be acceptable.