--- createdAt: 2026-08-29 updatedAt: 2026-08-29 title: "htmx i18n - Complete guide to translate your app" description: "No more i18next. The 2026 guide to building a multilingual (i18n) htmx app. Translate with AI agents and optimize bundle size, SEO and performances." keywords: - Internationalization - Documentation - Intlayer - htmx - Hypermedia - JavaScript - Backend slugs: - doc - environment - htmx history: - version: 9.4.1 date: 2026-08-29 changes: "Initial history" author: aymericzip --- # Translate your htmx application using Intlayer | Internationalization (i18n) htmx renders no content of its own. Every label a visitor reads is HTML your server produced, and every swap is a separate HTTP request. Internationalizing an htmx app is therefore a server concern: the locale has to be resolved on each request, and each fragment has to be rendered in that locale. Intlayer covers this through its backend integrations, which detect the locale per request and expose your declared content to the handler that builds the HTML. ## Table of Contents ## The three rules of i18n in an htmx app A single page can trigger dozens of swaps. Each one is a fresh request with no memory of the page that issued it. If the locale lives in a variable set during the initial render, every fragment after it falls back to the default language. The Intlayer middleware resolves the locale from the request itself, so a fragment served at minute ten answers in the same language as the page served at minute zero. Two carriers work with htmx. A cookie (`INTLAYER_LOCALE`) is sent by the browser automatically on every request, including htmx ones. A header (`x-intlayer-locale`) can be attached to htmx requests with the `hx-headers` attribute. Both are read by default. A translated value interpolated into a fragment is markup. Escape it, exactly as you would any other dynamic value, so a translation containing `<` cannot break the document it is swapped into. --- ## Step-by-Step Guide