Bug 153010 - Inconsistency and confusing strings when numeric field's numbering format is not available for a language
Summary: Inconsistency and confusing strings when numeric field's numbering format is ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86-64 (AMD64) All
: low minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Number-Format Fields-Page-Number User-Locale
  Show dependency treegraph
 
Reported: 2023-01-13 17:40 UTC by Stéphane Guillou (stragu)
Modified: 2023-01-31 16:54 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
test ODT with Page Number fields vs other Statistics fields (18.93 KB, application/vnd.oasis.opendocument.text)
2023-01-13 17:40 UTC, Stéphane Guillou (stragu)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stéphane Guillou (stragu) 2023-01-13 17:40:09 UTC
Created attachment 184642 [details]
test ODT with Page Number fields vs other Statistics fields

If a Page Number field's numbering format (likely provided by libnumbertext) is not available for a specific language, a replacement string is used. It can be confusing to the user.

Steps:
1. Open attachment

Results:
If the localised formatting is not available for the language set on the field, some fallbacks are used. For example:

* "Ordinal-number 1" for format "1st, 2nd, 3rd..."
* "Ordinal 1" for format "First, Second, Third..."
* "1" for format "One, Two, Three"

This is different to what happens with number fields of the Statistics type. For those, the fallback is first the format for LibreOffice's current locale, and then those same fallback strings if the current LO locale doesn't have the format available either.

So there are two things to fix:
1) Inconsistency between "Page number" and "Statistics" fields. Fallback sequence should be consistent for all numeric fields.
2) The fallback strings can be improved, especially for non-English speakers.

I see two options to replace the strings:
A) Fall back to the default numbering "1, 2, 3.." (solution proposed by Khaled in bug 152985 comment 18)
B) Or display a (translatable) string that explains the issue to the user, e.g. "[numbering format not available for this language]". More informative as to what the issue is, but not very elegant since this big string is displayed in place of what is often a small number field.

A more involved solution that will make it less likely to see a fallback is to modify the Insert Field and Edit Field dialogs so the field's language can be changed in the dialog and only available formats are displayed, like in Calc Format Cell's dialog. However, unless the language can only be changed in the Edit Field dialog, a sensible fallback will still be needed when the language is later changed (for example when changing a whole paragraph's language).

More info:

The inconsistency in fallback started with 6.2 (previous versions didn't have the intermediate LO locale fallback for Statistics fields):

Version: 6.2.0.0.beta1
Build ID: d1b41307be3f8c19fe6f1938cf056e7ff1eb1d18
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3; 
Locale: en-AU (en_AU.UTF-8); UI-Language: en-US
Calc: threaded

Still present in master build from today:

Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 197e5f81213d14fdcbff40edf73385ecd4cd9815
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded
Comment 1 Dieter 2023-01-31 16:54:14 UTC
I confirm it with

Version: 7.5.0.2 (X86_64) / LibreOffice Community
Build ID: c0dd1bc3f1a385d110b88e26ece634da94921f58
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL threaded