On Thu, 2003-02-13 at 12:53, Konstantin Piroumian wrote:
> From: "Bruno Dumon" <[EMAIL PROTECTED]>
[...]
> > > 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
[EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
