• State Not Answered
  • Replies 3 replies
  • Subscribers 139 subscribers
  • Views 836 views
  • Users 0 members are here
Options
Related

Importing a Second Language (Spanish) Card into SDL.

Keith Woolliscroft

We are currently trying to import English and Spanish content, for one of our products, into our SDL repository. The Spanish content does not need to be translated.

We can import the English content, as we have done in the past, using SDL's Content Importer tool. However, we understand it is not possible to create the required Spanish "cards", and hence import the data, using Content Importer. We have therefore been seeking alternative options.

After a meeting with one of our contacts at SDL we were lead to believe that the only option was to use a combination of the TranslationManagement and TranslationJob API classes. This is far from an ideal solution for us as we have had no prior use for these classes and hence have not yet implemented them.

We therefore decided to look at the DocumentObj 2.5 Create endpoint to see if that would work for us.

We had some success with this and was able to create a Spanish "card" but with what seems like a possible issue. It only succeeded after Translation Management was manually turned off for the relevant topic. This raises a number of important questions.

Is it possible to turn Translation Management off in the Create request?

If the answer to the above question is "No" does that mean it can only been done by using the TranslationManagement API class? This would in effect leave us having to create the Spanish "cards" by implementing and using the TranslationManagement and TranslationJob API classes.
Rate translation
×
Suggest better translation
×
Parents
  • 0

    Just confirming 's answer...

    Either you expect Translation Management within an object (GUID) to be handled by the system. This means that upon release of the source language, translation target stubs are created by Translation Management. Also upon unrelease of the source language, the stubs are removed, and much more scenarios.

    Or you handle it without Translation Management. Turning off the boolean FNOTRANSLATIONMGMT toggles that feature per logical object. Typically images do not have Translation Management on, while xml content does. So in your scenario, do an Update/SetMetadata call, then a Create call as described in the earlier comments.

    Another route is to leave Translation Management on, add Spanish as requested language, release your English important content. Translation Management will generate Spanish target language stubs, which you can simply overwrite with your legacy content using an Update call. I believe that Content Importer can even do your Spanish import (given that GUIDs, <?ish processing instructions, etc are set correctly).

    -Dave
Reply
  • 0

    Just confirming 's answer...

    Either you expect Translation Management within an object (GUID) to be handled by the system. This means that upon release of the source language, translation target stubs are created by Translation Management. Also upon unrelease of the source language, the stubs are removed, and much more scenarios.

    Or you handle it without Translation Management. Turning off the boolean FNOTRANSLATIONMGMT toggles that feature per logical object. Typically images do not have Translation Management on, while xml content does. So in your scenario, do an Update/SetMetadata call, then a Create call as described in the earlier comments.

    Another route is to leave Translation Management on, add Spanish as requested language, release your English important content. Translation Management will generate Spanish target language stubs, which you can simply overwrite with your legacy content using an Update call. I believe that Content Importer can even do your Spanish import (given that GUIDs, <?ish processing instructions, etc are set correctly).

    -Dave
Children
No Data