Bug 152148 - Polish localisation issues for MAKS.K(dane; rząd_K) ≡ LARGE(…; …) and MIN.K() ≡ SMALL()
Summary: Polish localisation issues for MAKS.K(dane; rząd_K) ≡ LARGE(…; …) and MIN.K()...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
Version:
(earliest affected)
3.3.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on: 152292
Blocks: Calc-Function
  Show dependency treegraph
 
Reported: 2022-11-21 01:11 UTC by MarkOpen
Modified: 2024-12-01 03:12 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description MarkOpen 2022-11-21 01:11:22 UTC
Description:
My review concerns the Polish version:
MAKS.K(dane; rząd_K) ≡ LARGE(…; …) and MIN.K()
1. Syntax error – „K” with „rząd_K” ≠ „K” with „MAKS.K”.
„K” with „MAKS.K” = K
„K” with „rząd_K” = 1, 2, 3...
My proposition - rename the function to:
MAKS.W() from MAKSymalna Wartość
MIN.W() from MINimalna Wartość

2. 2 bugs in feature description  MAKS.K()
„Zwraca K-tą największą wartość zbioru danych.”
1 – the greatest value is only for K=1,
2 – the dataset has no value.
My proposition:
„Zwraca wartości ze zbioru danych - od największej (w kolejności określonej przez K).”

3. 2 bugs in feature description  MIN.K()
My proposition:
„Zwraca wartości ze zbioru danych - od najmnieszej (w kolejności określonej przez K).”

4. Unnecessary synonym in the definition 
„Dane oznaczają zakres komórek zawierających dane.”
My proposition:
„dane oznaczają zakres komórek zbioru danych.”

Steps to Reproduce:
1.It's just an opinion.
2.It's just an opinion.
3.It's just an opinion.

Actual Results:
It's just an opinion.

Expected Results:
It's just an opinion.


Reproducible: Always


User Profile Reset: No

Additional Info:
It's just an opinion.
Comment 1 Stéphane Guillou (stragu) 2022-11-26 16:51:17 UTC
Thanks MarkOpen!
Let's focus on the first issue in this bug report. Unfortunately, I believe it will be difficult to rename functions, for back-compatibility issues, but I could be wrong.

Do you mean that the name of the function is misleading, because people might understand, for example, the formula:

MAKS.K(A1:A9; 2)

... as "the 2 highest values in the range A1:A9" instead of "the second highest value in the range A1:A9" ?

Regarding your points 2 and 3:
- If the descriptions are also wrong in the English-language in-app descriptions, or in the English-language online help, please report a separate issue so that can be fixed there
- If the descriptions are right in English but wrong in Polish, you can help by fixing the translation on LibreOffice's Weblate: https://translations.documentfoundation.org/

Thank you!
Comment 2 Eike Rathke 2022-11-28 14:22:22 UTC
(In reply to Stéphane Guillou (stragu) from comment #1)
> I believe
> it will be difficult to rename functions, for back-compatibility issues, but
> I could be wrong.
Renaming UI translated function names is no problem, stored in documents are the English OpenFormula function names.
Comment 3 MarkOpen 2022-11-28 22:24:07 UTC
(In reply to Stéphane Guillou (stragu) from comment #1)
> Thanks MarkOpen!
> Let's focus on the first issue in this bug report. Unfortunately, I believe
> it will be difficult to rename functions, for back-compatibility issues, but
> I could be wrong.
> 
> Do you mean that the name of the function is misleading, because people
> might understand, for example, the formula:
> 
> MAKS.K(A1:A9; 2)
> 
> ... as "the 2 highest values in the range A1:A9" instead of "the second
> highest value in the range A1:A9" ?
> 
> Regarding your points 2 and 3:
> - If the descriptions are also wrong in the English-language in-app
> descriptions, or in the English-language online help, please report a
> separate issue so that can be fixed there
> - If the descriptions are right in English but wrong in Polish, you can help
> by fixing the translation on LibreOffice's Weblate:
> https://translations.documentfoundation.org/
> 
> Thank you!

Thanks Stéphane Guillou 

You: „Do you mean that the name of the function is misleading, because people might
understand, for example, the formula:

MAKS.K(A1:A9; 2)

... as "the 2 highest values in the range A1:A9" instead of "the second highest value in the range A1:A9" ?”

I (MarkOpen). No. But that you have to rename the function with the change of K:
for K = 2 it must be MAKS.2(A1:A9; 2); for K = 5 it must be MAKS.5(A1:A9; 5).

Ad. 2 and 3. In the first sentence I wrote: „My review concerns the Polish version”.
I was convinced that I would get contact with the authors of Polish translations in "Help". I tried to contact one of them: Piotr Roszkowski, via LinkedIn. No answer.
Thank you!
Comment 4 QA Administrators 2022-11-29 03:44:22 UTC Comment hidden (obsolete)
Comment 5 Stéphane Guillou (stragu) 2022-11-29 10:57:50 UTC
Thank you Mark and Eike!

Regarding point 1):

My opinion is that a localisation that uses the letter "c" for the argument is a better strategy than changing the localised function name (less disruptive to users who are used to the current name, and makes it more consistent with English). I copied Piotr in for a more qualified opinion.

Regarding points 2) and 3):

