Translation Connectors

A translation connector takes the Translation Job and puts it into the required format for a translator or translation service to perform the translation.

e.g The XLIFF connector takes a translation job and turns it into an XLIFF file. You can then send it to a translator, who will fill in the translations and send the file back. The connector then puts the translated values back into the translation job for Translation Manager to process.

There are a number of connectors available for translation services, you can view our current list of connectors at : https://jumoo.co.uk/translate/providers/

Writing a connector - what changed in 17.9.0

Connectors build on the base classes in Jumoo.TranslationManager.Connectors. Everything below is opt-in: a connector written against 17.8 keeps working on 17.9 without changing a line.

Glossary support

A machine connector that wants the Glossary swaps its base class:

Instead of	Use
MachineConnectorBase<TOptions>	GlossaryMachineConnectorBase<TOptions>
BatchableMachineConnectorBase<TOptions>	GlossaryBatchableMachineConnectorBase<TOptions>

The base resolves the glossary for the job's language pair and hands it to your SubmitCore through the job options, where TryGetGlossary reads it back as a GlossaryContext. The context carries the terms themselves and, for services that hold their own glossaries, the id of the one Translation Manager has pushed.

Your options class extends GlossaryMachineOptionsBase, which adds a UseGlossary setting. Report it through IGlossaryAwareProvider.UsesGlossary so Translation Manager knows to show the Glossary screens - a connector that says it uses the glossary switches the feature on for the site, no config setting needed.

A connector whose service keeps glossaries of its own (a termbase) can also implement IGlossaryPushProvider. Translation Manager tracks what it has already sent and only calls you when the terminology has actually changed, so you never re-upload an unchanged glossary or have to remember what you pushed last time.

Retrying transient failures

MachineConnectorBase can retry a failed call rather than failing the job. It is off by default - a connector turns it on through the UseRetryPolicy setting on its options, alongside RetryCount and RetryBaseDelayMilliseconds.

By default only genuinely transient, service-agnostic failures are retried: a dropped connection, a socket error, or a request timeout. A cancelled request, a bad API key, an exhausted quota, and anything your own SDK throws are not retried, because none of them succeed on a second attempt.

Your service almost certainly has its own idea of what is worth retrying - a rate-limit exception, say. Override BuildResiliencePipeline to say so:

protected override ResiliencePipeline BuildResiliencePipeline(MyConnectorOptions options)
    => new ResiliencePipelineBuilder()
        .AddRetry(new RetryStrategyOptions
        {
            MaxRetryAttempts = options.RetryCount,
            BackoffType = DelayBackoffType.Exponential,
            Delay = TimeSpan.FromMilliseconds(options.RetryBaseDelayMilliseconds),
            ShouldHandle = new PredicateBuilder()
                .Handle<TooManyRequestsException>()
                .Handle<ConnectionException>(),
        })
        .Build();

ExecuteWithResilienceAsync is available for your own calls - a batch upload or a status check - so you get the same behaviour without taking a Polly dependency yourself.

Loading the shared settings

Every connector ends up reading the same handful of settings - throttle, split, translation memory, and now the retry ones. LoadBaseSettingsAsync reads them for you:

_options = new MyConnectorOptions { Throttle = 0 };   // your own defaults first
await _options.LoadBaseSettingsAsync(config, this.Alias);
// then your connector's own settings

Each setting falls back to whatever is already on the options object, so set your defaults before calling it and they survive where nothing is stored. This is optional; a connector that loads its own settings carries on unchanged.