Steve Grunwell

Open-source contributor, speaker, and electronics tinkerer

Still from the 2003 film Lost in Translation, starring Bill Murray and Scarlet Johansson

Finding Missing Laravel Translations

Out of the box, Laravel ships with a simple-but-intuitive localization system: when you call trans('some.key')and Laravel will automatically replace it with the value of “key” within resources/lang/{locale}/some.php. Laravel translations also accept placeholders and can handle pluralization, making it extremely easy to build applications that are localization-ready.

Of course, building an application that’s localization-ready means the Laravel translations need to be filled out to begin with. It’s far too easy to get on a role writing several views, then miss a string or two when creating the localization files. Heck, even the comments in the Translator class within Laravel itself doesn’t seem to think much of it:

If the line doesn’t exist, we will return back the key which was requested as that will be quick to spot in the UI if language keys are wrong or missing from the application’s language files. Otherwise we can return the line.

Unfortunately, I’ve had one too many apps go live (or in front of clients for demos) with a string or two missing a translation. Finally, I decided to do something about it.

Discover when strings are Lost in Translation

I’m proud to announce that my first public Laravel package, Lost in Translation, is now available for download via Packagist! Lost in Translation extends the default Translation class, adding special handling when a string is left untranslated.

By default, Lost in Translation can do three different things when it detects an un-translated string:

  1. Log the string (along with any attempted replacements and the desired locale) to storage/logs/lost-in-translation.log.
  2. Throw a LostInTranslation\MissingTranslationException exception, which is great for integration testing environments!
  3. Dispatch a LostInTranslation\Events\MissingTranslationFound event, enabling applications to apply their own custom handlers, be it sending an email, opening a ticket, or anything else that might need to happen.

The logging and exception throwing behaviors are both controlled via environment variables, and nothing is registered to the event by default. As a result, Lost in Translation can be dropped into an existing application without requiring any modification to your existing codebase!

Installation

The easiest way to install Lost in Translation into your application is via Composer:

Laravel 5.5 will automatically discover the replacement for the default TranslationServiceProvider; simply install and get on your way!

The full source of the package is available on GitHub, where pull requests are welcome!

Previous

Developer-specific Laravel Homestead Configurations

Next

Deeper Testing with PHPUnit Markup Assertions

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Be excellent to each other.