- Is deeplcom/deepl-php a Laravel package?
- No. It is the official, framework-agnostic PHP SDK for the DeepL API, so it does not ship a Laravel service provider, facade, config file, or queue integration. In Laravel, wrap DeepLClient behind an application-owned TranslationService interface and a DeepL adapter to isolate vendor coupling.
- How do I install deeplcom/deepl-php in a Laravel application?
- Install it with Composer using composer require deeplcom/deepl-php. There are no migrations or frontend assets to publish. Confirm ext-curl and ext-json are enabled and that your app and queue workers can make outbound HTTPS requests to the DeepL API.
- Which PHP and Laravel versions does deepl-php support?
- The README states PHP 7.3 and later, but DeepL plans to drop end-of-life PHP versions, so target PHP 8.1 or newer for a modern Laravel app. The package is framework-agnostic and does not declare Laravel version constraints. Test it against your Laravel release and keep Composer constraints aligned with your runtime.
- How do I configure the DeepL API key in Laravel?
- Store the key in .env or a secrets manager and expose it through a config/deepl.php file; never commit it to source control. Bind DeepLClient as a singleton in a service provider using config values, and restrict who can read production configuration because the key is billable. Keep separate keys per environment where possible.
- How do I translate text with deepl-php in Laravel?
- Resolve DeepLClient from the container, call translateText with the source text, optional source language, and target language, then read the translated string from the result object. Wrap this in your own service so controllers do not depend directly on the SDK. Catch and translate vendor exceptions into application-level errors.
- Can I translate documents with deepl-php inside a Laravel HTTP request?
- Usually no. Document translation uploads a file, polls DeepL for status, and downloads the result, so it belongs in a queued job with a generous timeout and retry policy. Handle DocumentTranslationException carefully, including any document handle it exposes, to avoid orphaned uploads and duplicate costs.
- How should I test a DeepL integration in Laravel?
- Depend on your own TranslationService interface and bind a fake adapter in tests instead of calling DeepL. For the adapter itself, mock DeepLClient or the HTTP layer and assert request options, error handling, and billed character capture. Keep a small, explicit contract test against the live API only when needed, and never run it in normal CI.
- What production risks should I consider with deeplcom/deepl-php?
- The SDK is a transport client, not a resilience layer, so you must add retries with backoff, rate limiting, idempotency, and circuit breaking around it. DeepL availability, pricing, and API behavior are vendor-controlled, and source text or documents leave your application boundary. Review PII, confidential data, DPA, and data-residency requirements before rollout.
- How do I track DeepL usage and costs in Laravel?
- DeepL bills by character volume, and text translation results expose billedCharacters, which you should log or meter with tenant and feature attribution. Add budget alarms and quotas around that data, and account for document translation separately. The SDK does not provide application-level cost attribution or billing controls.
- Is deepl-php actively maintained, and what are the alternatives for Laravel?
- It is an official, MIT-licensed vendor SDK, which reduces abandonment risk, but its modest star count and low listed dependents mean fewer public field reports, so pin versions and validate internally. Alternatives include Laravel-specific DeepL wrappers or other translation providers behind your own adapter. Keeping DeepL behind a TranslationService interface preserves an exit path if multi-provider support becomes necessary.