I just upgraded a v13 project to v17. Almost every document type, group, tab, property label and property description were localized using the #DictionaryKey syntax, which – apparently – doesn’t work the same way in v17, I’ve discovered.
I’m now looking at a mess of #ContentTab, #MetaTab, #PageHeader etc. in all my Content - I’m sure you can imagine it…
Digging through the docs I can see that I should be able to use localization by wrapping the labels in UFM - e.g. {#MetaTab}, but that doesn’t work either - because now we’re supposed to provide all these labels in YABE (“Yet Another Backoffice Extension”).
I don’t believe I can be the first to discover this, so would love to hear if anyone knows if there was something I could have done before migrating the content, or if there’s an easy way to get all of my Dictionary Items converted in some way (yes, I can export them one by one, or if they’re nested, the whole group at once and then convert them from the simple XML to the required JSON format).
Do I also really have to then go through every single label and wrap it in curly-braces?
Update:
Yep - unless someone has a neat trick up their sleeve (you’re already thinking of getting AI to do it, right?), It looks like I’m going to have to go through every property label and -description, along with tabs, groups, block-element and settings-element names and update them, since they seem to have to be in the format of an area and key ( {#area_key}). That, and that whole “convert all dictionary keys to a JavaScript export” thing.
Update 2:
I am actually not against the decision to do these UI localizations this way - those labels probably “belong” more to the code than the content. What I can’t believe is that anyone thought this was the way to handle it in a migration - the Backoffice looks ridiculous to the editors and there’s no quick way of fixing it. Even if I decide to just ditch the localizations, I still have to go through every single label and type something sensible instead of the key that’s in there now.
