Google Translation Bundle Laravel Package

Getting Started

• Require the package and its underlying translator: composer require lsv/google-translate-bundle. In a Laravel app you are effectively installing the stichoza/google-translate-php library that this bundle wraps; the bundle layer itself is Symfony-specific glue.

• Look first at the bundle's Resources/config/services.* and its DependencyInjection/Configuration to see what translator object it constructs and which defaults (source/target locale, timeout) it applies. That tells you what you need to replicate in Laravel.

• First use case: translate a single string. In practice, register the underlying translator in a service provider and resolve it:

  // AppServiceProvider::register()
  $this->app->singleton(\Stichoza\GoogleTranslate\GoogleTranslate::class, fn () => new \Stichoza\GoogleTranslate\GoogleTranslate('en', 'fr'));
  

  app(\Stichoza\GoogleTranslate\GoogleTranslate::class)->translate('Hello');
  

Implementation Patterns

• Don't fight the Symfony bundle. Laravel has no auto-discovery for Symfony bundles, so the bundle's DI extensions won't load. Consume the wrapped translator class directly, or write a thin adapter/service provider that mirrors the bundle config.
• Singleton translator per locale pair. Bind one instance per source/target combination (or a small factory) so you reuse the HTTP client within a request/job and avoid reconnect overhead.
• Cache aggressively. Wrap translate() in Cache::remember("translate:{$locale}:".md5($text), ...). Translation calls are the slow, quota-consuming part; identical strings are common in UI copy.
• Batch in jobs. Move translation into queued jobs (ShouldQueue) with retry/backoff to absorb rate-limit and transient network errors instead of blocking requests.
• Language detection via the translator's getLastDetectedSource() (or detect()) is useful for user-submitted content before choosing a target locale.
• Config binding. Mirror the bundle's locale/timeout settings in config/services.php (e.g. google_translate.source, target, timeout) and inject them into your service provider rather than hardcoding.
• Facade/adapter. Expose a small Translator class with translate() / translateBatch() methods and a facade so app code doesn't depend on the vendor API surface directly — this makes swapping to the official Cloud Translation client later trivial.

Gotchas and Tips

• This is a Symfony bundle, not a Laravel package. There is no service provider, no facade, no config publishing. You will not get it "working day-to-day" in Laravel as-is; the realistic path is using the underlying stichoza/google-translate-php library directly.
• v1.0.1 impact is negligible for Laravel. The only change is Symfony 8 support — relevant only if you're on Symfony 8. No new features, no breaking changes, no deprecations that affect a Laravel integration.
• Unofficial, fragile transport. The underlying library scrapes the public Google Translate endpoint rather than the paid Cloud Translation API. Expect breakage when Google changes markup, plus ToS/rate-limit risk. For production, prefer google/cloud-translate and treat this package as a prototype shortcut.
• No credentials/quotas. Because it's the public endpoint, there's no API key or quota config to tune — you get opaque throttling (HTTP 429/Too many requests) instead. Add generous retries and backoff.
• Timeouts and locale validation. Malformed target locales throw exceptions; validate against a whitelist of supported codes before calling, and set an explicit HTTP timeout so a hung request doesn't stall workers.
• Extension points are limited — the bundle mainly exposes the translator service. Any caching, logging, or batching you want has to be built in your own wrapper/provider layer, which is fine but means you're writing it either way.
• Debugging tip: log the source/target pair and a hash of the text on failure. The library gives terse exceptions; correlating them to inputs is the hard part when translating user content at scale.