Hi Team,
Look and feel of the this platform looks really cool. Looking forward to learn and share .
We are using editable text in fragment using data-lfr-editable-type=“text” and in between editable text we want a translatable text using language override . But once fragment is dropped on the page and we change it from language override it does not take effect and we have to re-drop the fragment on the pages, we have same kind of requirement for almost 100+ pages and re-dropping fragment on all pages is not feasible.
Schengen travel plans starting at just ₹[@liferay.language key="Schengen-travel-plan-start-rate" /]*, You can start now.
Result
Schengen travel plans starting at just ₹403*, You can start now.
Is there a way to handle this value 403 can be changed any time without re dropping the fragment.
A fragment author rarely knows where a fragment is used, so it’s a rather dangerous operation to point-blank update all existing usages of a fragment.
The default for fragments is to not update all of their usages upon change. But within the fragment administration, you have the option to find a fragment’s usages and you’re able to propagate the current vresion to all those places.
There’s also an instance setting to change the default.
With Language-Overrides I’m not so sure, that seems to be static. But the manual propagation of the fragment should at least boil your operation down from 100s to 1. Alternatively, you might want to introduce a custom language key lookup that is purely dynamic. But given the potential frequency of updates vs the expected performance implication, I’ll leave it to you which of the approaches you’ll pick
So I don’t think re-dropping is necessary, I think you’re facing a caching issue. The re-dropping just makes it a new instance and that bypasses the cache showing the new value.
However, I do think you’re abusing the intent of i18n. It’s not intended for you to dynamically set and change prices and have them cascade whenever you need that value. That is not what the i18n support is for.
The i18n stuff has a great deal of caching and other optimizations in place with the idea that keys are re-translated to a different translation rarely if ever, and your attempt to just stuff in new prices is not expected and goes against that structure.
So how do you fix this? You have to do it a different way. Because you are apparently doing this one i18n change and expecting it to cascade across multiple pages, I’d go with a structured web content and a template and drop the web content displays where you need it.
When it comes time, you edit the web content, change the structure value to the new dollar amount, and this will update on all pages that are displaying that web content.