Lang Import Export Laravel Package

Product Decisions This Supports

• Localization operating model: repo-native vs. TMS-driven. The package makes CSV the interchange format between the Laravel codebase and whoever owns translations. That directly informs the decision "do translators work in Git, in a spreadsheet, or in a paid platform?" — CSV round-tripping is the cheapest credible middle ground.
• Build vs. buy for translation tooling. An artisan import/export command is the kind of utility teams often build internally (a day or two of engineering plus ongoing maintenance). This package is a ready-made candidate for the "buy" (well, adopt) side of that comparison, and its MIT license keeps the fork/vendor option open. The decision to make is explicit: adopt, fork, or write ~100 lines in-house.
• Roadmap sequencing for international expansion. Adding a locale is mostly a translation-throughput problem, not an engineering one. If the roadmap includes N new markets, this package is a lever on the "how fast can we ship locale X" estimate — and on whether that work blocks engineers.
• Release-readiness and QA process. Exporting language files to CSV enables coverage audits (missing keys per locale, untranslated strings, drift between locales) as a pre-release check. That supports a decision about whether translation completeness becomes a release gate.
• Staffing and ownership. If translators or vendors can round-trip CSVs, translation ownership moves off the engineering backlog. That's an org-design decision (who owns i18n) as much as a technical one.
• Procurement timing. Adopting this defers a TMS purchase (Crowdin, Lokalise, Phrase, Weblate). The PM decision is whether to spend now for workflow features (context, screenshots, review, MT) or defer and accept spreadsheet-based coordination.
• Vendor/package risk posture. With ~41 stars and zero dependents, this is a utility to treat as "a script with a license," not a platform bet. That shapes the decision on pinning, vendoring, and exit planning.

When to Consider This Package

Adopt or pilot when:

• The application is Laravel with file-based translations (lang/ or resources/lang/), and translations live in the repo.
• Non-engineers (translators, agency, regional leads) need to contribute and are comfortable with CSV/Excel/Google Sheets rather than pull requests.
• You have no TMS budget or no appetite for integration work, and want a low-ceremony round-trip: export → translate → import → commit.
• You need a one-off audit or migration — extracting existing strings for a coverage review, or seeding a new locale from a spreadsheet.
• You want a small, auditable, MIT-licensed codebase you can vendor or fork if the command behavior needs to change (file naming, nesting, key ordering).
• Your locale count and string volume are modest — this scales to "a few languages maintained by humans," not to continuous localization at scale.

Look elsewhere — or plan to build — when:

• You need runtime-editable translations (admin UI, per-tenant overrides, DB-backed strings). Use a translation loader / DB-backed approach instead.
• You need TMS capabilities: translator context, screenshots, glossary, translation memory, machine translation, review workflows, per-string history. That's a platform purchase, not a CLI package.
• You rely on complex message formats — ICU messages, advanced pluralization, nested/namespaced vendor translations, or JSON translation files. Verify the package's handling of your exact file shapes before committing; if it doesn't cover them, a fork is required.
• Maintenance risk is unacceptable. Check last commit, supported Laravel/PHP versions, and open issues against your upgrade cadence. Low adoption means you are effectively the maintainer if it breaks. If you can't tolerate that, write the command in-house — the scope is small.
• You need CI-grade guarantees (schema validation, key-parity enforcement, deterministic diffs). You'll likely wrap or extend whatever you pick.

A sensible PM posture: time-boxed pilot on one locale, with a fallback plan to fork or replace with an internal command if the round-trip proves lossy or unmaintained.

How to Pitch It (Stakeholders)

For executives (one paragraph): Localization is currently an engineering-shaped bottleneck: every new market or copy change routes through developers and pull requests. This package is a free, MIT-licensed Laravel utility that lets us move translations in and out of the codebase as spreadsheets, so translators and regional teams can work in tools they already know while engineers keep shipping. It's a small bet with a clear exit: no runtime dependency, no vendor lock-in, and the fallback is a short internal script. Approve it as a pilot on the next locale, with success measured by translation turnaround time and engineering hours removed from the i18n backlog.

For engineering: Two artisan commands, CSV in and CSV out, no runtime footprint, fits existing Laravel conventions. Caveats to accept explicitly: low adoption (~41 stars, no dependents), so we pin the version, review the source, and assume ownership. Verify it handles our file layout, nesting, and pluralization conventions on a sample locale before rollout. Keep it isolated behind our own command wrapper so swapping it out is a one-file change.

For finance/procurement: Zero license cost and it defers a TMS subscription. The honest comparison is not "free vs. paid" but "free plus coordination overhead vs. paid plus workflow features." If we later adopt a TMS, CSV is the standard import format, so this work is not wasted — it becomes the export path.

For localization/ops: Translators get a spreadsheet round-trip instead of Git. That means familiar tooling, easier review, and faster iteration — provided we define a clear file-naming and handoff convention and a review step before import.

The risk to name out loud: this is a utility, not a platform. Treat it as a script we happen to have licensed, keep an exit plan, and don't let it become load-bearing infrastructure without an owner.