Polyglot 1.10 - i18n_headers 개선

Jekyll-Polyglot 1.10이 출시되었습니다. 이번 릴리스에서는 SEO 개선을 위한 i18n_headers liquid 플러그인에 대한 대대적인 개선과, 병렬 빌드의 멱등성 관련 소규모 조정이 포함되어 있습니다. 커뮤니티 기여자들과 Vibe Coding이 많은 기능, 테스트, 블로그 포스트 작성에 큰 도움을 주었습니다.

i18n_headers 개선 사항

이번 릴리스에서 i18n_headers 플러그인은 다음과 같은 확장된 기능을 갖추게 되었습니다:

• 각 페이지 언어별로 <link rel="canonical" ...>을 추가하여 사이트별 인덱싱이 고유하게 됩니다.
• 브라우저에서 일치하는 언어를 요청하지 않을 때, 사이트의 기본 언어 버전을 가리키는 <link rel="alternate" hreflang="x-default" ...>을 추가합니다.
• 커스텀 퍼머링크가 적용된 컬렉션 내의 페이지 및 포스트에 대해 <link rel="alternate" hreflang="...">를 올바르게 정의합니다.
• 기본 URL에 site.baseUrl이 정의되어 있다면 이를 포함합니다.

또한, 절대 URL을 상대화할 때 이러한 태그가 의도치 않게 손상되는 버그도 수정되었습니다.

vibe-coded 기여

vibe coding 도구를 활용하여 이번 릴리스의 버그 수정과 기능 추가를 찾고, 측정하고, 검증할 수 있었습니다. 이는 소프트웨어 개발의 새로운 접근 방식으로, 다양한 언어로 빌드된 사이트에서 동작하는 Jekyll 플러그인 코드를 대상으로 고급 Ruby 테스트를 작성할 수 있게 해줍니다.

vibe coding으로 작성된 테스트는 높은 테스트 커버리지를 유지하고, 복잡한 기능을 자신 있게 추가할 수 있도록 도왔습니다. 테스트 자동화로 인해 까다로운 기능도 올바르게 구현될 수 있었습니다.

또한, vibe coding 도구는 이 블로그 포스트를 여러 언어로 번역하는 데에도 도움을 주었습니다.

커뮤니티 기여

Jekyll-Polyglot은 사람들의 지원을 받아왔습니다. 인간 언어로 된 문서는 자신의 모국어로 이 플러그인이 문서화되기를 바라는 사람들이 기여합니다. 버그 수정과 문서화에 기여한 사람들은 이 플러그인이 릴리스마다 수천 번 다운로드되는 데 큰 역할을 했습니다. AI 지원 프로그래밍은 저와 여러분의 손에서 우리가 사용하는 소프트웨어와 우리가 쓰고 말하는 다양한 언어를 형성할 것입니다.

ruby >= 3.1 필요

jekyll-polyglot 빌드 타임 의존성의 지속적인 보안 업데이트로 인해 ruby 3.1로의 주요 버전 업그레이드가 필요했습니다. 이로 인해 jekyll-polyglot으로 문서를 빌드하는 시스템에 영향이 있을 수 있습니다. 지금이 최신 ruby 주요 버전으로 업그레이드할 좋은 시기입니다. 이 변경으로 인해 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이 출시되었습니다. 이번 릴리스에는 몇 가지 기능 개선 사항과 커뮤니티에서 발견된 버그 해결이 포함되어 있습니다.

커뮤니티 제공 버그 수정

hacketiwack은 문서 퍼malink 설정을 위한 보다 엄격한 검사를 제공하여 빈 프런트매터 필드로 인한 하류 문제를 방지했습니다.

Github 사용자 blackpill은 기본 언어 링크 대체 href 렌더링 시 i18n 헤더 태그에 대한 단일 문자 버그 수정을 제출했습니다.

Polyglot 1.8.0 - 커뮤니티 제공물 릴리스

몇 가지 기능 향상과 커뮤니티 문서 및 기여를 인정하는 Jekyll-Polyglot 1.8.0에 대해 기대를 높이세요! 몇 가지 기능 향상과 커뮤니티 문서 및 기여를 인정하는 제킬-폴리글롯 1.8.0 에 대해 기대를 높이세요!

언어별 고유 링크

한 가지 새로운 기능은 페이지에 언어별 고유 링크를 제공하고 다른 상대 페이지와의 연결을 유지하는 것입니다. 이 새로운 기능은 또 다시 antoniovazquezblanco 에 의해 개선되었습니다, 진실된 신사이면서 학식 있는 분입니다.

사이트맵 생성 및 다국어 SEO

이 릴리스는 또한 품질을 인정합니다 sitemap.xml 그리고 robots.txt solution provided by jerturowetz. 이 사이트는 이제 검색 엔진에 의해 정적 제킬 웹사이트로 크롤링될 수 있도록 이러한 설정을 사용하여 더 많은 SEO 기능을 보여주고 활용합니다. 여기 예시 웹사이트 파일을 참조하십시오.

jekyll :polyglot :post_write hook

Github 사용자 obfusk 몇 년 전 작은 기여를 했습니다 기여를 했습니다.

을 사용하여 polyglot :site, :post_write 이 기능은 각 자식 프로세스 실행 시 한 번 실행됩니다:

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

이 릴리스는 모든 언어가 처리된 후 정확히 한 번 실행되는 사용자 정의 후크 :post_write 를 추가합니다 (여부 parallel_localization 사용됩니다):

Jekyll::Hooks.register :polyglot, :post_write do |site|
  # 여기서 놀라운 것을 만들어 보세요!
end

이 기능은 추가적인 활용이 필요한 복잡한 제킬 정적 사이트에 유용합니다 jekyll hook plugins.

그녀는 또한 다음과 같은 문제를 해결하는 언어 서브 프로세스 충돌 시 추가 로깅. 이 기여에 감사합니다!

지역 변수 및 포르투갈어 번역

george-gca 재능이 뛰어나고 멋진 분입니다, 그는 전체 블로그 게시물을 기고했습니다 웹사이트 데이터에서 리치 텍스트를 가장 효과적으로 로컬라이징하는 방법에 대한. 그는 또한 제공했습니다 브라질 포르투갈어 사이트 번역.

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