You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Bruno Dumon <br...@outerthought.org> on 2003/02/12 15:13:14 UTC
Extending I18nTransformer to support multiple resource bundles
Hi,
we are looking at extending the I18nTransformer so that it can use
multiple resource bundles at the same time. Thus, when it looks up a
key, it should check multiple different bundles for this key.
Our idea is to simply pass multiple bundle names/locations to the
I18nTransformer, and it would check them one by one until the value is
found.
A possible alternative would be that the bundle to be used is specified
explicitely when retrieving the key, e.g.
<i18n:text bundle="mybundle">key</i18n:text>
(and we'd also need a syntax for attributes)
Thoughts?
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Extending I18nTransformer to support multiple resource bundles
Posted by Bruno Dumon <br...@outerthought.org>.
On Fri, 2003-02-14 at 10:44, Konstantin Piroumian wrote:
[...]
> Another idea that came to me is that we could implement import/include for
> the dictionary files themselves. So the users could combine the
> dictionaries.
We've been thinking about that, but preferred the explicit referencing
of catalogues because then the catalogues are centrally managed, which
makes it more transparent from an administration point-of-view.
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Extending I18nTransformer to support multiple resource bundles
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Bruno Dumon" <br...@outerthought.org>
> On Thu, 2003-02-13 at 12:53, Konstantin Piroumian wrote:
> > From: "Bruno Dumon" <br...@outerthought.org>
> [...]
> > > > or maybe use namespaces:
> > > > <input name="Submit" value="dynamic" i18n:attr="mybundle:name
> > > other:value">?
> > >
> > > I think this will cause confusion with namespaced attributes.
> > > How about this:
> > > <input name="mybundle:Submit" value="other:dynamic" i18n:attr="name
> > > value">
> >
> > Don't forget that if value is not found then the key is displayed by
default
> > (if not configured other 'untranslated' message). So it would display
> > mybundle:Submit which can be confusing for users (even it is not a good
way
> > to use as default values).
>
> Maybe we can just remove the catalogue prefix (mybundle:) in that case?
> we'll need to parse that value anyhow.
Ok.
>
> >
> > >
> > > (this approach assumes one's not using colons in i18n key names)
> > >
> > > Now about the configuration, here's what I propose:
> > >
> > > for the component-level configuration, something like this:
> > >
> > > <map:transformer name="i18n" src="...">
> > > <catalogues default="cat1">
> > > <catalogue name="cat1">
> > > <name>...</name>
> > > <location>...</location>
> > > </catalogue>
> > > <catalogue name="cat2">
> > > <name>...</name>
> > > <location>...</location>
> > > </catalogue>
> > > </catalogues>
> > > </map:transformer>
> >
> > Why have two 'name's: one as an attribute, the second one as an element?
>
> It's a logical name, so that the catalogue filename is not directly used
> in the instance documents.
>
> > What about 'id'? (It is common for JSP to use 'id' in similar cases).
>
> id is a better name indeed.
>
> > And
> > also I'd make it as single line:
> >
> > <catalogue id="cat1" name="messages" location="translations" />
>
> yep
>
> >
> > and the default one can have no id:
> >
> > <catalogue name="default" location="translations" />
>
> But if the catalogue has no id, it is impossible to refer to it (which
> can be required if a certain i18n transformer instance uses another
> catalogue as the default).
>
> So I would make the configuration as follows:
> <catalogues default="cat1">
> <catalogue id="cat1" name="..." location="..." />
> <catalogue id="cat2" name="..." location="..." />
> </catalogues>
Agreed.
>
> [...]
> > > On the component instance level, I thought of only allowing to
override
> > > the default bundle (and not specifying additional bundles):
> >
> > Not sure about this one, but it's the same as the old behavior, so
should be
> > Ok.
>
> I meant here specifying another catalogue id as the default catalogue,
> such as
>
> <map:transform type="i18n">
> <map:parameter name="default-catalogue-id" value="cat2"/>
> </map:transform>
>
> >
> >
> > >
> > > <map:transform type="i18n">
> > > <map:parameter name="default-catalogue" value="cat2"/>
> > > </map:transform>
> >
> > Why not use the old syntax? E.g.:
> >
> > <map:parameter name="catalogue-name" value="menu"/>
> >
> > Don't think that it'd be much confusing, but will preserve a little
backward
> > compatibility.
>
> But will the value ("menu") in this case refer to the id or the name of
> a catalogue?
>
> What I would do is:
> (1) if the old syntax is used (i.e. there are parameters called
> 'catalogue-name' and 'catalogue-location'), then use that catalogue as
> the default
> (2) if there is parameter 'default-catalogue-id', then use that
> catalogue as the default
> (3) if both are used at the same time, go for (1) but log a warning
> (4) otherwise use the default one specified in the component
> configuration
>
> Likewise, for the component configuration:
> (1) if the old syntax is used (i.e. there are elements called
> 'catalogue-name' and 'catalogue-location'), then use those (thus then
> there will be only one catalogue)
> (2) if the new syntax is used (thus when there is a catalogues
> element), use that.
> (3) if both are used at the same time, go for (1) but log a warning
Also Ok with me.
Another idea that came to me is that we could implement import/include for
the dictionary files themselves. So the users could combine the
dictionaries. If you think that it'd be a good idea then we can discuss the
syntax. It can be similar to the XSLT syntax, I think.
Konstantin
>
> --
> Bruno Dumon http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Extending I18nTransformer to support multiple resource bundles
Posted by Bruno Dumon <br...@outerthought.org>.
On Thu, 2003-02-13 at 12:53, Konstantin Piroumian wrote:
> From: "Bruno Dumon" <br...@outerthought.org>
[...]
> > > or maybe use namespaces:
> > > <input name="Submit" value="dynamic" i18n:attr="mybundle:name
> > other:value">?
> >
> > I think this will cause confusion with namespaced attributes.
> > How about this:
> > <input name="mybundle:Submit" value="other:dynamic" i18n:attr="name
> > value">
>
> Don't forget that if value is not found then the key is displayed by default
> (if not configured other 'untranslated' message). So it would display
> mybundle:Submit which can be confusing for users (even it is not a good way
> to use as default values).
Maybe we can just remove the catalogue prefix (mybundle:) in that case?
we'll need to parse that value anyhow.
>
> >
> > (this approach assumes one's not using colons in i18n key names)
> >
> > Now about the configuration, here's what I propose:
> >
> > for the component-level configuration, something like this:
> >
> > <map:transformer name="i18n" src="...">
> > <catalogues default="cat1">
> > <catalogue name="cat1">
> > <name>...</name>
> > <location>...</location>
> > </catalogue>
> > <catalogue name="cat2">
> > <name>...</name>
> > <location>...</location>
> > </catalogue>
> > </catalogues>
> > </map:transformer>
>
> Why have two 'name's: one as an attribute, the second one as an element?
It's a logical name, so that the catalogue filename is not directly used
in the instance documents.
> What about 'id'? (It is common for JSP to use 'id' in similar cases).
id is a better name indeed.
> And
> also I'd make it as single line:
>
> <catalogue id="cat1" name="messages" location="translations" />
yep
>
> and the default one can have no id:
>
> <catalogue name="default" location="translations" />
But if the catalogue has no id, it is impossible to refer to it (which
can be required if a certain i18n transformer instance uses another
catalogue as the default).
So I would make the configuration as follows:
<catalogues default="cat1">
<catalogue id="cat1" name="..." location="..." />
<catalogue id="cat2" name="..." location="..." />
</catalogues>
[...]
> > On the component instance level, I thought of only allowing to override
> > the default bundle (and not specifying additional bundles):
>
> Not sure about this one, but it's the same as the old behavior, so should be
> Ok.
I meant here specifying another catalogue id as the default catalogue,
such as
<map:transform type="i18n">
<map:parameter name="default-catalogue-id" value="cat2"/>
</map:transform>
>
>
> >
> > <map:transform type="i18n">
> > <map:parameter name="default-catalogue" value="cat2"/>
> > </map:transform>
>
> Why not use the old syntax? E.g.:
>
> <map:parameter name="catalogue-name" value="menu"/>
>
> Don't think that it'd be much confusing, but will preserve a little backward
> compatibility.
But will the value ("menu") in this case refer to the id or the name of
a catalogue?
What I would do is:
(1) if the old syntax is used (i.e. there are parameters called
'catalogue-name' and 'catalogue-location'), then use that catalogue as
the default
(2) if there is parameter 'default-catalogue-id', then use that
catalogue as the default
(3) if both are used at the same time, go for (1) but log a warning
(4) otherwise use the default one specified in the component
configuration
Likewise, for the component configuration:
(1) if the old syntax is used (i.e. there are elements called
'catalogue-name' and 'catalogue-location'), then use those (thus then
there will be only one catalogue)
(2) if the new syntax is used (thus when there is a catalogues
element), use that.
(3) if both are used at the same time, go for (1) but log a warning
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Extending I18nTransformer to support multiple resource bundles
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Bruno Dumon" <br...@outerthought.org>
> On Wed, 2003-02-12 at 16:15, Konstantin Piroumian wrote:
> [...]
> > > Our idea is to simply pass multiple bundle names/locations to the
> > > I18nTransformer, and it would check them one by one until the value is
> > > found.
> > >
> > > A possible alternative would be that the bundle to be used is
specified
> > > explicitely when retrieving the key, e.g.
> > > <i18n:text bundle="mybundle">key</i18n:text>
> > > (and we'd also need a syntax for attributes)
> >
> > Both possibilities would be fine.
>
> We'll go with the second one (mentioning the bundle explicitely).
Fine!
>
> > As for the attributes syntax what about this:
> > <input name="Submit" i18n:attr="name" i18n:bundle="mybundle">. This will
> > limit to a single bundle,
>
> Seems fine for me.
>
> > or maybe use namespaces:
> > <input name="Submit" value="dynamic" i18n:attr="mybundle:name
> other:value">?
>
> I think this will cause confusion with namespaced attributes.
> How about this:
> <input name="mybundle:Submit" value="other:dynamic" i18n:attr="name
> value">
Don't forget that if value is not found then the key is displayed by default
(if not configured other 'untranslated' message). So it would display
mybundle:Submit which can be confusing for users (even it is not a good way
to use as default values).
>
> (this approach assumes one's not using colons in i18n key names)
>
> Now about the configuration, here's what I propose:
>
> for the component-level configuration, something like this:
>
> <map:transformer name="i18n" src="...">
> <catalogues default="cat1">
> <catalogue name="cat1">
> <name>...</name>
> <location>...</location>
> </catalogue>
> <catalogue name="cat2">
> <name>...</name>
> <location>...</location>
> </catalogue>
> </catalogues>
> </map:transformer>
Why have two 'name's: one as an attribute, the second one as an element?
What about 'id'? (It is common for JSP to use 'id' in similar cases). And
also I'd make it as single line:
<catalogue id="cat1" name="messages" location="translations" />
and the default one can have no id:
<catalogue name="default" location="translations" />
>
> The default catalogue would be used if the catalogue is not explicitely
> mentioned. The name attribute on the catalogue tag is the name that
> would be used on the i18n tags:
> <i18n:text catalogue="cat2">...</i18n:text>
Ok.
>
> On the component instance level, I thought of only allowing to override
> the default bundle (and not specifying additional bundles):
Not sure about this one, but it's the same as the old behavior, so should be
Ok.
>
> <map:transform type="i18n">
> <map:parameter name="default-catalogue" value="cat2"/>
> </map:transform>
Why not use the old syntax? E.g.:
<map:parameter name="catalogue-name" value="menu"/>
Don't think that it'd be much confusing, but will preserve a little backward
compatibility.
>
> All this will cause some backward-incompatible changes (though maybe it
> would be possible to support the old-style and new-style configuration
> concurrently).
It would be also fine.
Konstantin
>
> --
> Bruno Dumon http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Extending I18nTransformer to support multiple resource bundles
Posted by Bruno Dumon <br...@outerthought.org>.
On Wed, 2003-02-12 at 16:15, Konstantin Piroumian wrote:
[...]
> > Our idea is to simply pass multiple bundle names/locations to the
> > I18nTransformer, and it would check them one by one until the value is
> > found.
> >
> > A possible alternative would be that the bundle to be used is specified
> > explicitely when retrieving the key, e.g.
> > <i18n:text bundle="mybundle">key</i18n:text>
> > (and we'd also need a syntax for attributes)
>
> Both possibilities would be fine.
We'll go with the second one (mentioning the bundle explicitely).
> As for the attributes syntax what about this:
> <input name="Submit" i18n:attr="name" i18n:bundle="mybundle">. This will
> limit to a single bundle,
Seems fine for me.
> or maybe use namespaces:
> <input name="Submit" value="dynamic" i18n:attr="mybundle:name
other:value">?
I think this will cause confusion with namespaced attributes.
How about this:
<input name="mybundle:Submit" value="other:dynamic" i18n:attr="name
value">
(this approach assumes one's not using colons in i18n key names)
Now about the configuration, here's what I propose:
for the component-level configuration, something like this:
<map:transformer name="i18n" src="...">
<catalogues default="cat1">
<catalogue name="cat1">
<name>...</name>
<location>...</location>
</catalogue>
<catalogue name="cat2">
<name>...</name>
<location>...</location>
</catalogue>
</catalogues>
</map:transformer>
The default catalogue would be used if the catalogue is not explicitely
mentioned. The name attribute on the catalogue tag is the name that
would be used on the i18n tags:
<i18n:text catalogue="cat2">...</i18n:text>
On the component instance level, I thought of only allowing to override
the default bundle (and not specifying additional bundles):
<map:transform type="i18n">
<map:parameter name="default-catalogue" value="cat2"/>
</map:transform>
All this will cause some backward-incompatible changes (though maybe it
would be possible to support the old-style and new-style configuration
concurrently).
--
Bruno Dumon http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
bruno@outerthought.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Extending I18nTransformer to support multiple resource bundles
Posted by Konstantin Piroumian <kp...@apache.org>.
From: "Bruno Dumon" <br...@outerthought.org>
> Hi,
>
> we are looking at extending the I18nTransformer so that it can use
> multiple resource bundles at the same time. Thus, when it looks up a
> key, it should check multiple different bundles for this key.
Great!
This was for a very long time in the i18n ToDo list.
>
> Our idea is to simply pass multiple bundle names/locations to the
> I18nTransformer, and it would check them one by one until the value is
> found.
>
> A possible alternative would be that the bundle to be used is specified
> explicitely when retrieving the key, e.g.
> <i18n:text bundle="mybundle">key</i18n:text>
> (and we'd also need a syntax for attributes)
Both possibilities would be fine.
As for the attributes syntax what about this:
<input name="Submit" i18n:attr="name" i18n:bundle="mybundle">. This will
limit to a single bundle, or maybe use namespaces:
<input name="Submit" value="dynamic" i18n:attr="mybundle:name other:value">?
>
> Thoughts?
Above ;)
Konstantin
>
> --
> Bruno Dumon http://outerthought.org/
> Outerthought - Open Source, Java & XML Competence Support Center
> bruno@outerthought.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org