Hi I wonder, whether we should not actually radically change the data structure: Move away from the fine grained content and back to File blobs in Properties or maybe JSON format ?
Currently the i18n bundle reads all translation entries for the request language in bulk anyway (it used to be read on-demand, but that is way back). Since this is a radical approach, we can have both approaches sit side by side and support both. If the new one is used, performance might be better. If the old one is still use, it still works. 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. Regards Felix Am 18.12.2013 um 18:35 schrieb Tobias Bocanegra <[email protected]>: > I don't think that the migration is straight forward. the way the > provider currently works, it would allow message definitions like: > > /content/de [mix:language] > /very/deep/structure/ > /hello [sling:Message] > + sling:message "Hallo." > > i.e. the messages and be deliberately distributed over the content, > where needed. we don't know how i18 support is used in general. > Adobe's Granite and CQ (and probably most of they customers) use full > subtree dictionaries like the example in [1]. > > otoh, applications that use compact dicts probably don't have many. > and adding a new sling:Dictionary mixin to those 5-10 nodes is no big > effort. > Regards, Toby > > > > On Tue, Dec 17, 2013 at 11:12 PM, Carsten Ziegeler <[email protected]> > wrote: >> The bundle can either set a marker in the repository or a file in the >> bundle private date; the repository is the better place as this can be used >> in a clustered installation to avoid duplicate or concurrent migration >> >> Carsten >> >> >> 2013/12/18 Alexander Klimetschek <[email protected]> >> >>> On 17.12.2013, at 22:03, Carsten Ziegeler <[email protected]> wrote: >>> >>>> What about if we add the migration code to the bundle? >>> >>> Hmm, interesting :) Not sure though if we should modify content from such >>> a bundle. And how do we know that we already did the migration and don't >>> run the migration code over and over again on startup (which would do the >>> same slower query and thus not really gain performance)? >>> >>> Cheers, >>> Alex >> >> >> >> >> -- >> Carsten Ziegeler >> [email protected]
