BingTranslator API has been retired

[tombogle]

The API used in the internal BingTranslator class to do fail-safe, on-the-fly translation of strings in the LanguageChoosingDialog was retired a couple years ago.

Look at alternatives.

[tombogle]

Design: Replace the retired BingTranslator API

Background

L10NSharp.Windows.Forms.Translators.BingTranslator does fail-safe, on-the-fly translation of a few UI strings in LanguageChoosingDialog (the dialog title, message, and OK button) when the dialog opens for a non-English requested UI language. It calls the old Bing/Microsoft Translator v1 SOAP API (api.microsofttranslator.com/v1/Soap.svc) via a WCF-generated proxy, using a hardcoded personal App ID. That API was retired in 2021, so BingTranslator has been silently failing (and falling back to showing the English text) for years — a failure this code was already designed to swallow invisibly, which is why it went unnoticed.

The linked connector page (https://learn.microsoft.com/en-us/connectors/microsofttranslator/) turns out to be a deprecated Power Platform/Logic Apps connector wrapper, not something a C# app calls directly. The real replacement is the Azure AI Translator Text API v3 (https://api.cognitive.microsofttranslator.com/translate), a REST/JSON endpoint. Unlike the old v1 API, it has no free, publicly-shareable App ID — it requires an Azure account and a provisioned Translator resource with a subscription key (there is a free tier: 2M characters/month).

There's also a second, already-dead translator in the same folder: GoogleTranslator.cs, which called a Google AJAX endpoint retired around 2011. It's not referenced anywhere in the codebase.

Goals

• Restore working fail-safe translation in LanguageChoosingDialog with zero provisioning required by host apps (Bloom, etc.) — this is best-effort UX polish, not core functionality, and volume is trivial (a handful of short strings, translated once per dialog open, only for non-English locales).
• Give host apps that want more robust/reliable translation an opt-in path to a real Azure Translator resource, without requiring it.

Design

1. MyMemoryTranslator (internal) — new default

Replaces the dead GoogleTranslator.cs in place (same file, same slot in the Translators folder). Calls the MyMemory Translation API — a free, public, documented REST/JSON translation service explicitly intended for light/anonymous use:

• GET https://api.mymemory.translated.net/get?q={text}&langpair={from}|{to}
• No signup, no key.
• Anonymous quota: 5,000 characters/day per IP (verified live; response includes a quotaFinished flag). Each installed copy of a host app gets its own quota, since it's per-IP — comfortably covers our volume (a few dozen characters, once per dialog open, only in non-English locales).
• Response shape (verified live against the real endpoint):

  {"responseData":{"translatedText":"...", "match":1}, "quotaFinished": false, "responseStatus": 200, ...}

  This is essentially identical to what GoogleTranslator.cs already parses (responseData.translatedText) — minimal rewrite needed, same HttpClient + DataContractJsonSerializer pattern already used there.

This becomes the always-available default translator — no configuration, no host-app changes required.

2. MicrosoftTranslator (public) — opt-in override

Replaces BingTranslator.cs/the WCF proxy in Service References/BingTranslatorService/. Calls the real Azure AI Translator v3 REST API directly (no WCF, no code-gen):

• POST https://api.cognitive.microsofttranslator.com/translate?api-version=3.0&from={from}&to={to}
• Headers: Ocp-Apim-Subscription-Key (required), Ocp-Apim-Subscription-Region (required only for regional resources; omitted for "Global" resources), Content-Type: application/json.
• Body: [{"Text": "..."}]; response: [{"translations":[{"text":"...","to":"..."}]}].

Configuration (all public static, on MicrosoftTranslator):

• SubscriptionKey — settable in code by a host app; if unset, falls back to reading the L10NSHARP_TRANSLATOR_KEY environment variable.
• Region — settable in code; if unset, falls back to the L10NSHARP_TRANSLATOR_REGION environment variable. Optional (only needed for regional resources).
• IsConfigured — true when a subscription key is available (from either source).

This gives host apps a "backdoor" to more robust, quota-generous translation without forcing every consumer to provision anything.

Making this class public requires making its base class, TranslatorBase, public too (C# requires a base class to be at least as accessible as the derived class). TranslatorBase's existing member accessibility (public virtual TranslateText, protected virtual InternalTranslate/PreTranslateProcess/PostTranslateProcess) is already a reasonable public shape for subclassing — no changes needed there beyond the class-level access modifier. MyMemoryTranslator stays internal.

3. Selection logic

In LanguageChoosingDialog.Application_Idle (where new BingTranslator(...) is constructed today): use MicrosoftTranslator if MicrosoftTranslator.IsConfigured, otherwise MyMemoryTranslator. No runtime failover between the two for now (see "Out of scope" below) — the choice is made once, up front, based on configuration.

4. Cleanup enabled by dropping WCF

Since both new translators are plain REST/HttpClient calls (matching the existing GoogleTranslator.cs pattern), the WCF/SOAP plumbing this feature previously required becomes dead weight:

• Delete Service References/BingTranslatorService/Reference.cs and Reference.svcmap.
• Remove the System.ServiceModel framework reference (net462/net48) and the System.ServiceModel.Http/System.ServiceModel.Primitives package references (net8.0-windows) from L10NSharp.Windows.Forms.csproj.
• Remove the leftover <system.serviceModel> bindings/client block from src/L10NSharp/app.config (a stale artifact of the old config-name-based WCF client endpoint).

This also removes an entire dependency chain (System.ServiceModel.*) that recently caused build breakage during a dependency upgrade pass on this repo.

Out of scope (future enhancement, not built now)

Automatic runtime failover — e.g., trying MicrosoftTranslator first, falling back to MyMemoryTranslator on failure or quota exhaustion, and potentially further falling back to the unofficial/reverse-engineered translate.googleapis.com/translate_a/single endpoint (undocumented, unsupported by Google, used by many hobbyist "free Google Translate" wrapper libraries, but carries ToS and stability risk). Left as a documented possibility for later; not needed for the "restore fail-safe translation" goal.

Testing

No new unit tests for the live network calls — this matches existing precedent (LanguageChoosingDialogViewModelTests already tests LanguageChoosingDialogViewModel.TranslateStrings against fake TranslatorBase implementations, decoupled from any real translator). Verified manually via SampleApp, same as the build-fix work earlier in this branch's history.