Opened on 11/30/2017 at 02:19:26 PM
Closed on 09/09/2019 at 02:40:17 PM
#6114 closed change (rejected)
Add ability to specify documentation link in translatable strings
Reported by: | greiner | Assignee: | |
---|---|---|---|
Priority: | P3 | Milestone: | |
Module: | User-Interface | Keywords: | |
Cc: | wspee, saroyanm, Shikitita | Blocked By: | |
Blocking: | Platform: | Unknown / Cross platform | |
Ready: | yes | Confidential: | no |
Tester: | Unknown | Verified working: | no |
Review URL(s): |
Description
Background
Translatable strings can include basic HTML tags such as <a> and <strong> but no arbitrary HTML for security reasons. Anchor tags will be hyperlinked at runtime when we convert those strings into HTML elements.
However, the order of the links may change in certain languages and there's no indication whether that is the case when we decide on which links should be assigned which URL. Furthermore, we have to set the "href" attribute for each link individually.
We could resolve both issues at once by including the documentation link ID directly in the translatable strings. This'll (a) allow us to associate the anchor tag with the correct URL, (b) resolve hyperlinks automatically during the conversion process and (c) further ensure that only documentation links are used.
What to change
Extend support for HTML anchor tags in translatable strings to allow for an optional "doclink" attribute which is expected to contain the associate documentation link ID.
e.g.
We'd like to encourage websites to use straightforward, unobtrusive advertising. That's why we've established <a doclink="acceptable_ads_criteria">strict guidelines</a> to identify acceptable ads, which are shown under default settings. If you still want to block every ad you can <a>disable</a> this in a few seconds.
Attachments (0)
Change History (1)
comment:1 Changed on 09/09/2019 at 02:40:17 PM by greiner
- Resolution set to rejected
- Status changed from new to closed
Closing this ticket. It's unclear whether this is still something we want/need because we fixed one of the problems this ticket refers to in #6743. If that is the case, however, please create a new issue for it on GitLab.