Laravel localization in Japanese 日本語

Locale codes

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

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

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

Plural rules: what Japanese actually needs

CLDR defines 1 cardinal category for Japanese. The sample numbers below were computed by ICU for this exact locale:

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

// lang/ja/messages.php
'items' => ':count'

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

This language has no grammatical plural, so a single form covers every number.

Try any number live in the pluralization tester.

Localized dates with Carbon

Real output for Japanese (ja locale), generated by Carbon for March 21, 2026:

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

$date->translatedFormat('l, j F Y');
// "土曜日, 21 3月 2026"

$date->isoFormat('LLLL');
// "2026年3月21日 土曜日 14:30"

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

$date->subDays(3)->diffForHumans();
// "3ヶ月前"

What to watch out for in Japanese

• No spaces between words; line breaking follows character-based rules, not word boundaries.
• Honorific registers (keigo) matter: polite -masu/desu forms are the norm for UI copy.
• No grammatical plural or gender; particles (は, が, を) mark grammatical roles, so word order around placeholders differs from English.
• Dates are written year-first (2026年3月1日) and full-width punctuation (。、) is standard.

Three scripts, no spaces, and what that does to your layout

Japanese writes with three scripts simultaneously: kanji for most content words, hiragana for grammar, and katakana for loanwords and emphasis. Latin characters and Arabic numerals appear freely alongside them. A single ordinary sentence uses all of these, and none of it is separated by spaces.

The absence of spaces is the detail with the most practical consequences. Word-boundary logic built for European languages — str_word_count(), wordwrap(), ucfirst(), anything splitting on whitespace — does nothing useful. Line breaking is instead governed by kinsoku shori, a set of rules about which characters may not begin or end a line.

Let the browser break Japanese properly

<p lang="ja" class="[line-break:strict] [overflow-wrap:anywhere]">
    ユーザーアカウント設定を保存しました。
</p>

/* Browsers apply kinsoku rules when the language
   is declared. Without lang="ja" they may break
   before a closing bracket or a small kana. */

Japanese is typically shorter than English in character count — often thirty to fifty per cent fewer characters — but each character occupies a full-width cell, so the rendered width is closer than the count suggests. Text will rarely overflow a container sized for English, which makes Japanese one of the more forgiving locales for layout.

Vertical space is a different matter. Japanese glyphs are dense and need more line height than Latin text at the same font size to remain readable. A line height tuned for English will look cramped, and small sizes that work in Latin become genuinely hard to read in kanji.

Politeness levels are the register decision

Japanese encodes politeness grammatically through verb forms, and the choice is more consequential than the tu/vous distinction in European languages because it changes the ending of nearly every sentence. Software has a strong convention here, which makes the decision easier than it first appears.

The desu/masu polite form is the default for essentially all consumer and business software. It reads as neutral and professional rather than stiff. Plain form appears in headings, buttons and documentation where brevity matters; humble and honorific forms are reserved for error messages that apologise and for formal correspondence.

Button labels are conventionally nouns or noun phrases rather than verbs — 保存 (save) rather than a conjugated verb — which sidesteps the politeness question for most short interface strings. This is a genuine difference from English interface writing and something translators handle naturally but machine translation often does not.

Japanese also avoids second-person pronouns. あなた (you) is technically correct and sounds oddly confrontational in an interface; natural Japanese omits the subject entirely or uses the user's name. A literal translation of 'You have 3 new messages' that includes あなた marks the copy as translated.

One plural form, and counters instead

Japanese has no grammatical plural. CLDR defines a single category, so trans_choice() takes one form and the same string serves every number. This makes plural handling trivially simple and hides a different complication.

A single form covers every count

// lang/ja/messages.php
'items' => ':count件のアイテム',

// 0 → 0件のアイテム
// 1 → 1件のアイテム
// 5 → 5件のアイテム

The complication is counters. Japanese requires a classifier between the number and the noun, and which classifier applies depends on what is being counted — flat objects, long objects, people, machines, and so on each take a different one.

This means a generic :count items string cannot be reused across contexts the way it can in English. Messages, files, users and images each need their own key with the correct counter, and a translator supplied with a single shared string has no way to get it right for all of them.

Some counters also change pronunciation with certain numbers, which does not affect the written form but does affect any text-to-speech or voice interface built on the same strings.

Input, search and the fullwidth problem

Japanese text entry goes through an input method editor, which converts phonetic input into kanji as the user types. This produces a class of bugs unique to CJK languages: JavaScript that reacts to every keystroke will fire on the intermediate, uncommitted text.

Respect IME composition

let composing = false

