Laravel localization in English English

Locale codes

Set the base locale in config/app.php. For regional variants, English commonly uses: en_US, en_GB, en_AU, en_CA, en_IN

// config/app.php
'locale' => 'en',
'fallback_locale' => 'en',

// Or switch at runtime
App::setLocale('en');

Plural rules: what English actually needs

CLDR defines 2 cardinal categories for English. The sample numbers below were computed by ICU for this exact locale:

Laravel's trans_choice() maps numbers to 2 pipe-separated forms for this locale:

// lang/en/messages.php
'items' => ':count item|:count items'

// Usage
trans_choice('messages.items', $count, ['count' => $count]);

Try any number live in the pluralization tester.

Localized dates with Carbon

Real output for English (en locale), generated by Carbon for March 21, 2026:

$date = now()->locale('en');

$date->translatedFormat('l, j F Y');
// "Saturday, 21 March 2026"

$date->isoFormat('LLLL');
// "Saturday, March 21, 2026 2:30 PM"

$date->isoFormat('L');
// "03/21/2026"

$date->subDays(3)->diffForHumans();
// "3 months ago"

What to watch out for in English

• Spelling differs between variants (color/colour, organize/organise); pick en_US or en_GB and stay consistent.
• Date order differs sharply by region: en_US uses month-day-year, en_GB uses day-month-year.
• Decimal point with comma as thousands separator (1,234.56).

English is your source, and that is the problem

English is almost always the language your strings are written in, which means every structural decision you make in English propagates into every other locale. Most translation defects are not translation errors at all — they are English source strings that cannot be translated correctly, no matter who does the work.

English is unusually permissive. It has almost no inflection, no grammatical gender, no case system, two plural forms and a fixed word order. A sentence assembled from fragments usually reads acceptably, which is precisely why the habit forms and why it survives until the first inflected locale exposes it.

The pattern that breaks everything downstream

// Reads fine in English:
__('actions.delete') . ' ' . __("types.{$type}")
// 'Delete file', 'Delete user', 'Delete project'

// German needs a different article per noun,
// Polish a different case, Hungarian a different
// suffix, Korean a different particle.
//
// None of them can be produced from these parts.

Write one key per complete message. If English needs six near-identical strings where a template would have needed one, write the six. The duplication looks wasteful and is far cheaper than the alternative, because a template that cannot be translated has to be restructured eventually — and by then the code, the keys and every existing translation change together.

Treat the English file as an interface contract rather than as copy. Every decision in it — whether a placeholder holds a noun, whether a sentence addresses the user directly, whether a count is present — determines what is possible in thirty other languages.

Word order is not universal, so placeholders must move

English fixes subject, verb and object in that order, and the rest of the sentence around them. Many languages do not, and a translator needs the freedom to put your placeholders where the target language wants them.

Named placeholders permit that; positional ones do not. Laravel's :name syntax is named by design, which is one of the framework's quieter good decisions — but the benefit is lost the moment a string is split into fragments whose order the code controls.

Named placeholders can be reordered; fragments cannot

// Good — the translator moves :count and :folder freely
'moved' => 'Moved :count files to :folder',

// Thai puts the classifier after the number,
// Japanese puts the verb last, Turkish puts the
// location marker as a suffix. All are possible
// here and none are possible with concatenation.

The same applies to markup. A sentence containing a link should be one string with the anchor inside it, not three strings glued around an <a> tag, because the linked words fall in a different place in most languages. Blade makes it tempting to split; resist it.

The plural system English teaches you is the wrong one

English has two plural forms and a rule most developers can state from memory: one is singular, everything else is plural. This produces a habit — $count === 1 ? $singular : $plural — that is wrong in the majority of the world's languages.

Always route counting through trans_choice() rather than through a conditional in application code. The framework consults CLDR data for the active locale and selects the right form; a hand-written check hardcodes the English rule into every language you will ever add.

Give translators the count as a placeholder even when English does not obviously need it, and never split a counting sentence around the number. You have plus the count plus new messages is three fragments in an order most languages will not accept.

Test with the awkward values rather than with one and five. Zero, two, eleven, twenty-one and a fraction between them exercise every branch of every plural rule in common use, and they are exactly the values an English-speaking developer has no reason to think about.

Which English, and what that changes

English has its own regional varieties, and while they rarely block comprehension, mixing them within one product reads as carelessness. Pick one, record it in the style guide, and enforce it in review.

