What locale code should I use for Hebrew in Laravel?

Use 'he' as the base locale in config/app.php. For regional variants use he_IL. Carbon accepts 'he' for localized dates.

How many plural forms does Hebrew need in trans_choice()?

Laravel's translator expects 2 pipe-separated forms for Hebrew. CLDR defines the categories one, two, other for cardinal numbers.

Is Hebrew a right-to-left language?

Yes. Hebrew is written right-to-left in the Hebrew script; set dir="rtl" on your HTML element and mirror your layout.

Laravel localization in Hebrew עברית

Everything you need to ship Hebrew in a Laravel app: the right locale codes, the exact plural forms trans_choice() expects, real localized Carbon output and Hebrew-script considerations. Every value on this page was generated by running ICU, CLDR and Carbon — not copied from another article.

ISO 639-1

he

Script / Direction

Hebrew · RTL

Plural forms (Laravel)

2

Text vs English

Contracts

Locale codes

Set the base locale in config/app.php. For regional variants, Hebrew commonly uses: he_IL

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

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

Plural rules: what Hebrew actually needs

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

CLDR category	Numbers that select it
one	1
two	2
other	0, 3–130, 200, 1000, 1000000, 1.5

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

Form index	Numbers that select it
0	1
1	0, 2–130, 200, 1000

// lang/he/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 Hebrew (he locale), generated by Carbon for March 21, 2026:

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

$date->translatedFormat('l, j F Y');
// "שבת, 21 מרץ 2026"

$date->isoFormat('LLLL');
// "שבת, 21 במרץ 2026 14:30"

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

$date->subDays(3)->diffForHumans();
// "לפני 3 חודשים"

What to watch out for in Hebrew

