Lang English Laravel Package

Product Decisions This Supports

• Baseline localization for any Flarum-based community product. This is the canonical source of every default UI string — buttons, validation errors, transactional emails, moderation tooling, admin panel. It is the fallback layer every other locale keys off, so it directly underwrites the question "can a non-English-speaking user complete onboarding?"
• Terminology and brand voice. The English pack is the override surface. If your product calls threads "Discussions" versus "Topics," or your moderation actions need domain language ("Flag" vs. "Report"), the decisions and diffs live against these keys.
• Language expansion sequencing. Knowing which strings exist and how they're namespaced tells you the marginal cost of locale N+1 and what users see for untranslated keys.
• Build vs. buy for translation tooling. The pack is free, MIT, and versioned with core — that is the "buy" baseline. Any TMS or Crowdin integration is additive, not a replacement.
• Upgrade and release planning. Version pinning here tracks Flarum core releases; i18n regression scope follows that cadence.
• Community vs. in-house translation sourcing. A maintained upstream English pack plus a community locale ecosystem is the argument for leaning on upstream rather than staffing translators for base strings.

When to Consider This Package

Adopt when:

• You run Flarum (self-hosted or managed) and need the English baseline — practically always, and usually transitively via flarum/core.
• You need a pinned, reproducible dependency for CI/builds instead of a VCS path into the Flarum monorepo.
• You want a stable key namespace to diff against when auditing coverage of your own overrides.

Look elsewhere when:

• You are on Laravel generally, not Flarum. This is not a generic lang/en replacement; it uses Flarum's translator and key conventions. Use laravel-lang/* or your own lang/ directory.
• You want to contribute corrections — this repo is a read-only subtree split; PRs and issues belong upstream in the Flarum monorepo.
• You need a non-English locale — this is the English pack only; use the corresponding flarum-lang/* package.
• You need translation memory, glossaries, or human review workflows — that is a TMS, not this.

Signals to discount: 30 stars and a ~21.9 composite score are artifacts of a split mirror, not evidence of adoption or quality. Evaluate the parent project's health and release cadence instead. Verify the 2026-10-09 release date against the upstream changelog before betting an upgrade window on it.

How to Pitch It (Stakeholders)

Executives: This is the default English text layer for our forum — free, MIT-licensed, and versioned in lockstep with the platform. There is no procurement, licensing, or vendor decision here; it is table stakes infrastructure. The strategic point is that base localization is a solved, zero-cost problem, so budget and headcount should go to product-specific terminology and to the locales our users actually need — not to translating generic buttons.

Engineering: Treat it as an immutable dependency. Pin it, do not fork it, do not open PRs against it — it is a read-only subtree split and changes land in the Flarum monorepo. Customize through overrides and extensions rather than patching keys, so upgrades stay cheap. Every string we change is a diff against this pack; keep those diffs small and documented so locale fallback behavior stays predictable. Budget the real work as: (1) a coverage audit of keys we override, (2) an i18n regression pass whenever core bumps, (3) TMS evaluation only once we exceed a handful of locales.

Bottom line: low risk, low cost, low optionality — adopt by default and spend PM attention on the decisions it enables (brand terminology, locale roadmap), not on the package itself.