I understand better now. The English help page is correct in its use of arguments names, for both functions (despite some inconsistency, see Bug 152292):

https://help.libreoffice.org/7.4/en-US/text/scalc/01/04060183.html

The Polish-language translation is confusing, as it talks about the K-th ("K-tą") largest/smallest value instead of using the proper argument name "rząd_K":

https://help.libreoffice.org/7.4/pl/text/scalc/01/04060183.html

This specific translation issue can be corrected in Weblate: 
- https://translations.documentfoundation.org/translate/libo_help-master/textscalc01/pl/?checksum=e4e1e7f63b3df58c&q=K-t%C4%85&sort_by=-priority%2Cposition
- https://translations.documentfoundation.org/translate/libo_help-master/textscalc01/pl/?checksum=9c9720e908f3f204&q=K-t%C4%85&sort_by=-priority%2Cposition

Note that the German translation also uses "K" in the function name and, misleadingly, in the description (the argument name doesn't use "K").
For reference, the function description from MS Office: https://support.microsoft.com/en-us/office/large-function-3af0af19-1190-42bb-bb8b-01672ec00a64

If you think the *original* (English) description needs changing, better open a new Bugzilla ticket here to fix that (and the translations will follow from there).

In any case, I have filed Bug 152292 to *first* make the English version consistent (which will avoid some unnecessary translations).
Comment 6 MarkOpen 2022-12-01 21:02:43 UTC
(In reply to Stéphane Guillou (stragu) from comment #5)
> Thank you Mark and Eike!
> 
> Regarding point 1):
> 
> My opinion is that a localisation that uses the letter "c" for the argument
> is a better strategy than changing the localised function name (less
> disruptive to users who are used to the current name, and makes it more
> consistent with English). I copied Piotr in for a more qualified opinion.
> 
> Regarding points 2) and 3):
> 
> I understand better now. The English help page is correct in its use of
> arguments names, for both functions (despite some inconsistency, see Bug
> 152292):
> 
> https://help.libreoffice.org/7.4/en-US/text/scalc/01/04060183.html
> 
> The Polish-language translation is confusing, as it talks about the K-th
> ("K-tą") largest/smallest value instead of using the proper argument name
> "rząd_K":
> 
> https://help.libreoffice.org/7.4/pl/text/scalc/01/04060183.html
> 
> This specific translation issue can be corrected in Weblate: 
> -
> https://translations.documentfoundation.org/translate/libo_help-master/
> textscalc01/pl/?checksum=e4e1e7f63b3df58c&q=K-t%C4%85&sort_by=-
> priority%2Cposition
> -
> https://translations.documentfoundation.org/translate/libo_help-master/
> textscalc01/pl/?checksum=9c9720e908f3f204&q=K-t%C4%85&sort_by=-
> priority%2Cposition
> 
> Note that the German translation also uses "K" in the function name and,
> misleadingly, in the description (the argument name doesn't use "K").
> For reference, the function description from MS Office:
> https://support.microsoft.com/en-us/office/large-function-3af0af19-1190-42bb-
> bb8b-01672ec00a64
> 
> If you think the *original* (English) description needs changing, better
> open a new Bugzilla ticket here to fix that (and the translations will
> follow from there).
> 
> In any case, I have filed Bug 152292 to *first* make the English version
> consistent (which will avoid some unnecessary translations).

Thanks Stéphane Guillou 

Ad.1. Eike Rathke spoke about changing the name of the function. 
In the Polish translation, arguments are marked with capital letters, e.g. "K". The suggestion of a lowercase "c" is against the accepted principle. My proposal does not interfere with the basic nomenclature adopted by Polish IT specialists. The uniformity of the Polish translation is more important than the consistency of individual letters with the English version. 
I agree that it would be enough to change the "K" argument to something like "P" (Pozycja-Position), "R" (Rząd-Row), "S" (Stopień-Stage) or "M" (Miejsce-Location). 
If my arguments are convincing, I consider the author of the Polish translation in "Help" to be the most competent to introduce corrections. 
Thank you!
Comment 7 QA Administrators 2024-12-01 03:12:24 UTC
Dear MarkOpen,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug