@intlayer/docs 8.12.4 → 9.0.0-canary.10

package/docs/pt/autoFill.md

@@ -16,6 +16,9 @@ slugs:
   - concept
   - auto-fill
 history:
+  - version: 7.0.0
+    date: 2025-10-23
+    changes: "Renomear `fill` para `fill` e atualizar comportamento"
   - version: 6.0.0
     date: 2025-09-20
     changes: "Adicionada configuração global"
@@ -25,13 +28,80 @@ history:
   - version: 5.5.10
     date: 2025-06-29
     changes: "Histórico inicial"
+author: aymericzip
 ---
 
-# Traduções de Arquivos de Declaração de Conteúdo com Preenchimento Automático
+# Traduzir Traduções de Arquivo de Declaração de Conteúdo
 
 **Arquivos de declaração de conteúdo com preenchimento automático** são uma forma de acelerar seu fluxo de trabalho de desenvolvimento.
 
-O mecanismo de preenchimento automático funciona através de uma relação _mestre-escravo_ entre arquivos de declaração de conteúdo. Quando o arquivo principal (mestre) é atualizado, o Intlayer aplicará automaticamente essas alterações aos arquivos de declaração derivados (preenchidos automaticamente).
+## Entender o comportamento
+
+O comando `fill` inclui dois modos:
+
+- **Completo**: Preenche automaticamente todo o conteúdo faltante para cada localidade e edita o arquivo atual ou outro arquivo se especificado. Ou seja, o modo completo irá pular a tradução do conteúdo existente, se já foi traduzido.
+- **Revisão**: Preenche automaticamente **todo** o conteúdo para cada localidade e gera para um arquivo específico ou outro arquivo se especificado.
+
+O comando fill irá processar todos os seus arquivos de declaração de conteúdo de localidade. Ou seja, não irá processar seu conteúdo remoto do CMS. O CMS inclui seu próprio gerenciamento de traduções.
+Se você usar plugins como `@intlayer/sync-json-plugin`, o Intlayer transformará os arquivos JSON em arquivos de declaração de conteúdo por localidade. Ou seja, eles serão processados pelo comando `fill`.
+
+Os novos arquivos gerados incluem uma instrução `filled` como metadados do dicionário. Esta instrução será usada pelo Intlayer para saber se o arquivo foi preenchido automaticamente ou não e pular este arquivo de ser traduzido novamente se presente.
+
+O Intlayer também considerará a seguinte instrução para preenchimento automático:
+
+- Do seu `.content.{ts|js|json}` → instrução `fill`
+- Do seu arquivo de configuração `.intlayer.config.ts` → instrução `dictionary.fill`
+- Será definido como `true` por padrão caso contrário
+
+Para arquivos de declaração de conteúdo por localidade, a instrução `true` será substituída por `./{{fileName}}.fill.content.json`. Isto é porque um arquivo de declaração de conteúdo por localidade não pode receber conteúdo localizado adicional. Portanto, irá gerar um novo arquivo para não sobrescrever o arquivo existente.
+
+## Comportamento Padrão
+
+Por padrão, `fill` é definido como `true` globalmente, o que significa que o Intlayer irá preencher automaticamente todos os arquivos de conteúdo e editar o arquivo em si. Este comportamento pode ser customizado de várias formas:
+
+### Opções de Configuração Global
+
+1. **`fill: true` (padrão)** - Preenche automaticamente todas as localidades e edita o arquivo atual
+2. **`fill: false`** - Desabilita preenchimento automático para este arquivo de conteúdo
+3. **`fill: "./relative/path/to/file"`** - Cria/atualiza o arquivo especificado sem editar o arquivo atual apontando para um caminho relativo resolvido com base na localização do arquivo atual
+4. **`fill: "/absolute/path/to/file"`** - Cria/atualiza o arquivo especificado sem editar o arquivo atual apontando para um caminho relativo resolvido com base na localização do diretório base (campo `baseDir` no arquivo de configuração `.intlayer.config.ts`)
+5. **`fill: "C:\\absolute\path\to\file"`** - Cria/atualiza o arquivo especificado sem editar o arquivo atual apontando para um caminho absoluto resolvido com base no seu sistema operacional
+6. **`fill: { [key in Locales]?: string }`** - Cria/atualiza o arquivo especificado para cada localidade
+
+### Mudanças de Comportamento v7
+
+Na v7, o comportamento do comando `fill` foi atualizado:
+
+- **`fill: true`** - Reescreve o arquivo atual com conteúdo preenchido para todas as localidades
+- **`fill: "path/to/file"`** - Preenche o arquivo especificado sem modificar o arquivo atual
+- **`fill: false`** - Desabilita preenchimento automático completamente
+
+Ao usar uma opção de caminho para escrever em outro arquivo, o mecanismo de preenchimento funciona através de uma relação _mestre-escravo_ entre arquivos de declaração de conteúdo. O arquivo principal (mestre) serve como fonte da verdade e, quando é atualizado, o Intlayer aplicará automaticamente essas alterações aos arquivos de declaração derivados (preenchidos) especificados pelo caminho.
+
+### Customização Por Localidade
+
+Você também pode customizar o comportamento para cada localidade usando um objeto:
+
+```ts fileName="intlayer.config.ts"
+const config: IntlayerConfig = {
+  content: {
+    internationalization: {
+      locales: [Locales.ENGLISH, Locales.FRENCH, Locales.POLISH],
+      defaultLocale: Locales.ENGLISH,
+      requiredLocales: [Locales.ENGLISH], // Recomendado para evitar a propriedade 'pl' está faltando no tipo '{ en: string; xxx } na sua função t
+    },
+  },
+  dictionary: {
+    fill: {
+      en: true, // Preenche e edita o arquivo atual para Inglês
+      fr: "./translations/fr.json", // Cria arquivo separado para Francês
+      es: false, // Desabilita preenchimento para Espanhol
+    },
+  },
+};
+```
+
+Isto permite que você tenha comportamentos de preenchimento diferentes para diferentes localidades dentro do mesmo projeto.
 
 ```ts fileName="src/components/example/example.content.ts"
 import { Locales, type Dictionary } from "intlayer";
@@ -39,7 +109,7 @@ import { Locales, type Dictionary } from "intlayer";
 const exampleContent = {
   key: "example",
   locale: Locales.ENGLISH,
-  autoFill: "./example.content.json",
+  fill: "./example.content.json",
   content: {
     contentExample: "Este é um exemplo de conteúdo",
   },
@@ -49,7 +119,7 @@ const exampleContent = {
 export default exampleContent;
 ```
 
