Stop Passing App::getLocale() to Laravel’s __() Helper

πŸ“– 2 minutes read

I’ve seen this pattern in multiple Laravel codebases β€” a translation helper that manually fetches the locale before passing it to the translation function:

// Don't do this
$locale = App::getLocale();
$label = __('orders.status_label', [], $locale);

That third parameter is unnecessary. The __() helper already calls App::getLocale() internally when no locale is provided.

How __() Actually Works

Under the hood, __() delegates to the Translator’s get() method:

// Illuminate\Translation\Translator::get()
public function get($key, array $replace = [], $locale = null, $fallback = true)
{
    $locale = $locale ?: $this->locale;
    // ...
}

When $locale is null (the default), it uses $this->locale β€” which is the application locale set by App::setLocale(). It’s the same value App::getLocale() returns.

So the clean version is just:

// Do this instead
$label = __('orders.status_label');

When You DO Need the Locale Parameter

The third parameter exists for a reason β€” when you need a translation in a specific locale that differs from the current one:

// Sending an email in the user's preferred language
$subject = __('emails.welcome_subject', [], $user->preferred_locale);

// Generating a PDF in a specific language regardless of current request
$label = __('invoice.total', [], 'ja');

These are legitimate uses. The anti-pattern is fetching the current locale just to pass it right back.

The Compound Version

This gets worse when the manual locale fetch spreads across a method:

// This entire method is doing unnecessary work
public function getLabels()
{
    $locale = App::getLocale();
    
    return [
        'name'    => __('fields.name', [], $locale),
        'email'   => __('fields.email', [], $locale),
        'phone'   => __('fields.phone', [], $locale),
        'address' => __('fields.address', [], $locale),
    ];
}

Every single $locale parameter is redundant. This should be:

public function getLabels()
{
    return [
        'name'    => __('fields.name'),
        'email'   => __('fields.email'),
        'phone'   => __('fields.phone'),
        'address' => __('fields.address'),
    ];
}

Same output, less noise, fewer places to introduce bugs. The framework already handles locale resolution β€” let it do its job.

Daryle De Silva

VP of Technology

11+ years building and scaling web applications. Writing about what I learn in the trenches.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *