In addition to fields we can localize item and organizational item names. I see maybe three use cases for localizing names depending on the setup.

  • Templating. If templates use paths or item names (titles), localizing item names show the appropriate translations for child publications
  • Localized Navigation. If navigation relies on structure groups and naming conventions, child publication (local) authors can adjust URLs using localized names
  • Local Authors. Schema and (maybe) template localization can present options in local authors' languages

A major catch is code that relies on Content Manager-side paths (e.g. referencing a template by name) and I probably wouldn't recommend localizing templates without a good process for updates. But I also suspect centralized editorial teams might want to avoid changing folders and item names to better keep track of everything.

I'm not sure what's "typical." Would you recommended item and path localization?

Maybe it depends on the type of item (e.g. maybe not folders, but okay for certain components)?


I'm clarifying the main point of this question and summarizing some of the comments below. The background to this was a question in training that was something like:

Wait, if local content owners localized the names of items or folders, won't it be hard to find things for us?

"Us" would that centralized editorial team supporting local content owners. This simple example that assumes Structure Groups (SGs) drive navigation with naming conventions for prefixes):

Parent Publication SGs

  • 001 Home
  • 002 Products

Child SGs

  • 001 Casa
  • 002 Productos

CM-side requirement: navigate, troubleshoot, and find pages in child publication without knowing the language (specifically "centralized editorial teams" [wanting to] "keep track of everything".

I was thinking that options were exclusively one of two options:

  1. SG names unchanged. SGs only show prefixes and Centralized Editors have control and local translations have to be stored somewhere else (metadata). Folders, SGs, and items only show in a source language (e.g. English for US).
  2. SG names localized. Localized items in the Child publication provide translation values for things like Navigation. Centralized Editors cope by learning other languages or using the BluePrint viewer.

I accepted Miguel's answer which includes both of the above options as well as a way to show both the source and target. Ant adds trade-offs and gotchas with either enforced localization or relying on a specific (and parsed) author-maintained convention (e.g. the brackets in Miguel's example), especially over the life of a CMS. Read the comments for additional perspective.

My take-away is you can present both to show central editors familiar SGs in the same order while still having a spot for the translated versions. But it doesn't have to be a specific convention or approach. GUI extension, automation, or even something handled in managed translation outside Tridion could work.

2 Answers 2


In case of Structure Groups and Folder Structures, there are different ways to do that, and no one is better than other, just depends on what fits into the Users preferences

Case 1: Localize and Translate directly the Folder or SG Name

 001 Home -->  001 Casa 

Case 2: Localize and add translation but still keep the original name in English

 001 Home -->  001 Home [Casa] 

Pros: Your users can maintain the folder structure / SG Structure without knowing the language that has been translated into. (But keep in mind that if you change the parent name, the child won't be changed, but maybe you could think on Event System for maintain that in Synch). For me this is a clear way to maintain same structure across multiple translated websites, however, pretty sure won't fit for all customers.

Case 3: Localize and add translation as Metadata.

 001 Home -->  001 Home   "Casa" is added as Metadata 

Other option but personally I don't like much, as you have to go to properties of the folder, sg to see the translated name, and still folder is localized

  • Nice and thank you, Miguel. Case 2 is a great way to keep a familiar structure (and ordering) while keeping both the original and translated languages in context. I see how case 3 would work with managed translation scenarios but does hide the expected, translated value from local editors. I'll remember to keep naming conventions handy as another tool to handle direct/indirect relationships. :-) Commented May 19, 2014 at 18:13
  • 1
    Even case 2 would work in automatic translation. We should consider just the translation of the words between brackets [] and rename the SG or Folder when comes back from translation getting the English (or main language) name from the parent and adding the translated name (The one that is between [])
    – Miguel
    Commented May 19, 2014 at 18:21
  • Example: Step 1) 020 News is created in the parent Step 2) As is new, we automatic localize and just put the name between brackets 020 News [News] is created in the child Step 3) Item is send for translation and comes back as 020 Noticias [Noticias] Step 4) We ignore everything from the translation except [Noticias], access the parent and get the name 020 News [Noticias] Step 5) Parent is updated, 020 Breaking News we can rebuild the child and transtale again 020 Breaking News [Ultimas Noticias]
    – Miguel
    Commented May 19, 2014 at 18:34