-Aqui está um [arquivo de declaração de conteúdo por localidade](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/per_locale_file.md) usando a instrução `autoFill`.
+Aqui está um [arquivo de declaração de conteúdo por localidade](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/per_locale_file.md) usando a instrução `fill`.
 
 Então, quando você executar o seguinte comando:
 
@@ -88,6 +158,40 @@ O Intlayer irá gerar automaticamente o arquivo de declaração derivado em `src
 
 Posteriormente, ambos os arquivos de declaração serão mesclados em um único dicionário, acessível usando o hook padrão `useIntlayer("example")` (react) / composable (vue).
 
+## Configuração Global
+
+Você pode configurar a configuração de preenchimento automático global no arquivo `intlayer.config.ts`.
+
+```ts fileName="intlayer.config.ts"
+import { type IntlayerConfig, Locales } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+    requiredLocales: [Locales.ENGLISH, Locales.FRENCH],
+  },
+  dictionary: {
+    // Gera automaticamente traduções faltantes para todos os dicionários
+    fill: "./{{fileName}}Filled.content.ts",
+    //
+    // fill: "/messages/{{locale}}/{{key}}/{{fileName}}.content.json",
+    //
+    // fill: true, // gera automaticamente traduções faltantes para todos os dicionários como usando "./{{fileName}}.content.json"
+    //
+    // fill: {
+    //   en: "./{{fileName}}.en.content.json",
+    //   fr: "./{{fileName}}.fr.content.json",
+    //   es: "./{{fileName}}.es.content.json",
+    // },
+  },
+};
+
+export default config;
+```
+
+Você ainda pode ajustar melhor por dicionário usando o campo `fill` em arquivos de conteúdo. O Intlayer irá primeiro considerar a configuração por dicionário e então voltar para a configuração global.
+
 ## Formato do Arquivo Preenchido Automaticamente
 
 O formato recomendado para arquivos de declaração preenchidos automaticamente é **JSON**, que ajuda a evitar restrições de formatação. No entanto, o Intlayer também suporta `.ts`, `.js`, `.mjs`, `.cjs` e outros formatos.
@@ -95,7 +199,7 @@ O formato recomendado para arquivos de declaração preenchidos automaticamente
 ```ts fileName="src/components/example/example.content.ts"
 const exampleContent = {
   key: "example",
-  autoFill: "./example.filled.content.ts",
+  fill: "./example.filled.content.ts",
   content: {
     // Seu conteúdo
   },
@@ -115,12 +219,12 @@ src/components/example/example.filled.content.ts
 
 ## Caminhos Absolutos
 
-O campo `autoFill` também suporta caminhos absolutos.
+O campo `fill` também suporta caminhos absolutos.
 
 ```ts fileName="src/components/example/example.content.ts"
 const exampleContent = {
   key: "example",
-  autoFill: "/messages/example.content.json",
+  fill: "/messages/example.content.json",
   content: {
     // Seu conteúdo
   },
@@ -135,12 +239,12 @@ Isso irá gerar o arquivo em:
 
 ## Geração Automática de Arquivos de Declaração de Conteúdo Por Localidade
 
-O campo `autoFill` também suporta a geração de arquivos de declaração de conteúdo **por localidade**.
+O campo `fill` também suporta a geração de arquivos de declaração de conteúdo **por localidade**.
 
 ```ts fileName="src/components/example/example.content.ts"
 const exampleContent = {
   key: "example",
-  autoFill: {
+  fill: {
     fr: "./example.fr.content.json",
     es: "./example.es.content.json",
   },
@@ -159,12 +263,12 @@ Isso irá gerar dois arquivos separados:
 
 ## Filtrar Autofill para Localidade Específica
 
-Usar um objeto para o campo `autoFill` permite aplicar filtros e gerar apenas arquivos de localidades específicas.
+Usar um objeto para o campo `fill` permite aplicar filtros e gerar apenas arquivos de localidades específicas.
 
 ```ts fileName="src/components/example/example.content.ts"
 const exampleContent = {
   key: "example",
-  autoFill: {
+  fill: {
     fr: "./example.fr.content.json",
   },
   content: {
@@ -177,7 +281,7 @@ Isso irá gerar apenas o arquivo de tradução em francês.
 
 ## Variáveis de Caminho
 
-Você pode usar variáveis dentro do caminho `autoFill` para resolver dinamicamente os caminhos de destino para os arquivos gerados.
+Você pode usar variáveis dentro do caminho `fill` para resolver dinamicamente os caminhos de destino para os arquivos gerados.
 
 **Variáveis disponíveis:**
 
@@ -188,7 +292,7 @@ Você pode usar variáveis dentro do caminho `autoFill` para resolver dinamicame
 ```ts fileName="src/components/example/index.content.ts"
 const exampleContent = {
   key: "example",
-  autoFill: "/messages/{{locale}}/{{key}}.content.json",
+  fill: "/messages/{{locale}}/{{key}}.content.json",
   content: {
     // Seu conteúdo
   },
@@ -203,7 +307,7 @@ Isso irá gerar:
 ```ts fileName="src/components/example/index.content.ts"
 const exampleContent = {
   key: "example",
-  autoFill: "./{{fileName}}.content.json",
+  fill: "./{{fileName}}.content.json",
   content: {
     // Seu conteúdo
   },

package/docs/pt/benchmark/index.md

@@ -17,6 +17,7 @@ history:
   - version: 8.7.5
     date: 2026-01-06
     changes: "Início do benchmark"
+author: aymericzip
 ---
 
 # Benchmark - Relatório
@@ -25,8 +26,8 @@ O Benchmark Bloom é uma suíte de benchmarks de desempenho que mede o impacto r
 
 Abaixo estão os relatórios detalhados e a documentação técnica de cada framework:
 
-- [**Next.js Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/nextjs.md)
-- [**TanStack Start Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/tanstack.md)
-- [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/vue.md)
-- [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/solid.md)
-- [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/svelte.md)
+- [**Next.js Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/benchmark/nextjs.md)
+- [**TanStack Start Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/benchmark/tanstack.md)
+- [**Vue Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/benchmark/vue.md)
+- [**Solid Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/benchmark/solid.md)
+- [**Svelte Benchmark Report**](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/benchmark/svelte.md)

package/docs/pt/benchmark/nextjs.md

@@ -14,7 +14,7 @@ slugs:
   - doc
   - benchmark
   - nextjs
-author: Aymeric PINEAU
+author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
 history:
   - version: 8.9.8

package/docs/pt/benchmark/solid.md

@@ -14,7 +14,7 @@ slugs:
   - doc
   - benchmark
   - solid
-author: Aymeric PINEAU
+author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
 history:
   - version: 8.9.8
@@ -118,6 +118,28 @@ Comparamos **quatro estratégias de carregamento**:
 - **Scoped static**: Mantém o código organizado (separação lógica) sem requisições de rede extras complexas.
 - **Scoped dynamic**: Melhor abordagem para _code splitting_ e desempenho. Minimiza a memória carregando apenas o que a view atual e o local ativo precisam.
 
+### O que medi:
+
+Executei o mesmo aplicativo multilíngue em um navegador real para cada stack e anotei o que realmente aparecia na rede e quanto tempo levava. Os tamanhos são relatados **após compressão web normal**, porque isso se aproxima mais do que as pessoas fazem download do que contagens de código-fonte bruto.
+
+- **Tamanho da biblioteca de internacionalização**: Após bundling, tree-shaking e minificação, o tamanho da biblioteca i18n é o tamanho dos providers + código de hooks/primitives em um componente vazio. Não inclui o carregamento de arquivos de tradução. Responde o quão caro é a biblioteca antes de seu conteúdo entrar na história.
+
+- **JavaScript por página**: Para cada rota de benchmark, quanto script o navegador extrai para essa visita, em média nas páginas do conjunto (e entre idiomas onde o relatório os agrega). Páginas pesadas são páginas lentas.
+
+- **Vazamento de outros idiomas**: É o conteúdo da mesma página mas em outro idioma que seria carregado por engano na página auditada. Este conteúdo é desnecessário e deve ser evitado. (ex. conteúdo da página `/fr/about` no bundle da página `/en/about`)
+
+- **Vazamento de outras rotas**: A mesma ideia para **outras telas** no aplicativo: se sua cópia está viajando junto quando você abriu apenas uma página. (ex. conteúdo da página `/en/about` no bundle da página `/en/contact`). Uma pontuação alta sugere divisão fraca ou bundles muito amplos.
+
+- **Tamanho médio do bundle do componente**: Peças de UI comuns são medidas **uma de cada vez** em vez de se esconder dentro de um número gigante de aplicativo. Mostra se a internacionalização silenciosamente infla componentes cotidianos. Por exemplo, se seu componente é renderizado novamente, ele carregará todos esses dados da memória. Anexar um JSON gigante a qualquer componente é como conectar um grande armazenamento de dados não utilizados que desacelerará o desempenho de seus componentes.
+
+- **Responsividade da troca de idioma**: Mudo o idioma usando o controle do próprio aplicativo e cronometro quanto tempo leva até a página ter claramente trocado, o que um visitante notaria, não um micro-passo de laboratório.
+
+- **Trabalho de renderização após uma mudança de idioma**: Um acompanhamento mais estreito: quanto esforço a interface levou para redesenhar o novo idioma uma vez que a troca está em andamento. Útil quando o tempo "sentido" e o custo do framework divergem.
+
+- **Tempo de carregamento da página inicial**: Da navegação até o navegador considerar a página totalmente carregada para os cenários que testei. Bom para comparar inícios frios.
+
+- **Tempo de hidratação**: Quando o aplicativo o expõe, quanto tempo o cliente gasta transformando HTML do servidor em algo que você pode realmente clicar. Um travessão nas tabelas significa que a implementação não forneceu uma figura de hidratação confiável neste benchmark.
+
 ## Estrelas do GitHub
 
 As estrelas do GitHub são um forte indicador da popularidade de um projeto, da confiança da comunidade e da relevância a longo prazo. Embora não sejam uma medida direta da qualidade técnica, elas refletem quantos desenvolvedores consideram o projeto útil, acompanham seu progresso e têm probabilidade de adotá-lo. Para estimar o valor de um projeto, as estrelas ajudam a comparar a tração entre as alternativas e fornecem insights sobre o crescimento do ecossistema.

package/docs/pt/benchmark/svelte.md

@@ -14,7 +14,7 @@ slugs:
   - doc
   - benchmark
   - svelte
-author: Aymeric PINEAU
+author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
 history:
   - version: 8.9.8
@@ -116,6 +116,28 @@ Comparamos **quatro estratégias de carregamento**:
 - **Scoped static**: Mantém o código organizado (separação lógica) sem requisições de rede extras complexas.
 - **Scoped dynamic**: Melhor abordagem para _code splitting_ e desempenho. Minimiza a memória carregando apenas o que a view atual e o local ativo precisam.
 
+### O que medi:
+
+Executei o mesmo aplicativo multilíngue em um navegador real para cada stack, depois anotei o que realmente apareceu na rede e quanto tempo levou. Os tamanhos são reportados **após a compressão web normal**, porque isso é mais próximo do que as pessoas baixam do que contagens de código-fonte bruto.
+
+- **Tamanho da biblioteca de internacionalização**: Após bundling, tree-shaking e minificação, o tamanho da biblioteca i18n é o tamanho do código de providers + stores em um componente vazio. Não inclui o carregamento de arquivos de tradução. Responde o quanto a biblioteca custa antes do seu conteúdo entrar em cena.
+
+- **JavaScript por página**: Para cada rota de benchmark, quanto script o navegador puxa nessa visita, em média nas páginas do conjunto (e entre locales onde o relatório as agrupa). Páginas pesadas são páginas lentas.
+
+- **Vazamento de outros locales**: É o conteúdo da mesma página mas em outro idioma que seria carregado por engano na página auditada. Este conteúdo é desnecessário e deve ser evitado. (ex: conteúdo da página `/fr/about` no bundle da página `/en/about`)
+
+- **Vazamento de outras rotas**: A mesma ideia para **outras telas** do app: se a sua cópia vem junto quando você apenas abriu uma página. (ex: conteúdo da página `/en/about` no bundle da página `/en/contact`). Uma pontuação alta sugere splitting fraco ou bundles muito amplos.
+
+- **Tamanho médio do bundle do componente**: Peças comuns da UI são medidas **uma de cada vez** em vez de se esconder dentro de um número gigante do app. Mostra se a internacionalização silenciosamente inflaciona componentes cotidianos. Por exemplo, se seu componente fizer rerender, carregará todos esses dados da memória. Anexar um JSON gigante a qualquer componente é como conectar um grande armazenamento de dados não utilizados que desacelerará o desempenho de seus componentes.
+
+- **Responsividade da troca de idioma**: Eu troco o idioma usando o controle do próprio app e cronometro quanto tempo leva até a página ter claramente mudado, o que um visitante notaria, não um micro-passo de laboratório.
+
+- **Trabalho de renderização após uma troca de idioma**: Um follow-up mais estreito: quanto esforço a interface levou para repintar para o novo idioma uma vez que a troca está em andamento. Útil quando o tempo "sentido" e o custo do framework divergem.
+
+- **Tempo de carregamento inicial da página**: Da navegação até o navegador considerar a página totalmente carregada para os cenários que testei. Bom para comparar cold starts.
+
+- **Tempo de hidratação**: Quando o app o expõe, quanto tempo o cliente gasta transformando HTML do servidor em algo que você realmente pode clicar. Um travessão nas tabelas significa que essa implementação não forneceu um número de hidratação confiável neste benchmark.
+
 ## Estrelas do GitHub
 
 As estrelas do GitHub são um forte indicador da popularidade de um projeto, da confiança da comunidade e da relevância a longo prazo. Embora não sejam uma medida direta da qualidade técnica, elas refletem quantos desenvolvedores consideram o projeto útil, acompanham seu progresso e têm probabilidade de adotá-lo. Para estimar o valor de um projeto, as estrelas ajudam a comparar a tração entre as alternativas e fornecem insights sobre o crescimento do ecossistema.

package/docs/pt/benchmark/tanstack.md

@@ -14,7 +14,7 @@ slugs:
   - doc
   - benchmark
   - tanstack
-author: Aymeric PINEAU
+author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
 history:
   - version: 8.9.8
@@ -124,6 +124,28 @@ Comparamos **quatro estratégias de carregamento**:
 - **Scoped static**: Mantém o código organizado (separação lógica) sem requisitos complexos de rede extras.
 - **Scoped dynamic**: Melhor abordagem para _code splitting_ e desempenho. Minimiza a memória carregando apenas o que a visualização atual e a localidade ativa precisam.
 
+### O que medi:
+
+Executei o mesmo aplicativo multilíngue em um navegador real para cada stack, depois anotei o que realmente aparecia na rede e quanto tempo levava. Os tamanhos são relatados **após compressão web normal**, porque isso é mais próximo do que as pessoas baixam do que contagens de fonte bruta.
+
+- **Tamanho da biblioteca de internacionalização**: Após bundling, tree-shaking e minificação, o tamanho da biblioteca i18n é o tamanho dos providers (por exemplo, `NextIntlClientProvider`) + código de hooks (por exemplo, `useTranslations`) em um componente vazio. Não inclui o carregamento de arquivos de tradução. Responde o quão caro é a biblioteca antes do seu conteúdo entrar na imagem.
+
+- **JavaScript por página**: Para cada rota de benchmark, quanto script o navegador puxa naquela visita, em média entre as páginas do conjunto (e entre locales onde o relatório as agrupa). Páginas pesadas são páginas lentas.
+
+- **Vazamento de outras locales**: É o conteúdo da mesma página, mas em outro idioma que seria carregado por engano na página auditada. Este conteúdo é desnecessário e deve ser evitado. (por exemplo, conteúdo da página `/fr/about` no pacote da página `/en/about`)
+
+- **Vazamento de outras rotas**: A mesma ideia para **outras telas** no aplicativo: se a cópia delas vem junto quando você abriu apenas uma página. (por exemplo, conteúdo da página `/en/about` no pacote da página `/en/contact`). Uma pontuação alta indica splitting fraco ou pacotes muito amplos.
+
+- **Tamanho médio do pacote de componentes**: Partes comuns da UI são medidas **uma de cada vez** em vez de se esconderem dentro de um número gigante de aplicativo. Mostra se a internacionalização silenciosamente infla componentes cotidianos. Por exemplo, se o seu componente é renderizado novamente, ele carregará todos esses dados da memória. Anexar um JSON gigante a qualquer componente é como conectar um grande armazém de dados não utilizados que desacelerará o desempenho dos seus componentes.
+
+- **Responsividade da mudança de idioma**: Alterno o idioma usando o controle do próprio aplicativo e meço quanto tempo leva até que a página tenha claramente mudado, o que um visitante notaria, não uma micro-etapa de laboratório.
+
+- **Trabalho de renderização após uma mudança de idioma**: Um acompanhamento mais estreito: quanto esforço a interface levou para se redesenhar para o novo idioma uma vez que a mudança está em voo. Útil quando o tempo "sentido" e o custo do framework divergem.
+
+- **Tempo de carregamento inicial da página**: Da navegação até o navegador considerar a página totalmente carregada para os cenários que testei. Bom para comparar inicializações a frio.
+
+- **Tempo de hidratação**: Quando o aplicativo o expõe, quanto tempo o cliente gasta transformando HTML do servidor em algo que você pode realmente clicar. Um travessão nas tabelas significa que essa implementação não forneceu um valor de hidratação confiável neste benchmark.
+
 ## Estrelas do GitHub
 
 As estrelas do GitHub são um forte indicador da popularidade de um projeto, da confiança da comunidade e da relevância a longo prazo. Embora não sejam uma medida direta da qualidade técnica, elas refletem quantos desenvolvedores consideram o projeto útil, acompanham seu progresso e têm probabilidade de adotá-lo. Para estimar o valor de um projeto, as estrelas ajudam a comparar a tração entre as alternativas e fornecem insights sobre o crescimento do ecossistema.

package/docs/pt/benchmark/vue.md

@@ -14,7 +14,7 @@ slugs:
   - doc
   - benchmark
   - vue
-author: Aymeric PINEAU
+author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
 history:
   - version: 8.9.8

package/docs/pt/bundle_optimization.md

@@ -22,6 +22,7 @@ history:
   - version: 8.7.0
     date: 2026-04-08
     changes: "Adicionadas opções `minify` e `purge` para configuração de build"
+author: aymericzip
 ---
 
 # Otimizando o Tamanho e a Performance do Bundle i18n
@@ -391,11 +392,11 @@ export default config;
 
 ### Os Fatores Sobre Integrações E Opções
 
-| Fator do Propósito Construtivo Relativo | Suportes e Tipologias  | Default Base Constante | Diretriz das Definições De Escopos Construtivos                                                                                                                                                                                                                                                                                                                                                               |
-| :-------------------------------------- | :--------------------- | :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
-| **`optimize`**                          | `boolean \| undefined` | `undefined`            | Integração em otimizações formatando suporte sem bases irrelevantes ou em produção do processo na arquitetura final sem afetar bases na construtiva referencial sem minificar ou excluir parâmetros irrelevantes associados e com base com parâmetros referenciados no suporte do false na formatação do formato do processo de base da arquitetura final associada sem premissas com ligações nos processos. |
-| **`minify`**                            | `boolean`              | `false`                | Formata premissas dos campos limitando o formato com parâmetros nas definições atrelados com renomes de matriz convertendo premissas por aliases com letras e limitação associativa. Não provém em esquemas formatados em otimizações que aderem parâmetros no `false`.                                                                                                                                       |
-| **`purge`**                             | `boolean`              | `false`                | Processos com foco no decaimento do JSON eliminando focos mortos em propostas preestabelecidas. Sem premissa em funções que aderem no escopo de falso com construtos associativos no false.                                                                                                                                                                                                                   |
+| Fator do Propósito Construtivo Relativo | Suportes e Tipologias | Default Base Constante | Diretriz das Definições De Escopos Construtivos                                                                                                                                                                                                                                                                                                                                                               |
+| :-------------------------------------- | :-------------------- | :--------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| **`optimize`**                          | `boolean / undefined` | `undefined`            | Integração em otimizações formatando suporte sem bases irrelevantes ou em produção do processo na arquitetura final sem afetar bases na construtiva referencial sem minificar ou excluir parâmetros irrelevantes associados e com base com parâmetros referenciados no suporte do false na formatação do formato do processo de base da arquitetura final associada sem premissas com ligações nos processos. |
+| **`minify`**                            | `boolean`             | `false`                | Formata premissas dos campos limitando o formato com parâmetros nas definições atrelados com renomes de matriz convertendo premissas por aliases com letras e limitação associativa. Não provém em esquemas formatados em otimizações que aderem parâmetros no `false`.                                                                                                                                       |
+| **`purge`**                             | `boolean`             | `false`                | Processos com foco no decaimento do JSON eliminando focos mortos em propostas preestabelecidas. Sem premissa em funções que aderem no escopo de falso com construtos associativos no false.                                                                                                                                                                                                                   |
 
 ### Redução Modular Atrelada Nas Extensões (Minificação De Estruturas Relacionadas)
 

package/docs/pt/cli/build.md

@@ -17,6 +17,7 @@ history:
   - version: 8.1.5
     date: 2026-02-23
     changes: "Adicionar opção checkTypes"
+author: aymericzip
 ---
 
 # Construir Dicionários

package/docs/pt/cli/ci.md

@@ -20,6 +20,7 @@ history:
   - version: 7.5.11
     date: 2026-01-06
     changes: "Adicionar comando CI"
+author: aymericzip
 ---
 
 # Comando CI
@@ -139,6 +140,28 @@ steps:
     run: npx intlayer ci fill
 ```
 
+## GitHub Actions Scaffolding
+
+Quando você executa `intlayer init`, o Intlayer detecta seu gerenciador de pacotes (npm, yarn, pnpm ou bun) e cria dois workflows do GitHub Actions em `.github/workflows/`, com comandos que correspondem a esse gerenciador de pacotes:
+
+- **`intlayer-fill.yml`** — Em cada pull request, compila os dicionários e executa `intlayer fill --git-diff --mode complete` para gerar traduções ausentes para os dicionários alterados, depois confirma o resultado de volta ao branch do PR.
+- **`intlayer-test.yml`** — Em cada pull request, compila os dicionários e executa `intlayer test`, falhando a verificação quando traduções de locales obrigatórias estão ausentes.
+
+Os arquivos de workflow existentes nunca são sobrescritos. Para pular o scaffolding inteiramente, execute:
+
+```bash
+npx intlayer init --no-github-actions
+```
+
+### Fornecendo acesso à IA para o workflow de preenchimento
+
+O `intlayer-fill.yml` gerado requer acesso à IA. Duas opções estão disponíveis (configuradas no bloco `env` do workflow):
+
+1. **Sua própria chave de provedor de IA** — Adicione um secret `AI_API_KEY` nas configurações do seu repositório (Settings → Secrets and variables → Actions). O workflow o encaminha via `--provider`, `--model` e `--api-key`.
+2. **Chaves de acesso do Intlayer CMS** — Adicione os secrets `INTLAYER_CLIENT_ID` e `INTLAYER_CLIENT_SECRET` e integre-os na seção `editor` do seu `intlayer.config`. As chaves de acesso do CMS concedem acesso à IA através do backend do Intlayer.
+
+O workflow `intlayer-test.yml` não requer nenhum acesso à IA.
+
 ## Tratamento de erros
 
 - Se `INTLAYER_PROJECT_CREDENTIALS` não estiver definida, o comando sairá com um erro.

package/docs/pt/cli/configuration.md

@@ -14,6 +14,7 @@ slugs:
   - concept
   - cli
   - configuration
+author: aymericzip
 ---
 
 # Gerenciar Configuração

package/docs/pt/cli/debug.md

@@ -13,6 +13,7 @@ slugs:
   - concept
   - cli
   - debug
+author: aymericzip
 ---
 
 # Depurar comando intlayer

package/docs/pt/cli/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-06-17
 title: Revisar Documento
 description: Aprenda como revisar arquivos de documentação para qualidade, consistência e completude em diferentes locais.
 keywords:
@@ -15,6 +15,11 @@ slugs:
   - concept
   - cli
   - doc-review
+history:
+  - version: 9.0.0
+    date: 2026-06-17
+    changes: "Adicionar opção --log"
+author: aymericzip
 ---
 
 # Revisar Documento
@@ -54,8 +59,110 @@ Para a maioria dos casos de uso,
 
 ## Argumentos:
 
-O comando `doc review` aceita os mesmos argumentos que o `doc translate`, permitindo que você revise arquivos de documentação específicos e aplique verificações de qualidade.
+**Opções de lista de arquivos:**
 
-Se você ativou uma das opções do git, o comando revisará apenas a parte dos arquivos que está sendo alterada. O script processará dividindo o arquivo em chunks e revisará cada chunk. Se não houver alterações no chunk, o script o pulará para acelerar o processo de revisão e limitar o custo da API do Provedor de IA.
+- **`--doc-pattern [docPattern...]`**: Padrões glob para corresponder aos arquivos de documentação a serem revisados.
 
-Para uma lista completa de argumentos, consulte a documentação do comando [Translate Document](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pt/cli/doc-translate.md).
+  > Exemplo: `npx intlayer doc review --doc-pattern "docs/**/*.md" "src/**/*.mdx"`
+
+- **`--excluded-glob-pattern [excludedGlobPattern...]`**: Padrões glob para excluir da revisão.
+
+  > Exemplo: `npx intlayer doc review --excluded-glob-pattern "docs/internal/**"`
+
+- **`--skip-if-modified-before [skipIfModifiedBefore]`**: Pular o arquivo se ele foi modificado antes do tempo especificado.
+  - Pode ser um tempo absoluto como "2025-12-05" (string ou Date)
+  - Pode ser um tempo relativo em ms `1 * 60 * 60 * 1000` (1 hora)
+  - Esta opção verifica o tempo de atualização do arquivo usando o método `fs.stat`. Portanto, pode ser impactada pelo Git ou outras ferramentas que modificam o arquivo.
+
+  > Exemplo: `npx intlayer doc review --skip-if-modified-before "2025-12-05"`
+
+- **`--skip-if-modified-after [skipIfModifiedAfter]`**: Pular o arquivo se ele foi modificado dentro do tempo especificado.
+  - Pode ser um tempo absoluto como "2025-12-05" (string ou Date)
+  - Pode ser um tempo relativo em ms `1 * 60 * 60 * 1000` (1 hora)
+  - Esta opção verifica o tempo de atualização do arquivo usando o método `fs.stat`. Portanto, pode ser impactada pelo Git ou outras ferramentas que modificam o arquivo.
+
+  > Exemplo: `npx intlayer doc review --skip-if-modified-after "2025-12-05"`
+
+- **`--skip-if-exists`**: Pular o arquivo se ele já existir.
+
+  > Exemplo: `npx intlayer doc review --skip-if-exists`
+
+**Opções de modo de revisão:**
+
+- **`--log`**: Modo apenas de registro (log-only). Não traduz com IA; em vez disso, registra os blocos que precisam de atenção (com números de linha e conteúdo) para as localidades base e de destino, a fim de ajudar outro agente a gerar as traduções.
+
+  > Exemplo: `npx intlayer doc review --log`
+
+**Opções de saída da entrada:**
+
+- **`--locales [locales...]`**: Locais de destino para revisar a documentação.
+
+  > Exemplo: `npx intlayer doc review --locales fr es de`
+
+- **`--base-locale [baseLocale]`**: Local de origem (documento base) para comparar.
+
+  > Exemplo: `npx intlayer doc review --base-locale en`
+
+**Opções de processamento de arquivos:**
+
+- **`--nb-simultaneous-file-processed [nbSimultaneousFileProcessed]`**: Número de arquivos para processar simultaneamente para a revisão.
+
+  > Exemplo: `npx intlayer doc review --nb-simultaneous-file-processed 5`
+
+**Opções de IA:**
+
+- **`--model [model]`**: O modelo de IA a ser usado para a revisão (exemplo: `gpt-3.5-turbo`).
+- **`--provider [provider]`**: O provedor de IA a ser usado para a revisão.
+- **`--temperature [temperature]`**: Configuração de temperatura para o modelo de IA.
+- **`--api-key [apiKey]`**: Forneça sua própria chave de API para o serviço de IA.
+- **`--application-context [applicationContext]`**: Forneça contexto adicional para a revisão de IA.
+- **`--data-serialization [dataSerialization]`**: O formato de serialização de dados a ser usado nas funcionalidades de IA do Intlayer. Opções: `json` (padrão, confiável), `toon` (menos tokens, menos consistente).
+- **`--custom-prompt [prompt]`**: Personalize o prompt base usado para a revisão. (Nota: Para a maioria dos casos de uso, a opção `--custom-instructions` é recomendada, pois oferece melhor controle.)
+
+  > Exemplo: `npx intlayer doc review --model deepseek-chat --provider deepseek --temperature 0.5 --api-key sk-1234567890 --application-context "Minha aplicação é uma loja de gatos"`
+
+**Opções de variáveis de ambiente:**
+
+- **`--env`**: Especifica o ambiente (exemplo: `development`, `production`).
+- **`--env-file [envFile]`**: Fornece um arquivo de ambiente personalizado para carregar variáveis.
+- **`--base-dir`**: Especifica o diretório base do projeto.
+- **`--no-cache`**: Desativa o cache.
+
+  > Exemplo: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
+
+**Opções de log:**
+
+- **`--verbose`**: Ativa o log detalhado para depuração. (padrão para true usando CLI)
+
+  > Exemplo: `npx intlayer doc review --verbose`
+
+**Opções de instruções personalizadas:**
+
+- **`--custom-instructions [customInstructions]`**: Instruções personalizadas adicionadas ao prompt. Útil para aplicar regras específicas relacionadas à formatação, tradução de URLs, etc.
+
+  > Exemplo: `npx intlayer doc review --custom-instructions "Evite traduzir URLs e mantenha o formato markdown"`
+
+  > Exemplo: `npx intlayer doc review --custom-instructions "$(cat ./instructions.md)"`
+
+**Opções do Git:**
+
+- **`--git-diff`**: Executa apenas em arquivos que incluem alterações da base (padrão `origin/main`) para o branch atual (padrão: `HEAD`).
+- **`--git-diff-base`**: Especifica a referência base para o git diff (padrão `origin/main`).
+- **`--git-diff-current`**: Especifica a referência atual para o git diff (padrão: `HEAD`).
+- **`--uncommitted`**: Inclui alterações não comitadas.
+- **`--unpushed`**: Inclui alterações não enviadas.
+- **`--untracked`**: Inclui arquivos não rastreados.
+
+  > Exemplo: `npx intlayer doc review --git-diff --git-diff-base origin/main --git-diff-current HEAD`
+
+  > Exemplo: `npx intlayer doc review --uncommitted --unpushed --untracked`
+
+> Note que o caminho do arquivo de saída será determinado substituindo os seguintes padrões:
+>
+> - `/{{baseLocale}}/` por `/{{locale}}/` (Unix)
+> - `\{{baseLocale}}\` por `\{{locale}}\` (Windows)
+> - `_{{baseLocale}}.` por `_{{locale}}.`
+> - `{{baseLocale}}_` por `{{locale}}_`
+> - `.{{baseLocaleName}}.` por `.{{localeName}}.`
+>
+> Se o padrão não for encontrado, o arquivo de saída adicionará `.{{locale}}` na extensão do arquivo. `./my/file.md` será revisado e atualizado para `./my/file.fr.md` para o idioma francês.

package/docs/pt/cli/doc-translate.md

@@ -15,6 +15,7 @@ slugs:
   - concept
   - cli
   - doc-translate
+author: aymericzip
 ---
 
 # Traduzir Documento

package/docs/pt/cli/editor.md

@@ -13,6 +13,7 @@ slugs:
   - concept
   - cli
   - editor
+author: aymericzip
 ---
 
 # Comandos do editor