1. Can a Source Publication have multiple Target Publications?
  2. Can a Target Publication have multiple Source Publications?

I think I've seen the first scenario, where Global Content needs to be translated into the same language pair but to separate child Publications. But I'm trying to figure out how to avoid conflicts if the second scenario is possible.

The use case would be for a given Target (e.g. 040 Marketing Content - Spanish for the US), the business wants the ability to translate from either English Publication:

  • 020 Global Content or
  • 030 Marketing Content.

If possible, how (or when) could we copy BluePrinting rules so the closest localized items "win," in case of conflicts (see example below)? For example:

  • During Translation Job creation
  • When Translation Jobs start
  • Or maybe failing individual items?

This is somewhat related to "Multiple languages in a source Publication?" but there I was asking about multiple locations within a given Publication.


As an example, we might have the following:

  • Component "Policies" created in 020 Global Content in English (US)
  • "Policies" localized in 030 Marketing Content in English (US) <-- we only want to permit translations from this Publication
  • "Policies" localized in 040 Marketing Content in Spanish (US)

In this case, with "Policies" localized in 030, the business wants this version to be the shared item in 040. We'd also want to prevent translation jobs started from 020, which I believe would directly update 040, regardless if 030 is localized.

In other words, could we only allow translations from the closest localized parent Publication?

  • Yes, you can have multiple sources - but without any details on the relation ship between the publication it is impossible to say if TM would accept both of them as valid sources in this case. I do not know what you mean with "copy Blueprinting rules". TM relies heavily on the BluePrinting rules (adding it's own to deal with situations CM does not need to care about). So you should not "copy" them, but you do have to design according to them. Commented Dec 4, 2014 at 9:20
  • I'll try to clarify in the question, but the use case is if we've already translated a shared item (e.g. a "Policies" Article) in a 040 Publication from 030, could we prevent translating those items again from 020? "Policies" is created in 020 in English, localized in 030 (also English), and localized in 040 in Spanish. Commented Dec 4, 2014 at 18:14
  • I updated the question with that example. I definitely see how Translation Manager works with and relies on BluePrinting. I think the practical solution for this scenario is to try to translate global content in global translation Publications (this particular BluePrint is missing a separate target for 020). Users can also organize and name their folders and jobs to be clear on where to translate from. Initiating "pull" translations to 040 from the nearest parent would also help here. Commented Dec 4, 2014 at 19:39

1 Answer 1


If 030 Marketing Content does not have any ancestors that are configured for translation you will be able to translate shared items from 020 Global Content by starting a translation job in 030 Marketing Content.

If there are ancestors configured for translation this will not work unless it happens to be the exact same configuration. The items in 020 Global Content will inherit their language from the ancestor configuration, and in order to be send out with the 030 content, it must share the configuration with it. In this case configure 020 the same way as 030. If you then want to restrict translations from 020 make a UI extension or TM plugin that will stop translation actions in 020. The UI extension is probably a bit more work (though if you know how to make them and have never made a Translation Manager plugin it is probably the fastest way). The TM API is most likely changing significantly in the next release, so even though the old API will still work for a few versions (as per standard deprecation policy) I would consider going with the UI plugin - this is how it would have to be done in the new API.

  • Thanks Lars. In terms of matching the configuration, is that the Publication Translation Manager settings like Language, Publications, Default Workflow (for TMS), and Authorization required? Commented Dec 8, 2014 at 17:50
  • 1
    As far as I remember it just needs to be the same TMS configuration/WS project type. Commented Dec 8, 2014 at 21:08
  • Okay, I found the documentation on push and pull that confirm it's the language configuration (ID) for TMS or client/project type for World Server. There are also some nice explanations on resolving items in both scenarios including how Translation Manager views version 2.0 items in a BluePrint. Commented Dec 9, 2014 at 22:52

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.