Community
Participate
Working Groups
These names are visible on wizards and property pages for connections. There needs to be a displayable label associated with these objects that is persisted in addition to the name. This is a high priority item for globalization.
Why would you want to persist the translated label of the property set? This does not work in a multi-language setup where connections are shared between installations running in different locales. Note that this is a non-trivial API change since every creator of a property set needs to supply and associate the (translated) label with it. I do think, though that the API change can be done in a non-breaking compatible manner. I'd see the biggest problem with properties of the "Enum" type since each enum item needs to have the untranslated as well as the translated label. UI (the forms) are also affected. Are you confident that you can handle all this for 2.0? I thought we'd rather shoot for a different solution where we'd live with untranslated properties for 2.0, and try to ensure that property sets are never exposed to the user directly in the future. Instead, there would always be a (hand written, much more user-friendly) UI for them. See bug #176490 comment 2 for reference.
You are correct. The labels should not be persisted. The forms are easily fixed, and I would ordinarily agree with you about necessity but I think I have a relatively workable solution for this. The translators have identified this as a high priority item inside of IBM. I will not be breaking API for this. Instead there will be an additional interface that model objects can use for label getting/setting. It will be implemented by ServerLauncher and PropertySet.
The plan sounds good, I'm just wondering what you'd be doing with dropdowns in the Property Sets (i.e. Properties of type Enum)? Also, for Properties of type Boolean, would you translate "true" and "false"?
Those would have to be left as is since the code is dependent on the values. This is strictly for the labels of the objects that show up in the tree viewer. I hope this particular usage only for this release, but the we should be able to exploit this interface elsewhere in the future.
Added new ILabeledObject interface. Interface is implemented by property sets and server launchers. The label provider in ConnectorServiceForm now understands ILabeledObjects and will use the provided labels rather than the names.
[target cleanup] 2.0 RC1 was the original target milestone for this bug
