- How do I install andrey-helldar/laravel-lang-publisher in a Laravel app?
- Install it with Composer, typically as a dev dependency: composer require --dev andrey-helldar/laravel-lang-publisher. The package uses Laravel package auto-discovery, so no manual service provider registration is normally required. After installation the Artisan command becomes available, and you can run it to publish the locales you need.
- Which Laravel versions does laravel-lang-publisher support?
- The package targets modern Laravel releases, and its recent 16.8.0 release adds support for Laravel 13 through its dependency chain. Because framework compatibility can move inside patch releases, check the composer.json constraints for the exact Laravel and PHP versions supported by the version you install. Teams staying on an older Laravel major should confirm their constraint still resolves before upgrading.
- What Artisan command publishes the translation files?
- The package registers a dedicated Artisan command, commonly invoked as php artisan lang:publisher, which publishes localization files into your application's lang directory. Run it interactively to select the locales you want, or pass options for non-interactive use. Always check the README for your installed version, since flags and command names can change between majors.
- How do I choose which locales to publish or refresh?
- The publisher lets you select locales rather than dumping every available language into your project. You can run it interactively and pick from the list, which keeps the lang directory focused on the languages your application actually supports. For repeatable setups, pass the locale list as command options so scripts and CI runs stay deterministic.
- Can I update existing translation files without losing my custom translations?
- The package is designed to keep your lang directory in sync with the upstream laravel-lang translations, but overwriting files always carries risk if you have edited them locally. Review the command's force and sync options carefully, and commit or back up your lang directory before refreshing. A good pattern is to keep app-specific overrides separate from published vendor translations.
- Where does laravel-lang-publisher put the language files?
- Files are published into the standard Laravel lang directory, following the usual lang/{locale} structure that Laravel's translator expects. That means no custom configuration is needed for the framework to pick them up. If your application uses a custom lang path, verify that the publisher writes to the same location your translator reads from.
- Should laravel-lang-publisher be a dev dependency or a production dependency?
- It is a build-time and maintenance tool, so installing it with --dev is the usual choice. Run the publisher locally or during deployment when you want to add or refresh locales, then commit the generated lang files if your workflow tracks them in version control. Keeping it out of production dependencies reduces the surface area of your runtime Composer install.
- How is this different from running php artisan vendor:publish or using laravel-lang/common?
- vendor:publish copies whatever files a package ships, whereas laravel-lang-publisher is purpose-built for fetching and syncing laravel-lang translations by locale. The laravel-lang/common package provides the shared translation data and related tooling; the publisher is the convenience layer that writes those translations into your app. Use the publisher when you want a single command to manage locale files rather than wiring the pieces together yourself.
- Do I need to publish a config file or register a service provider manually?
- In most Laravel applications, no manual provider registration is needed thanks to auto-discovery. If the package ships a config file, publish it only when you need to override defaults such as paths or locale behaviour. Start with the defaults, confirm the command works, and add configuration later if your project has non-standard requirements.
- How actively is laravel-lang-publisher maintained, and should I worry about major version churn?
- The package is on a high major version, which reflects a historically fast release cadence tied to Laravel framework changes. That is not a functional risk by itself, but budget for occasional constraint bumps instead of treating it as set-and-forget. Pin a version in composer.json and review upgrade notes when moving between majors.