[Bug 160986] Use CLDR number formatting pattern 'standard-percentage' in the UI, e.g. show 'X %' instead of 'X%' depending on locale

[bugzilla-daemon at bugs.documentfoundation.org]

https://bugs.documentfoundation.org/show_bug.cgi?id=160986

--- Comment #6 from V Stuart Foote <vsfoote at libreoffice.org> ---
(In reply to V Stuart Foote from comment #5)

> We hold the CLDR in i18npool/source/localedata/data as an XML for each
> supported locale, and IIUC the format code for 'PercentFormatskey1' or
> 'PercentFormatskey2' is what gets picked up for localized FUNIT_PERCENT
> depending on precision.
> 
> If you look through the XML you'll see the mix of usage for localizations.
> 

The tr_TR.xml is a good test case. Its CLDR number format for percentage is 


96     <FormatElement msgid="PercentFormatskey1" default="true" type="short"
usage="PERCENT_NUMBER" formatindex="8">
97       <FormatCode>%0</FormatCode>
98     </FormatElement>
99     <FormatElement msgid="PercentFormatskey2" default="true" type="long"
usage="PERCENT_NUMBER" formatindex="9">
100       <FormatCode>%0,00</FormatCode>

Note that for the Turkish locale the "%" glyph is moved to the front of the
format code!

And if from Tools -> Options -> Language and Locales -> General you change your
LO "User Interface" and "Locale" to 'Turkish' (checking "Ignore system input
language") and relaunch the format for the Statusbar zoom control does match
that format.

Likewise for fr-FR, test that with its

94     <FormatElement msgid="PercentFormatskey1" default="true" type="short"
usage="PERCENT_NUMBER" formatindex="8">
95       <FormatCode>0" "%</FormatCode>
96     </FormatElement>
97     <FormatElement msgid="PercentFormatskey2" default="true" type="long"
usage="PERCENT_NUMBER" formatindex="9">
98       <FormatCode>0,00" "%</FormatCode>

shows the Statusbar zoom control matching the format and a *NBSP (0x00A0)
preceding* the "%" glyph.

So are we already using our CLDR format values for the stbctrls/zoomctrl.cxx as
well?

If so, we're doing the correct thing. And any changes would need to be to our
CLDR implementation, or upstream. Which for en-US allows both no-space and
spaced. And this is a non-issue.

-- 
You are receiving this mail because:
You are on the CC list for the bug.