Polyglot 1.10 - améliorations de i18n_headers

Jekyll-Polyglot 1.10 est maintenant disponible. Il apporte de vastes améliorations et changements au plugin liquid i18n_headers pour le SEO, ainsi que des ajustements mineurs pour l’idempotence lors des constructions parallèles. Les contributions de la communauté et le Vibe Coding ont aidé à une grande partie des fonctionnalités, des tests et de la rédaction de cet article.

Améliorations de i18n_headers

Le plugin i18n_headers dispose désormais de capacités étendues dans cette version :

• Il ajoute <link rel="canonical" ...> pour chaque langue de page, afin que l’indexation soit unique sur tous les sites.
• Il ajoute <link rel="alternate" hreflang="x-default" ...> pour pointer vers la version par défaut du site lorsqu’aucune langue ne correspond à la demande du navigateur.
• Il définit correctement <link rel="alternate" hreflang="..."> pour les pages et articles dans des collections avec des permaliens personnalisés.
• L’URL par défaut inclura désormais site.baseUrl si défini.

Cela corrige également un bug qui causait la modification involontaire de ces balises lors de la relativisation des URLs absolues.

Contributions vibe-coded

L’utilisation de certains outils de vibe coding a permis de trouver, mesurer et vérifier les corrections de bugs et les fonctionnalités de cette version. C’est une nouvelle approche du développement logiciel, qui a permis d’écrire des tests Ruby avancés pour le code du plugin Jekyll exécuté sur de nombreux sites multilingues.

Les tests écrits avec vibe coding ont permis de maintenir une couverture de test élevée et d’ajouter des fonctionnalités complexes en toute confiance. L’automatisation des tests a permis de garantir la bonne construction de fonctionnalités délicates.

De plus, les outils de vibe coding ont aidé à traduire cet article de blog dans de nombreuses langues.

Contributions de la communauté

Jekyll-Polyglot est soutenu par des humains. La documentation linguistique humaine est apportée par des personnes qui souhaitent voir ce plugin documenté dans leur langue maternelle. Les personnes qui contribuent à la correction de bugs et à la documentation ont permis à ce plugin d’atteindre des milliers de téléchargements à chaque version. La programmation assistée par l’IA, entre mes mains ou les vôtres, façonnera les logiciels que nous utilisons, et dans les nombreuses langues que nous écrivons et parlons.

ruby >= 3.1 requis

Les mises à jour de sécurité continues des dépendances de compilation de jekyll-polyglot ont nécessité une mise à niveau majeure vers ruby 3.1. Cela peut affecter les systèmes de build qui génèrent leur documentation avec jekyll-polyglot. C’est le bon moment pour passer à la dernière version majeure de ruby. Faites-nous savoir si ces changements posent des problèmes avec les builds jekyll.

Polyglot 1.9.0 - Instructional Improvements

Jekyll-Polyglot 1.9.0 has been released, which has minor dependency updates, and instructional improvements for getting the most from your multi-language website.

Community provided instructional improvements

Thank you to aturret for helping to maintain the existing zh-CN site pages. 谢谢！

george-gca improved the optional derive_lang_from_path configuration to better identify document language from the path inference. Tests were added for his helpful feature improvement PR. This improvement helps infer the language of posts and pages missing lang frontmatter, from any part of the document filepath.

Github user yunseo-kim submitted a instructions to improve sitemap generation . To help with SEO, a website should have only one root sitemap.xml , and not have duplicates for each sub-language site. Be sure to add the sitemap.xml to the exclude_from_localization configuration.

Polyglot 1.8.1 - Community Bug Fixes Release

Jekyll-Polyglot 1.8.1 has been released, which has a few feature improvements and recognizes community found bugs and provided fixes.

Community provided bugfixes

hacketiwack provided a stricter check for setting a doc permalink, preventing downstream problems with empty frontmatter fields.

Github user blackpill submitted a one character bugfix for the i18n headers tag when rendering the default language link alternative href.

Polyglot 1.8.0 - Community Contributions Release

Get excited for Jekyll-Polyglot 1.8.0, which has a few feature improvements and recognizes community documentation and contributions!

language specific permalinks

One new feature is to give pages language specific permalinks and to retain their association to other relative pages. This new feature is again improved by antoniovazquezblanco, who is a gentleman and a scholar.

sitemap generation & i18n SEO

This release also recognizes the quality sitemap.xml and robots.txt solution provided by jerturowetz. This website now demonstrates and captures more SEO power by using these to be crawlable as a static jekyll website by search providers. See the example website files here.

