Open jaandrews opened 1 year ago
Yes, the current approach I'd recommend to use would be what you have in your second example (but without the square brackets, that doesn't look to be needed and clashes with the syntax for the "magic string" for a field on the current page).
There's a note in the docs about magic strings in the rich text field here.
I'm not sure the dictionary is really the best place for big blocks of formatted content. As you say, there's a character limit, but I'd also suggest the UI isn't really intended for that. Nor is it really appropriate/editor friendly for editing of mark-up.
I'll keep this open as a as "directly supporting variants" would indeed be a nice, albeit fairly large, feature to add to the product.
In the meantime I think the best way is to use the dictionary for smaller, non-formatted phrases. And construct them using the new HTML field type as you outlined above.
@AndyButland I have the same problem. The client wishes to have a popup with a lot of text when a user clicks a radio button, and then also has to be multiLanguage. I have been using dictionary, but came up against the 1000 character limit. I could create a content item, however how would I link that to settings on a Umbraco form field?
Currently, umbraco forms can support multiple languages by using dictionary values via magic strings. There are a couple issues with how this works for the "rich text" field though.
Dictionary can't completely overwrite content. Using the current setup, entering [#example] would result in "\<p>{content from example dictionary}\</p>." If markup is in the dictionary item, it can lead to broken markup. This can be worked around by chopping up the content into multiple dictionaries, but this isn't ideal. Instead of
I have to do something like
which is trickier to manage.
Umbraco dictionaries only allow 1000 characters, which is a problem if the content includes markup that will quickly push up the character count.
The preferable solution would be to directly support variants with umbraco forms instead of relying dictionaries, avoiding both of these problems. A stopgap solution could be to add another textfield setting to set the magic string block without wrapping it in a "p" tag. This will still have issues with the 1000 character limit though, which can't be resolved without changes to the umbraco core.