Glottos Laravel Package

Product Decisions This Supports

• Localization strategy: build vs. buy. Glottos is a self-hosted, database-backed translation management console — it lets non-engineers edit locale strings through a web UI instead of committing to lang/ files. Deciding to adopt, fork, or merely copy its model is a concrete input to the "do we build an internal TMS or pay for one" call.
• Removing engineering from the copy-change critical path. Today, every string tweak is a PR, a review, and a deploy. A tool in this category converts that into a content operation. That is a measurable roadmap item (deploy frequency, cycle time for marketing requests), not just a developer convenience.
• Market expansion sequencing. If the roadmap includes new locales, the workflow question — who edits, who reviews, how strings ship — becomes blocking. This package frames the minimum viable workflow: locale registry, key management, import/export, translator-facing UI.
• Internal tooling investment sizing. A 69-star, zero-dependent, PHP 5.3-era package is a useful cost anchor: "the naive version of this is small enough that one person built it." That calibrates whether an internal build is a two-week spike or a multi-quarter platform.
• Admin-surface product decisions. It surfaces the real requirements for any translation console you ship: role separation (translator vs. reviewer vs. admin), audit history, publish/rollback, and environment safety — the things a demo tool skips and production demands.
• CMS/admin panel use cases. For Laravel products with a back office, the pattern (edit strings at runtime, cache them, expose per-locale) is directly reusable for tenant-configurable copy, not just i18n.
• Risk register input. Zero dependents and stale PHP version support make this a deliberate reference architecture, not an adoption candidate — that distinction belongs in the build/buy memo.

When to Consider This Package

Consider it (as a pattern, spike, or internal fork) when:

• You run a Laravel monolith and the team already owns the admin panel; bolting on a translation screen is incremental work.
• You have one to three locales, a handful of internal translators, and no vendor/agency translation workflow to coordinate.
• Self-hosting is a hard requirement — regulated, air-gapped, or data-residency-constrained environments where sending product copy to a SaaS TMS is not approvable.
• You need to prototype the translator experience cheaply to validate requirements before committing budget to Lokalise, Phrase, Crowdin, or Weblate.
• Budget is near zero and the alternative is "marketing keeps emailing CSVs to an engineer."

Look elsewhere — or straight to a commercial TMS — when:

• You need maintenance and security guarantees: this package targets PHP 5.3+, has negligible adoption (69 stars, 0 dependents), and should be assumed incompatible with modern Laravel/PHP and unpatched. Vendoring it into a production app is a liability, not a shortcut.
• You require CI/CD integration, translation memory, glossary enforcement, MT pipelines, or vendor/agency handoff — those are the reasons TMS platforms exist and the reason not to build.
• You need RBAC, audit trails, approval workflows, or SOC 2-style controls around who changed which customer-facing string.
• Your stack is not Laravel/PHP, or you need framework-agnostic string management (mobile, multiple services).
• Localization is a growth pillar with a headcount attached — at that point the buy decision is trivially cheaper than the build.

How to Pitch It (Stakeholders)

For executives: Localization is currently gated on engineering time — every translated string waits for a deploy. This package is an early, self-hosted attempt at the console that fixes that: translators edit copy in a browser, engineers stop being the bottleneck. My recommendation is not to adopt it — it is unmaintained, built for PHP 5.3, and has effectively no user base, so it carries real security and upgrade risk. What it does give us is a cheap, credible proof that the workflow is small: one developer built the core of it. That lets us decide with evidence between (a) a two-to-three week internal console scoped to our actual locales, and (b) a paid TMS if we're heading into three-plus markets with external translators. Either way, the decision unblocks the localization roadmap item without a multi-quarter platform bet.

For engineering: Treat Glottos as a reference implementation and a source of requirements — locale registry, key management, import/export, translator-facing UI — not as a dependency. We'd be inheriting an unmaintained PHP 5.3-era codebase with no downstream users to catch regressions. If we build, we scope it to our admin panel with modern framework support, explicit environment guards so production strings can't be edited live, and a caching layer. Estimate the spike, then compare against TMS seat pricing before committing.