cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Konstantin Piroumian" <kpiroum...@apache.org>
Subject Re: Extending I18nTransformer to support multiple resource bundles
Date Thu, 13 Feb 2003 11:53:56 GMT
From: "Bruno Dumon" <bruno@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


Mime
View raw message