Weave Code
Weaver
Helps Laravel developers discover, compare, and choose open-source packages. See popularity, security, maintainers, and scores at a glance to make better decisions.
Feedback
Share your thoughts, report bugs, or suggest improvements.
Subject
Message

Google Translator Bundle Laravel Package

zeliard91/google-translator-bundle

A Symfony bundle that integrates Google Translate into your application, exposing a simple service for translating text between languages and configuration options to wire it into your project quickly.

View on GitHub
Deep Wiki
Context7

Product Decisions This Supports

  • Localization roadmap sequencing. Whether to machine-translate a first pass of UI strings, help-center articles, or long-tail SEO pages before human review. The category is real and worth a decision; this package is not the vehicle for it.
  • Build vs. buy for the translation layer. This is ~20 lines of glue over Google's HTTP API. The genuinely buyable parts are (a) the translation engine (Google Cloud Translation) and (b) the workflow layer (TMS: Phrase, Lokalise, Crowdin). The adapter in between is build, not buy.
  • Risk-tiering content for MT. High-volume, low-blast-radius content (support macros, UGC moderation previews, internal docs, SEO landing pages) is a go. Legal, pricing, safety, and brand-hero copy is a no — MT stays out of the publish path there.
  • Framework scope check. The listing is framed as a Laravel/PHP package, but the artifact is a Symfony bundle. That is a hard blocker for a Laravel decision: no service provider, no facade, no config/*.php publish path. Treat any "Laravel translation package" shortlist as needing re-sourcing.
  • Vendor concentration. Committing to Google Translate v2-era plumbing locks the content pipeline to one engine; a decision to abstract behind an internal interface (Google / DeepL / Amazon Translate) is cheap now and expensive later.

When to Consider This Package

Adoption criteria — all of these would have to be true simultaneously, which is close to never:

  • You are on Symfony 2.x/3.x with a legacy PHP runtime from the 2015–2017 window.
  • You are already calling the Google Translate v2 API with a plain server API key (not the v3 / Cloud Translation Advanced project-based auth).
  • The integration is a throwaway prototype with a hard expiry date.
  • You accept no security patches, no PHP 8 compatibility, no maintainer response.

Signals to look elsewhere (all of which currently apply):

  • 1 GitHub star, 0 dependents, last release 2017-09-26. Roughly eight years without maintenance. No community to catch a breaking upstream API change.
  • Composite score 0.095 / 1.0. This is a dormant artifact, not an early-stage bet.
  • You are on Laravel — the framework mismatch alone ends the evaluation.
  • You need v3 features: glossaries, batch translation, glossaries per project, model selection (NMT vs. LLM), or IAM-based auth.

The one number worth carrying forward is opportunity 21.24 against an overall 0.095 — that gap says the problem space (translation automation) has headroom while this implementation has none. Direct the exploration budget at the problem, not the repo.

How to Pitch It (Stakeholders)

Recommendation: do not adopt. Fund a thin internal adapter instead.

To executives: The underlying capability — machine translation — is a commodity API we can call directly for pennies per thousand characters. This specific library is an unmaintained 2017 wrapper with one star and zero downstream users. Adopting it would trade a few hours of engineering for years of unpatched-dependency risk on a customer-facing content path. The proposal is: buy the translation engine (Google Cloud Translation), buy the workflow tooling if we scale past ~5 locales (a TMS), and build the ~1-day adapter that connects them. That keeps us portable across vendors and free of orphaned code.

To engineering: It's a Symfony bundle in a Laravel codebase — no service provider, no facade, no config publishing. It targets the deprecated v2 API surface and predates PHP 8. Reimplementation is trivial: a single HTTP client call behind a Translator interface, with caching, batching, and a provider swap so we can A/B Google against DeepL. That interface is the actual asset; the package is not.

To the localization/content team: Nothing about this changes your workflow. The decision that matters for you is which content classes enter the MT pipeline and what the human-review gate looks like — not which PHP library calls the API.

Bottom line: the package fails on framework fit, maintenance, and adoption signal simultaneously. The category is worth a roadmap line; this artifact is not worth a spike.

Weaver

How can I help you explore Laravel packages today?

Conversation history is not saved when not logged in.
Prompt
Add packages to context
No packages found.
skyraptor/chatter
edlugz/sasapay
abbasudo/artisan-route
mirvan/ippanel
ignibyte/aic-framework
glavweb/data-schema-bundle
glavweb/datagrid-bundle
tacticmedia/scim-server
uni-method/frame
neika-ai/sdk
adachsoft/php-code-style
pharaonic/laravel-notification-dependencies
beautinow/translug
dev-brainiac/bot-cloaked
octoberrain/html
octoberrain/extension
octoberrain/exception
octoberrain/contracts
adachsoft/api-version-bundle
cgv/localized-resource