Hi all, Could you give some inputs on these changes to Mihail. Please keep the l10n list in copy as most of the translators are not subscribed to this list. Thanks a lot! Cheers Sophie
-------- Message transféré -------- Sujet : [libreoffice-l10n] Change in the documentation of the Format function (LO BASIC) Date : Fri, 7 May 2021 09:07:33 +0300 De : Mihail Balabanov <m.balaba...@gmail.com> Pour : LibreOffice-l10n <l10n@global.libreoffice.org> Hello, I noticed that in documentation of the Format function, the name of the first parameter had been changed from "Number" to "expression". (Starts around https://translations.documentfoundation.org/translate/libo_help-master/textsbasicshared/bg/?checksum=b7bf473e14ccdc22, tens of strings are affected). Why this change? The Format function does not convert an *expression* to a string, it actually does convert a *number*; Format (1 + 2 + 3) returns "6", not "1 + 2 + 3". It does not care about how the number is produced before being passed to it. The next segments mention things like "if *expression* contains a digit in this position" and "where *expression* appears in the *format* code" which do not make sense; the thing that contains a digit at position X to be formatted is the *number* produced by the expression and being formatted by the function; the expression itself cannot appear anywhere in the format code. If we mean this naming to convey the idea that any argument to any function call may be the result of an expression nested in the call, we should change all arguments of all functions to read "numeric_expression", "start_date_expression", "format_code_expression", etc. It appears to me that a better solution would be to have a general explanation about nesting expressions on an introductory page about programming in Basic. If the reader is unfamiliar with basic programming concepts, either name may confuse them: "number" may be misunderstood to mean only literal numbers (1, 7.68, .78E5) and "expression" may be misunderstood to mean that the function actually formats expressions. If the reader is familiar with nesting expressions in function calls, they would expect the parameter name to denote the role of the respective value in the calculation, not the way it may be produced before passing it to the function. As a quick fix, maybe changing the parameter to something like "numericvalue" (following the latest convention of "all lowercase, no spaces/underscores" for the parameter names) would be slightly better than both "number" and "expression"? Best regards, Mihail -- To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/l10n/ Privacy Policy: https://www.documentfoundation.org/privacy -- To unsubscribe e-mail to: l10n+unsubscr...@global.libreoffice.org Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/ Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette List archive: https://listarchives.libreoffice.org/global/l10n/ Privacy Policy: https://www.documentfoundation.org/privacy
