In Laravel's config/app.php, what do locale, fallback_locale and faker_locale each control, and which environment variables set them?

## The three keys at a glance | Key | Env variable | Skeleton default | Used by | |---|---|---|---| | `locale` | `APP_LOCALE` | `en` | the translator's starting locale, `App::currentLocale()` | | `fallback_locale` | `APP_FALLBACK_LOCALE` | `en` | the translator's second lookup for short keys | | `faker_locale` | `APP_FAKER_LOCALE` | `en_US` | the `fake()` helper and model factories | The skeleton writes each as `env('APP_...', default)` inside `config/app.php`, so the values are baked in when you run `php artisan config:cache`. ## locale The **default locale** is read when the translator singleton is first built: its constructor receives `app.locale`. From then on the translator holds its own copy, which is why `App::setLocale()` exists: it updates the config value and the translator together and fires `LocaleUpdated`. ## fallback_locale The **fallback locale** is handed to the translator with `setFallback()` when it is built. It matters in three places: 1. A short key such as `hr.leave` missing from `lang/pl/hr.php` is looked up in the fallback locale's `lang/en/hr.php` before the translator gives up. 2. `trans_choice()` uses the fallback locale's line *and* its plural rules when the active locale lacks the key. 3. It is **not** consulted for JSON sentence keys: a sentence missing from `lang/pl.json` returns the sentence itself. `App::setFallbackLocale('de')` changes it at runtime, updating config and translator together. Setting the fallback to the same value as the locale simply removes the second lookup. ## faker_locale The **Faker locale** controls generated test and seed data only. The `fake()` helper reads `app.faker_locale` and caches one Faker generator per locale in the container; the factory layer and the `WithFaker` test trait read the same key. A Polish HR portal whose `faker_locale` is still `en_US` gets English-looking names and addresses in its seeded data, whatever `APP_LOCALE` says. `fake('pl_PL')` asks for a specific locale in one call. ## Changing values at runtime - `App::setLocale()` and `App::setFallbackLocale()` update both config and the translator. - `config(['app.locale' => 'de'])` updates only config. If the translator has not been resolved yet in this process it will pick the new value up when it is built; if it already exists it keeps the old locale, so `__()` output does not change. That order dependency is why the setters are the only safe route. - `env('APP_LOCALE')` in application code returns `null` after `config:cache`; read `config('app.locale')` or `App::currentLocale()` instead. ## Pitfalls - Treating `faker_locale` as a translation setting, or `locale` as a data-generation setting. - Expecting `fallback_locale` to fill gaps in JSON translation files. - Leaving `APP_FALLBACK_LOCALE` pointing at a locale with incomplete files, so the fallback itself misses and raw keys appear. ## A worked example: the HR portal's settings A portal whose head office works in Polish, with English as the common second language, might use: - `APP_LOCALE=pl`, so anonymous pages and anything that never sets a locale speak Polish; - `APP_FALLBACK_LOCALE=en`, because the English files are the ones every feature ships with first, so a missing Polish short key shows English rather than a raw key; - `APP_FAKER_LOCALE=pl_PL`, so seeded demo employees have Polish names and addresses that exercise the layouts the real users will see. Choosing the fallback is a product decision: the language with the **most complete** files is usually safer than the language most users speak, because a fallback that itself misses produces raw keys. ## Checking the configuration 1. `php artisan config:show app` prints the resolved values of all three keys. 2. `php artisan about` shows the `Locale` value among its environment details. 3. After changing `.env` on a server that caches config, rebuild the cache; until then the old values stay in effect.