Product Decisions This Supports
- Localisation roadmap: helps decide when to add locales. If string editing is the main blocker, this removes it cheaply; if translator workflow is the blocker, it does not.
- Build vs. buy for an internal copy/translation admin: a free, MIT-licensed addon that puts Laravel language files behind a Statamic Control Panel UI versus building or buying a bespoke string-management tool.
- Source-of-truth decision: forces an explicit choice between language files as code (PR-reviewed, versioned, rolled back with releases) and language files as live content (edited in the CP by non-engineers). This is the decision with the most downstream process impact.
- Editorial ownership: shifts ownership of microcopy, validation/error messages, email text, and seasonal/regional variants from engineers to content and marketing ops.
- TMS timing: a deliberate stopgap that defers spend on Lokalise/Phrase/Crowdin/Weblate while locale count and string volume stay small.
- Release/QA process: raises questions worth settling early — who approves string changes, how they are tested, and whether CP edits are captured back into the repo or lost on deploy.
- Use cases: small multilingual marketing sites, regional variants (en-GB/en-US), fixing awkward UI copy without a sprint, and handing a client a self-serve copy lever.
Treat this as a string editor, not a localisation platform. It does not replace translation memory, approval flows, or translator portals.
When to Consider This Package
Consider it when:
- The site runs Statamic and the editorial team already lives in the Control Panel.
- Laravel language files are the real runtime source of strings — not a CMS field, not a JS bundle, not a database table.
- You have a small locale footprint (roughly 2–5) and modest string volume.
- No dedicated localisation tool exists yet, and the budget/process case for one isn't made.
- You want a fast stopgap while a TMS decision is pending.
- You can absorb addon risk: 9 stars, 0 dependents, single maintainer — assume you may need to fork or patch it, and pin the version.
Look elsewhere when:
- You need translator portals, review/approval, glossary, translation memory, pluralisation/gender rules, or vendor SLAs — use a dedicated TMS.
- Language files are strictly code-owned and reviewed in PRs; CP editing creates drift, merge conflicts, and unreviewed copy in production.
- You have many locales, high string churn, or many contributors.
- Strings live predominantly in JavaScript, a database, or third-party services.
- Compliance or enterprise support requirements rule out a small community package.
Given the adoption signals, validate with a scoped spike on one site before standardising.
How to Pitch It (Stakeholders)
For executives: This is a small, free, MIT-licensed addon that lets non-engineers edit the site's language strings directly inside the Statamic admin, instead of filing engineering tickets for every copy change. It is a low-cost way to unblock localisation and routine copy work, and it defers any spend on a commercial translation platform until we actually need one. The trade-off is maturity: it is an early-stage package with minimal adoption, so I'd recommend a limited pilot on a single site with a pinned version, rather than making it a standard.
For engineering: It adds a Control Panel screen over the existing Laravel language files — no meaningful new runtime surface expected. Before adopting, we need to confirm the write path and permissions, decide how CP edits reconcile with version control (commit-back, or accept it as a runtime-only override), check cache-clearing behaviour after edits, and make sure a deploy can't silently overwrite translator work. Keep lang files under review until the pilot proves out; if the package stalls, the fallback is to fork it or move to a TMS.