All examples are incorrect: arguments are separated by "," instead of ";". The example =SOMMA.SE(A2:A6,"penna*",C2:C6) has a nonsensical description: "Adds the values in area C2:C6 only if the values in the corresponding area A2:A6 contain the letters "penna". Returns 150 because rows A4:A5 do not meet the criterion.", in fact it returns 85.
If I understand correctly, you are talking about an Italian guide book for Calc 25.2? Can you give a link to the book as I can't find it?
Created attachment 200409 [details] scrshot for Guide
Created attachment 200410 [details] scrshot Both samples are meaningless because the string "penna" exists and the result is 85.
Reproducible https://help.libreoffice.org/latest/fr/text/scalc/01/func_sumif.html?DbPAR=CALC#bm_id3151957 It has ';' as separator in function definition, but has ',' as separator in examples. If I am not mistaken, all languages accept ';' as separator, it would be better to use it everywhere.
(In reply to gmarco from comment #2) > Created attachment 200409 [details] > scrshot for Guide This is not from a guide book, but from the translation of Help. While reports can be made about translations, Weblate does accept suggestions even from unregistered users, so making those directly would skip a step: https://translations.documentfoundation.org/projects/libo_help-master/-/it/ For example, I can search with "=SOMMA.SE(A2:A6,"penna*",C2:C6)" and find the relevant string. https://translations.documentfoundation.org/translate/libo_help-master/textscalc01/it/?checksum=adc691b541dcf043&sort_by=-priority%2Cposition
(In reply to Buovjaga from comment #5) > (In reply to gmarco from comment #2) > > Created attachment 200409 [details] > > scrshot for Guide > > This is not from a guide book, but from the translation of Help. > ..... That is what I can get by going to Help -> LibreOffice Help or pressing F1.
(In reply to m_a_riosv from comment #4) > Reproducible > https://help.libreoffice.org/latest/fr/text/scalc/01/func_sumif. > html?DbPAR=CALC#bm_id3151957 > > It has ';' as separator in function definition, but has ',' as separator in > examples. > > If I am not mistaken, all languages accept ';' as separator, it would be > better to use it everywhere. I would say more precisely: ';' is the universal rule, the ',' or whatever gives "Err:501"
It seems to me that it is not a problem of translation into a specific language, the reported malfunctions are just in the original English text.
(In reply to gmarco from comment #8) > It seems to me that it is not a problem of translation into a specific > language, the reported malfunctions are just in the original English text. Indeed, they are in the original source: https://help.libreoffice.org/latest/en-US/text/scalc/01/func_sumif.html
Olivier: I've submitted https://gerrit.libreoffice.org/c/help/+/184388 on gerrit to change "," into ";" for sumif function.
Julien Nabet committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/help/commit/2487e71ba257e1115eda0cab2d86186845b07239 Related tdf#166251 Use ";" for separator in SUMIF function
Please, don't forget the 2° and 3° examples too (look at my attachment).
(In reply to gmarco from comment #12) > Please, don't forget the 2° and 3° examples too (look at my attachment). I changed 6 examples in the patch, I don't think I missed some but perhaps I'm wrong?
(In reply to gmarco from comment #0) > The example =SOMMA.SE(A2:A6,"penna*",C2:C6) has a nonsensical description: > "Adds the values in area C2:C6 only if the values in the corresponding > area A2:A6 contain the letters "penna". Returns 150 because rows A4:A5 do > not meet the criterion.", in fact it returns 85. What about these problems?
(In reply to Buovjaga from comment #14) > (In reply to gmarco from comment #0) > > The example =SOMMA.SE(A2:A6,"penna*",C2:C6) has a nonsensical description: > > "Adds the values in area C2:C6 only if the values in the corresponding > > area A2:A6 contain the letters "penna". Returns 150 because rows A4:A5 do > > not meet the criterion.", in fact it returns 85. > > What about these problems? "only if the values in the corresponding area A2:A6 contain the letters "penna". Returns 150 because rows A4:A5 do not meet the criterion." As I said, some nonsense: - area A2:A6 ... rows A4:A5 - Returns 150 because rows A4:A5 do not meet the criterion: if the criterion is not met why does it return 150? Was it so, it should be 0 ! But the criterion is just satisfied, "penna" is in A3 and corresponds to the value 85 in C3 !
(In reply to gmarco from comment #15) > (In reply to Buovjaga from comment #14) > > (In reply to gmarco from comment #0) > > > The example =SOMMA.SE(A2:A6,"penna*",C2:C6) has a nonsensical description: > > > "Adds the values in area C2:C6 only if the values in the corresponding > > > area A2:A6 contain the letters "penna". Returns 150 because rows A4:A5 do > > > not meet the criterion.", in fact it returns 85. > > > > What about these problems? > > "only if the values in the corresponding area A2:A6 contain the letters > "penna". Returns 150 because rows A4:A5 do not meet the criterion." > As I said, some nonsense: > - area A2:A6 ... rows A4:A5 > - Returns 150 because rows A4:A5 do not meet the criterion: if the criterion > is not met why does it return 150? Was it so, it should be 0 ! > But the criterion is just satisfied, "penna" is in A3 and corresponds to the > value 85 in C3 ! gmarco is right, product names should have been adapted and not only translated. Indeed, in English, =SUMIF(A2:A6,"pen*",C2:C6) gives 150 since, we have: - C2 (65) which is in the same row as "pencil" A2 - C3 (85) which is in the same row as "pen" A3 but in Italian, only A3 "penna" corresponds to the criteria "pen*", so we should have only 85 and not 150. There's exactly the same problem in French and certainly in other languages.
(In reply to Julien Nabet from comment #16) > (In reply to gmarco from comment #15) > > (In reply to Buovjaga from comment #14) > > > (In reply to gmarco from comment #0) > > > > The example =SOMMA.SE(A2:A6,"penna*",C2:C6) has a nonsensical description: > > > > "Adds the values in area C2:C6 only if the values in the corresponding > > > > area A2:A6 contain the letters "penna". Returns 150 because rows A4:A5 do > > > > not meet the criterion.", in fact it returns 85. > > > > > > What about these problems? > > > > "only if the values in the corresponding area A2:A6 contain the letters > > "penna". Returns 150 because rows A4:A5 do not meet the criterion." > > As I said, some nonsense: > > - area A2:A6 ... rows A4:A5 > > - Returns 150 because rows A4:A5 do not meet the criterion: if the criterion > > is not met why does it return 150? Was it so, it should be 0 ! > > But the criterion is just satisfied, "penna" is in A3 and corresponds to the > > value 85 in C3 ! > > gmarco is right, product names should have been adapted and not only > translated. > Indeed, in English, > =SUMIF(A2:A6,"pen*",C2:C6) gives 150 since, we have: > - C2 (65) which is in the same row as "pencil" A2 > - C3 (85) which is in the same row as "pen" A3 > > but in Italian, only A3 "penna" corresponds to the criteria "pen*", so we > should have only 85 and not 150. > > There's exactly the same problem in French and certainly in other languages. VERY GOOD, thanks!!!
Now that "," have been replaced with ";" there are several steps: 1) helpcontent fixed strings must be present in Weblate 2) translations + adaptation must be done on languages (but no need to wait for all languages to be fixed). 3) synchro from Weblate to translation repository 4) wait for a new LO release including the fix. I may be wrong but the fixes will be done only from next release 25.8 Sophie/Christian: could you just remind the time needed for step 1?
The issue is in the data table that has translations enabled and the translated examples becomes inconsistent. I'll disable the data table translation and warn translators in weblate or l10n list.
I would suggest to keep the data table translatable. In my opinion, this is what localization should be about: not only to translate the strings, but also to adapt the examples to be meaningful in a target language. While keeping English items in cells is certainly an option, I think that is less natural for the reader than their translated variants.
I support leaving the examples translatable but maybe with some comments that warn the translators to adapt, rather than translate, the example product names. I have adapted them when they first appeared in Help and readapted them after the changes, and I would prefer to leave them in Bulgarian because almost all other examples are translated/adapted.