Always check out the original article at http://www.oraclequirks.com for latest comments, fixes and updates.
If you, like me, think that it could be useful having text messages available as substitution strings (ideally using the #syntax#) inside certain Apex's element attributes like button attributes, report links, form attributes and so on, then you might want to vote for this feature request on Apex feature application
https://apex.oracle.com/pls/apex/f?p=55447:1:0
You need an OTN membership to log on to the application.
The feature request is titled: "Make text messages available as substitution strings"
The rationale behind this request follows:
"It happens frequently that one needs to add certain HTML attibutes
like ALT, TITLE inside certain APEX elements like links, buttons, icons
and so on. In the best case Apex makes available this attributes as
translatable text, but unfortunately this stuff is often a mix of HTML
fragments and real text which is not so desirable given the risk of
corrupting the syntax in the translated form. It would be much better to
have text messages available as substitution strings either using the
"hash" syntax or the ampersand and period syntax throughout the entire
page or region after specifying somewhere which messages we really need
to have at hand in that context."
I also happen to desire such feature when I need to manually build links in Apex reports using the APEX_ITEM APIs. Instead of calling the APEX_LANG.MESSAGE function inside the query, I'd prefer to put a single occurrence of TITLE="#TITLE_MESSAGE#" or ALT="#ALT_MESSAGE#" in the appropriate place so that the API is called only once by Apex before rendering the region.
In order to decide which messages I need to get translated, there could be a region (or page level) attribute where I specify a comma separated list of message names, such that only the required ones will be made available as substitution strings.
I know that there could be some workarounds out there where one allocates a certain number of substitution strings and dynamically alters their content with the desired text messages, but this makes the whole thing just too cumbersome in my view, so I'd prefer a more straightforward approach.
It's just a proposal, so have your say.
No comments:
Post a Comment