Weave Code
I18N Laravel Package
conedevelopment/i18n
Multilingual routing for Laravel: define a route once, then serve translated URIs and route names per locale. Includes middleware to detect and set the application locale from the URL, plus helpers for generating localized links and language switchers.
Push your Laravel translations to the front-end and use them easily with JavaScript.
Frequently asked questions about I18N
- How do I install and set up conedevelopment/i18n in a Laravel app?
- Install it with Composer, which supports Laravel package auto-discovery. Optionally publish the config file, then add the package's Blade directive to your base layout so translations are serialized into the rendered HTML. From there you can call the JavaScript __() helper in your front-end code. No database migrations or new infrastructure are required.
- How does conedevelopment/i18n expose Laravel translations to JavaScript?
- It reads Laravel's existing translation repository and inlines the strings into the rendered HTML through a Blade directive. A small JavaScript helper named __() then mirrors Laravel's PHP __() helper so you can look up strings client-side. Translations stay in your lang/ directory as the single source of truth, and there is no separate JS translation build pipeline. Because it defines a global window.__ helper, confirm it does not collide with existing analytics shims or other i18n packages before rollout.
- Which Laravel and PHP versions does conedevelopment/i18n support?
- The package is Composer-installed and designed for Laravel applications, but the exact Laravel and PHP version matrix should be verified against the repository's composer.json and release history before committing. It is a small-maintainer package with limited visibility into backward-compatibility guarantees across Laravel majors. Pin the dependency and confirm it tracks your current and next Laravel major.
- Does inlining translations into HTML hurt page performance?
- Yes, payload growth is the primary technical risk: every shipped key scales linearly with key count times locales. A 3,000-key, five-locale app can add tens to hundreds of kilobytes to each HTML response before compression, affecting TTFB, cache efficiency, and mobile performance. Measure your actual payload and consider loading only the keys needed per page or view. The cost is developer time and response size, not platform spend.
- How should I configure caching and CDNs when translations are inlined in HTML?
- Because translations are baked into the HTML, any CDN or full-page cache keyed without the locale and translation version will serve stale or wrong-language content. Define an explicit cache-key strategy that includes the active locale and a translations version or build hash. Assign an owner for changing that cache configuration before rollout. This is an operational risk that should be resolved up front.
- Is conedevelopment/i18n safe against XSS when translations contain user input?
- Translation strings are interpolated into a script context, so correct JSON encoding and context-aware escaping must be verified rather than assumed. This matters most when translation values are user-influenced, such as tenant-defined labels or CMS content. Review the package's escaping behavior and its tests before shipping. Do not rely on Blade escaping alone for a script context.
- Does conedevelopment/i18n work with Vue, React, or an API-first SPA?
- It is a thin presentation-layer adapter for server-rendered Blade apps with light client-side behavior like Alpine, vanilla JS, jQuery, Livewire, or Turbo. It is a poor fit for API-first or SPA architectures where Blade layouts are not the delivery vehicle. In those cases a JSON endpoint or build-time extraction with a Vite i18n loader is usually better. The package does not change routing, persistence, auth, or queueing.
- What happens when a translation key is missing in conedevelopment/i18n?
- Missing keys fail silently and render the raw key string in the UI, so the bug surfaces in QA or production rather than at build time. The package provides no type safety or key validation. Mitigate this with conventions, key linting, and tests that assert expected keys exist for every locale. Treat key hygiene as a team process, not something the package enforces.
- Does conedevelopment/i18n support namespaced and vendor translations, or per-view loading?
- This is one of the open questions to resolve before committing: confirm whether namespaced and vendor translations are supported and whether partial or per-view loading is possible. Full-payload inlining is the documented concern, so per-view loading matters for larger apps. Verify against the package source and README rather than assuming parity with Laravel's PHP translator. If unsupported, plan a workaround or scope only the keys you actually ship.
- Is conedevelopment/i18n actively maintained and does it have tests?
- It is a small-maintainer package (roughly 128 GitHub stars, MIT licensed) with no SLA and limited visibility into its test surface. Backward-compatibility guarantees across Laravel majors are unknown, so treat it as a pinned dependency with an internal owner rather than a platform component. Check the repository's release history and test coverage for escaping, missing keys, and locale switching before committing. Budget time to fork or wrap it if maintenance stalls.
Weaver
How can I help you explore Laravel packages today?