| Summary: | "Unknown item" in Places list | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [ECD] Orion | Reporter: | John Arthorne <john.arthorne> | ||||
| Component: | Client | Assignee: | Susan McCourt <susan> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | malgorzata.tomczyk, susan | ||||
| Version: | unspecified | ||||||
| Target Milestone: | 1.0 M1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
John Arthorne
Created attachment 219494 [details]
Screen shot
This appears to have been broken by externalizing the plugin strings. We assume there is a "name" property on the file service, but since the default file service is externalized, there is only "NameKey". We probably need some general solution that ensures the name field is filled in once resolved, but I may look for a more surgical fix here...investigating. Fixed very surgically/bogusly by simply defining a hard coded "Name" property in the Orion file client plugin in addition to "NameKey" and "nls". This means that the Places list will not be translated correctly but it will get us through M1. Something feels wrong here, that service metadata properties are changing names when they get translated. I think instead we need some convention whereby the ServiceReference looks for a catalog and replaces the property value if there is a translated version of it. Clients shouldn't have to deal with this. Opened bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=386890 to discuss. For now the fix is in http://git.eclipse.org/c/orion/org.eclipse.orion.client.git/commit/?id=1a98fafc5fc4ce8ee1dca1865f0a41bc6ce8b53b |