Hi Dieter!
Dieter Maurer wrote:
If would be nice if the message catalog translating
CMFCore term were independent from the (probably much larger)
CMFDefault catalog. Especially, we would like to continue to deploy
our application without a need to include the CMFDefault product.
If this does n
yuppie wrote at 2005-8-11 09:36 +0200:
> ...
>> Can we give "CMFCore" its own domain?
>>
>> We would like to use "CMFCore" without any reference to
>> "CMFDefault".
>>
>
>Are you concerned about imports from CMFDefault or do you see a need to
>ship CMFCore with its own translations?
We build ap
yuppie wrote:
Can we give "CMFCore" its own domain?
We would like to use "CMFCore" without any reference to
"CMFDefault".
Frankly I hate domains. The less domains there are, the better.
Myself, I'd much rather have a single "cmf" domain for everything in
CMF. Let addon frameworks like Plone
Jens Vagelpohl wrote:
Does that mean you are voting against using 'cmf_calendar' in
CMFCalendar?
The reason why I'd like to use a different domain for CMFCalendar is
that CMFCalendar is our example add-on product. This way we *use*
different domains for Actions and TypeInfos within the CMF
Does that mean you are voting against using 'cmf_calendar' in
CMFCalendar?
The reason why I'd like to use a different domain for CMFCalendar
is that CMFCalendar is our example add-on product. This way we
*use* different domains for Actions and TypeInfos within the CMF,
showing how to do t
Florent Guillaume wrote:
Dieter Maurer wrote:
yuppie wrote at 2005-8-9 19:11 +0200:
...
2.) Using different domains for different products:
While 'cmf_default' should be used by the core products (CMFCore,
CMFDefault, CMFTopic, CMFSetup) I'd like to use 'cmf_calendar' for
CMFCalendar.
Dieter Maurer wrote:
yuppie wrote at 2005-8-9 19:11 +0200:
...
2.) Using different domains for different products:
While 'cmf_default' should be used by the core products (CMFCore,
CMFDefault, CMFTopic, CMFSetup) I'd like to use 'cmf_calendar' for
CMFCalendar.
Can we give "CMFCore" its ow
On 11 Aug 2005, at 09:33, yuppie wrote:
For importing/exporting domain settings we have to extend CMFSetup
and need new properties in the ZODB. Thinking a bit more about this
we might have some trouble to write XML files containing i18n
attributes. Is there an easy way to tell PageTemplateFi
Hi Dieter!
Dieter Maurer wrote:
yuppie wrote at 2005-8-9 19:11 +0200:
...
2.) Using different domains for different products:
While 'cmf_default' should be used by the core products (CMFCore,
CMFDefault, CMFTopic, CMFSetup) I'd like to use 'cmf_calendar' for
CMFCalendar.
Can we give "CM
Hi Florent!
Florent Guillaume wrote:
yuppie wrote:
4.) Adding i18n support for settings loaded from profiles:
This is the most difficult part and so far I just have some ideas.
One issue is extracting message strings. I hope to find a way to use
the i18n namespace in profile XML files. Th
Hi Yuppie,
yuppie wrote:
Zope 2.8.1 with Five 1.1 and Zope 2.9 will come with integrated i18n
support. Localizer / PTS are no longer needed.
CMF currently has limited i18n support and describes in INSTALL.txt how
to use it with Localizer and TranslationService.
I propose the following chan
Raphael Ritz wrote:
yuppie wrote:
Just one minor question out of curiosity:
i18nextract.py is quite zope3 specific, but with some modifications it
seems to work quite well for CMF. I'd like to add a modified
i18nextract.py to the root of the CMF repository.
How about making the original i1
Jens Vagelpohl wrote:
I'd like to work at least on the first 3 items for CMF 1.6. AFAICS
this should not break anything on Zope 2.8.0. But maybe we should
anyway make Zope 2.8.1 the required platform for CMF 1.6.
Making Zope 2.8.1 the required platform for CMF 1.6 is fine IMHO, I
believe
yuppie wrote:
Hi!
Hi Yuppie,
+1 from me all the way!
Just one minor question out of curiosity:
i18nextract.py is quite zope3 specific, but with some modifications it
seems to work quite well for CMF. I'd like to add a modified
i18nextract.py to the root of the CMF repository.
How about m
14 matches
Mail list logo