Lang English Laravel Package

Technical Evaluation

Architecture fit — This is not a Laravel package in any conventional sense: there is no service provider, no config file to publish, no facades, no Eloquent/queue/HTTP surface. flarum/lang-english is a Flarum locale pack — a content-only Composer package whose payload is translation resource files consumed by the Flarum forum application. It is relevant only if the product operates a Flarum instance (typically as a sidecar/embedded community alongside the Laravel application). For a Laravel-only codebase, the only realistic use is borrowing YAML/JSON strings as a translation corpus, which is a copy-paste exercise, not an integration.

Integration feasibility — If Flarum is present, integration is trivial: composer require flarum/lang-english, clear the cache, done — Flarum auto-discovers locales via Composer extra metadata. No application code changes, no DI wiring, no migration. If Flarum is absent, feasibility drops to "not applicable." The asymmetry matters for scoping: this is a 30-minute task or a zero task, never a sprint.

Technical risk — Moderate-to-low technical risk, moderate provenance risk:

• README-only split. The description explicitly marks this as a read-only subtree split of the canonical Flarum language pack. PRs, issues, and security disclosures do not land here; they land in the upstream monorepo. Any contribution workflow pointed at this repo is broken by design.
• Provenance gap. Repository: unknown plus a release date of 2026-10-09 (future-dated relative to any normal consumption window) is a data-quality anomaly. Before adoption, verify the Packagist vendor/dist URL resolves to the official Flarum organization and confirm the tag against the upstream monorepo.
• Version-lock coupling. The package version must track the Flarum core minor. Skew produces missing keys rendered as raw identifiers in the UI — cosmetic but user-visible and hard to spot in smoke tests.
• Popularity signal is misleading. 30 stars is expected for a subtree split and tells you nothing; the real health metric is flarum/framework activity. Do not score this package's viability on its own star count.

Key questions — (1) Do we actually run Flarum, and which core version? (2) Is English already a transitive dependency of flarum/core — in which case this is an incidental, core-pinned dependency and we should not manage it directly? (3) Is the source of truth the monorepo, and do we have a policy for consuming split repos? (4) Do we need to customize any strings — because that requires a fork or a separate override pack, not edits here.

Integration Approach

Stack fit — Requires PHP (7.3+ for Flarum 1.x, 8.1+ for Flarum 2.x) and Composer 2, matching the Flarum host. It has no relationship to the Laravel application's PHP constraint unless both run in the same container. Treat it as a Flarum-side dependency and keep it out of the Laravel composer.json entirely to avoid polluting the app's dependency graph with a package the app never autoloads.

Migration path — Two directions:

• Into Flarum: add the requirement pinned to the same minor as core, run php flarum cache:clear, verify locale appears in admin → Languages.
• Out of Flarum (if decommissioning the forum): extract the YAML keys into Laravel lang/en/*.php or JSON via a small mapping script. Key namespaces are Flarum-specific (core.forum.*, core.admin.*) and do not map cleanly to Laravel's validation.*/auth.* conventions, so budget a manual reconciliation pass rather than assuming a mechanical conversion.

Compatibility — Pin explicitly ("flarum/lang-english": "1.x.*" aligned with core) rather than floating. Because the split lags the monorepo, a tag may exist without reflecting the latest upstream strings; if a specific string fix is required, source it from the monorepo tag instead.

Sequencing — (1) Confirm Flarum presence and core version; (2) check whether English is already pulled in transitively and skip if so; (3) verify Packagist provenance against the official org; (4) pin and install; (5) cache-clear and validate locale rendering in forum + admin; (6) register the upstream monorepo — not this repo — as the release/security watch target in the dependency tracker.

Operational Impact

Maintenance — Effectively zero runtime maintenance: content-only, no executable code, no transitive dependency surface of consequence. The real cost is process: someone must know that this repo is a mirror, so bug reports and translation corrections route upstream. Budget a one-line note in the dependency register; that is the whole maintenance story.

Support — MIT license means fork-and-own is always available if upstream stalls. Community support comes via the Flarum forum and monorepo issues; this repo offers neither. Escalation for a bad string or missing key is "wait for the next core release or pin an older tag," not "file a bug here."

Scaling — Negligible. Translation resources are loaded and cached at bootstrap; footprint is a set of YAML files and adds nothing to request-path latency, DB load, or memory pressure at any realistic forum volume. No horizontal-scaling considerations.

Failure modes — Ranked by likelihood:

1. Version skew — missing keys render as raw identifiers in the UI (e.g., core.forum.post.edited_text). Low blast radius, high visibility; caught by a locale smoke test on core upgrades.
2. Composer resolution conflict — over-tight pinning blocks a core upgrade; prefer range constraints within a major.
3. Silent staleness — an automated dependency bot bumps the package independently of core, or the mirror stops receiving splits and nobody notices because nothing breaks loudly.
4. Provenance/supply chain — the unknown repository URL plus anomalous release date means the package must be verified against the official Flarum org before it enters the lockfile. This is the only failure mode with a security dimension.

Ramp-up — Minutes. Any PHP developer who has run composer require on a Flarum instance can own this. No domain knowledge transfer, no runbook, no on-call implications. The one piece of tribal knowledge worth writing down: this package is a read-only mirror — never target it with a PR, and never let a bot bump it without checking core compatibility.