Yes, one of the "guidelines" (or maybe a better term is best practice)
is to not have HTML in translation labels. There are a few reasons for
this that have come up over time:
1. ability to use labels in non-webapp contexts
2. be able to externally format/style the labels, perhaps differently
in different places
3. avoid HTML in labels interfering with other HTML/CSS in the page
Anyway, there was an effort a while back to remove HTML from the
labels for some of these reasons, and when doing the output encoding
it seemed best to encode all characters from labels to encourage this
practice.
-David
On Apr 23, 2009, at 12:28 PM, Adrian Crum wrote:
Why would we want to put HTML in the UI labels?
-Adrian
Andrew Zeneski wrote:
Here is a patch which does exactly this, and appears to work with
just a little testing. I'm just not sure of the total impact it
will cause.
On Apr 23, 2009, at 1:44 PM, Andrew Zeneski wrote:
Well there is an option which might be viable. We could simply
wrap all values in the uiLabelMap using StringUtil.wrapString().
This will allow HTML characters in the UI labels again and
shouldn't be too much of a security risk, as only developers have
access to these strings.
Thoughts?
Andrew
On Apr 23, 2009, at 10:56 AM, Adrian Crum wrote:
I agree. We should look into the widget code and the label
manager code to get these issues fixed properly.
-Adrian
Scott Gray wrote:
That's probably something we can fix in the widget code isn't
it? If the title attribute is missing then use the field name
otherwise render whatever is specified in the title even if it
is just an empty string.
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com <http://www.hotwaxmedia.com/>
On 23/04/2009, at 8:53 PM, Jacopo Cappellato wrote:
I think it is related to the situation where you want to
specify an empty content for the "title" attribute in form
widgets. if title element is missing or is set to title="" then
the widgets render it with the name of the field or simialr.
Jacopo
On Apr 23, 2009, at 10:43 AM, Scott Gray wrote:
I can't remember the reason for adding the CommonEmptyHeader
label but I'm wondering if we should consider removing it and
find another solution to whatever problem it solved?
Regards
Scott
HotWax Media
http://www.hotwaxmedia.com
On 23/04/2009, at 8:25 PM, Jacques Le Roux wrote:
Hi Andrew,
From: "Andrew Zeneski" <andrew.zene...@hotwaxmedia.com <mailto:andrew.zene...@hotwaxmedia.com
>>
I think this is due to the new HTML security, but now we
have these " " codes floating all over the place. I'm
not sure what the best solution for this is, but I thought
I would check in a change like this:
This is not as simple. I agree it's a quick fix for the issue
at hand. But this is due to Labels Manager. If you put a sole
space (ie > < ) then if you do some modifications with Labels
Manager in this file and then save in the file you will get
<property key="CommonEmptyHeader">
<value xml:lang="en"/>
</property>
In order to cope with this I tried to write directly at
SaveLabelsToXmlFile.saveLabelsToXmlFile[93] the String
" " which should be ok. But I guess I would have to
change the format passed to UtilXml.writeXmlDocument some
lines below since else it write "&#160;" and not " "
as intended. Not sure it's possible though. And I have no
time to look at it right now.
So I made the change you proposed at r767845 and r767848
for R9.04
And we will have to deal with that in a complete way since
else we will find an even worst trouble later (as soon
someone will use Labels Manager to save changes in this file)
Jacques
I had some zele here (ok not only here ;o)
Index: config/CommonUiLabels.xml
=
=
=
=
=
==============================================================
--- config/CommonUiLabels.xml (revision 767649)
+++ config/CommonUiLabels.xml (working copy)
@@ -1997,7 +1997,7 @@
<value xml:lang="zh_CN">电子邮件</value>
</property>
<property key="CommonEmptyHeader">
- <value xml:lang="en">&#160;</value>
+ <value xml:lang="en"> </value>
</property>
<property key="CommonEnabled">
<value xml:lang="ar">شغال</value>
Any thoughts???
Andrew