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

Different behavior for BUILD and SERVE #159

Closed
kwisatz opened this issue Feb 20, 2020 · 2 comments
Closed

Different behavior for BUILD and SERVE #159

kwisatz opened this issue Feb 20, 2020 · 2 comments

Comments

@kwisatz
Copy link

kwisatz commented Feb 20, 2020

We observed that jekyll serve and jekyll build seem to behave differently in regards to site.translations. Whereas the serve process seems to build a hash from all available languages, then build the site, the build process seems to start building a first version with only that locale present in the site.translations hash.

Consider the following snippet:

               <ul class="dropdown-menu">
                  {% for language in site.languages %}
                  <li class="{% if site.lang == language %}lang-active{% endif %}">
                    <a
                      href="{{ site.baseurl_root }}/{% if language != 'en' %}{{ language }}{% endif %}{% if page.url != '/' %}{{ page.url }}{% endif %}"
                      title="{{ site.translations[language]['meta']['name'] }}">
                        {{ site.translations[language]['meta']['name'] }}
                    </a>
                  </li>
                  {% endfor %}
                </ul>

And the following yaml files:

meta:
  name: English
meta:
  name: Français
meta:
  name: Deutsch

In a serve context, this drop-down will correctly display links for all locales defined for the project.
However, in a build context, the dropdown for the first locale version will have empty values for any locale > 1, the second locale will only have values for 1 & 2 and the third locale version will have values for 1, 2 and 3.

So my assumption is that during the first run (1st locale), the site.translations hash does not yet have values for any locales other than that very first locale.

Can someone confirm that assumption and maybe explain why this difference exists?

ebroder added a commit to CAVaccineInventory/site that referenced this issue Feb 12, 2021
We're not using this currently, although I'd like to eventually use it
in the language picker (although we need a way through
kurtsson/jekyll-multiple-languages-plugin#159 first). In the mean time,
I'd like to make sure we get a translation from the person that's
translating the rest of the text, just so we don't have to go rooting
around for it ourselves.
ebroder added a commit to CAVaccineInventory/site that referenced this issue Feb 12, 2021
We're not using this currently, although I'd like to eventually use it
in the language picker (although we need a way through
kurtsson/jekyll-multiple-languages-plugin#159 first). In the mean time,
I'd like to make sure we get a translation from the person that's
translating the rest of the text, just so we don't have to go rooting
around for it ourselves.
@figgles
Copy link
Contributor

figgles commented Aug 3, 2023

I found this issue as well. The analysis by OP is correct:

So my assumption is that during the first run (1st locale), the site.translations hash does not yet have values for any locales other than that very first locale.

This would be fixed by: #207

@shushugah
Copy link
Collaborator

Thank you @figgles for fixing it!

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

3 participants