Description: In the zoom level indicator (lower right of the window) and on the Zoom level selection dialog, I suggest using the percentage symbol separated from the number with one space: '100 %' instead of '100%'. In English, there is no definitive rule (it is OK both with and without the space). But in many other languages, the space is the correct form. Therefore, why not use a space and accommodate more users? Steps to Reproduce: . Actual Results: . Expected Results: . Reproducible: Always User Profile Reset: No Additional Info: .
Thanks for posting! Hmm, gave it some thought about using MS-LCID and applying a number format. But seems over engineered, and mostly the percent formats are without space anyhow. Status quo here for UI suffices. -1
(In reply to V Stuart Foote from comment #1) > ... > -1 Addressed more directly in Unicode CLDR 'standard-percent' number formatting pattern handling, which seems more what is requested. As used already [1] in Calc for cell value formatting of percentages. Just don't know if we apply it anywhere else against the UI, or how involved such an l10n change to be able to label the Status Bar UI (stbctrls/zoomctrl.cxx) might be. If simple enough, then sure. But not if it ends up too complicated and needing substantial refactoring to handle the zoom attribute. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/i18nutil/source/utility/unicode.cxx?r=19ea4aad#1032
SvxZoomStatusBarControl::ImplUpdateItemText() calls unicode::formatPercent() which starts with the comment //Format a number as a percentage according to the rules of the given //language, e.g. 100 -> "100%" for en-US vs "100 %" for de-DE Now I wonder why ICU defines no space between number and unit while the usual English typography does according https://en.wikipedia.org/wiki/Space_(punctuation)#Unit_symbols_and_numbers. Eike, what's your take?
> //Format a number as a percentage according to the rules of the given > //language, e.g. 100 -> "100%" for en-US vs "100 %" for de-DE This is a bit misleading: As pointed out in my original post, there seems not to be a 'correct' way 'according to English', therefore it is not true that "100%" is the 'rule' for this language. If we, as an open and international community, stick to international standards (as I guess we intend to?), then we should follow the widely used and accepted International System of Units (SI) [1], followed even by English-speaking science institutions [2]. [1] Page 151 in https://www.bipm.org/documents/20126/41483022/SI-Brochure-9-EN.pdf [2] https://physics.nist.gov/cuu/Units/checklist.html
(In reply to Heiko Tietze from comment #3) >... > which starts with the comment > > //Format a number as a percentage according to the rules of the given > //language, e.g. 100 -> "100%" for en-US vs "100 %" for de-DE Don't know why FUNIT_PERCENT (of AOo i56998) was not applied for the status bar zoom control, but upstream Unicode "Common Locale Data Repository" (CLDR) contains the "accepted" usage. When Caolán ported the changes, he was a little sparse in its commenting. In reality, the CLDR addresses spacing, decimal separator and position of the % glyph per locale. 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. Also, localization doesn't follow SI usage.
(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.
So we agree that the missing space between number and unit is a bug. The code has some level of spaghettiness, simply changing the XML is not enough. And PERCENT_NUMBER is #6, while formatindex is 8... Beyond my skills.
(In reply to Heiko Tietze from comment #7) > So we agree that the missing space between number and unit is a bug. > Nope, norm would be to follow the CLDR. Which I think we do? Space and position as specified in CLDR, otherwise space is not required (we seem to do the correct thing already, if consistent use of the XML can be confirmed on the Statusbar zoom). And certainly not hardcoding a "percentage symbol separated from the number" as suggested in OP.