In Laravel, how do you change a package's translation lines without editing vendor/, and what should the override file contain?

## Why not edit the package Anything under `vendor/` is overwritten by the next `composer install` or `composer update`, so edits there vanish on deploy. Laravel gives you a **vendor override directory** instead. ## How packages expose translations A package registers its translation directory under a **namespace** from its service provider, and its lines are addressed as `namespace::group.key`: ```php __('billing::invoices.paid'); ``` The namespace is whatever the package chose when registering, which is often, but not always, the package's short name. Read the package's docs or its keys to find it. ## Writing the override The path is: ``` lang/vendor/{namespace}/{locale}/{group}.php ``` For a package namespaced `billing` with a group `invoices`, a Spanish override is `lang/vendor/billing/es/invoices.php`: ```php <?php return [ 'paid' => 'Donación recibida', ]; ``` Rules for the file: - **Only include the lines you change.** The loader reads the package's own file first and then applies your file with `array_replace_recursive`, so missing keys keep the package's value. - **Nested arrays merge key by key**, not wholesale, for the same reason. - **One file per group and locale.** Overriding Polish needs `lang/vendor/billing/pl/invoices.php` too. ## Overrides by string type | What you want to change | Where the override goes | |---|---| | A package's short-key group line | `lang/vendor/{namespace}/{locale}/{group}.php` | | A package's sentence-keyed (JSON) line | your own `lang/{locale}.json`, same sentence as key | | A framework line such as a validation message | `lang/{locale}/validation.php` after `lang:publish` | The JSON row works because the file loader merges JSON files from package-registered JSON paths first and the application's `lang` directory last, so your entry for the same sentence wins. The framework row differs because Laravel's own lines are not namespaced: its `lang` directory is simply the first base path, and your `lang` directory is merged over it. ## Pitfalls 1. **Copying the whole package file.** It works, but freezes every line at today's wording; later package fixes never reach you. 2. **Using the Composer vendor name as the directory.** If the package registered a different namespace, your override is never read. 3. **Expecting lang:publish to copy package files.** It copies only the framework's English files; packages that want you to customise more offer their own publish step. 4. **Forgetting the locale level.** `lang/vendor/billing/invoices.php` without a locale directory is never loaded. ## A worked example A charity site uses a donations-billing package whose Spanish receipt line reads `Pago recibido`; the charity wants `Donación recibida`, and a Polish wording of its own. The steps: 1. Find the namespace in a key the package uses, for instance `billing::invoices.paid`, which gives the namespace `billing` and the group `invoices`. 2. Create `lang/vendor/billing/es/invoices.php` returning `['paid' => 'Donación recibida']`. 3. Create `lang/vendor/billing/pl/invoices.php` with the Polish line. 4. Leave every other key out of both files. ## Checking the result - Call `__('billing::invoices.paid')` from `php artisan tinker` with the locale set, and compare it with a key you did not override. - In a test, assert that `Lang::get('billing::invoices.paid', [], 'es')` returns the new text, so a package update that renames the key fails the build instead of silently reverting the wording. ## Keeping overrides healthy on upgrades - Read the package's changelog for renamed translation keys; an override for a key the package no longer reads has no effect. - Keep a short comment in each override file explaining why the wording differs, so the next developer does not delete it as noise. - Review overrides when the package adds or improves a locale you already override, since its new lines may now cover what you wrote.