Hi,
On Fri, Dec 20, 2013 at 1:27 AM, Felix Meschberger <[email protected]> wrote:
> 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 ?
that would certainly be a good option that also helps reducing the
overhead we have today managing/installing/deploying large
dictionaries.
so something like:
/en.json [sling:Dictionary, nt:file]
/jcr:content ....
or better
/en.json [nt:file]
/jcr:content [nt:resource, sling:DictionaryResource]
- sling:language
- jcr:data
or
/en [sling:DictionaryFolder, sling:Folder]
/dict1.json [nt:file]
/dict2.json [nt:file]
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.
> 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.
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?
> 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
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.
thanks.
regards, toby
>
> 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]
>
