Description Susan McCourt 2012-08-08 17:00:00 EDT

In bug 386509, the "Places" list broke because we use service metadata property "Name" to show the name of the file system.  But when the plugin got internationalized, "Name" got replaced with "NameKey".  (I wondered why the breadcrumb got it right...it was because "fileClient" initializes all of its cached names by reading the catalog.)

But several things seem wrong here:
- Are we saying that for every translatable plugin property there are two possible metadata keys?...  "{PropertyName}" and "{PropertyName}Key"?
- And that every metadata consumer has to now check the property and then check for the NLS property as well?
- how is a particular service consumer to know which properties will/should be translated over time?

It seems that instead, we should change ServiceReference.getProperty to be the one that would know whether a property is translated or not.  A related issue is that we've said "service metadata is fast" and encouraged use of service properties, and now service metadata is asynchronous and possibly slow.

If we can't bury this knowledge in ServiceReference, then we need "rules of engagement" for API clients - how they use service metadata properties and how in the world they would know whether any particular property might be translated.