Loco Importer Bundle Laravel Package

Product Decisions This Supports

• Localization pipeline architecture: Informs how translated copy travels from the TMS (Loco/localise.biz) into the application's translation catalogs — a decision every multi-locale product eventually has to make, whether it's a one-off script, a scheduled job, or a CI step.
• Build vs. buy vs. borrow: This package is best treated as a reference implementation, not a dependency. It demonstrates the shape of the integration (authenticate to Loco's API → fetch assets/tags → write to translation files) that an in-house Artisan command could replicate in a few hundred lines with full ownership.
• Vendor/tooling risk scoring: A data point for how the team evaluates third-party packages generally — 1 star, 0 dependents, no release since Feb 2020 is a textbook "do not adopt" signal, and the same rubric should apply to every package in the evaluation backlog.
• Roadmap sequencing for internationalization: Supports the argument that i18n infrastructure (string extraction, TMS sync, locale fallbacks) needs to land before a market-launch or multi-language feature commitment, not after translators are already blocked.
• Use-case fit assessment: Relevant for content-heavy or marketing-driven surfaces with frequent copy churn, where manual export/import of translation files is a recurring tax on engineering time. Less relevant for products with a handful of static strings or a single locale.

When to Consider This Package

Consider it only as reading material or a fork candidate when:

• You are on Symfony (it is a bundle, not a Laravel package — the naming in the request is misleading; there is no service provider, no published config, and it will not drop into a Laravel app without adaptation).
• You are already committed to Loco/localise.biz as your TMS and need a pull-only import of translations into local files.
• You need a throwaway prototype or internal tool to prove the sync concept before investing in a maintained solution.
• You are comfortable vendoring/forking the code, pinning it, and owning it — including verifying PHP 8.x and current framework compatibility, which is unconfirmed for a 2020-era release.

Look elsewhere (or build in-house) when:

• You need a Laravel-native integration — prefer a small Artisan command hitting Loco's documented REST API, or Loco's official CLI/exports in CI.
• You require active maintenance, security patching, or support — zero dependents and a five-year-old last release mean effectively no community backstop.
• You need bidirectional sync (push source strings to Loco) or CI/CD gating on missing translations — this is import-only.
• Your translation volume, locale count, or compliance requirements demand tested, versioned, observable tooling rather than a single-contributor bundle.
• PHP 8.1+ / modern framework support is a hard requirement, since compatibility here is unverified.

How to Pitch It (Stakeholders)

To executives: Don't add this as a dependency. It solves a real problem — keeping translated copy in sync with the codebase without manual copy-paste — but the package itself is effectively abandoned (one star, no dependents, last release February 2020). The recommendation is to treat it as a blueprint, not a purchase, and fund a short internal spike instead. The integration surface is small and well-documented on Loco's side; replicating it in-house is days, not weeks, and gives us ownership, tests, and a maintenance path. Net: low cost, removes a recurring manual workflow, and avoids a stale third-party dependency in our localization pipeline.

To engineering: This is a Symfony bundle that pulls translation assets from Loco's API into local translation files. It's useful as a structural reference, but we should not install it: it predates PHP 8, has no maintenance signal, and its framework conventions don't map to our stack. Proposed path: a thin, tested Artisan command (or CI job) against Loco's REST API, with credentials in the secret store, a scheduled pull, and a diff check that fails builds on untranslated keys. That gives us the same outcome with a fraction of the risk. Recommend a one-day spike to validate the API surface before committing to the roadmap slot.