Bing Translation Laravel Package

Getting Started

What this package actually is. melk/bing-translation is a small Symfony bundle that wraps the legacy Bing/Microsoft Translator HTTP API. It ships a DI-registered translator service plus a melk_bing_translation configuration block holding your API credentials. It is not a Laravel package and has no Laravel service provider — you are wiring it into Laravel manually or using it inside a Symfony app that sits next to your Laravel services. That distinction drives everything below.

Minimal setup (Symfony context):

1. composer require melk/bing-translation
2. Register the bundle in app/AppKernel.php (or config/bundles.php on Symfony 4+) — check the README, it is a classic Bundle subclass.
3. Add credentials to config.yml:

   melk_bing_translation:
       client_id: %bing_client_id%
       client_secret: %bing_client_secret%
   

4. Clear the container cache and confirm the service is registered:

   bin/console debug:container | grep -i bing
   

In a Laravel app, skip the bundle: pull the translator class out and instantiate it directly, or (better) copy the ~100 lines of HTTP logic into a small BingTranslator class of your own. The bundle's only real value here is as a reference implementation of the auth handshake.

Where to look first: vendor/melk/bing-translation/README.md, then DependencyInjection/Configuration.php (tells you the exact config keys) and Resources/config/services.yml (tells you the exact service id and class). Do this before writing any code — the bundle is old enough that the README and the code may disagree, and the service id is not guessable.

First use case: translating a batch of UI strings on deploy. Pull the service, feed it your source-language array, dump the result into lang/{locale}.php. That is the single highest-value thing this package can do for you, and it is what most users of these old Bing wrappers actually did.

Implementation Patterns

Inject the translator, don't fetch it statically. In Symfony, type-hint the bundle's translator class (or, preferably, your own TranslatorInterface that the bundle's class implements via an adapter) in your service constructor. In Laravel, bind it in a service provider:

$this->app->singleton(BingTranslator::class, function ($app) {
    return new BingTranslator(
        config('services.bing.client_id'),
        config('services.bing.client_secret'),
    );
});

Wrap it immediately. The most important pattern with a 0-star, 0-dependent package is a one-class adapter:

interface MachineTranslator {
    public function translate(string $text, string $to, ?string $from = null): string;
    public function translateBatch(array $texts, string $to, ?string $from = null): array;
}

class BingMachineTranslator implements MachineTranslator { /* delegates to the package */ }

This costs 30 minutes and lets you swap to Azure Translator v3, DeepL, or a local model later without touching call sites. Given the package's maintenance profile, treat this as mandatory rather than optional.

Batch, then cache. The Bing API is char-billed and rate-limited. Two patterns that pay for themselves:

• Hash-keyed cache. cache()->remember('mt:'.md5($text.$to.$from), $ttl, fn () => $translator->translate(...)). Locale strings rarely change; a 30-day TTL is fine.
• Associative-array batching. Translate ['welcome' => 'Welcome', ...] and return the same keys, so your call sites stay legible and you can diff the output against the source file.

Command-driven string sync. A php artisan translations:sync --to=fr (or Symfony console equivalent) that walks lang/en/, translates the missing keys, writes lang/fr/, and leaves a git diff for a human reviewer. Never translate at request time for static UI copy — it is slow, costs money on every cold cache, and makes output non-deterministic.

Database content translation. For user-facing records (product descriptions, help articles), translate on write via a queued job, store the result in a translations JSON column, and mark it machine_generated. This keeps the request path fast and makes it trivial to flag/override later.

Human-in-the-loop. Round-trip the machine output into your admin UI with an "edit" field. Machine translation from an unmaintained Bing wrapper is a first draft, not a final answer — build the review step in from day one.

Gotchas and Tips

The API itself is the biggest risk. The legacy Bing Translator AppId/OAuth flow this bundle targets was retired in favour of Azure Cognitive Services Translator (subscription key in an Ocp-Apim-Subscription-Key header, /translate?api-version=3.0). If your bundle version talks to api.microsofttranslator.com with a client_id/client_secret pair, expect 401s. Confirm with a single curl before debugging your own code — the failure looks identical to a bad config.

No compatibility guarantee. This is a Symfony 2/3-era bundle with zero dependents. Expect AppKernel-style registration, no autowiring, no PHP 8 type declarations, and possible deprecation notices on modern PHP. If you are on Symfony 5+, you will likely spend more time fighting the bundle than reimplementing the ~80 lines of HTTP it contains.

Credentials config quirks. The bundle reads config at container compile time. Changing .env values requires cache:clear; in dev this is easy to forget and results in "it works in prod but not locally" confusion. Also verify whether the bundle expects client_id/client_secret or an app_id — the key names changed across Bing API generations.

Character limits and encoding. The API has per-request length caps and the bundle does not chunk for you. Wrap calls in a splitter that breaks on sentence boundaries under ~1–2 KB, and always run input through mb_* functions — the endpoint chokes on malformed UTF-8, and the resulting exception is unhelpful.

HTML and placeholders get mangled. Do not send markup (<strong>, :attribute, {name}) through the translator blindly. Either translate text nodes only, or protect placeholders with sentinel tokens (__PH1__) and substitute back afterwards. This is the single most common source of production bugs with any MT wrapper.

Error handling is thin. Assume translate() returns a string on success and throws or returns null/false on failure, and that a transient 429/503 is not distinguishable from a config error by exception type. Wrap calls in try/catch with a retry-with-backoff and a fallback to the source string — never let a translation failure take down a page render.

Extension points. The useful ones are: (a) subclassing the translator to override the HTTP client, (b) decorating the service in services.yml to add caching without touching call sites, (c) replacing the endpoint URL in config if the bundle exposes it. If none of those are exposed, that is your signal to fork the class into your own namespace.

Do not put it on the request path for cache misses. Cold-cache translation in a controller means a 200–800 ms external call inside a user request. Queue it or precompute it.