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
- 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:
- 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).
- 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.