07 Jul 2025
O Jekyll-Polyglot 1.10 já está disponível. Ele traz grandes melhorias e mudanças no plugin liquid i18n_headers para SEO, além de pequenos ajustes para idempotência em builds paralelos. Contribuições da comunidade e Vibe Coding ajudaram em grande parte dos recursos, testes e redação deste lançamento.
O plugin i18n_headers agora possui capacidades estendidas nesta versão:
- adiciona
<link rel="canonical" ...> para cada idioma da página, garantindo que a indexação seja única em todos os sites.
- adiciona
<link rel="alternate" hreflang="x-default" ...> para apontar para a versão padrão do site quando nenhum idioma correspondente é solicitado pelo navegador.
- define corretamente
<link rel="alternate" hreflang="..."> para páginas e posts em coleções com permalinks personalizados.
- a URL padrão agora incluirá
site.baseUrl se definido.
Isso também corrige um bug que fazia com que a relativização de URLs absolutas alterasse essas tags involuntariamente.
Contribuições vibe-coded
O uso de certas ferramentas de vibe coding ajudou a encontrar, medir e verificar correções e recursos para este lançamento. Essa é uma nova abordagem para o desenvolvimento de software e permitiu a criação de testes Ruby avançados para código de plugin Jekyll executado em muitos idiomas do site.
Os testes escritos com vibe coding ajudaram a manter a alta cobertura de testes e a adicionar recursos complexos com confiança. Garantir a automação dos testes permitiu que recursos complicados fossem construídos corretamente.
Além disso, as ferramentas de vibe coding ajudaram a traduzir este post do blog para muitos idiomas.
Contribuições da comunidade
O Jekyll-Polyglot tem sido apoiado por pessoas. A documentação em linguagem humana é contribuída por pessoas que querem ver este plugin documentado em sua língua materna. Pessoas que contribuem com correções de bugs e documentação ajudaram este plugin a alcançar milhares de downloads por lançamento. A programação assistida por IA, em minhas ou suas mãos, moldará o software que usamos e os muitos idiomas em que escrevemos e falamos.
ruby >= 3.1 obrigatório
Atualizações contínuas de segurança das dependências de build do jekyll-polyglot exigiram uma atualização importante para ruby 3.1. Isso pode afetar sistemas de build que geram documentação com jekyll-polyglot. Agora é um bom momento para atualizar para a versão principal mais recente do ruby. Avise se essas mudanças causarem complicações nas builds do jekyll.
18 Jan 2025
Jekyll-Polyglot 1.9.0 foi lançado, que possui pequenas atualizações de dependência e melhorias instrucionais para obter o máximo do seu site multilíngue.
Melhorias instrucionais fornecidas pela comunidade
Obrigado a aturret por ajudar a manter as páginas do site chinês (zh-CN) existentes. 谢谢！
george-gca aprimorou a configuração opcional derive_lang_from_path para melhor identificar o idioma do documento a partir da inferência do caminho. Testes foram adicionados para seu útil PR de melhoria de recurso. Essa melhoria ajuda a inferir o idioma de posts e páginas sem frontmatter lang, de qualquer parte do caminho do arquivo do documento.
O usuário do Github yunseo-kim enviou instruções para melhorar a geração de sitemap. Para ajudar no SEO, um site deve ter apenas um sitemap.xml raiz, e não duplicatas para cada site de sub-linguagem. Certifique-se de adicionar sitemap.xml à configuração exclude_from_localization.
18 Aug 2024
Jekyll-Polyglot 1.8.1 foi lançado, trazendo algumas melhorias de recursos e reconhecendo bugs identificados pela comunidade, para os quais foram fornecidas correções.
Correções de Bugs Fornecidas pela Comunidade
hacketiwack contribuiu com uma verificação mais rigorosa para definir um permalink de documento, evitando problemas posteriores com campos vazios de frontmatter.
O usuário do Github blackpill enviou uma correção de bug de um caractere para a tag de cabeçalhos i18n ao renderizar o href alternativo do link do idioma padrão.
17 Mar 2024
Fique animado com o Jekyll-Polyglot 1.8.0, que tem algumas melhorias de recursos e reconhece a documentação e contribuições da comunidade!
links permanentes específicos idoma
Um novo recurso é fornecer links permanentes específicos ao idioma das páginas e manter sua associação com outras páginas relativas. Este novo recurso foi novamente aprimorado por antoniovazquezblanco, que é um cavalheiro e estudioso.
geração de mapa de site e SEO i18n
Este lançamento também reconhece a qualidade sitemap.xml y robots.txt solução fornecida por jerturowetz. Este site agora demonstra e captura mais poder de SEO ao usá-los para ser rastreável como um site jekyll estático por provedores de pesquisa. Veja os arquivos do site de exemplo aqui.
jekyll :polyglot :post_write hook
Github user obfusk contribuiu com pequeno PRs alguns anos atrás:
Com o poliglota :site, :post_write como estes são executados para cada processo filho:
Jekyll::Hooks.register :site, :post_write do |site|
...
end
Esta versão adiciona um personalizado :post_write hook que é executado exatamente uma vez, depois que todos os idiomas foram processados (whether or not parallel_localization is used):
Jekyll::Hooks.register :polyglot, :post_write do |site|
# faça algo incrível aqui!
end
Este recurso é útil para sites estáticos jekyll complexos que fazem uso adicional de jekyll hook plugins.
Obfusk também contribuiu com uma correção para registro adicional quando os subprocessos da linguagem falham. Obrigado por esta contribuição!
variáveis localizadas e tradução para o português.
george-gca é um cara talentoso e incrível, ele contribuiu com um todo blogpost por qual a melhor forma de localizar rich text dos dados do site. Ele também forneceu umsite de tradução brasileiro.
29 Feb 2024
Polyglot permite que você tenha diferentes páginas para diferentes idiomas em seu site Jekyll. Por exemplo, você pode ter uma página about.md em inglês e outra about.md em espanhol com layouts completamente diferentes. Mas se você quiser ter o mesmo layout para todas as páginas, você pode usar variáveis traduzidas. Esta é uma maneira de ter diferentes dados para diferentes idiomas em seu site Jekyll, mas usando o mesmo layout para todos os idiomas.
Como exemplo, usarei um site modelo criado com Polyglot.
Compartilhando um layout entre páginas
Nesse site eles têm uma página sobre para cada idioma, no caso deles inglês em _pages/en-us/about.md e português brasileiro em _pages/pt-br/about.md. Em ambas as páginas podemos ver que elas têm as mesmas chaves no frontmatter, mas algumas com valores diferentes. Ambos os arquivos apontam para o mesmo layout, about, e este layout usa os valores no frontmatter para renderizar a página.
Por exemplo, a chave subtitle na página em inglês tem o valor subtitle: <a href='#'>Affiliations</a>. Address. Contacts. Moto. Etc. e na página em português brasileiro tem subtitle: <a href='#'>Afiliações</a>. Endereço. Contatos. Lema. Etc.. Essa informação no layout é usada dessa forma:
O mesmo vale para o conteúdo abaixo do frontmatter em ambos os arquivos, que é simplesmente usado no layout dessa forma:
Polyglot renderizará automaticamente a página com os valores corretos para o idioma atual.
Para o subtitle da página eles usaram pares chave: valor no frontmatter, mas às vezes queremos usar esses mesmos pares em diferentes partes do site. Por exemplo, se quisermos usar o mesmo subtitle no about.md e em outra página, teríamos que repetir o mesmo par no frontmatter de ambas as páginas. Isso não é ideal porque se quisermos mudar o subtitle teríamos que mudá-lo em dois lugares. É aí que entram os dados traduzidos. Você pode criar um arquivo como _data/:lang/strings.yml, um para cada idioma, e o Polyglot trará essas chaves sob site.data[:lang].strings.
Por exemplo, no site modelo existem dois arquivos, _data/en-us/strings.yml e _data/pt-br/strings.yml. No primeiro arquivo eles têm:
latest_posts: latest posts
E no segundo arquivo eles têm:
latest_posts: últimas postagens
Dessa forma, eles podem usar a chave latest_posts no layout assim:
{{ site.data[site.active_lang].strings.latest_posts }}
O que obterá corretamente o valor para a variável latest_posts definida no arquivo _data/:lang/strings.yml para o idioma atual.
Definindo qual variável usar no frontmatter
Agora, se você quiser definir essa variável no frontmatter da página, isso fica um pouco mais complicado. Uma possível solução é verificar se o valor da variável tem um . nele e, se tiver, usar o valor no arquivo _data/:lang/strings.yml. É assim que você faria:
{% 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 }}
Isso funcionará, por exemplo, se frontmatter_var = blog.title.
Agora, se você precisar verificar se a string de tradução (neste caso blog.title) realmente existe no arquivo _data/:lang/strings.yml antes de usá-la, você terá que criar um plugin para verificar se a variável existe no arquivo _data/:lang/strings.yml e, se existir, usá-la, caso contrário, retornar para qualquer valor que você quiser. Não entrarei em detalhes sobre como fazer isso, mas mostrarei como usá-lo. Você pode ver o código do plugin aqui.
{% 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 }}