Closed callumbwhyte closed 4 months ago
Yep - been looking at this, does a couple of things, but wondering about the interface
this has a default implimentation :
public TextTranslateOptions GetOptions(string sourceLanguage, string targetLanguage, bool IsHtml)
=> new TextTranslateOptions
{
TagHandling = IsHtml ? "html" : string.Empty,
};
but it hopefully going to have enough info that if you wanted to build something to do per language glossaries your could ?
I was going to also add some glossary options to the connector, but the per language pair thing probiblty makes it a bit more than a quick fix (we will need to have something where you pick both languages and then pick the glossary id, not hard, but not super quick).
I need to set aside a little bit of time for that, not least because i will need to go purchase the pro version to make sure i get all the options right!
OK,
So we have a beta : (this is v12.x - but for deeplL v12 works on v10 - v13 of Umbraco)
https://www.nuget.org/packages/Jumoo.TranslationManager.Connector.DeepL/12.5.0-beta02
this has two features to help (i think).
it has the option to 'auto map' the glossaries, so it will attempt to find a glossary that matches the source and target languages being used, and if it finds one it will add it to the options.
it allows you to impliment a IDeepLConfigurationProvider
interface (and register it in a composer) to replace how the options are defined for a job. (There is a base class DeepLConfigurationBase
that you can use that does most of the default config, so you can choose to just do the bit that matters.
public class CustomDeepLConfigProvider : DeepLConfigurationBase, IDeepLConfigurationProvider
{
public CustomDeepLConfigProvider(
TranslationConfigService configService,
Lazy<IDeepLTranslationService> deepLService) : base(configService, deepLService)
{
}
public override TextTranslateOptions GetOptions(string sourceLanguage, string targetLanguage, bool IsHtml)
{
var options = base.GetOptions(sourceLanguage, targetLanguage, IsHtml);
// custom things here ?
options.GlossaryId = "my-id";
return options;
}
}
but maybe the mapping means you don't need this ?
also - added some more of the options, to the config
This is really really awesome @KevinJump, will give this a test!
Hi @KevinJump, I've been testing this out and realised the glossary ID is always returning null when using the "map glossaries".
We did some digging and found that the IDeepLTranslationService
is a lazy type and never initialised because of the IsValueCreated
check.
Removing this will fix the provider and return the correct glossary ID. 🙌🏻
Hi,
yeah - don't know what i was actually thinking there!
beta03 on nuget https://www.nuget.org/packages/Jumoo.TranslationManager.Connector.DeepL/12.5.0-beta03
Just tested the new version and it's all working nicely! Thanks @KevinJump 👌🏻
tidying up : this feature has been released in the standalong version of the deepL connector
We have a client that uses some domain-specific language in their content that does not translate well.
DeepL has a Glossary feature making it possible to provide an alternative list of translations to the engine.
You must pass the
glossary_id
field in the translation request (see docs), but Translation Manager does not offer this as an option (or provide a way to add programatically) 😔It would be super awesome if we could optionally set a glossary ID in the DeepL connector settings at the very least, or a way to append this programatically... Even better would be the ability to set a different ID per language (as you may have different glossaries per source + target language)... Even even better would be for Translation Manager to manage the contents (+creation) of the Glossary itself as it needs to be created by the API – but I know I'm getting carried away there!
(PS the link to the DeepL docs on the Providers web page says "Google Docs" 😉)