@intlayer/docs 9.4.2 → 9.4.3

package/blog/en/i18n_testing_strategies.md

@@ -0,0 +1,179 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "How to test translations without writing brittle tests"
+description: What is worth testing in an i18n app and what is not. Provider-based rendering tests, pseudolocalization, RTL and plural coverage, and the snapshot trap.
+keywords:
+  - test translations
+  - i18n testing
+  - testing library i18n
+  - pseudolocalization
+  - locale provider test
+  - snapshot test i18n
+slugs:
+  - blog
+  - i18n-testing-strategies
+author: aymericzip
+---
+
+# How to test translations without writing brittle tests
+
+Most i18n test suites fail in one of two ways. Either they assert on literal copy, so every wording change breaks fifty tests and the team deletes them. Or they render everything in the default locale, so they prove nothing about the other seventeen. Both end in the same place: a suite nobody trusts.
+
+## Table of Contents
+
+<TOC/>
+
+## The patterns are library-agnostic
+
+Every pattern below works on any i18n stack. Swap the provider for `I18nextProvider`, `NextIntlClientProvider` or `IntlProvider` and the tests are otherwise identical, because they assert on rendered output rather than on a library API.
+
+The coverage tooling ports too: with the [Sync JSON plugin](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/plugins/sync-json.md) pointed at your existing catalogs, or a [compat adapter](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/compat/index.md) aliasing your current imports, the coverage assertion runs against the JSON you already have.
+
+## Decide what you are actually testing
+
+Translation quality is not a test. No assertion tells you whether the German is idiomatic, and pretending otherwise is how you get a suite full of hardcoded strings.
+
+What is worth testing is mechanical:
+
+| Worth testing                              | Not worth testing               |
+| :----------------------------------------- | :------------------------------ |
+| Every required locale has a value          | Whether the wording is good     |
+| The right locale reaches the component     | Exact copy of every label       |
+| Plurals resolve for each category          | That a translator did their job |
+| RTL locales set direction and mirror       | Every string in every locale    |
+| Formatted dates and numbers use the locale | Third-party `Intl` correctness  |
+
+Coverage belongs in one data-driven test, not in your component tests. That is covered in [finding missing translations](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/detecting_missing_translations.md); this post is about the rest.
+
+## Render under a provider, assert on role
+
+The core pattern is to mount the component inside a locale provider and query by role or test id rather than by copy.
+
+```tsx fileName="CartSummary.test.tsx"
+import { render, screen } from "@testing-library/react";
+import { IntlayerProvider } from "react-intlayer/client";
+import { CartSummary } from "./CartSummary";
+
+test("renders the summary heading in French", () => {
+  render(
+    <IntlayerProvider locale="fr-FR">
+      <CartSummary />
+    </IntlayerProvider>
+  );
+
+  expect(screen.getByRole("heading")).toBeInTheDocument();
+});
+```
+
+Querying `getByRole("heading")` survives a copy change. `getByText("Récapitulatif")` does not. Use the literal only when the string itself is the thing under test, which is rare.
+
+For attributes such as `aria-label` you need the raw string rather than a renderable node. In React, `useIntlayer` entries expose a `.value` field for that.
+
+## Parameterize across locales
+
+One test body, every locale, is worth more than one test per locale.
+
+```tsx fileName="direction.test.tsx"
+import { getHTMLTextDir } from "intlayer";
+import { render } from "@testing-library/react";
+import { IntlayerProvider } from "react-intlayer/client";
+
+describe.each(["en", "fr", "ja", "ar"])("locale %s", (locale) => {
+  it("renders without falling back to the key", () => {
+    const { container } = render(
+      <IntlayerProvider locale={locale}>
+        <CartSummary />
+      </IntlayerProvider>
+    );
+
+    // A rendered key means the lookup failed.
+    expect(container.textContent).not.toMatch(/^[a-z]+(\.[a-z]+)+$/);
+  });
+
+  it("sets the correct text direction", () => {
+    expect(getHTMLTextDir(locale)).toBe(locale === "ar" ? "rtl" : "ltr");
+  });
+});
+```
+
+The first assertion is the cheap generic win: if a lookup fails and your library renders the key, the DOM contains something shaped like `cart.summary.title`. That catches a whole class of bugs without naming a single string.
+
+## Pseudolocalization finds what catalogs cannot
+
+Add a fake locale that transforms every string, for example `Checkout` becoming `[!!! Çĥéçķöũţ !!!]`. Then render a page in it.
+
+Anything still in plain English is hardcoded, and no catalog-based check can see that, because as far as the tooling is concerned the string does not exist. The brackets do a second job: they expand the text by roughly 30 percent, which surfaces layout that breaks in German before German does.
+
+This is worth running as a visual or end-to-end pass rather than a unit test, since the failure is something you look at.
+
+## Plurals need a test per category, not per language
+
+Plural bugs hide because English has two forms and most developers only ever exercise those. Polish has four, Arabic six.
+
+```ts fileName="plural.test.ts"
+// Arabic exercises zero, one, two, few, many, other.
+describe.each([0, 1, 2, 3, 11, 100])("count %i", (count) => {
+  it("produces a non-empty string in Arabic", () => {
+    expect(formatItems(count, "ar")).not.toBe("");
+  });
+});
+```
+
+Pick counts that hit each CLDR category for your worst-case language rather than testing 1 and 2 everywhere. `Intl.PluralRules` tells you which category a number falls into, so you can derive the sample set instead of guessing. More on the categories in [the ICU message format post](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/icu_message_format.md).
+
+## The snapshot trap
+
+Snapshots and i18n are a bad match. A snapshot of a localized component encodes every string in it, so a translator fixing a typo in Portuguese turns a green suite red, in a file no reviewer can evaluate. After the third time, someone runs `-u` without reading the diff, and the snapshots stop meaning anything.
+
+If you want snapshots, take them in one locale only, and treat that as a structural check rather than a content check. Everything locale-specific belongs in explicit assertions.
+
+## Test the negotiation, not just the rendering
+
+The most common production i18n bug is not a missing string. It is the wrong locale being selected: a URL says `/fr/`, the client reads `navigator.language`, and they disagree.
+
+Test the resolution order directly, as a pure function, separate from any component:
+
+```ts fileName="locale-resolution.test.ts"
+it("prefers the URL over the stored preference", () => {
+  expect(resolveLocale({ url: "/fr/about", stored: "de", header: "ja" })).toBe(
+    "fr"
+  );
+});
+
+it("falls back to the header when the URL has no prefix", () => {
+  expect(resolveLocale({ url: "/about", stored: null, header: "ja" })).toBe(
+    "ja"
+  );
+});
+```
+
+This is the single highest-value i18n test most codebases are missing, and it needs no DOM.
+
+## What to run where
+
+- **Unit**: locale negotiation, formatters, plural categories. Fast, no DOM.
+- **Component**: one provider-based render per locale, asserting on roles and on the absence of raw keys.
+- **Coverage**: one data-driven test asserting no missing required locales.
+- **Visual or end-to-end**: pseudolocale pass and one RTL page, because those failures are visual.
+
+Keep the first three in the pipeline on every commit. The last one is cheap to run nightly and expensive to run on every push.
+
+## Common mistakes
+
+- **Asserting on literal copy everywhere.** Guarantees the suite is deleted within a quarter.
+- **Snapshotting localized components.** Translators break your build, reviewers rubber-stamp the update.
+- **Testing only the default locale.** The one locale that cannot be missing.
+- **Testing 1 and 2 for plurals.** Misses every category English does not have.
+- **Mocking the i18n library away.** You are then testing that your mock returns strings.
+- **Never testing negotiation.** The most common real-world failure, and the easiest to test.
+
+## Going further
+
+- [Testing your content: CLI audit, programmatic API and UI assertions](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/testing.md)
+- [ESLint plugin: catching hardcoded strings and dead content](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/eslint.md)
+- [Formatters and locale utilities, including `getHTMLTextDir`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/formatters.md)
+- [Benchmark reports across frameworks](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/index.md)
+- [Drop-in react-i18next compat adapter](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/compat/react-i18next.md)
+- [How to find missing translations](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/detecting_missing_translations.md)
+- [ICU message format: plurals, select and skeletons](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/icu_message_format.md)

