Try this procedure with German locale settings: SUB Formattest msgbox Format(123.546, "Currency") END SUB Will show 124 € instead of 123,55 €. Decimal separator and decimal places will be lost. Value will be rounded without decimal places. Bug appears in Version: 7.6.2.1 (X86_64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded and also in every older version installed here.
Hello Robert I wouldn't expect Basic to follow localizations, just use the dot as a decimal separator. ``` SUB Formattest msgbox Format(123.546 ,"#,##0.00 €") END SUB The output of the msgbox is then localized
(In reply to Werner Tietz from comment #1) > Hello Robert > > I wouldn't expect Basic to follow localizations, just use the dot as a > decimal separator. > > ``` > SUB Formattest > msgbox Format(123.546 ,"#,##0.00 €") > END SUB > > The output of the msgbox is then localized … but Format(123.546, "Currency") would run well in AOO (tested with AOO 4.1.8) and did run in the past with OpenOffice. So I thought it is intended to follow localization. Your code will run well, but doesn't follow the localization. Format(123.546, "Currency") will have a look at the localization (€-sign is set right) but will suppress decimal places.
Hallo Robert seems locale-related?! If I switch the UI to **en-US** the Example works as expected: ``` SUB Formattest msgbox Format(123.546, "Currency") '############## '# 123,55 € '############## END SUB ``` Version: 7.6.2.1 (AARCH64) / LibreOffice Community Build ID: 56f7684011345957bbf33a7ee678afaf4d2ba333 CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Flatpak Calc: threaded ``` LO 7.4.7.2 shows the same behaviour with UI: en-US →→ 123,55 € # ok! with UI: de-DE →→ 123 € # not ok!
Regression in version 3.6, after commit https://git.libreoffice.org/translations/+/30b3fc977ed4bdb018c4b94d4b9034d3bb9807bd "update translations for LibreOffice 3.6.0 rc1" which used localized decimal separators for the currency string STR_BASICKEY_FORMAT_CURRENCY (basic/inc/strings.hrc [1]). Same problem must be with dsb, hsb, nn, and pt-BT UI. Similar problems would be e.f. in mk locale, which didn't change decimal separator, but changed the currency symbol The string there must not localize the notation of separators - they must stay "." for decimal, "," for thousand, and "$" for currency symbol, and will be analized / replaced with localized variants in SbxBasicFormater::AnalyseFormatString and SbxBasicFormater::ScanFormatString. The idea of localizing the string is about possible differences in the components' placement, or maybe digit count, or 0 vs. #, literal text, etc. This needs to be somehow mentioned for the localizable string context, and the localizations that modified those must be fixed. [1] https://opengrok.libreoffice.org/xref/core/basic/inc/strings.hrc?r=dcea29c2#31
See https://translations.documentfoundation.org/translate/libo_ui-master/basicmessages/de/?sort_by=-priority%2Cposition&offset=147#suggestions I have no privileges to make translations, so there is only a suggestion. Also, there is no way to add a comment there, so I have no way to communicate there why do I propose that. A german-speaking translator would have difficulty understanding why someone proposes this seemingly nonsensical change, without a link to this issue.
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f24cf13f0eaa3fb2f5e159d83eaf4c705b4388a8 Related: tdf#158092 add a comment to avoid symbols localization It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The Brazilian Portuguese, Romanian and Silesian strings are affected as well. I left suggestions that you may want to review @Julien @Olivier https://translations.documentfoundation.org/user/Fito/suggestions/
(In reply to Mike Kaganski from comment #5) > See > https://translations.documentfoundation.org/translate/libo_ui-master/ > basicmessages/de/?sort_by=-priority%2Cposition&offset=147#suggestions > > I have no privileges to make translations, so there is only a suggestion. > Also, there is no way to add a comment there, so I have no way to > communicate there why do I propose that. A german-speaking translator would > have difficulty understanding why someone proposes this seemingly > nonsensical change, without a link to this issue. Ok done.
For Dutch, there's @0.00 $;@(0.00$) instead of @0.00 $;@(0.00 $) (See https://translations.documentfoundation.org/translate/libo_ui-master/basicmessages/nl/?q=note%3AYXUyZ&sort_by=-priority%2Cposition&offset=1) should we add the extra space or should we let it as it is?
(In reply to Julien Nabet from comment #9) This string is OK from Basic point of view (Basic will find the $, and replace with localized currency); I have no idea if it's OK from the localization point of view. I believe that *that* potential change is out of scope for *this* bug.
(In reply to Mike Kaganski from comment #10) > (In reply to Julien Nabet from comment #9) > > This string is OK from Basic point of view (Basic will find the $, and > replace with localized currency); I have no idea if it's OK from the > localization point of view. I believe that *that* potential change is out of > scope for *this* bug. Ok I let the Dutch translation and kept on the review. I changed about a dozen of translations, hope I didn't miss some and it'll be ok.
Thank you everybody who filed, commented, and worked on this; let's call it fixed :-)