| Summary: | [NLS] Most hyperlinks show as 'Unknown Hyperlink' | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [WebTools] WTP Source Editing | Reporter: | Nitin Dahyabhai <thatnitind> | ||||
| Component: | wst.sse | Assignee: | Nitin Dahyabhai <thatnitind> | ||||
| Status: | RESOLVED FIXED | QA Contact: | Nitin Dahyabhai <thatnitind> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | david_williams, nsand.dev | ||||
| Version: | 3.0.4 | ||||||
| Target Milestone: | 3.2 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows XP | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 315483 | ||||||
| Attachments: |
|
||||||
When only a single hyperlink is valid in an editor, the familiar link underline is used to show that the link is armed. But when multiple hyperlinks are valid at a location in the editor, the platform shows all of them using the value returned from IHyperlink.getHyperlinkText(), which we don't implement well at all. The attached patch tries to address that minimally by pairing a sensible value after the verb "Open". I think the penalty of not having them translated in 3.0.5 (they'd be externalized at least) is well worth removing the confusion brought about from presenting multiple hyperlinks displayed with 'Unknown Hyperlink'. This isn't a problem we've addressed during 3.1's development, so I'd really like approval for both branches if possible. I think I'm ok with this, but some question about the patch .... What's NLS.Bind buy you? Also, shouldn't public static final String Open = "Open"; be externalized? Or are you just waiting to do after patch applied? (In reply to comment #2) > I think I'm ok with this, but some question about the patch .... > > What's NLS.Bind buy you? > > Also, shouldn't > > public static final String Open = "Open"; > > be externalized? Or are you just waiting to do after patch applied? That class is a little confusing since it's still using the old resource bundle scheme. I'd probably go ahead and switch it to the proper modern NLS utility, but until then, the resource string key needed to be placed somewhere. Hey Nitin, can this be resolved? I did a quick runthrough of the hyperlinks and they all seem to be externalized with more descriptive text now. Sure. |
Created attachment 131729 [details] proposed patch None of the hyperlink implementations in source editing implement getHyperlinkText() improperly. Some of them display strings without verbs, such as the full path to a file when that's what would open, but most don't return any text at all and show up in the hyperlink list as 'Unknown Hyperlink', which is an especially bad problem when multiple hyperlinks are available in the same location. The attached patch adds 3 strings to source editing to generically represent "Open {0}" and sets up the hyperlink implementations to bind better strings to it.