I'd come at this question from a slightly different angle, particularly regarding situations like this...

A major catch is code that relies on Content Manager-side paths (e.g. referencing a template by name)

... and suggest that you shouldn't need naming conventions for these things. In fact, I'd go as far as to expressly avoid it as to me, this screams of complacency with a sub-par implementation.

Whenever I develop anything that will affect - or be affected by - actions in the CME, there are a few key questions that I tend to keep in mind.

1. Can I Localize all involved items safely?

If you can safely localize anything and make changes without affecting the functionality of the feature you're implementing, you don't have a problem. This step, of course, includes asking whether you can adjust the implementation so you can safely Localize items.

2. Can I provide a "production-ready" fallback for breaking content changes?

If you find a scenario where localizing and modifying an item in a certain way will break something, evaluate whether or not you can live with it being broken. If it's not a critical failure or - better still - you can provide an acceptable (i.e. acceptable in production) fallback, you probably don't have much to worry about.

This is also where I would begin to consider some less obtrusive conventions, such as, "the footer will be Published to the path xyz, or we'll revert to a pre-configured default," rather than, for example, "the path of the footer in the CME must be *xyz."

You can also mitigate a lot of risk here by moving bits of configuration into places like Publication metadata, where you know the client is less likely (or perhaps even not able) to make breaking changes - safe in the knowledge that even if they do, it won't be a disaster.

3. Will the failure be CM-side (e.g. Publish failures) or CD-side (e.g. missing content)?

If it's the former, then it's not the end of the world. If it's the latter (and you've already been via 2), you have a problem.

This is when you need to either look at an entirely fresh approach to the problem or you need to have some very clear discussions with your client about the fact that they should definitely not touch this, ever.

I would still avoid defining conventions for this sort of thing, though, because you shouldn't anticipate getting into this situation often enough that a convention is worthwhile (and if you do, naming conventions won't save you).

Edit: So, to address your requirement directly:

"Wait, if local content owners localized the names of items or folders, won't it be hard to find things for us?"

My recommendation would be to allow your editors the freedom to define their own conventions, that allow them to manage (and find) their content in whatever way is most appropriate for their own use case (by all means assist them in defining these conventions, but don't enforce them as they may not always be appropriate), which links back to 1 - ensure that the items can be safely localized and have their paths and item names manipulated in any way the client sees fit. This, as you say, will typically involve delegating the responsibility of managing any information required for functionality to things like metadata.

  • I agree with side-effect free approaches and also recommend good defaults and fall-backs. Localizing a folder or structure group doesn't necessarily "screams of complacency with a sub-par implementation" to me. The two familiar use cases would be CM-side paths for navigation or delivery-side image paths. Basically, if using structure groups for navigation, how do you handle any translation requirements? Commented May 20, 2014 at 8:05
  • I'm not saying that localizing a folder or structure group screams complacency with a sub-par implementation; I'm saying that not being able to localize as you please and needing to define conventions to get around it does. If it's a matter of having to localize structure groups to name them for navigation but editorial teams not wanting to change the structure group names, then that is a requirement that needs to be isolated and can be solved using Metadata for the navigation titles as Miguel suggests.
    – Ant P
    Commented May 20, 2014 at 8:11
  • Bundling stuff into the name and using string manipulation to get at the translations is flaky.
    – Ant P
    Commented May 20, 2014 at 8:12
  • 'flaky' isn't the most descriptive term. Perhaps you'd do better to say something specific and accurate. Commented May 20, 2014 at 11:24
  • 1
    @DominicCronin The difference here is that we're not "asking editors to rely on the ability of programmers to write code that copes with their input," we're doing the very opposite; asking programmers to rely on the ability of editors to write input that copes with their code. The difficulty in parsing square brackets out of item names isn't a technical one; it's that it is restrictive (for editors), prone to error, usually unintuitive and as a system develops in size and maturity (and as users - and developers - come and go) is likely to become increasingly obscure and difficult to manage...
    – Ant P
    Commented May 20, 2014 at 22:05

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.