Product Decisions This Supports
- Localization build-vs-buy for the sync layer. The package exists to answer one narrow question: do we write our own Crowdin pull/push automation, or take a dependency? It automates the translation file round-trip (download translated resources, upload source strings) through console commands — the glue code teams otherwise hand-roll in CI. As of 0.2.0 the Crowdin API work has been pushed out to a separate
php-crowdin-lib dependency, so the bundle is now a thin Symfony wrapper rather than a self-contained integration.
- Vendor lock-in assessment for Crowdin. Adopting anything that speaks Crowdin's API is a soft commitment to that TMS. Reviewing this codebase is a cheap way to see how much surface area the integration actually touches before you sign a Crowdin contract. Note that the API surface has moved: the meaningful calls now live in
php-crowdin-lib, so that repo is the one to read for a true lock-in read.
- Roadmap scoping for i18n. If localization is on the roadmap, this still tells you the minimum viable workflow shape: a scheduled job or pipeline step that syncs strings, plus a developer-facing command. That shape is worth keeping even though the implementation isn't.
- Build-time estimate for the alternative. As a reference implementation it still bounds the effort of an equivalent in-house command — but the estimate is now more honest: the Crowdin REST calls are delegated, so the "few hundred lines" figure should be attributed to the underlying library, and the bundle itself represents maybe tens of lines of console wiring. Either way, days, not a quarter.
- Dependency-chain risk signal. The 0.2.0 change adds a transitive, unmaintained-era dependency into the mix. For a package already rejected on maintenance grounds, this makes the supply-chain picture marginally worse, not better: two aging repos to trust instead of one.
- Taxonomy signal on your package shortlist. This is a Symfony2 bundle, not a Laravel package. If it surfaced in a Laravel evaluation set, that list has a filtering problem worth fixing before it produces more false candidates.
When to Consider This Package
Adopt only under narrow conditions:
- You are maintaining a legacy Symfony 2.x application (PHP 5.x era) and already use Crowdin. Even then, the 0.2.0 dependency split means you are now also inheriting
php-crowdin-lib — fork both, vendor both, and own both.
- You want a read-only reference for console command structure while designing your own integration. Read it, don't require it — and read
php-crowdin-lib alongside it, since that's where the API patterns now live.
Look elsewhere — or build — in essentially every other case:
- Laravel or modern Symfony (5/6/7). The Symfony2 console and bundle registration APIs no longer exist; there is no drop-in path. Integration cost exceeds rewrite cost, and the new dependency does not change that.
- Still unmaintained: last bundle release 2014-08-11, 8 stars, 0 dependents. A single dependency bump does not constitute a maintenance revival. No security response, no dependency updates, no bus factor. For anything touching build pipelines or credentials, that is disqualifying — and the added transitive dependency widens the surface you'd be trusting.
- Any compliance or support requirement. No CVE process, no SLA, no one to escalate to. Now true of two packages instead of one.
- Modern alternatives exist and are better. Crowdin ships an official CLI and an official PHP API client; either plus a thin Laravel console command gives you a maintained, documented integration in less time than resurrecting this bundle. The 0.2.0 change effectively concedes this by extracting the API layer rather than improving it.
- You need more than file sync. Branching, review workflows, machine translation, and webhook-driven flows are all outside this package's scope.
Net: do not adopt; recommendation unchanged. The 0.2.0 release is a dependency reshuffle, not a maintenance signal. Treat it as a design reference, point reviewers at php-crowdin-lib for the API patterns, and tighten package-list sourcing.
How to Pitch It (Stakeholders)
To executives: This came up as a candidate for automating our translation workflow with Crowdin. It's a decade-old, effectively abandoned Symfony2 component with no users and no maintenance — wrong framework for our stack, no security support, and no one to call if it breaks. Its latest release does not change that; it simply moves the Crowdin API code into a second old dependency, so we'd be trusting two unmaintained projects instead of one. The underlying need (a pipeline step that syncs strings with our translation vendor) is real and small. Recommendation: don't adopt; budget a short engineering task to build a thin integration on Crowdin's official CLI or PHP client, which is maintained and supported. Cost of the alternative is days, not weeks, and the risk profile is the opposite.
To engineering: jjanvier/crowdin-bundle is a Symfony2 bundle providing console commands to push/pull Crowdin translation files. Release 0.2.0 adds php-crowdin-lib as a dependency, which means the actual Crowdin REST calls now live outside this repo and the bundle is just console wiring. It still targets Symfony2 and PHP 5, was last shipped in 2014, and has no dependents — not usable in Laravel or current Symfony, and not something we should accept into the build pipeline. Its residual value is as a reference: skim the command structure here, then read php-crowdin-lib for the API call patterns we'd need. Proposal: use Crowdin's official CLI or official PHP API client, wrap it in a single artisan/console command and a scheduled CI job, and own roughly 200 lines of code we control. Link both repos in the ticket for historical context and move on.