Jekyll-Polyglot 1.8.1 has been released, which has a few feature improvements and recognizes community found bugs and provided fixes.
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.
Freuen Sie sich auf Jekyll-Polyglot 1.8.0, das einige Funktionsverbesserungen bietet und Beiträge und Dokumentationen der Community anerkennt!
Eine neue Funktion besteht darin, Seiten sprachspezifische Permalinks zu geben und ihre Verknüpfung mit anderen relativen Seiten beizubehalten. Diese neue Funktion wurde erneut von antoniovazquezblanco verbessert antoniovazquezblanco, ein wahrer Gentleman und Gelehrter.
Diese Version erkennt außerdem die Qualität sitemap.xml und robots.txt solution provided by jerturowetz. Diese Website demonstriert und nutzt jetzt mehr SEO-Leistung, indem sie diese Einstellungen verwendet, um von Suchmaschinen als statische Jekyll-Website gecrawlt werden zu können. Sehen Sie sich die Beispiel-Website-Dateien hier.
Github-Benutzer obfusk hat vor einigen Jahren PR einen winzigen Beitrag geleistet a:
Mit polyglot :site, :post_write diese Funktion wird einmal pro untergeordnetem Prozess ausgeführt:
Jekyll::Hooks.register :site, :post_write do |site|
...
end
Diese Version fügt einen benutzerdefinierten Hook :post_write hinzu, der genau einmal ausgeführt wird, nachdem alle Sprachen verarbeitet wurden (ob parallel_localization verwendet wird):
Jekyll::Hooks.register :polyglot, :post_write do |site|
# Mach hier etwas Großartiges!
end
Diese Funktion ist hilfreich für komplexe statische Jekyll-Websites, die zusätzlich genutzt werden jekyll hook plugins.
Sie hat außerdem einen Fix für zusätzliche Protokollierung bei Abstürzen von Sprach-Subprozessen. Vielen Dank für diesen Beitrag!
george-gca ist ein talentierter und großartiger Kerl, Er hat einen ganzen Blogbeitrag beigesteuert zum Thema, wie man Rich Text aus Website-Daten am besten lokalisiert. Er hat außerdem die Brasilianische Portugiesisch Website-Übersetzung.
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.
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.
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.
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 }}
I’m excited to announce Jekyll-Polyglot 1.7.0, which has a new feature to give pages language specific permalinks and to retain their association to other relative pages.
This new feature is provided by antoniovazquezblanco, who is a gentleman and a scholar.
page_id frontmatter to associate pages with different permalinksPolyglot associates pages by matching their permalinks or filenames. However some site translations may instead desire pages with unique permalinks.
Polyglot already coordinates multiple copes of the same document across different languages. So keying off of a different property like page_id is no different than keying off of the permalink.
Using a page_id to coordinate similar pages with different permalinks ensures that custom permalinks can still be seen on language specific sites.
The challenge with unique permalinks comes with relativizing those urls. Polyglot avoids this problem entirely by suggesting consistent permalinks.
To help with this, polyglot sets redirect_from hidden frontmatter on these pages, listing the unique permalinks of corresponding pages.
When using the jekyll-redirect-from plugin, that frontmatter will be picked up, and intelligent redirects made to the page’s custom permalink.
To see this in action, visit this page with a long permalink in different languages.
The Polyglot website has been updated with support for Chinese!
This is made possible by aturret, who contributed numerous bugfixes to the plugin, the website, and an entirely new site translation.
Additionally, jekyll-polyglot 1.6.0 is now available from rubygems.
Polyglot used String::gsub! which mutates a .frozen? string. This has now been fixed to duplicate the cloned string before modifying it.
A typo in the html on the site layout prevented the previous page navigation from being translated correctly.
With a big 谢谢 of support and appreciation to aturret, polyglot.untra.io now supports a zh-CN Simplified Chinese translation!