Begin by identifying where meaningful text becomes available. A server-rendered application returns most content in the initial HTML, while a client-rendered application builds the page after JavaScript runs. Hybrid frameworks may use both patterns across different routes. Network requests, route transitions, modals, validation messages, and content loaded after interaction all belong in the inventory.

This map determines whether response translation, a browser widget, or a crawler-generated page is appropriate. Choosing by framework name alone is unreliable because the same framework can be deployed with very different rendering modes.

A browser runtime can observe visible text and apply translations as components render or change. It works well for dashboards, interactive tools, and applications with frequent client-side updates. The integration should preserve protected product names, variables, form values, code samples, and elements explicitly excluded from translation.

Runtime translation must handle route changes without duplicating observers or causing visible flicker. Cache translated segments, batch requests, enforce domain-bound credentials, and avoid placing private keys in frontend code. Public site keys should still be scoped and rate limited.

Search engines and social previews need complete, stable HTML at a public locale URL. A crawler can render the JavaScript application, capture the final DOM, translate eligible content, and publish a cached page. The result should include localized metadata, canonical and hreflang links, internal URLs, and current structured data.

Define a freshness policy based on source hashes or deployment events. Never publish a partial render as complete. Failed resources, authentication walls, consent overlays, and delayed content can all produce an incomplete snapshot that should remain unavailable until validation succeeds.