jekyll :polyglot :post_write hook

Github user obfusk contributed a tiny PR a few years back:

With polyglot :site, :post_write like these run for each child processes:

Jekyll::Hooks.register :site, :post_write do |site|
  ...
end

This release adds a custom :post_write hook that runs exactly once, after all languages been processed (whether or not parallel_localization is used):

Jekyll::Hooks.register :polyglot, :post_write do |site|
  # do something amazing here!
end

This feature is helpful for complex jekyll static sites that make additional use of jekyll hook plugins.

She also contributed a fix for additional logging when language subprocesses crash. Thanks for this contribution!

localized variables and portuguese translation.

george-gca is a talented and awesome guy, contributing an entire blogpost on how best to localize rich text from site data. He also provided a site brazilian translation.

Localized variables

Polyglot allows you to have different pages for different languages in your Jekyll site. For example, one could have a page about.md in English and another about.md in Spanish with completely different layouts. But if you want to have the same layout for both pages, you can use localized variables. This is a way to have different data for different languages in your Jekyll site, but using the same layout for all languages.

As an example I will use a template site created with Polyglot.

Sharing a layout between pages

In that site they have an about page for every language, in their case english in _pages/en-us/about.md and brazilian portuguese in _pages/pt-br/about.md. In both pages we can see that they have the same keys in the frontmatter, but some with different values. Both files point to the same layout, about, and this layout uses the values in the frontmatter to render the page.

For example, the subtitle key in the english page has the value subtitle: <a href='#'>Affiliations</a>. Address. Contacts. Moto. Etc. and in the brazilian portuguese page it has subtitle: <a href='#'>Afiliações</a>. Endereço. Contatos. Lema. Etc.. To use this information in the layout, it is used like this:

{{ page.subtitle }}

The same goes for the content below the frontmatter in both files, which is simply used in the layout like this:

{{ content }}

Polyglot will automatically render the page with the correct values for the current language.

Sharing a layout between pages with localized data

For the subtitle of the page they used key: value pairs in the frontmatter, but sometimes we want to use these same pairs in different parts of the site. For example, if we want to use the same subtitle in the about.md and in another page, we would have to repeat the same pair in the frontmatter of both pages. This is not ideal because if we want to change the subtitle we would have to change it in two places. This is where localized data comes in. You can create a file like _data/:lang/strings.yml, one for each language, and Polyglot will bring those keys under site.data[:lang].strings.

For example, in the template site there are two files, _data/en-us/strings.yml and _data/pt-br/strings.yml. In the first file they have:

latest_posts: latest posts

And in the second file they have:

latest_posts: últimas postagens

This way, they can use the latest_posts key in the layout like this:

{{ site.data[site.active_lang].strings.latest_posts }}

Which will correctly get the value for the latest_posts variable defined in the file _data/:lang/strings.yml for the current language.

Defining which variable to use in the frontmatter

Now if you want to define this variable in the frontmatter of the page, this gets a little bit trickier. One possible solution is to check if the value of the variable has a . in it, and if it does use the value in the file _data/:lang/strings.yml. This is how you would do it:

{% if frontmatter_var contains '.' %}
  {% assign first_part = frontmatter_var | split: '.' | first %}
  {% assign last_part = frontmatter_var | split: '.' | last %}
  {% capture result %}{{ site.data[site.active_lang].strings[first_part][last_part] }}{% endcapture %}
{% endif %}

{{ result }}

This will work, for example, if frontmatter_var = blog.title.

Now, if you need to check if the localization string (in this case blog.title) actually exists in the file _data/:lang/strings.yml before using it, you’ll have to create a plugin to check if the variable exists in the file _data/:lang/strings.yml and if it does, use it, otherwise fallback to any value you want. I will not go into detail on how to do this, but I will show you how to use it. You can see the code for the plugin here.

{% if frontmatter_var contains '.' %}
  {% capture contains_localization %}{% localization_exists {{ frontmatter_var }} %}{% endcapture %}
  {% if contains_localization == 'true' %}
    {% assign first_part = frontmatter_var | split: '.' | first %}
    {% assign last_part = frontmatter_var | split: '.' | last %}
    {% capture result %}{{ site.data[site.active_lang].strings[first_part][last_part] }}{% endcapture %}
  {% else %}
    {% capture result %}fallback value{% endcapture %}
  {% endif %}
{% endif %}

{{ result }}