Polyglot 1.10 - verbeteringen aan i18n_headers

Jekyll-Polyglot 1.10 is nu beschikbaar. Het bevat grote verbeteringen en wijzigingen aan de i18n_headers liquid plugin voor SEO, en kleine aanpassingen voor idempotentie bij parallel bouwen. Communitybijdragen en Vibe Coding hebben geholpen bij een groot deel van deze releasefuncties, testen en blogpost.

Verbeteringen aan i18n_headers

De i18n_headers plugin heeft nu uitgebreide mogelijkheden in deze release:

• voegt <link rel="canonical" ...> toe voor elke paginataal, zodat indexering uniek is op alle sites.
• voegt <link rel="alternate" hreflang="x-default" ...> toe om te verwijzen naar de standaardtaalversie van een site, wanneer geen overeenkomende taal door de browser wordt aangevraagd.
• definieert <link rel="alternate" hreflang="..."> correct voor pagina’s en berichten in collecties met aangepaste permalinks.
• de standaard-URL bevat nu site.baseUrl indien gedefinieerd.

Dit verhelpt ook een bug waarbij het relativiseren van absolute URL’s deze tags onbedoeld kon wijzigen.

Vibe-coded bijdragen

Het gebruik van bepaalde vibe coding tools heeft geholpen bij het vinden, meten en verifiëren van bugfixes en features voor deze release. Dit is een nieuwe aanpak voor softwareontwikkeling en maakte geavanceerde Ruby-tests mogelijk tegen Jekyll plugin-code die draait op veel gebouwde sitetalen.

De met vibe coding geschreven tests hielpen om de testdekking hoog te houden en complexe features met vertrouwen toe te voegen. Door testautomatisering konden lastige features correct worden gebouwd.

Daarnaast hielpen vibe coding tools bij het vertalen van deze blogpost naar vele talen.

Communitybijdragen

Jekyll-Polyglot wordt ondersteund door mensen. Documentatie in menselijke taal wordt bijgedragen door mensen die deze plugin in hun moedertaal gedocumenteerd willen zien. Mensen die bugfixes en documentatie bijdragen, hebben ervoor gezorgd dat deze plugin bij elke release duizenden downloads bereikt. Door AI ondersteund programmeren, in mijn of jouw handen, zal de software die we gebruiken en de vele talen waarin we schrijven en spreken, vormgeven.

ruby >= 3.1 vereist

Doorlopende beveiligingsupdates voor de build-afhankelijkheden van jekyll-polyglot vereisten een grote upgrade naar ruby 3.1. Dit kan buildsystemen beïnvloeden die hun documentatie met jekyll-polyglot bouwen. Nu is een goed moment om te upgraden naar de nieuwste grote ruby-versie. Laat het weten als deze wijzigingen complicaties veroorzaken bij jekyll-builds.

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 - Communitybijdragen release

Wordt enthousiast voor Jekyll-Polyglot 1.8.0, dat een aantal functieverbeteringen bevat en documentatie en bijdragen van de community erkent!

Taalspecifieke permalinks

Een nieuwe functie is om pagina’s taalspecifieke permalinks te geven en hun koppeling met andere relatieve pagina’s te behouden. Deze nieuwe functie is opnieuw verbeterd door antoniovazquezblanco, een echte gentleman en een geleerde.

Sitemapgeneratie & meertalige SEO

Deze release erkent ook de kwaliteit sitemap.xml en robots.txt solution provided by jerturowetz. Deze website demonstreert en benut nu meer SEO-kracht door deze instellingen te gebruiken om door zoekmachines als een statische Jekyll-website gecrawld te kunnen worden. Zie de voorbeeldwebsitebestanden hier.

jekyll :polyglot :post_write hook

Github-gebruiker obfusk heeft een paar jaar geleden PR een heel kleine bijdrage geleverd:

Met polyglot :site, :post_write deze functie wordt één keer uitgevoerd voor elk subprocess:

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

Deze release voegt een custom hook :post_write toe die precies één keer wordt uitgevoerd, nadat alle talen zijn verwerkt (of niet parallel_localization wordt gebruikt):

Jekyll::Hooks.register :polyglot, :post_write do |site|
  # Creëer hier iets geweldigs! 
end

Deze functie is handig voor complexe statische Jekyll-sites die extra worden gebruikt jekyll hook plugins.

Zij heeft ook een oplossing geleverd voor extra logboekregistratie bij crashes van taal-subprocessen. Bedankt voor deze bijdrage!

Gelokaliseerde variabelen en Portugese vertaling

george-gca is een getalenteerde en geweldige gast, Hij heeft een hele blogpost bijgedragen over de beste manier om rich text uit websitegegevens te lokaliseren. Hij heeft ook de Braziliaans-Portugese sitevertaling.

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 }}