- How do I install kg-bot/laravel-localization-to-vue in a Laravel app?
- Install it with Composer as a dev dependency, optionally publish its config file, then run the package's Artisan export command to generate your JS translation artifacts. Because it is a build-time tool, it does not need to be installed in production. Pin the version in composer.json so the generated output stays consistent across machines and deploys.
- Does it work with both PHP lang files and JSON translation files?
- Yes. The package reads Laravel's standard PHP language files as well as JSON lang files and emits them in the format required by JavaScript localization packages such as vue-i18n. That lets you keep lang/ as the single source of truth instead of hand-maintaining a second set of front-end translation strings.
- Is kg-bot/laravel-localization-to-vue a runtime dependency or a build-time tool?
- It is build-time only. It registers an Artisan command that reads your lang files and writes JS or JSON artifacts, and it does not sit in the request path of your application. Install it with require-dev and run it as part of your asset build or CI pipeline, which means a failure shows up as a build error rather than a production outage.
- Which Laravel versions does this package support?
- The 2.4 release adds Laravel 13.x compatibility alongside automated formatting changes, and it is a narrow, non-breaking update with no API or config schema changes. Because chasing a new framework major can also mean older versions were dropped, check the composer.json constraints for the exact Laravel floor before adopting. If you run a mixed-version fleet, pin the package per application.
- Can it watch lang files and regenerate translations automatically?
- The package supports a watch mode so translation artifacts can be regenerated as you edit PHP or JSON lang files during development, which keeps the front end in sync without manual re-runs. For CI, prefer a single generate step plus a git diff check rather than watch mode. Watch mode is a developer convenience, not something you run in a deployed environment.
- How does it handle nested keys when converting to vue-i18n format?
- Nested arrays are flattened into the dot-notation keys vue-i18n expects, so a key inside lang/en/auth.php becomes something like auth.failed in JavaScript. Conversion fidelity is the main risk with any bridge like this, so diff the generated output key by key against your existing artifacts before switching consumers. Nested keys, plurals and interpolation escaping are the specific cases worth covering with tests.
- Does it handle Laravel pluralization and :placeholder syntax correctly for vue-i18n?
- Verify this rather than assume it, because Laravel's pipe-based pluralization and :name placeholders do not map one-to-one onto vue-i18n message syntax. Placeholder styles such as :name versus {name}, and :attribute-style replacements, are exactly where drift bugs appear. Write tests for plurals, placeholders and escaped characters, and compare generated files against known-good output before rollout.
- Which vue-i18n version is the generated output shaped for?
- The output is plain JS or JSON translation objects intended for vue-i18n, but message format and pluralization behaviour changed between vue-i18n v8, v9 and v11. Confirm which major your front end uses and test the generated artifacts against it. If you are on an older major, expect to adjust plural handling rather than relying on a drop-in conversion.
- Is this a good alternative to xiCO2k/laravel-vue-i18n?
- They solve adjacent problems. kg-bot/laravel-localization-to-vue generates static translation artifacts at build time, while xiCO2k/laravel-vue-i18n exposes translations at runtime through a shared __() helper. If your team already uses the runtime helper, this package may be redundant. Choose the build-time approach when you want no runtime translation dependency and are happy to regenerate artifacts on every deploy.
- Can I verify generated translations in CI and roll back safely?
- Yes. Run the export command in CI followed by git diff --exit-code to prove the generated artifacts match what is committed. Treat adoption as an additive, reversible step: point the output at your existing artifact path so no front-end import statements change, and keep the previous files in branch history as your rollback. Cut over consumers only once parity holds key by key.