Right-to-left script: mirror layouts and set dir="rtl"; numbers and Latin fragments remain left-to-right (bidi).
Gender pervades the grammar, including second-person verbs, so "you"-form strings may need masculine/feminine variants.
Everyday text is written without vowel points (niqqud).
CLDR defines one/two/many/other plural categories for Hebrew.
Right-to-left script: set dir="rtl" on the <html> element and use CSS logical properties (or Tailwind's rtl: variant) instead of left/right.

Your interface has a gender, and so does your user

Hebrew has no neuter. Every noun is masculine or feminine, and — the part that catches teams off guard — verbs and adjectives conjugate for the gender of the person being addressed. There is no gender-neutral way to say "you saved" or "you are logged in". The sentence itself commits.

English	To a man	To a woman
You saved	שמרת (shamarta)	שמרת (shamart)
Welcome	ברוך הבא	ברוכה הבאה
Are you sure?	אתה בטוח?	את בטוחה?
Enter your name	הזן את שמך	הזיני את שמך

This is a product decision before it is a translation decision, and it has three realistic answers. You can collect the user's gender and store two variants of every second-person string. You can default to masculine, which is the traditional generic and is what most Israeli software does, though it reads as dated to a growing number of users. Or you can rewrite the copy to avoid addressing the user directly at all.

The third option is the one worth designing for, and Hebrew interfaces use it heavily. Infinitives and nouns carry no gender: שמירה (saving) works as a button label where שמור/שמרי would force a choice. Restructuring interface copy around noun phrases removes the problem for the great majority of strings.

Where direct address is unavoidable, some products use combined forms such as שמור/י with a slash. It is compact and widely understood, but it reads as bureaucratic and screen readers handle it badly. Treat it as a fallback, not a strategy.

If you do store gendered variants, model it as a translation dimension rather than as two unrelated keys. Two parallel key trees drift apart within a release or two, and the divergence is invisible to anyone who does not read Hebrew.

Right-to-left, and the ways it differs from Arabic

Hebrew reads right to left, so everything said about mirroring an Arabic interface applies: set dir="rtl" on the root element, replace physical CSS properties with logical ones, and flip directional icons while leaving object icons alone.

Direction and logical properties

<html lang="he" dir="rtl">

<!-- Physical properties keep pointing the same way
     when the document flips; logical ones follow
     the reading direction. -->
<div class="ms-4 pe-2 text-start border-s">

Two things make Hebrew easier than Arabic. Letters do not change shape according to position, so there is no contextual shaping to get wrong and fonts are far less likely to render Hebrew as disconnected fragments. And Hebrew always uses Western digits, so there is no Arabic-Indic numeral decision to make.

One thing makes it harder in a specific way: five Hebrew letters take a different form at the end of a word — כ becomes ך, מ becomes ם, נ becomes ן, פ becomes ף, צ becomes ץ. These are distinct Unicode characters, not styling. Truncating a Hebrew string mid-word therefore leaves a non-final letter where a final one belongs, which reads as a spelling error rather than as an obvious cut.

Truncate on word boundaries, or better, let CSS handle overflow with an ellipsis so the browser never alters the characters themselves. The same rule rules out reversing or slicing Hebrew strings in application code.

Bidirectional text needs the same care as in Arabic. Numbers, Latin brand names and email addresses inside Hebrew copy run left to right, and neutral characters at the boundary — brackets, full stops, slashes — can resolve to the wrong side. Wrap user-supplied values in <bdi> so the browser isolates their direction.

Four plural forms, including one for two

Hebrew retains a dual number from its older grammar, and CLDR gives it four plural categories. The two category is genuinely separate, as in Arabic, and the many category applies to round multiples of ten from twenty upward.

Category	Selected by	Example
one	1	קובץ אחד
two	2	שני קבצים
many	20, 30, 40… (tens, from 20)	20 קבצים
other	0, 3–19, 21–29…	5 קבצים

Four forms in CLDR order

// lang/he/messages.php
// one|two|many|other
'files' => 'קובץ אחד|שני קבצים|:count קבצים|:count קבצים',

trans_choice('messages.files', $count, ['count' => $count]);

The dual is where a two-form translation breaks most visibly, because the number two appears constantly in real interfaces. Note also that the noun being counted has its own gender, and the numeral agrees with it — שני for masculine nouns, שתי for feminine — so the counting word changes with the thing counted, not only with the count.

Verify the boundaries with the pluralization tester. The values worth checking are 1, 2, 3, 20 and 21, none of which behave the way an English two-form system would predict.

No capitals, optional vowels, and what that means for code

Hebrew has no uppercase and lowercase. This is convenient — none of the case-transformation bugs that plague German, Dutch and Turkish exist here — but it means any design relying on capitalisation for emphasis or hierarchy simply does not translate. Use weight, size or colour instead, and make sure text-transform rules are scoped so they do not apply to Hebrew.

Hebrew is normally written without vowels. The vowel points (niqqud) exist but appear only in children's books, poetry, religious texts and dictionaries. Ordinary interface copy omits them entirely, which means the same written form can represent several different words distinguished only by context.

That ambiguity is a practical reason machine translation of short interface strings performs poorly in Hebrew, and a reason to give translators the surrounding screen context rather than a bare key. It also means search needs to tolerate the presence or absence of niqqud: a user typing an unvowelled word should match a vowelled record, which requires normalising the marks away for comparison while preserving them in storage.

Hebrew text is typically shorter than English — often twenty to thirty per cent fewer characters — because the script omits vowels and the language is economical with function words. Layouts sized for English rarely overflow. Vertical space is a different matter: Hebrew letterforms sit within a more uniform height band than Latin ones, and generous line height helps readability considerably.

Acronyms are marked with a gershayim (״) before the final letter, and abbreviations with a geresh (׳). These are dedicated Unicode punctuation characters that look like quotation marks but are not, and a normalisation routine that converts "smart quotes" will silently corrupt them.

Calendars, weeks and formatting

The Hebrew calendar is lunisolar and runs alongside the Gregorian one in Israeli life. It determines holidays, which fall on different Gregorian dates each year, and appears on official documents. Its days begin at sunset rather than midnight, so a Hebrew date does not map cleanly onto a Gregorian one.

The working week is the more immediate concern for software. In Israel the week runs Sunday to Thursday, with Friday a short day and Saturday the day of rest. A calendar component defaulting to a Monday start, or business-day logic assuming a Saturday-and-Sunday weekend, will be wrong for scheduling, deadlines and delivery estimates.

	Hebrew convention
First day of week	Sunday
Weekend	Friday evening – Saturday
Digits	Western (0–9)
Thousands	1,234,567
Decimal	1234.56
Currency	₪1,234.56 (shekel sign before)
Short date	21.3.2026

Numbers and currency follow English conventions, which removes the decimal-comma hazard that affects most of continental Europe. Dates are day-first with dots. Month names have no capitalisation to get wrong, since the script has no case.

Set the full locale so the week start and calendar support resolve correctly. A bare language code will usually still produce Hebrew text, and will just as usually produce a Monday-first calendar that no Israeli user recognises.

Testing Hebrew without reading Hebrew

Almost every Hebrew failure mode is invisible to a reviewer who does not read the script. A mirrored layout looks deliberate, a masculine-only greeting looks like text, a truncated final letter looks like a font quirk, and a wrong plural form looks like a number followed by a word. Coverage metrics will report the locale as fully translated in all of these cases.

That makes automated checks unusually valuable here. Three are worth building. The first asserts that no stylesheet reaching production contains physical direction properties — margin-left, padding-right, text-align: left — since every one of them is a mirroring bug waiting for an RTL locale. The second renders each Hebrew string into its real container and flags overflow, which catches the layout consequences of switching direction. The third compares plural segment counts against the four the locale requires.

Pseudo-localisation is worth using during development, but only the right kind. Reversing Latin characters exercises none of the behaviour that actually breaks: it produces no bidirectional boundaries, no final letter forms and no genuine RTL layout. Use real Hebrew strings, or an RTL pseudo-locale built from actual Hebrew characters, so the browser applies the bidirectional algorithm you are trying to test.

Budget for review by a Hebrew reader before launch rather than after. The gender strategy in particular is a judgement call about tone and audience that no test can make, and getting it wrong is the difference between software that feels written for Israeli users and software that feels translated at them.

Set the full locale so the Sunday week start and calendar support resolve. And keep in mind that Israel observes daylight saving on its own schedule, which diverges from both European and American transition dates — scheduling and reminder features that assume a shared changeover will drift for several weeks each year.

What ships broken most often

Layout not mirrored. dir="rtl" set while the CSS still uses margin-left and text-align: left.
Everything addressed to a man. Masculine defaults throughout, with no plan for the alternative.
Two plural forms instead of four. Wrong for 2 and for every multiple of ten from twenty.
Final letter forms broken by truncation. Character-level slicing leaving מ where ם belongs.
Gershayim replaced by quotation marks. A smart-quote normaliser corrupting acronyms.
Monday-first calendars. And business-day logic assuming a Saturday-Sunday weekend.
Bidirectional punctuation scrambled. Latin names or numbers inside Hebrew reordering the surrounding marks.

Sequence the work deliberately: convert the CSS to logical properties and settle the gender strategy before commissioning translation. Both decisions change what the translator needs to produce, and discovering either one late means revisiting every string rather than adding to them.

Install the Laravel-Lang Hebrew files for framework strings. Validation messages involve gender agreement and four-form plurals across dozens of rules, and the community translations already handle both.

Framework strings already translated

Laravel's own validation, auth and pagination strings are maintained in Hebrew 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 he
php artisan lang:update