On 20.12.2013, at 10:08, Tobias Bocanegra <[email protected]> wrote: > however, there are currently tools and UIs developed on top of the > existing content based solution which assume the fine grained storage. > so changing the structure would also impact those.
Yes, having written a few of those tools (all propietary) I can say that this would require a lot of changes in that area. For example, we use jcr filevault (which was just recently open sourced at Jackrabbit) and use that to bring in our translations, that come through xliff files from the translators, and merge the vault xml files with the updates from the xliff files. It's not impossible to adapt them, but it is considerable effort. > So this would be a new resource bundle provider - and over time, we > can disabled / remove the old one. or would you make the existing one > support the new storage model? A new one sounds better IMO. > >> Then we can offer a web console plugin (which might be a good idea anyway >> to, for example, show what language we have, etc.) to ask the bundle migrate >> the old structure to the new structure. > > If we use a JSON for the new storage model, it should be as easy as to > request /libs/i18n/en.2.json Note that there is a difference between a single dictionary at some location and the JcrResourceBundle which merges all of them into a single big view. > In any case, my proposed patch in SLING-2881 at least solves the > overly frequent flushing of the resource bundle cache for the current > storage model. it would be good if a sling committer could look at it. Right, this should be fixed separately from any further solution that requires content migrations. Cheers, Alex
