The Service Mesh Behind a Single Translate Button

Every FluentRead surface eventually faces a service boundary, but the boundary is not the same as a single provider. This chapter explains why FluentRead places a broker between features and vendor protocols, then follows the consequences for language choice, free endpoints, cloud and local models, caching, key health, and deadlines. The reader’s practical task is to choose a service by its real compatibility and failure behavior rather than by the size of its menu.

One feature-facing choice, many provider realities

A page translator should not need to know the request format of every machine-translation service. An image feature should not have to implement a second version of AI context handling simply because a provider uses a different endpoint. FluentRead’s architecture therefore places a translation service layer and broker between user-facing features and provider adapters. A feature describes the translation it needs; the broker applies shared policy; a registry selects an adapter; the adapter speaks the provider’s protocol at the network or local boundary.

This separation is easy to mistake for a purely organizational preference. It is actually what lets different reading surfaces share decisions that affect the meaning of a result. Language direction, model choice, endpoint, prompt context, glossary, custom headers, request deadlines, cache use, and cancellation all need to travel with a request. If each feature assembled those fields independently, a document job, a page paragraph, and an image overlay could silently use different rules for the same apparent service. The broker creates one place where those identities and limits can be kept coherent.

It also gives the reader a stable choice while the underlying options remain diverse. The service directory includes free web endpoints, configured machine-translation APIs, DeepL, cloud vendors, AI-compatible services, local Ollama models, browser translation, and downloaded local translation models. These are not equivalent products. A free endpoint may need no key but can be rate-limited or unavailable. A cloud API may offer a published quota but require credentials and charge after the allowance. An AI service can explain a sentence but may cost more or require a model with the right tool or streaming support. A local model can keep translation text on the device while consuming storage and memory.

A language selector does not erase these differences. FluentRead documents 52 language options, but the availability of a language code depends on the selected service and the direction of translation. Providers use different codes and sometimes different support boundaries. A listed language may be accepted by one endpoint and rejected by another. DeepL’s documented limitations for some languages are not fixed by adding the language to FluentRead’s general selector. A model catalog entry similarly proves that an identifier exists in a directory, not that a particular account, deployment, or compatible endpoint can call it successfully.