From: "Bruno Dumon" <[EMAIL PROTECTED]>
> 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.
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
> [EMAIL PROTECTED]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, email: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
