Yes, it should. I haven't looked into this enough to know what the
issue is with that... it could be that the label parsing code is
turned into an empty String... and if so changing that might be the
probably the best way to go. Someone was just writing about how an
> Fair enough, then in this case this specific field CommonEmptyHeader
> should be just a single space. The label manager should define its
> own special label which is not used anywhere else.
>
> Andrew
>
> On Apr 23, 2009, at 2:42 PM, David E Jones wrote:
>
>>
>> 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" <
[hidden email] <mailto:
[hidden email]
>>>>>>>>>> >>
>>>>>>>>>>> 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>
>>
>