> From: Stephen McConnell [mailto:[EMAIL PROTECTED]] > > > 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: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
