search

osgi / bugzilla-archive

Archive of OSGi Alliance Specification Bugzilla bugs. The Specification Bugzilla system was decommissioned with the move to GitHub. The issues in this repository are imported from the Specification Bugzilla system for archival purposes.
0 stars 1 forks source link

[rfc 176][DS] Localization of information in component's configuration #1323

Closed bjhargrave closed 13 years ago

bjhargrave commented 15 years ago

Original bug ID: BZ#1424 From: Simon Archer <sarcher@us.ibm.com> Reported version: R4 V4.2

bjhargrave commented 15 years ago

Comment author: Simon Archer <sarcher@us.ibm.com>

There seems to be no way to externalize and translate string values, such as those of a , in a DS component's XML document. It would appear that the SCR should make use of the Bundle-Localization manifest header to find translated property files. Ideally it should also be possible to translate:

I cannot think of any other element/attribute that has a value that would require translating.

bjhargrave commented 15 years ago

Comment author: @bjhargrave

CPEG call: Discussed the possibility of looking for property files () using the default locale information as file name suffixes as per section 3.10 of the spec. Also discussed possible overloading ComponentFactory.newInstance to take a locale to be used when searching for property files () for the created component instance.

However, we did not find it interesting to use %key localization keys like in section 3.10.2 of the spec for information in the component description XML (e.g. ). If information needs to be localized, it should be moved to property files.

bjhargrave commented 15 years ago

Comment author: Simon Archer <sarcher@us.ibm.com>

Thanks BJ, that's good to hear. But I'm curious why the CPEG did not find it interesting to be able to do the following, and have SCR bind %title, %description, %item1, %item2 and %item3 using the localized properties files pointed at by the Bundle-Localization header?

<?xml version="1.0"?> <scr:component ...>

%description %item1 %item2 %item3

</scr:component>

bjhargrave commented 15 years ago

Comment author: @bjhargrave

Well, you couple DS to the Bundle-Localization header which is for manifest localization. So now DS localization needs to be put in the same resources which does not mesh well with DS support for many component description XML files in a bundle.

Also, you complicate the spec and the parser. The spec must specify where %key can be used (and not used) and the parser must look for %key and replace with the localized string.

Given that DS already support property resources which already have a well known localization scheme, using property resources is the best way to localize properties for DS. It also gives the component description author control over the name of the property resource.

bjhargrave commented 15 years ago

Comment author: Simon Archer <sarcher@us.ibm.com>

Thanks for your insight, BJ. In the interest of simplicity, I agree that using is the right solution.

bjhargrave commented 14 years ago

Comment author: @bjhargrave

CPEG mtg: Assign to BJ to update DS spec.

bjhargrave commented 14 years ago

Comment author: @bjhargrave

In the 1.1 DS spec, the properties element is defined with a single required attribute: entry. The value of the entry attribute specifies the path of a propertied file entry in the bundle. For example,

This path include the extension, if any, of the entry. To support a localization scheme for component properties like 3.10 in the spec, the properties element really needs to specify the basename, without extension, of the "family" of entries. I don't think it is wise to require SCR to parse off the file extension and attempt to insert local names. It would be much cleaner to define a new attribute to specify the basename and indicate the properties element wishes to participate in localization. For example,

However, adding a new attribute will require updating the version of the XML schema (to 1.2.0). At this point, there are no other new features being added to DS for the upcoming 4.3 release and I think that localization of properties is not enough to justify a schema version change by itself. So I think this change should be held until some other changes for DS are being added.

bjhargrave commented 13 years ago

Comment author: @bjhargrave

CPEG mtg: We discussed this at the CPEG f2f and had the question of what locale would be used for localization? There is no method like Bundle.getHeaders which takes a locale name as a parameter. Using the default locale of the vm seems odd.

This also leads to the question of why localizable information is really doing in the component properties. UI elements should really be somewhere else where they could be retrieved for some desired locale.

CPEG is inclined to close this bug WONTFIX.

bjhargrave commented 13 years ago

Comment author: @bjhargrave

After discussion in CPEG, we decided localizing component properties is not useful in any practical way. Requirement DS1 was removed from RFC 176.