input.addEventListener('compositionstart', () => composing = true)
input.addEventListener('compositionend', () => {
  composing = false
  search(input.value)
})

input.addEventListener('input', () => {
  if (!composing) search(input.value)
})

Without this, a live-search field fires a query for every phonetic fragment before the user has chosen a kanji, producing both noise and irrelevant results. It is one of the most common complaints about Western software in Japan.

Fullwidth and halfwidth characters are the other input trap. Japanese keyboards can produce fullwidth Latin letters and digits (ＡＢＣ１２３) that look different but mean the same as their ASCII equivalents. A user may type a fullwidth email address or postcode in complete good faith, and naive validation will reject it.

Normalising before validation

<?php

// NFKC folds fullwidth forms to their ASCII equivalents
$normalised = Normalizer::normalize($input, Normalizer::FORM_KC);

// 'ＡＢＣ１２３' becomes 'ABC123'

Normalise on input rather than rejecting it. The same applies to halfwidth katakana, a legacy encoding still produced by some systems, which NFKC folds to standard fullwidth katakana.

Names, dates and formatting conventions

Japanese names are written family name first, with no comma. A form labelled 'First name' and 'Last name' in that visual order is confusing, and code that assembles a display name as given-then-family produces a name that reads as foreign. Store the parts separately and let the locale decide the display order.

Many Japanese forms also collect a phonetic reading alongside the name — furigana, in either hiragana or katakana — because kanji names have multiple possible pronunciations. This is standard in Japanese services and its absence is noticeable in anything handling formal records.

Dates are written largest unit first, which happens to align with ISO order and makes Japanese one of the least ambiguous locales for dates.

The imperial era calendar remains in official and government use, and eras change on the accession of a new emperor — an event that is not scheduled in advance. Any system hardcoding era boundaries will eventually be wrong; use the platform's calendar support rather than a lookup table.

Yen amounts conventionally have no decimal places, since the smallest circulating unit is the yen itself. Formatting currency with two decimals is a small but immediately visible sign that the amount was formatted by code written for dollars.

Encoding, sorting and text handled by code

Japanese exercises parts of your stack that Latin text never reaches, and the failures tend to appear well below the presentation layer where they are harder to attribute.

Storage is the first checkpoint. MySQL's utf8 is a three-byte encoding that cannot represent characters outside the Basic Multilingual Plane, which includes emoji and a number of rare kanji used in personal names. Inserting one either throws or silently truncates the rest of the field, and the affected users are precisely those whose names are unusual. Use utf8mb4 throughout, for the column, the connection and the table default.

Sorting is the second. Japanese has no single obvious alphabetical order: kanji can be ordered by stroke count, by radical, or by reading, and only the reading produces an order users recognise. Because the reading is not derivable from the characters themselves, sorting a list of Japanese names correctly requires the furigana field, which is a strong practical reason to collect it rather than treating it as optional.

Search needs normalisation on both sides. A user may type in hiragana, katakana, kanji, fullwidth Latin or halfwidth katakana and expect to find the same record. NFKC normalisation folds the width variants; matching kana against kanji requires a reading index, which is again the furigana. Applying Normalizer::FORM_KC to both the stored search column and the query handles most real cases cheaply.

Finally, be careful with any code that measures or trims Japanese. Character counts do not correspond to visual width, since Latin characters and halfwidth katakana occupy half a cell while kanji and kana occupy a full one. Truncating a mixed string at a fixed character count produces inconsistent visual lengths, and truncating by bytes will split a multi-byte character outright. Use mb_ functions throughout, and prefer CSS ellipsis to server-side trimming wherever the layout allows it.

What ships broken most often

• Live search firing during IME composition. Queries sent for uncommitted phonetic input.
• Fullwidth input rejected. Valid email addresses and postcodes failing validation because they were typed in fullwidth.
• A shared counter across contexts. 件 used for images, or 個 used for people.
• あなた in interface copy. A literal translation of 'you' that natural Japanese would omit.
• Name order reversed. Display names assembled given-first, or forms whose field order confuses users.
• Cramped line height. Latin typography metrics applied to dense kanji.
• Yen shown with decimals. ￥1,234.00 rather than ￥1,234.
• Bad line breaks. Missing lang="ja", so the browser applies no kinsoku rules.

Japanese is forgiving in layout and unforgiving in convention. The text will fit; what marks a product as poorly localised is the counter used with the wrong noun, the search box that fights the input method, and the form that asks for a surname in the wrong position. None of these are visible to a reviewer who does not read Japanese, so plan for review by a native speaker rather than trusting a translation-coverage figure.

Framework strings already translated

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