Separate Content Publications and Translation

Question

I'm exploring the impact of division- or group-specific content Publications in a BluePrint.

For example, we might have:

• 010S Schemas
• 020 Global Content
  • 030 Group 1 Content
  • 030 Group 2 Content
  • 030 Group n Content

Assuming m languages for translation (and disregarding region-specific translation needs), I see two options here:

1. Simple setup with many publications. Each Group needs its own translation publications. This could grow to n content publications x m translation publications.
2. Merge into shared translation publications. All 030 Group publications could potentially "merge" into each translation publication.

The caveats for option 2 as I understand it include:

• Naming conventions required to avoid organizational and item conflicts (i.e. conflicting WebDAV paths).
• Priority settings matter (e.g. Group 1 won't get its localized content translated if it doesn't have publication priority).

Question:

I prefer leading with a single content publication in BluePrint design sessions, but maybe I'm biased as a Tridion user (don't make me jump too much) and I'm fine with setting authorization as needed for different groups.

• Am I missing any pros/cons? Is option 2 practical or "seen in the wild?"
• Have you seen the two scenarios match certain patterns? So far I've seen these specific publications match completely separate groups (separate development and/or geography). But could this be a North American versus European BluePrint distinction or maybe it follows the size or type of an organization?

Answer 1

In my opinion, both the options can be implemented based on specific business requirement - I have practically seen both on them in picture.

The option 2 is viable in case end client want to save on licensing cost (and not willing to understand the increase in cost of development) with many disadvantages - apart from the few that you have mentioned (Naming Convention, Priority Management, Huge Effort in Access Right Setting) there are few other disadvantages as mixing of component is quite possible and can create a mess in content - Those who have implemented first might be efficient to manage, but it would be really difficult for new people joining the project to manage.

Additionally if there is some functionality based on Components (using webdav path and implementing logic based on it) - may sound bad,but never know the client requirement - then it will be hell to implement.

Option 1, I have seen most often and very obvious advantages of simple & easy management and most of the disadvantaged of option 2 are taken care.

Again in my person opinion, I would suggest Option 1 - as we should consider how easy it is for the end user to use and manage.