As discussed in bug 80196 and in http://nabble.documentfoundation.org/quot-LibreColour-quot-palettes-for-LibreOffice-td4200043.html a cleanup of palettes is needed. HTML should remain as the web standard.
https://gerrit.libreoffice.org/#/c/31010/1
heiko tietze committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1f04be242b42048bd25adb9fe604d1811dd39a23 tdf#104048 Refresh html palette It will be available in 5.3.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Assume we should have spaces between color names, so we show 'Mint Cream' rather than 'MintCream'.
(In reply to Yousuf Philips (jay) from comment #3) > Assume we should have spaces between color names, so we show 'Mint Cream' > rather than 'MintCream'. I think, the names should be exactly as the color keywords standardized by W3C; for example listed in https://www.w3.org/wiki/CSS/Properties/color/keywords and because they are keywords, they should not be translated.
(In reply to Regina Henschel from comment #4) > I think, the names should be exactly as the color keywords standardized by > W3C; for example listed in > https://www.w3.org/wiki/CSS/Properties/color/keywords and because they are > keywords, they should not be translated. I started with this list and moved forward to Wikipedia (references are in the header of the palette) because the sequence there is more usable. Having the basic colors first (and again below) makes the set untidy. The names are exactly as listed there including the camel case, which is usually something to avoid. About translating names please follow also bug 104053.
*** Bug 112079 has been marked as a duplicate of this bug. ***
Gabor had prepared https://gerrit.libreoffice.org/42516 to support Pootle translation of the HTML/CSS and SVG colors, I think that should be abandoned. Our html palette should not be translated. =-ref-= Regards translating the HTML/CSS and SVG color name keywords, taken from the dupe bug 112079 asking about the CamelCase naming: Gabor: > ... > But does this also mean that we should not translate them either? That would > cause quite a bit of divergence from that list as well in case of a > translated UI. Stuart: Both SVG and CSS use these as 'keywords', capitalization does not matter--so camelCase is fine. But the names as 'keywords' should probably be left intact and _not_ translated to be standards compliant with our filter handling to assure the correct sRGB hex gets assigned when keyword is parsed. https://www.w3.org/TR/SVG/types.html#ColorKeywords https://www.w3.org/TR/css3-color/#svg-color
Stuart, I don't think these are used as keywords - I mean they are not saved to files. The way I see is that these are just strings on the UI and it does not really matter how we spell them or how we display them, i.e. localized or not. As a simple experiment I saved a simple image with a DarkSeaGreen color as FODG and SVG using English UI in 6.1 master. The color is stored as a hex or RGB value in these: gabor@dome:~$ grep 8fbc8f smiley.* smiley.fodg: <style:graphic-properties draw:fill="solid" draw:fill-color="#8fbc8f" draw:textarea-horizontal-align="justify" draw:textarea-vertical-align="middle" draw:auto-grow-height="false" fo:min-height="4.842cm" fo:min-width="4.592cm"/> smiley.fodg: <loext:graphic-properties draw:fill="solid" draw:fill-color="#8fbc8f"/> gabor@dome:~$ grep 188 smiley.* smiley.svg: <path fill="rgb(143,188,143)" stroke="none" d="M 9000,6800 C 11041,6800 12600,8359 12600,10400 12600,12441 11041,14000 9000,14000 6959,14000 5400,12441 5400,10400 5400,8359 6959,6800 9000,6800 Z M 5400,6800 L 5400,6800 Z M 12601,14001 L 12601,14001 Z"/><desc>140</desc><desc>139</desc><desc>132</desc><desc>512: XPATHSTROKE_SEQ_BEGIN</desc><desc>132</desc><desc>133</desc><desc>109</desc> This is why I think we could safely display these strings localized - even if most of them is uncommon for normal users.
Also please note that due to the weird magic used to localize palette names, the most common color names in the html palette are already translated - ones that are present in other palettes as well: Red, Green, Blue, Yellow, Black, White etc. This is so since ages and we should be aware of any problems this would have caused.
(In reply to Gabor Kelemen from comment #8) > Stuart, I don't think these are used as keywords - I mean they are not saved > to files. > > ... > > This is why I think we could safely display these strings localized - even > if most of them is uncommon for normal users. Right, and I understand that it would be mostly benign for any filter export of the colors because we push the sRGB, in either decimal or HEX notation depending on format, rather than the X11/W3C color name "keyword". We don't make use of the X11/W3C color names other than in the picker for the html.soc palette. Although we do use them in the import filters [note]. However in the context of the pallet chart, preparing compliant SVG or HTML/CSS the tooltip color name should show the "keyword", and should not be localized, using the name and color swatch to visually pick a standard color. And if localized, once a color is set set the user will have no method of identify compliant colors short of comparing HEX or decimal value of the color against an external chart. So I still believe the X11/W3C color label is what is significant here--and so should not be translated for the html.soc palette. =-note-= If you run a query for the X11/W3C strings they are common in the filters. We parse them in several import filters. For example: https://opengrok.libreoffice.org/search?project=core&q=aliceblue&defs=&refs=&path=&hist=&type= or https://opengrok.libreoffice.org/search?project=core&q=SeaGreen&defs=&refs=&path=&hist=&type=