@intlayer/docs 8.12.5-canary.0 → 9.0.0-canary.10

package/docs/pl/releases/v9.md

@@ -0,0 +1,316 @@
+---
+createdAt: 2026-06-14
+updatedAt: 2026-06-26
+title: Nowy Intlayer v9 - Co nowego?
+description: Odkryj nowości w Intlayer v9. Przedstawiamy pakiety kompatybilności typu drop-in dla popularnych bibliotek i18n oraz wsparcie dla Kolekcji (Collections) i Wariantów (Variants).
+keywords:
+  - Intlayer
+  - Kompatybilność
+  - Migracja
+  - Kolekcje
+  - Warianty
+  - i18next
+  - next-intl
+  - vue-i18n
+slugs:
+  - doc
+  - releases
+  - v9
+author: aymericzip
+---
+
+# Nowy Intlayer v9 - Co nowego?
+
+Witaj w Intlayer v9! To główne wydanie (major release) stanowi ogromny krok milowy w upraszczaniu ścieżki migracji do Intlayer dzięki **pakietom kompatybilności (Compat Adapter Packages)** dla najpopularniejszych bibliotek i18n (takich jak `react-i18next`, `next-intl`, `vue-i18n` itp.) oraz wprowadza wsparcie dla bogatych struktur treści: **Kolekcji (Collections)** i **Wariantów (Variants)**.
+
+## Spis treści
+
+<TOC levels={[2]} maxDepth={1} />
+
+---
+
+## Pakiety kompatybilności (Compat Adapter Packages)
+
+Migracja do Intlayer z popularnych bibliotek i18n jest teraz łatwiejsza niż kiedykolwiek. Stworzyliśmy pięć pakietów kompatybilności (compat packages), które udostępniają **dokładnie to samo publiczne API** co standardowe biblioteki i18n, ale delegują całą pracę związaną z tłumaczeniami do Intlayer w czasie działania aplikacji (runtime).
+
+### To samo publiczne API ze ścisłym typowaniem (Strict Typing)
+
+Zastępując importy, zyskujesz wszystkie zalety Intlayer (w tym bezpieczeństwo typów w czasie kompilacji - compile-time type safety - w oparciu o Twoje rzeczywiste słowniki) przy minimalnych zmianach w kodzie:
+
+- `@intlayer/i18next`
+- `@intlayer/react-i18next`
+- `@intlayer/next-intl`
+- `@intlayer/react-intl`
+- `@intlayer/next-i18next`
+- `@intlayer/vue-i18n`
+- `@intlayer/lingui`
+
+Na przykład, po prostu zmień:
+
+```ts
+import { useTranslation } from "react-i18next";
+```
+
+na:
+
+```ts
+import { useTranslation } from "@intlayer/react-i18next";
+```
+
+Twoje klucze będą teraz **ściśle typowane** (strictly typed) w oparciu o słowniki Intlayer, oferując pełne autouzupełnianie ścieżek kropkowych (dot-path) w Twoim IDE!
+
+### Pluginy aliasów dla bundlerów (Vite, Next.js, Turbopack)
+
+Aby umożliwić migrację bez konieczności ręcznego przepisywania wszystkich importów, każdy pakiet adaptera kompatybilności zawiera **dedykowany plugin dla bundlera** (Vite lub Next.js) w podścieżce `/plugin`.
+
+Pluginy te automatycznie przepisują istniejące importy (np. `react-i18next` lub `next-intl`) na ich odpowiedniki `@intlayer/*` w czasie budowania (build time).
+
+#### Przykład dla Next.js (Webpack / Turbopack)
+
+Zamiast `withIntlayer`, owiń swoją konfigurację Next.js pluginem kompatybilności:
+
+```ts fileName="next.config.ts"
+import { createNextI18nPlugin } from "@intlayer/next-i18next/plugin";
+import type { NextConfig } from "next";
+
+const withIntlayer = createNextI18nPlugin();
+const nextConfig: NextConfig = {};
+
+export default withIntlayer(nextConfig);
+```
+
+#### Przykład dla Vite (React, Vue, Solid, Svelte)
+
+```ts fileName="vite.config.ts"
+import vueI18nVitePlugin from "@intlayer/vue-i18n/plugin";
+
+export default defineConfig({
+  plugins: [vueI18nVitePlugin()],
+});
+```
+
+---
+
+## Wspólny parser czasu działania (Mutualized Runtime Resolver)
+
+Wszystkie adaptery kompatybilności kierują teraz proces rozwiązywania tłumaczeń przez jeden, wysoce zoptymalizowany parser czasu działania (runtime parser): `@intlayer/core/messageFormat`.
+
+- **Interpolacja wiadomości (Interpolate Message)**: Obsługuje standardowe szablony `{{var}}` (ze spacjami i ścieżkami kropkowymi), argumenty formatowane w standardzie ICU (`{v, number, percent}` itp.) oraz proste szablony `{var}`.
+- **Rozwiązywanie węzłów wiadomości (Message Node Resolver)**: Obsługuje zagnieżdżone węzły: `insert()`, `plural()` (reguły liczby mnogiej CLDR), `enu()` (wyliczenia), `gender()`, tagi HTML, tablice oraz węzły funkcji wywoływalnych (callable functions).
+- **Parser tagów tokenizowanych (Tokenized Tag Parser)**: Wspiera wbudowane tagi XML/HTML oraz tagi numerowane (np. `<1>children</1>`), aby zapewnić renderowanie bogatego tekstu (rich-text) po wyjęciu z pudełka.
+
+---
+
+## Specyfikacja funkcji: Kolekcje i Warianty
+
+Intlayer v9 wykracza poza statyczne obiekty klucz-wartość, umożliwiając słownikom deklarowanie dynamicznych struktur układu, które są w pełni typowane od początku do końca (end-to-end).
+
+### 1. Kolekcje (Collections)
+
+Zdefiniuj zarządzaną przez CMS uporządkowaną lista elementów (np. FAQ, produkty lub listy blogów):
+
+```ts fileName="faq.1.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "faq",
+  item: 1,
+  content: {
+    question: t({ en: "What is Intlayer?", fr: "Qu'est-ce qu'Intlayer ?" }),
+    answer: t({ en: "An i18n toolkit.", fr: "Une boîte à outils i18n." }),
+  },
+} satisfies Dictionary;
+```
+
+```ts fileName="faq.2.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "faq",
+  item: 2,
+  content: {
+    question: t({ en: "Is it free?", fr: "Est-ce gratuit ?" }),
+    answer: t({ en: "Yes, open-source.", fr: "Oui, open-source." }),
+  },
+} satisfies Dictionary;
+```
+
+#### Użycie:
+
+```ts
+// Fetch all items as an array
+const allFaqs = useIntlayer("faq"); // -> { question: string, answer: string }[]
+
+// Fetch a single item by index
+const faq = useIntlayer("faq", { item: 2 }); // -> { question: string, answer: string }
+```
+
+### 2. Warianty (Variants)
+
+Dostarczaj testy A/B, nagłówki sezonowe, flagi funkcji (feature flags) lub niestandardowe strony docelowe (landing pages):
+
+#### Warianty tekstowe (np. testy A/B)
+
+```ts fileName="hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero-banner",
+  variant: "default",
+  content: {
+    control: t({ pl: "Witaj", en: "Welcome", fr: "Bienvenue" }),
+    black_friday: t({
+      pl: "Kup teraz",
+      en: "Shop now",
+      fr: "Acheter maintenant",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+#### Użycie:
+
+```ts
+const banner = useIntlayer("hero-banner", { variant: "black_friday" });
+```
+
+#### Warianty obiektowe (np. Dynamic Records)
+
+```ts fileName="product.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "product-copy",
+  variant: {
+    id: "prod_123",
+    category: "books",
+  },
+  content: {
+    title: t({ pl: "Czysty kod", en: "Clean Code", fr: "Code Propre" }),
+  },
+} satisfies Dictionary;
+```
+
+#### Użycie:
+
+```ts
+// Pobiera dynamicznie tylko żądany element (wymaga Suspense)
+const product = useIntlayer("product-copy", {
+  variant: { id: "prod_123", category: "books" },
+});
+```
+
+---
+
+## Dynamiczne ładowanie i optymalizacja rozmiaru paczki (Bundle Size)
+
+Aby zachować niezwykle mały rozmiar paczek (bundles), Intlayer v9 wspiera dynamiczne leniwe ładowanie (lazy loading).
+
+W swojej konfiguracji ustaw `importMode` na `'dynamic'` lub `'fetch'`:
+
+```ts fileName="intlayer.config.ts"
+export default {
+  dictionary: {
+    importMode: "dynamic", // "static" | "dynamic" | "fetch"
+  },
+};
+```
+
+W czasie budowania (build time), `@intlayer/swc` oraz `@intlayer/babel` skanują Twoje pliki i zastępują wywołania `useIntlayer` / `getIntlayer` opakowaniami wspierającymi tree-shaking (`useDictionary` / `useDictionaryDynamic`). Ładowana jest tylko treść wymagana dla wybranego elementu kolekcji, wariantu lub języka (locale), co zapobiega dołączaniu nieużywanych tłumaczeń do Twojej paczki produkcyjnej (production bundle).
+
+---
+
+## Vite Plugin: Bundled Compiler & Proxy
+
+Plugin Vite `intlayer()` teraz łączy **kompilator** i **proxy do routingu locale'ów** bezpośrednio, więc większość projektów potrzebuje tylko jednej wtyczki w `vite.config.ts`:
+
+```ts fileName="vite.config.ts"
+import { defineConfig } from "vite";
+import { intlayer } from "vite-intlayer";
+
+export default defineConfig({
+  plugins: [intlayer()],
+});
+```
+
+- **Compiler**: Aktywuje się automatycznie, gdy `compiler.enabled` jest ustawione na `true` i skonfigurowana jest ścieżka `compiler.output`. Nie musisz już rejestrować `intlayerCompiler()` osobno.
+- **Proxy**: Aktywuje się automatycznie w oparciu o nową opcję `routing.enableProxy` (domyślnie `true`). Podłącza middleware do wykrywania locale'ów / przekierowywania / przepisywania w developmencie, preview i produkcyjnym SSR. Nie musisz już rejestrować `intlayerProxy()` osobno.
+
+### Opcja `routing.enableProxy`
+
+Nowa opcja `routing.enableProxy` kontroluje, czy proxy routingu lokalizacji jest podłączony. Domyślnie ma wartość `true`. Wyłącz to, jeśli chcesz samodzielnie obsługiwać routing lokalizacji:
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  routing: {
+    enableProxy: false, // Domyślnie: true
+  },
+};
+
+export default config;
+```
+
+Autonomiczne pluginy `intlayerCompiler()` i `intlayerProxy()` pozostają eksportowane dla zaawansowanych konfiguracji. Rejestrowanie ich razem z `intlayer()` jest bezpieczne — każdy plugin deduplikuje się i uruchamia się tylko raz.
+
+---
+
+## Kompilator domyślnie wyłączony
+
+Od Intlayer v9 **kompilator jest domyślnie wyłączony** (`compiler.enabled` ma teraz domyślnie wartość `false`). Aby włączyć ekstrakcję plików `.content.ts` w czasie budowania, ustaw `compiler.enabled: true` w swojej konfiguracji:
+
+```ts fileName="intlayer.config.ts"
+import type { IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  compiler: {
+    enabled: true, // Domyślnie: false — wymagane do włączenia kompilatora od wersji v9
+    output: ({ fileName }) => `./${fileName}.content.ts`,
+  },
+};
+
+export default config;
+```
+
+Gdy kompilator jest wyłączony, Intlayer pomija krok ekstrakcji w czasie budowania i opiera się na już zadeklarowanych słownikach. Włącz go tylko wtedy, gdy chcesz, aby plugin bundlera (`@intlayer/swc`, `@intlayer/babel` lub plugin Vite `intlayer()`) automatycznie wyodrębniał zawartość.
+
+---
+
+## React Native: importy z jednego pakietu
+
+W aplikacji React Native lub Expo nie musisz już żonglować pakietami `react-intlayer` i `react-native-intlayer`. Pakiet `react-native-intlayer` teraz **ponownie eksportuje pełne API `react-intlayer`** (hooki, narzędzia oraz podścieżki `/format`, `/html` i `/markdown`), a jego `IntlayerProvider` automatycznie stosuje polyfille React Native.
+
+Importuj wszystko z jednego pakietu `react-native-intlayer`:
+
+```tsx
+import {
+  IntlayerProvider,
+  useIntlayer,
+  useLocale,
+} from "react-native-intlayer";
+```
+
+```bash
+npm install intlayer react-native-intlayer
+```
+
+> Importowanie z `react-intlayer` nadal działa, ale `react-native-intlayer` jest teraz zalecanym pojedynczym punktem wejścia dla React Native — jego provider zawiera polyfille, których nie posiada zorientowany na web provider `react-intlayer`.
+
+---
+
+## Uwagi dotyczące migracji z wersji v8
+
+Jeśli aktualizujesz aplikację z wersji v8, pamiętaj, że wersja v9 nie zawiera zmian wprowadzających niekompatybilność wsteczną (breaking changes). Oto jednak kluczowe zmiany:
+
+- **Kompilator domyślnie wyłączony**: `compiler.enabled` ma teraz domyślnie wartość `false`. Jeśli polegasz na ekstrakcji plików `.content.ts` w czasie budowania, ustaw `compiler.enabled: true` w swoim `intlayer.config.ts`.
+- **Języki i dialekty (Locales & Dialects)**: Jeśli używasz zewnętrznych zależności i18n, dodaj odpowiednie pluginy adapterów kompatybilności w swojej konfiguracji lub konfiguracji bundlera, aby automatycznie przepisywać importy.
+- **Niestandardowe selektory (Custom Selectors)**: Podczas wywoływania `useIntlayer`, drugi parametr jest teraz zarezerwowany dla obiektu opcji zawierającego `{ locale, item, variant }`. Jeśli wcześniej przekazywałeś bezpośrednio ciąg znaków języka (locale string), nadal możesz to robić, jednak zaleca się używanie obiektu opcji przy bardziej zaawansowanych wyborach.
+
+---
+
+## Przydatne linki
+
+- [Przewodnik po pakietach kompatybilności (Compat Adapter Packages)](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/compat/index.md)
+- [Dynamiczne słowniki - Kolekcje i Warianty](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/dynamic_dictionaries/index.md)
+- [Dokumentacja konfiguracji](https://github.com/aymericzip/intlayer/blob/main/docs/docs/pl/configuration.md)

package/docs/pl/roadmap.md

@@ -328,22 +328,6 @@ Intlayer obsługuje **TypeScript** (również JavaScript) oraz **JSON** do dekla
 
 ### 4. Ulepszenia SEO
 
-- Narzędzia do **analizy słów kluczowych**, intencji wyszukiwania użytkowników oraz pojawiających się trendów.
-- Sugestie ulepszonej treści dla lepszych pozycji w rankingach oraz monitorowanie długoterminowej wydajności.
-
-### 5. Zgodność z większą liczbą frameworków
-
-- Trwają prace nad wsparciem dla **Solid, Svelte, Angular** i innych.
-- Celem jest uczynienie Intlayer kompatybilnym z **dowolną aplikacją opartą na JavaScript**.
-
----
-
-## Podsumowanie
-
-- System generowałby tłumaczenia w tle, a następnie prosiłby Cię o ich zatwierdzenie lub edycję.
-
-### 4. Ulepszenia SEO
-
 - Narzędzia do **analizy słów kluczowych**, intencji wyszukiwania użytkowników oraz pojawiających się trendów.
 - Sugestie ulepszonej treści dla lepszych pozycji w rankingach oraz śledzenie długoterminowej wydajności.
 

package/docs/pt/CI_CD.md

@@ -26,6 +26,10 @@ author: aymericzip
 
 O Intlayer permite a geração automática de traduções para seus arquivos de declaração de conteúdo. Existem várias maneiras de realizar isso dependendo do seu fluxo de trabalho.
 
+## Índice
+
+<TOC/>
+
 ## Usando o CMS
 
 Com o Intlayer, você pode adotar um fluxo de trabalho onde apenas um único idioma é declarado localmente, enquanto todas as traduções são gerenciadas remotamente através do CMS. Isso permite que o conteúdo e as traduções fiquem completamente desacoplados da base de código, oferecendo mais flexibilidade para os editores de conteúdo e possibilitando o recarregamento dinâmico do conteúdo (sem necessidade de reconstruir a aplicação para aplicar as alterações).

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"
@@ -28,11 +31,77 @@ history:
 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";
@@ -40,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",
   },
@@ -50,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:
 
@@ -89,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.
@@ -96,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
   },
@@ -116,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
   },
@@ -136,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",
   },
@@ -160,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: {
@@ -178,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:**
 
@@ -189,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
   },
@@ -204,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

@@ -26,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/solid.md

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

@@ -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.