This repository has been archived by the owner on Jan 15, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 205
Different behavior for BUILD and SERVE #159
Comments
21 tasks
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.
21 tasks
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.
I found this issue as well. The analysis by OP is correct:
This would be fixed by: #207 |
Thank you @figgles for fixing it! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
We observed that
jekyll serve
andjekyll build
seem to behave differently in regards tosite.translations
. Whereas theserve
process seems to build a hash from all available languages, then build the site, thebuild
process seems to start building a first version with only that locale present in thesite.translations
hash.Consider the following snippet:
And the following
yaml
files: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?
The text was updated successfully, but these errors were encountered: