Add different languge combination of SDL language cloud to project with unsupported language pair

Question

Hi, 
 I have lots of translations into Luxembourgish (e.g. EN_GB > LB_LU), which of course is not supported by SDL language cloud but it would help a lot if I still could use EN_GB > DE_DE from language cloud as hints to translation. For me this would speed up translations in terms of terminology a lot although the languages are different. 
 
 Is there a way to trick EN_GB > DE_DE from SDL language cloud into a project with different language combination(s)? Else it would be nice if SDL could add a language selector when adding SDL language cloud to a project so users could chose similar languages (if available) for unsupported languages. 
 regards, 
 Pascal

Paul · Accepted Answer

Pascal Zotto 
 Yep... if you use the SDL MT Cloud plugin to connect to the MT as opposed to the out of the box SDL Language Cloud you can work with the mapping feature and map Luxembourgish to German. Then all the results for that language will be based on German.

Paul · Answer

Mats Linder 
 Did you read this? 
 https://community.sdl.com/product-groups/translationproductivity/w/customer-experience/5270/language-mapping 
 It's not too complicated. You just tell it what MT language it should be using for your chosen source language. The main purpose of this is to handle languages that don't use the same language codes as Studio, but you can also use it to "force" MT from a different language for anything you wish.

Paul · Answer

Mats Linder 
 ok. For example, I have an English to French project I was playing with earlier. If I remap the French to be Swedish like this: 
 
 Then two things happen. First my engines are this: 
 
 Note that the EN-FR project language pair is correct, but the engine being used is now English to Swedish. And in the translation editor I now see this: 
 
 Not French. 
 Is that more clear? 
 Mats Linder said: With de-LU as defined target language for the project, I then selected that row for SDL MT Cloud Provider settings, wrote "lux" as code(locale) and selected that. Sure enough, the target language was changed to "ger" and a "ger" engine was made available. Is that how it is supposed to work? 
 I think you're a bit confused Mats. If your target language was de-lu you can see this is already mapped to German by default: 
 
 You also added LUX which is a non-existent locale and it was most likely simply ignored. In the example from Pascal his target language was Luxembourgish (not de-LU) and we don't have any MT at all for this language. So he mapped it to German. 
 I think you're over thinking this and are not really testing the real usecase at all. The main use cases would be this: 
 
 map a language that is supported with MT to a language that has no MT at all. This way a multilingual translator can at least get some help sometimes and use it as a handy lookup to help understand a sentence that might have been unclear. 
 map a language has been given a new engine in a specific locale but has not been added to the plugin yet. For example, if we added engines to support the different variants of Swedish which are currently all mapped to SWE: Until the plugin is updated, as we don't actually know what locale code will be used yet, the MT Team could tell the user what the locale code should be. The user would add it in, for example (I just made these up... they don't really work!) Now, the new engines that have been created for these variants will be selectable and usable. 
 
 I hope this all makes sense?

Paul · Answer

Mats Linder 
 Mats Linder said: Nowhere in the documentation can I find an explanation of the concepts "MT Code" and "MT Code (locale)" 
 You're right. I honestly thought this didn't need explanation as the headings are "Trados code" and "MT code". Seems quite obvious for me that one relates to the code used in Trados Studio while the other is the code used by the MT engine. I think part of the problem here is that you don't have any reason to use this feature and as a result don't have a real use-case where someone would tell you what you need. 
 But, I will try and make this more obvious when I update the wiki. 
 Mats Linder said: From your explanation -- and from my own try-outs -- the mapping is made by substituting the MT Code of the desired language (in your example "swe") for the original MT Code (here: "fra"). 
 If you wish to replace the main language with another then yes, you would obviously replace the MT Code and not the locale. 
 The existing wiki is just explaining how to add a locale if you have got one. But I'll make sure the instructions are more clear there too. 
 Mats Linder said: Particularly since I'm not sure I understand the very last part of your explanation: " Until the plugin is updated, as we don't actually know what locale code will be used yet". Could it be the case that I need a locale code when several engines have one and the same MT code, but not when -- as in your first example -- there is no need for such differentiation? (But in that case, what about this instruction on the page I mentioned: "User can add a MTCode for the specific language using the MT Codes window" -- which makes it look like I can even make one up? And which does not say why I would need to do add such a code.) 
 Did you read my explanation about Swedish variants? Let me try again. Please imagine a scenario where we only have engines for French-France (fr-FR). One day the developers of the MT solution add the ability to support a specific flavour for French- Canadian (fr-CA). But the language code that the MT team use for French Canadian turns out to be FRC which Trados Studio would not recognise. We also didn't know that FRC would be used until it was developed so the plugin won't recognise this new engine even exists. The only way to map it used to be that we would have to update the plugin and release a new version. But now the user can simply map it themselves using this mapping table we are talking about and doesn't have to wait for the plugin to be updated. 
 We will still update the plugin so that known locales and languages are always in the defaults, but nobody has to wait to be able to work immediately when the new locales and languages are added thanks to the mapping table. 
 Hopefully now things are a bit clearer for you? 
 Mats Linder said: ADDENDUM: I just discovered that there is an exstensive wiki entry on MT codes! I shall read that and maybe afterwards I can take back everything I have written above! 
 Where? We also have a mapping capability for the XLIFF Manager to resolve a similar kind of problem. Is this the one you found?

Trados Studio > 1. Trados Studio

Add different languge combination of SDL language cloud to project with unsupported language pair

Top Replies