Breezejp Laravel Package

Product Decisions This Supports

• Localization as a launch requirement, not a later feature. askdkc/breezejp supplies Japanese translations for Laravel Breeze's authentication scaffolding (login, registration, password reset, email verification, profile screens and their validation/system messages). If a Japanese-language product is on the roadmap, this converts "we need to translate auth flows" from a multi-day task into a composer install plus one artisan command — it directly informs when a JP-market MVP can ship.
• Build vs. buy. Auth screens are high-visibility, low-differentiation surface area. Hand-translating Breeze's lang files and Blade views is recurring toil that reappears with every Breeze/Laravel upgrade. This package is a strong argument for "buy" (adopt) over "build" for anything that is not a bespoke auth UX.
• Feature scoping for i18n. Because it covers only Breeze's auth surface, it clarifies the boundary of what comes "free" with a JP launch versus what still needs product work: marketing copy, transactional email templates, domain-specific validation wording, legal/consent text. Use it to size the remaining localization backlog rather than treating all i18n as one opaque epic.
• Stack choice constraint. Adoption nudges the team toward Breeze (Blade/Livewire/Inertia+Vue/React) for auth. If the roadmap already contains Jetstream, Fortify-only, Filament, or a headless/API auth flow, this package does not cover it and the decision shifts.
• Release cadence as a maintenance signal. v2.6.3 is a one-line patch adding a translated array_keys error message (PR #193). It is not a feature or a breaking change, but it is evidence that the maintainer is tracking upstream Laravel validation-message changes and keeping Japanese strings in sync — the exact drift risk that makes hand-rolled translations decay. That supports a "low-risk, keep it as a dev dependency" call in dependency review.
• Not a differentiator, low switching cost. Because it is a dev-only dependency that publishes lang/view assets, adoption is reversible. Treat it as a default-yes for JP-facing Breeze apps and avoid spending roadmap time debating it.

When to Consider This Package

Consider it when most of the following hold:

• The product ships Laravel with Breeze as the auth scaffold, on a Japanese-first or Japanese-only UI.
• You want validation and system messages (not just labels) in natural Japanese — v2.6.3's array_keys addition is precisely this class of string, and keeping those current manually is the main ongoing cost you are avoiding.
• You are pre-launch or early-stage and optimizing for time-to-first-Japanese-user rather than bespoke auth design.
• The team has no in-house Japanese copywriter permanently on the auth surface, or wants a sane default that a translator can later refine.
• You can accept a dev dependency (require-dev) with published, overridable assets, so production runtime is unaffected and you can fork/override any string you disagree with.
• You are comfortable with single-maintainer OSS for a non-critical, easily replaceable layer.

Look elsewhere or plan a fallback when:

• Auth runs on Jetstream, Fortify-only, Filament, or a custom/API-token flow — coverage does not apply.
• You need multi-locale support (e.g. en + ja + more) with per-user locale switching; a single-locale translation set is the wrong shape, and you want Laravel's own lang/{locale} structure plus a translation-management workflow.
• The copy is brand-sensitive or legally reviewed (consent, privacy notices, terms) — those strings must be owned in-repo regardless.
• You have a hard dependency-governance policy requiring active multi-maintainer projects, security policy, or an SLA. There is no evidence of a security response process; mitigate by pinning versions and reviewing diffs, since the surface is only lang/asset files.
• Laravel or Breeze versions move faster than the package's compatibility matrix — verify against your pinned versions before committing, and keep the ability to publish-and-own the translation files.

How to Pitch It (Stakeholders)

For executives: This is a small, free, dev-only add-on that gives our Laravel authentication screens — sign-in, sign-up, password reset, email verification, and their error messages — professional Japanese out of the box. It removes roughly the equivalent of a few days of engineering plus translator coordination from a Japan-market launch, and it reduces the risk of awkward or incorrect Japanese in the highest-trust part of the product. Cost is negligible; risk is bounded because nothing ships to production servers and we can override any wording ourselves. The latest release (v2.6.3) is a minor patch — one added error message — which tells us the maintainer is actively keeping translations aligned with Laravel's changing validation messages. That upkeep, not the initial install, is the real value we are buying.

For engineering: Add askdkc/breezejp as a require-dev dependency and run its installer to publish Japanese lang files and Breeze view overrides. It is asset-copy, not runtime magic — version-pin it, treat published files as ours, and diff on upgrade. v2.6.3 adds a Japanese array_keys validation message (PR #193), confirming string-level parity with upstream Laravel; no breaking changes, no migration work, no API surface change. Two caveats to decide on before adoption: it assumes Breeze (not Jetstream/Fortify-only/API auth), and it is effectively single-maintainer, so we should own a fallback path — the published lang files remain functional on their own if we ever drop the dependency.

Recommendation: Approve as a dev-only dependency for Japanese-facing Breeze projects; no action required for v2.6.3 beyond routine version bump. Revisit if we add additional locales or move off Breeze for authentication.