Naming Conventions for Localized Items?

Question

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)?

Edit

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.

Answer 1

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

Answer 2

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.