Lync 2013 Conversation Translator: a historical integration note

In November 2012, I explored a conversation-translation integration for Lync 2013. The original post described registering an add-in, restarting the client and choosing a language in the conversation experience.

What the configuration contained

The example used a per-user Lync add-in registration. It named the component Lync Conversation Translator, configured its window and application properties, and pointed its internal and external URLs at a translation integration.

The original also included trusted-site entries for the remote service. Those entries are part of the integration’s trust configuration; they should not be treated as decorative lines to copy into a registry file.

Preserve the record without reconstructing a broken file

The WordPress text export has lost separators in several registry paths. For example, its displayed root begins HKEY_CURRENT_USERSoftwareMicrosoftOffice15.0LyncAddins. That is not a usable registry path as written.

This revised article explains the recorded settings rather than silently guessing the missing separators and presenting a new importable .reg file. The original screenshots and post remain linked below for historical inspection.

The user workflow being explored

1. Register the translation integration for the relevant legacy user and client.
2. Restart the Lync client so it can discover the registration.
3. Start a conversation and choose the intended language.
4. Check how the translation interface and conversation indicator appear.

These steps summarize the historical experience. Current availability of the old service, authentication behavior and language support have not been established by this revision.

Evaluate the external dependency

The original integration referenced a Microsoft redirect and a cloud-hosted translation service. If investigating a similar integration today, establish who operates the endpoint, what conversation data it receives, how it is authenticated and whether it meets the organization’s requirements.

That investigation should precede enabling an add-in or adding trust entries. A surviving link or a syntactically repaired registry file would not, by itself, establish that the service remains suitable.

The lasting integration lesson

A client feature can depend on configuration, user experience and an external service at the same time. Documentation is more useful when it explains those dependencies, so a later reader can distinguish an interface experiment from a maintained deployment.