package/blog/en/icu_message_format.md

@@ -0,0 +1,288 @@
+---
+createdAt: 2026-09-02
+updatedAt: 2026-09-02
+title: "ICU Message Format: Syntax, Plurals and Select"
+description: A practical reference to ICU MessageFormat - argument interpolation, plural and select branching, CLDR plural categories per language, and the usual mistakes.
+keywords:
+  - icu message format
+  - icu messageformat
+  - cldr plural rules
+  - plural categories
+  - selectordinal
+  - i18n pluralization
+  - message syntax
+slugs:
+  - blog
+  - icu-message-format
+author: aymericzip
+---
+
+# ICU Message Format: the syntax, and the parts that trip people up
+
+ICU MessageFormat is a string syntax that lets a translation contain its own branching logic: plurals, gendered forms, number and date formatting. It exists because grammar belongs to the translator, not to the developer writing `if (count === 1)`. This post covers the syntax, the language-dependent parts that break naive implementations, and how the JS ecosystem handles it.
+
+## Table of Contents
+
+<TOC/>
+
+## The problem, concretely
+
+Here is the code almost everyone writes first:
+
+```ts
+const label = count + " " + (count === 1 ? t("item") : t("items"));
+```
+
+This works in English and breaks everywhere else:
+
+- **Russian and Polish** need three or four forms, not two.
+- **Japanese** needs one, and the space you concatenated is wrong.
+- **Arabic** needs six, and the number itself should be rendered in the locale's numbering system.
+- **French** puts a non-breaking space before some punctuation, which your `+ " "` just destroyed.
+
+The deeper problem is that the sentence has been cut into fragments. A translator sees `item` and `items` with no context and no ability to reorder the sentence. ICU MessageFormat fixes this by keeping the whole sentence in one translatable string and giving the translator the branching operators.
+
+## Simple arguments
+
+The smallest unit is a placeholder in single braces:
+
+```text
+Hello, {name}!
+```
+
+You pass `{ name: "Alice" }` at format time and get `Hello, Alice!`. Braces are the only special characters; to print a literal brace you wrap it in single quotes: `'{'`.
+
+That is the entire "interpolation" feature. Everything else in ICU is built on top of it.
+
+## Plural
+
+`plural` selects a branch based on a number:
+
+```text
+{count, plural,
+  one {You have one unread message}
+  other {You have # unread messages}
+}
+```
+
+Three things to know:
+
+- **`#`** is replaced by the formatted value of `count`, locale-formatted, so `1234` becomes `1,234` in `en-US` and `1 234` in `fr-FR`.
+- **`other` is mandatory.** Every ICU implementation will throw or fail validation without it. It is the fallback when no category matches.
+- **`=0`, `=1`, … match exact values** and are checked _before_ the CLDR categories. Use them for special-cased copy ("No messages"), not as a substitute for `one`.
+
+```text
+{count, plural,
+  =0 {No unread messages}
+  one {One unread message}
+  other {# unread messages}
+}
+```
+
+### offset
+
+`offset:n` subtracts `n` from the value before both category selection and `#` substitution. It exists for the "Alice and 3 others liked this" pattern:
+
+```text
+{count, plural, offset:1
+  =0 {No one liked this}
+  =1 {{name} liked this}
+  one {{name} and one other liked this}
+  other {{name} and # others liked this}
+}
+```
+
+With `count: 4`, the `#` renders `3`. `offset` is genuinely useful and genuinely under-supported, so check your runtime before relying on it.
+
+## Plural categories are language-dependent
+
+This is the part people get wrong. The category names `zero`, `one`, `two`, `few`, `many`, `other` are not universal buckets you fill in for every language. Each locale uses a _subset_, defined by the [CLDR plural rules](https://cldr.unicode.org/index/cldr-spec/plural-rules), and the rules are grammatical, not intuitive.
+
+| Language | Tag  | Categories used                  | Count |
+| -------- | ---- | -------------------------------- | ----- |
+| Japanese | `ja` | other                            | 1     |
+| Chinese  | `zh` | other                            | 1     |
+| English  | `en` | one, other                       | 2     |
+| German   | `de` | one, other                       | 2     |
+| French   | `fr` | one, many, other                 | 3     |
+| Czech    | `cs` | one, few, many, other            | 4     |
+| Polish   | `pl` | one, few, many, other            | 4     |
+| Russian  | `ru` | one, few, many, other            | 4     |
+| Arabic   | `ar` | zero, one, two, few, many, other | 6     |
+| Welsh    | `cy` | zero, one, two, few, many, other | 6     |
+
+Two consequences that surprise people:
+
+- **`one` does not mean "1".** In Russian, `one` covers 1, 21, 31, 101: any number ending in 1 except those ending in 11. In French, `0` falls into `one`.
+- **Adding a category to the English source does nothing.** The English message only needs `one` and `other`; the Polish translation needs four branches, and that structure lives in the Polish string, not the English one. Any format that forces all locales to share one key shape will fight you here.
+
+You can check what a runtime actually does without installing anything:
+
+```ts
+new Intl.PluralRules("pl").select(2); // "few"
+new Intl.PluralRules("pl").select(5); // "many"
+new Intl.PluralRules("ru").select(21); // "one"
+new Intl.PluralRules("ar").select(0); // "zero"
+```
+
+`Intl.PluralRules` ships CLDR data in every modern browser and in Node. A library claiming CLDR pluralization is almost always calling it underneath.
+
+## select and selectordinal
+
+`select` branches on an arbitrary string: a gender, a role, a status, a plan tier.
+
+```text
+{gender, select,
+  female {She updated her profile}
+  male {He updated his profile}
+  other {They updated their profile}
+}
+```
+
+Keys are matched literally and `other` is mandatory here too. `select` is the right tool any time sentence structure depends on an enum value, because languages disagree about which enums affect grammar.
+
+`selectordinal` is the same shape as `plural` but uses the **ordinal** plural rules, which are a different table from the cardinal ones:
+
+```text
+{rank, selectordinal,
+  one {#st place}
+  two {#nd place}
+  few {#rd place}
+  other {#th place}
+}
+```
+
+English uses four ordinal categories (1st, 2nd, 3rd, 4th) even though it only uses two cardinal ones. That asymmetry is exactly why the two operators are separate.
+
+## Number, date and time arguments
+
+ICU can format the value it interpolates:
+
+```text
+Total: {price, number, currency}
+Published {publishedAt, date, long} at {publishedAt, time, short}
+Conversion: {rate, number, percent}
+```
+
+The modern form is the **skeleton**, introduced with ICU 60 and marked by a `::` prefix. Skeletons are far more expressive than the legacy style names:
+
+```text
+{price, number, ::currency/EUR}
+{value, number, ::percent scale/100}
+{amount, number, ::compact-short}
+{distance, number, ::unit/kilometer unit-width-narrow}
+```
+
+Skeleton support is the most uneven part of the ecosystem. FormatJS implements them; several other runtimes only accept the legacy `number, currency` / `date, long` forms. Verify `::` support in your actual runtime before shipping.
+
+## Nesting, and where it stops being readable
+
+ICU composes. A plural branch can contain a select, which can contain another plural:
+
+```text
+{hostGender, select,
+  female {{guestCount, plural, offset:1
+    =0 {{host} does not give a party}
+    =1 {{host} invites {guest} to her party}
+    other {{host} invites {guest} and # other people to her party}
+  }}
+  other {{guestCount, plural, offset:1
+    =0 {{host} does not give a party}
+    other {{host} invites {guest} and # other people to their party}
+  }}
+}
+```
+
+This is the canonical ICU example and also the canonical argument against deep nesting. Two levels is where translators start making brace errors and where TMS editors stop helping. Nest at most two levels; if you need a third, split the sentence into two messages.
+
+## How JS libraries handle ICU
+
+| Library               | ICU support       | What you actually write                                                   |
+| --------------------- | ----------------- | ------------------------------------------------------------------------- |
+| react-intl (FormatJS) | Native, full      | ICU strings, including skeletons and rich-text tags                       |
+| next-intl             | Native            | ICU strings, via FormatJS's `intl-messageformat`                          |
+| i18next               | Plugin required   | `key_one` / `key_other` suffix keys and `{{name}}`; ICU via `i18next-icu` |
+| vue-i18n              | Partial / its own | `{name}` interpolation and pipe-separated plural branches                 |
+| Angular (`$localize`) | Subset            | ICU `plural` / `select` inside templates, extracted to XLIFF              |
+
+A few notes so the table is not misleading:
+
+- **i18next's default syntax is not ICU** and is not worse for it. Suffix keys (`item_one`, `item_few`) map onto `Intl.PluralRules` categories and are arguably easier for translators to edit in flat JSON. But `select` and nested branching are not part of it, so you either add `i18next-icu` or you write the logic in code.
+- **vue-i18n's pipe plurals** use a per-locale rule function, not CLDR categories by default. That works, but the plural rule lives in your app config rather than in the data.
+- **FormatJS is the reference implementation** in JS. When people say "ICU MessageFormat" in a JS context, they usually mean what FormatJS accepts.
+
+## How Intlayer handles it
+
+Intlayer does not use a string DSL. The branching operators are functions in a content declaration file, so the structure is typed and each locale declares only the categories its grammar needs:
+
+```typescript fileName="**/*.content.ts"
+import { plural, t, type Dictionary } from "intlayer";
+
+const openingsContent = {
+  key: "total_openings",
+  content: {
+    totalOpenings: t({
+      en: plural({
+        one: "{{count}} opening",
+        other: "{{count}} openings",
+      }),
+      pl: plural({
+        one: "{{count}} oferta",
+        few: "{{count}} oferty",
+        many: "{{count}} ofert",
+        other: "{{count}} ofert",
+      }),
+    }),
+  },
+} satisfies Dictionary;
+
+export default openingsContent;
+```
+
+```tsx fileName="**/*.tsx"
+const { totalOpenings } = useIntlayer("total_openings");
+
+totalOpenings(5); // Polish locale → "5 ofert"
+```
+
+The mapping to ICU concepts is direct:
+
+| ICU construct                 | Intlayer                                     |
+| ----------------------------- | -------------------------------------------- |
+| `{name}`                      | `insert("Hello {{name}}")`, or auto-detected |
+| `{count, plural, …}`          | `plural({ one, few, many, other })`          |
+| `{value, select, …}`          | `select({ draft, published, fallback })`     |
+| gender branch of `select`     | `gender({ male, female, fallback })`         |
+| boolean branch of `select`    | `cond({ true, false })`                      |
+| numeric ranges (non-CLDR)     | `enu({ "0": …, ">5": …, fallback: … })`      |
+| `{n, number, ::currency/EUR}` | `useCurrency()(1234.5, { currency: "EUR" })` |
+
+`plural` delegates category selection to `Intl.PluralRules`, so the CLDR table above applies unchanged. Formatting stays separate: numbers, dates, currencies and lists go through the [formatter hooks](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/formatters.md) instead of being embedded in the message.
+
+Honest limits:
+
+- Intlayer requires a build step; the compiler extracts declarations at build time. If you want plain JSON loaded at runtime, that is a different model.
+- `plural` cannot nest a `t()` inside its branches yet; you wrap `plural` in `t()`, not the other way round.
+- The ecosystem is smaller than i18next's. Fewer TMS integrations, fewer StackOverflow answers.
+
+If you are coming from a codebase that already contains real ICU strings, the [react-intl compat adapter](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/compat/react-intl.md) parses them directly: `plural`, `select`, `selectordinal`, `#`, and the legacy `number` / `date` / `time` arguments. Skeletons and `offset:` are not covered by that resolver, so check those messages when you migrate. The [i18next adapter](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/compat/i18next.md) resolves the suffix form (`key_one`, `key_male`) against `Intl.PluralRules` instead.
+
+## Common mistakes
+
+- **Hardcoding plural logic in JS.** `count === 1 ? a : b` produces the wrong output for 8 of the 10 languages in the table above. Once the ternary is in code, no translator can fix it.
+- **Concatenating translated fragments.** Word order, agreement and punctuation spacing are all locale-dependent. Keep the sentence whole.
+- **Omitting `other`.** It is required by the spec, not a convention. Most parsers reject the message; the ones that do not will render nothing.
+- **Assuming your categories generalize.** An English source with `one` / `other` does not mean the Polish file has two branches. Let each locale declare its own. See [per-locale content declaration](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/per_locale_file.md).
+- **Using `=1` where you meant `one`.** `=1` matches only the literal 1. In Russian, 21 needs `one`, and `=1` will never fire for it.
+- **Putting `#` outside a plural branch.** It is only special inside `plural` / `selectordinal`. Elsewhere it is a literal hash.
+- **Forgetting that `#` is formatted.** If you want the raw number, interpolate the argument by name instead.
+
+## Going further
+
+- [Plural content in Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/dictionary/plurial.md): the CLDR-backed `plural` node and its category table.
+- [Select-based content](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/dictionary/select.md): the equivalent of ICU `select`, and when to use `enu` or `cond` instead.
+- [Insertion placeholders](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/dictionary/insertion.md): `{{name}}` interpolation and automatic detection.
+- [i18n library benchmark](https://github.com/aymericzip/intlayer/blob/main/docs/docs/en/benchmark/index.md): bundle size and runtime cost across the libraries listed above.
+- [react-i18next vs react-intl vs Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/react-i18next_vs_react-intl_vs_intlayer.md): a fuller comparison of the three message models.
+- [What is internationalization?](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/what_is_internationalization.md): the wider scope beyond message formatting.
+- [i18n meaning](https://github.com/aymericzip/intlayer/blob/main/docs/blog/en/i18n_meaning.md): where the term comes from and how i18n differs from l10n.

package/blog/en/intlayer_with_i18next.md

@@ -89,15 +89,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > the `--interactive` flag is optional. Use `intlayer-cli init` if you're an AI agent.

package/blog/en/intlayer_with_next-i18next.md

@@ -80,15 +80,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > the `--interactive` flag is optional. Use `intlayer-cli init` if you're an AI agent.

package/blog/en/intlayer_with_next-intl.md

@@ -79,15 +79,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > the `--interactive` flag is optional. Use `intlayer-cli init` if you're an AI agent.

package/blog/en/intlayer_with_react-i18next.md

@@ -80,15 +80,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > the `--interactive` flag is optional. Use `intlayer-cli init` if you're an AI agent.

package/blog/en/intlayer_with_react-intl.md

@@ -78,15 +78,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > the `--interactive` flag is optional. Use `intlayer-cli init` if you're an AI agent.

package/blog/en/intlayer_with_vue-i18n.md

@@ -80,15 +80,15 @@ npx intlayer init --interactive
 ```
 
 ```bash packageManager="pnpm"
-pnpm dlx intlayer@canary init --interactive
+pnpm dlx intlayer init --interactive
 ```
 
 ```bash packageManager="yarn"
-yarn dlx intlayer@canary init --interactive
+yarn dlx intlayer init --interactive
 ```
 
 ```bash packageManager="bun"
-bunx intlayer@canary init --interactive
+bunx intlayer init --interactive
 ```
 
 > the `--interactive` flag is optional. Use `intlayer-cli init` if you're an AI agent.