fidum/laravel-translation-faker
fidum/laravel-translation-faker generates fake translations for Laravel language files using Faker. Populate missing keys, create realistic demo data, and test multilingual interfaces without writing strings by hand. Ideal for local development and automated tests.
Install (dev-only):
composer require --dev fidum/laravel-translation-faker
The service provider is auto-discovered, so there is nothing to register.
Publish and inspect the config first — this is the one file worth reading before you use the package:
php artisan vendor:publish --tag=translation-faker-config
Open config/translation-faker.php and confirm two things: the enabled flag (usually driven by an env var such as TRANSLATION_FAKER_ENABLED) and the format/template used to render faked strings. Everything else about day-to-day behaviour follows from those two settings.
Enable it locally:
# .env
TRANSLATION_FAKER_ENABLED=true
php artisan config:clear # required if you have cached config
First use case: load your app in the browser. Every string that goes through Laravel's translator (__(), @lang, trans(), trans_choice()) now renders in the faker's obvious placeholder format instead of the real copy. Anything still showing a raw key like messages.welcome is a genuine gap in your language files. That single sweep — click through the app, screenshot-review it — is the highest-value thing the package does.
Environment-scoped toggling. The package is only useful where you can tolerate seeing fake copy. Typical setup:
| Environment | Enabled | Why |
|---|---|---|
local |
yes | catch missing keys as you build |
testing |
per-suite | opt in for key-coverage tests only |
staging |
sometimes | QA passes, behind auth |
production |
never | users would see placeholder text |
Keep the default in config/translation-faker.php as false and only opt in via env, so a forgotten .env fails safe.
QA / screenshot review workflow. Point a staging deploy at the faker, walk the critical journeys (signup, checkout, emails, validation errors), and file one ticket per raw key you see. Because the fake output is visually distinct from real copy, a reviewer does not need to know the codebase to spot a problem.
Key-coverage smoke test. Rather than toggling the whole suite, enable the faker in a dedicated test case and assert that rendered pages contain no raw-key patterns:
protected function setUp(): void
{
parent::setUp();
config(['translation-faker.enabled' => true]);
}
public function test_checkout_has_no_untranslated_keys(): void
{
$this->actingAs($user)->get('/checkout')
->assertOk()
->assertDontSee('checkout.'); // raw key prefix leaking through
}
This catches strings added by feature work that never made it into lang/.
Per-locale sweeps. Run the same sweep once per locale (app()->setLocale('fr') in a test loop, or a locale switcher in staging). A key present in en but absent in fr will fall back, and whether that fallback shows in the faker depends on your fallback locale config — so test each locale explicitly rather than assuming.
Custom output format. If your QA reviewers need something more obvious, or you want to embed the key so it is copy-pasteable into a bug report, adjust the format in the published config. Keeping the key visible in the output is more useful than a generic "FAKE" string — it tells you exactly which file to edit.
Pair it with a translation-key linter in CI. The faker is a runtime/visual tool; static extraction tools (or php artisan key-diff commands) catch gaps earlier. Use the faker for the things static analysis misses — dynamic keys built with concatenation or variables.
Config cache will silently defeat your env toggle. In any environment with config:cache (which includes most staging setups), changing TRANSLATION_FAKER_ENABLED does nothing until you re-run php artisan config:cache. This is the single most common "it's not working" cause.
Production safety is on you. The package cannot know your intent. Add a boot-time guard if your deploy pipeline is not trustworthy:
// AppServiceProvider::boot()
if ($this->app->isProduction() && config('translation-faker.enabled')) {
throw new RuntimeException('Translation faker enabled in production.');
}
It does not touch frontend translations. Strings resolved in JavaScript via laravel-vue-i18n, lang.js, or a JSON translation payload fetched from an endpoint are only affected if they pass through the PHP translator server-side. Anything already compiled into a JS bundle bypasses the faker entirely.
Tests that assert on real copy will break. If a suite asserts assertSee('Welcome back') and the faker is on, the assertion fails against the placeholder. Scope the faker to a dedicated test class or a trait rather than a global phpunit.xml env var.
Pluralisation and trans_choice. The faker intercepts the lookup, so the correct plural branch is chosen before the value is faked — which is what you want, but it means a wrong trans_choice count argument still produces a wrong-looking sentence. Do not treat faker output as validation of plural rules.
Blade view caching. Compiled Blade views are cached; if you are editing config and seeing stale behaviour, php artisan view:clear alongside the config clear removes one variable.
Fallback locales mask gaps. If fallback_locale is set to en, a missing fr key renders the English string, not a raw key — so it will not look broken in the faker. Temporarily unset the fallback (or check each locale in isolation) when you specifically want to hunt missing translations.
Version note (2.2.0). This release only widens compatibility — Laravel up to 13 and PHP up to 8.5 — with no API or config changes. If you are upgrading the host app to Laravel 13 or PHP 8.5, pin ^2.2 to get the widened constraints; on older Laravel versions ^2.1 remains equivalent. No migration steps required.
How can I help you explore Laravel packages today?