The date format is the consequential one. 03/04/2026 is the third of April in the UK and the fourth of March in the US, and there is nothing in the string to indicate which. Any interface showing dates to a mixed audience should use an unambiguous format — the month spelled out, or ISO order — rather than relying on the locale being right.

English is also frequently the fallback locale, which makes fallbacks visible. A missing key in another language renders an English sentence in the middle of translated copy, which reads as a fault rather than as graceful degradation. Prefer a key-parity check that fails the build over a fallback nobody notices until a customer does.

Writing strings that survive translation

A handful of habits in the source language remove most downstream problems, and each costs nothing at the time it is applied.

1. 1 Never concatenate. One key per complete message, including its punctuation. A trailing colon or question mark belongs inside the string, since not every language puts it in the same place — French needs a space before it and Greek uses a different character entirely.
2. 2 Give every key context. A key named close could be a verb or an adjective, and translators will guess. A note describing where the string appears is the single highest-value thing you can give them.
3. 3 Avoid addressing the user in the past tense. "Changes saved" translates everywhere; "You saved your changes" forces a gendered verb in Hebrew, Hindi, Polish and Russian.
4. 4 Keep units and numbers in placeholders. Hardcoded formats leak English conventions into every locale, and separators, grouping and currency placement all differ.
5. 5 Do not rely on capitalisation. German capitalises all nouns, Hebrew and Thai have no case at all, and Turkish case conversion is genuinely dangerous. Use weight or size for emphasis instead.
6. 6 Leave room. German, Greek and Finnish run thirty to forty per cent longer, and compounds arrive as single unbreakable tokens.

Pseudo-localisation is worth wiring in early. Rendering English with accented substitutes and a thirty per cent padding exposes truncation and hardcoded strings before any real translation exists, and it costs one build step.

Finally, get the framework strings for free. The open-source Laravel-Lang project maintains professionally translated validation, authentication and pagination messages for dozens of locales. Translating those yourself produces worse copy and more maintenance, and it is the first thing to hand over when adding a language.

Structuring the English file itself

How the source file is organised matters almost as much as how the strings are written, because it determines how translation work is divided, reviewed and kept in sync as the product changes.

Split by domain rather than by screen. Laravel namespaces short keys per file, so messages.title and invoices.title never collide, and each file is an independent unit for merge conflicts. Ten translators editing ten files produce far fewer conflicts than ten editing one, and a file organised by feature survives a redesign that moves components between screens.

Name keys for meaning, not for appearance. A key called red_warning becomes a lie the day the colour changes, and button_top_right becomes meaningless after a layout revision. Keys describing what a string says rather than where it sits stay accurate and give translators a hint of the context they otherwise lack.

Keep the file free of anything that is not copy. Analytics event names, feature flags, route fragments and CSS class names occasionally end up in translation files, where they are duly sent to a translator and duly translated, breaking whatever depended on their exact value.

Enforce key parity in CI. Every locale should expose the same key set as the source, and a build that fails on a gap catches the entire class of silently missing translations — which matters most in markets where users read English comfortably and therefore never report the fallback.

Finally, decide early whether you are using short keys or translation strings as keys. Laravel supports both, they behave differently, and migrating between them means rewriting every __() call in the codebase. Short keys in per-domain files are the right default for anything that will grow.

What ships broken most often

• Sentences assembled from fragments. The single largest source of untranslatable strings.
• Hand-written plural checks. The English two-form rule hardcoded into every locale.
• Markup splitting a sentence. Links and bold text glued between three separate keys.
• Keys with no context. One-word keys that are verbs or nouns depending on the screen.
• Ambiguous numeric dates. 03/04/2026 meaning two different days.
• Mixed US and UK spelling. Colour and color on adjacent screens.
• Second person past tense. Forcing a gender decision in four language families at once.

The unifying point is that internationalisation is mostly work done in English. By the time a string reaches a translator, its fate is largely decided — and the difference between a product that adds a language in a week and one that takes a quarter is almost entirely the quality of the source file.

That also makes English the cheapest place to fix things. A concatenated sentence corrected in the source costs one edit; the same sentence corrected after thirty locales have translated it costs thirty retranslations plus the code change. Reviewing new English strings for translatability, as a routine part of code review, is the highest-leverage habit a team shipping internationally can adopt.

Framework strings already translated

Laravel's own validation, auth and pagination strings are maintained in English by the open-source Laravel-Lang project (MIT). Install them, then manage your app's own strings live:

composer require laravel-lang/common --dev
php artisan lang:add en
php artisan lang:update