- How do I install kkomelin/laravel-translatable-string-exporter in a Laravel app?
- Install it as a development dependency with composer require --dev kkomelin/laravel-translatable-string-exporter. Laravel's package discovery registers the service provider automatically, so no manual registration is needed. You can optionally publish the config file with vendor:publish to customise search paths, extraction functions and output format, then run the translatable:export command for the locale you want.
- Which Laravel and PHP versions does this package support?
- Release 1.26.0 added support for Laravel 13, and the package has tracked recent Laravel majors including 10, 11 and 12. Because a compatibility release can also raise the minimum PHP version, check the composer.json constraints on Packagist for the exact version you pin. If your application is on an older Laravel major, pin an earlier tagged release that still lists your framework version.
- Does this package add any runtime overhead in production?
- No. It is development-time tooling: a single Artisan command plus generated language files that Laravel's built-in localizer already reads. There is no middleware, no request-time scanning and no external service or network access, so it introduces essentially no new runtime surface area. Keep it in require-dev so it never ships to production.
- How does the exporter find translatable strings in my code?
- It scans configured source paths for translation helper calls such as __(), trans() and the @lang Blade directive, then writes the discovered keys into Laravel language files. Both the search paths and the list of recognised extraction functions are configurable, so you can adapt it to your codebase conventions. It is a static scanner, so it only sees calls that match the patterns you have configured.
- Can I export translations to JSON instead of PHP language files?
- Yes. The package supports Laravel's native language resources in several shapes, including PHP array files under resources/lang or lang, JSON files such as lang/en.json, and a plain PHP array output. The export strategy is configurable, along with options like sorting keys and filtering which strings are written, so you can match your existing file layout.
- Will running the export overwrite my existing translations?
- The command writes discovered keys into your language files, so regenerating them can overwrite in-place human translations unless you review the diff and define a clear merge workflow. The export is one-way: it is not a two-way sync with a translation management platform. Keep language files in version control and treat generated output as something to review rather than blindly commit.
- Can it extract dynamically built translation keys?
- No. Extraction is static and pattern-based, so keys assembled from variables, interpolated strings, or wrapped inside custom helper functions will be missed or misread. For wrappers, add the function names to the configurable extraction list so the scanner recognises them. For truly dynamic keys, add them to the language files manually or handle them in a separate step.
- Can I run the export command in CI or a build pipeline?
- Yes. The command runs locally with no credentials, external services or network access, so it works fine in CI containers and build steps. A common pattern is running the export and failing the build when the generated files differ from what is committed, which surfaces missing or stale keys early. Review the diff before letting CI commit anything automatically.
- Does it handle frontend JavaScript, Vue or React translation strings?
- No. It scans PHP and Blade source for translation helper calls, so Vue, React and other JavaScript strings fall outside its scope, as do mobile app strings and CMS-authored content. Those need a separate frontend i18n extraction tool and workflow. Keep this package focused on the Laravel server-side strings it was built for.
- Is laravel-translatable-string-exporter actively maintained, and what are the alternatives?
- It is a small MIT-licensed project at single-maintainer scale, but recent releases such as 1.26.0 with Laravel 13 support came from community contributions, which is a good sign that pull requests are being merged. Alternatives include translation-manager packages for editing translations at runtime, and translation management platforms such as Crowdin, Lokalise or Phrase used as a downstream consumer of the exported files. For straightforward extraction into Laravel language files it remains a low-risk development dependency.