Hi

Am 19.12.2013 um 00:10 schrieb Carsten Ziegeler <cziege...@apache.org>:

> shop=ship

>From a deployer's point of view "shop" makes a lot of sense, actually.

Regards
Felix

> 
> 
> 2013/12/19 Carsten Ziegeler <cziege...@apache.org>
> 
>> Ok, but I don't want to shop a new i18n implementation which is
>> incompatible and would require manual changes to the content before it can
>> be installed.
>> So either, it automatically updates content or is able to detect which
>> format is used and acts accordingly.
>> 
>> Carsten
>> 
>> 
>> 2013/12/19 Tobias Bocanegra <tri...@apache.org>
>> 
>>> 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 <cziege...@apache.org>
>>> 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 <aklim...@adobe.com>
>>>> 
>>>>> On 17.12.2013, at 22:03, Carsten Ziegeler <cziege...@apache.org>
>>> 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
>>>> cziege...@apache.org
>>> 
>> 
>> 
>> 
>> --
>> Carsten Ziegeler
>> cziege...@apache.org
>> 
> 
> 
> 
> -- 
> Carsten Ziegeler
> cziege...@apache.org

Reply via email to