You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Stephen McConnell <mc...@osm.net> on 2002/06/21 06:22:55 UTC
i18n support in ComponentDescriptor
The metainfo ComponentDescript class contains the name, classname,
implementation version and attributes of a component together with a
display name. I think we need to consider internationalization
requirements for both the displayname element and attribute values. One
approach I could impagine is a reserved leading character in a
displayname or attribute value that is used to distinguish between a
i18n resource key and plain text. For example if the value starts with
#, then an implementation can attempt to resolve the string via the
component's package i18n resource.
Any thoughts?
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: i18n support in ComponentDescriptor
Posted by Peter Donald <pe...@apache.org>.
At 07:11 AM 6/21/2002 +0200, you wrote:
How about
>"avalon:display-name" = display name directly typed in
>"avalon:display-name-i18n" = Display name looked up from resource
>"avalon:description" = description name directly typed in
>"avalon:description-i18n" = description name looked up from resource
>
>And presumably we drop the getDisplayName method from ComponetDescriptor ?
works for me.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: i18n support in ComponentDescriptor
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 06:51 AM 6/21/2002 +0200, you wrote:
>
>> I think that's a good idea.
>> .... and the first formal reserved Avalon attribute key name would be ?
>
>
>
>
> How about
>
> "avalon:display-name" = display name directly typed in
> "avalon:display-name-rk" = Display name looked up from resource
> "avalon:description" = description name directly typed in
> "avalon:description-rk" = description name looked up from resource
How about
"avalon:display-name" = display name directly typed in
"avalon:display-name-i18n" = Display name looked up from resource
"avalon:description" = description name directly typed in
"avalon:description-i18n" = description name looked up from resource
And presumably we drop the getDisplayName method from ComponetDescriptor ?
Steve.
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: ComponentDescriptor attributes
Posted by Peter Donald <pe...@apache.org>.
At 07:13 AM 6/21/2002 +0200, you wrote:
>>No container will be looking up keys it does not know. So the container
>>limits the keys anyways?
>
>
>No sure.
>What about container extensions that leverage attributes?
>(e.g. an interceptor that handles something based on a compoent type
>atttribute)
The container still has to look up the attributes. Whether it is the
container or itself or some extension of the contianer (ie interceptors).
ie If Paul writes a Transaction interceptor for EOB then the container (or
more specifically his interceptor container extension) would look up its
known attribute "eob:transaction"
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
ComponentDescriptor attributes
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
>
> No container will be looking up keys it does not know. So the
> container limits the keys anyways?
No sure.
What about container extensions that leverage attributes?
(e.g. an interceptor that handles something based on a compoent type
atttribute)
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: i18n support in ComponentDescriptor
Posted by Peter Donald <pe...@apache.org>.
At 06:51 AM 6/21/2002 +0200, you wrote:
>I think that's a good idea.
>.... and the first formal reserved Avalon attribute key name would be ?
How about
"avalon:display-name" = display name directly typed in
"avalon:display-name-rk" = Display name looked up from resource
"avalon:description" = description name directly typed in
"avalon:description-rk" = description name looked up from resource
>>As long as that interpretation is restricted to specific "well known"
>>attributes or is considered container specific then I would be fine with that.
>
>Umm, don't like limiting this to well-know attributes. For example, I
>would want to include a description of the component as an i18n resource
>value and I wouldn't like to be restricted on what keys I could use.
No container will be looking up keys it does not know. So the container
limits the keys anyways?
> The alternative is to include a flag in an attribute defintion to
> indicate that the value is an i18n key. The default being FALSE.
Thats the path to the darkside. I could imagine ending up with 50-60
different flags on attributes which are flags on features ;)
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: i18n support in ComponentDescriptor
Posted by Stephen McConnell <mc...@osm.net>.
Peter Donald wrote:
> At 06:22 AM 6/21/2002 +0200, you wrote:
>
>> The metainfo ComponentDescript class contains the name, classname,
>> implementation version and attributes of a component together with a
>> display name. I think we need to consider internationalization
>> requirements for both the displayname element and attribute values.
>
>
> Yep - I forgot about displayname. I planned to add in description as
> an attribute so that it could be i18n'ed. The attribute was then going
> to be keyed in usual fashion. ie Look for attribute
> "description-en_au", then "description-en" and finally "description".
> However I think I prefer your approach where the attribute value is
> key into normal i18n files.
>
> Maybe we should make display name an attribute aswell?
I think that's a good idea.
.... and the first formal reserved Avalon attribute key name would be ?
>
>> One approach I could impagine is a reserved leading character in a
>> displayname or attribute value that is used to distinguish between a
>> i18n resource key and plain text. For example if the value starts
>> with #, then an implementation can attempt to resolve the string via
>> the component's package i18n resource.
>
>
> As long as that interpretation is restricted to specific "well known"
> attributes or is considered container specific then I would be fine
> with that.
Umm, don't like limiting this to well-know attributes. For example, I
would want to include a description of the component as an i18n resource
value and I wouldn't like to be restricted on what keys I could use.
The alternative is to include a flag in an attribute defintion to
indicate that the value is an i18n key. The default being FALSE.
Steve.
>
>
> Cheers,
>
> Peter Donald
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> "Faced with the choice between changing one's mind,
> and proving that there is no need to do so - almost
> everyone gets busy on the proof."
> - John Kenneth Galbraith
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
--
Stephen J. McConnell
OSM SARL
digital products for a global economy
mailto:mcconnell@osm.net
http://www.osm.net
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: i18n support in ComponentDescriptor
Posted by Peter Donald <pe...@apache.org>.
At 06:22 AM 6/21/2002 +0200, you wrote:
>The metainfo ComponentDescript class contains the name, classname,
>implementation version and attributes of a component together with a
>display name. I think we need to consider internationalization
>requirements for both the displayname element and attribute values.
Yep - I forgot about displayname. I planned to add in description as an
attribute so that it could be i18n'ed. The attribute was then going to be
keyed in usual fashion. ie Look for attribute "description-en_au", then
"description-en" and finally "description". However I think I prefer your
approach where the attribute value is key into normal i18n files.
Maybe we should make display name an attribute aswell?
> One approach I could impagine is a reserved leading character in a
> displayname or attribute value that is used to distinguish between a i18n
> resource key and plain text. For example if the value starts with #,
> then an implementation can attempt to resolve the string via the
> component's package i18n resource.
As long as that interpretation is restricted to specific "well known"
attributes or is considered container specific then I would be fine with that.
Cheers,
Peter Donald
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"Faced with the choice between changing one's mind,
and proving that there is no need to do so - almost
everyone gets busy on the proof."
- John Kenneth Galbraith
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: i18n support in ComponentDescriptor
Posted by Berin Loritsch <bl...@apache.org>.
> From: Gonzalo A. Diethelm [mailto:gonzalo.diethelm@aditiva.com]
>
> > (American)
> >
> > <require role="ConnectionManager">
> > <attribute name="policy" value="secure"/>
> > </require>
> >
> > (Spanish)
> > <supply role="Jeffe de Conneccio'n" version="1.0">
> > <attribute name="polici'a" value="seguro"/>
> > </supply>
>
> Nice try... :-) This is probably what you meant:
>
> (Spanish)
> <supply role="Administrador de Conneccio'n" version="1.0">
> <attribute name="poli'tica" value="seguro"/>
> </supply>
Uh, yeah. Spanish is the only other language I really have
any clue about--although I think I would be lucky to be put
on a second grade understanding of it...
I don't use it very often, and since I used to have "Bosses"
the derogetory Jeffe is all that my mind could come up with.
But you get the general idea.
And this illustrates one more issue with i18n.... When more
than one word satisfies a possible solution (i.e. administrator
vs. boss), only a language expert could know what the best
option is. If there are multiple translations for a language
(could you imagine an ebonics locale?) which is the correct
one...
However it is not our job to fix that problem, just to provide
a consistent layer.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: i18n support in ComponentDescriptor
Posted by "Gonzalo A. Diethelm" <go...@aditiva.com>.
> (American)
>
> <require role="ConnectionManager">
> <attribute name="policy" value="secure"/>
> </require>
>
> (Spanish)
> <supply role="Jeffe de Conneccio'n" version="1.0">
> <attribute name="polici'a" value="seguro"/>
> </supply>
Nice try... :-) This is probably what you meant:
(Spanish)
<supply role="Administrador de Conneccio'n" version="1.0">
<attribute name="poli'tica" value="seguro"/>
</supply>
--
Gonzalo A. Diethelm
gonzalo.diethelm@aditiva.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: i18n support in ComponentDescriptor
Posted by Berin Loritsch <bl...@apache.org>.
> From: Stephen McConnell [mailto:mcconnell@osm.net]
>
>
> The metainfo ComponentDescript class contains the name, classname,
> implementation version and attributes of a component together with a
> display name. I think we need to consider internationalization
> requirements for both the displayname element and attribute
> values. One
> approach I could impagine is a reserved leading character in a
> displayname or attribute value that is used to distinguish between a
> i18n resource key and plain text. For example if the value
> starts with
> #, then an implementation can attempt to resolve the string via the
> component's package i18n resource.
>
> Any thoughts?
Anything that is displayed to a user (which includes all humans who
work with a system) *should* be subject to i18n. Built in support
for those things would be very important. However, there are a few
caveats.
1) Anything that the system programatically uses to determine values
and assembly should not be subject to i18n as it increases the
complexity of the system.
2) How is the component specific i18n information going to be stored?
How are we going to allow it to be extended?
3) I18n bundles can get quite large, is this something that can be
distributed separate or allow a third party to provide? Keeping
it out of the distribution jar would be a good thing.
If Attributes are to be i18nalized, then the container needs to be
able to resolve the attributes properly.
For example, 2 components, one implemented by an American, one
implemented by a Spaniard. The American wants an SSL enabled
ConnectionManager. The Spaniard supplies one. The metadata are
exposed like this:
(American)
<require role="ConnectionManager">
<attribute name="policy" value="secure"/>
</require>
(Spanish)
<supply role="Jeffe de Conneccio'n" version="1.0">
<attribute name="polici'a" value="seguro"/>
</supply>
I appologize for my windows box not providing a nice portable
way of typing in the accents.
The XML descriptor language would be really troublesome
to internationalize due to the complexity of outfitting the
ConfigurationBuilder with i18n support.
The container would need to read in all attributes and convert
them to a neutral language--most likely whatever the default
locale is for the server.
There are other issues that may come up such as it may work for
English speaking locales, but not for russian speaking locales.
An example of that would be the bundle specifies the translation
for the attribute values but not the names. In the case above,
the container would never know that the Spanish component supplies
the secure connection that the American component wants. The
same applies if the name is translated but the values are not.
It is a good thing, but the devil is in the details.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>