Bug 151020 - Writer: Caption strings should be set to document language instead of UI language
Summary: Writer: Caption strings should be set to document language instead of UI lang...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
7.3.6.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Caption
  Show dependency treegraph
 
Reported: 2022-09-17 08:40 UTC by ajlittoz
Modified: 2023-03-16 12:54 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot (13.25 KB, image/png)
2022-10-07 10:28 UTC, Heiko Tietze
Details
Screenshot UI German, Document English (6.94 KB, image/png)
2022-10-07 10:45 UTC, Heiko Tietze
Details

Note You need to log in before you can comment on or make changes to this bug.
Description ajlittoz 2022-09-17 08:40:11 UTC
This is a follow-up to https://ask.libreoffice.org/t/working-with-different-language-documents/81898/

LO offers the possibility to separate UI language (menu, toolbars, …) from document language (both set in Tools>Options, Language Settings>Languages).

It is then expected that any action on text will be done according to document language.

This is correct for spell/grammar checking as document language "drips down" to Default Paragraph Style, then to all dependent paragraph styles.

However, this does not work when "synthesised" data is inserted into the document, as in the case of `Insert`>`Caption`. Captioning is driven by a dialog, hence this dialog is displayed in the UI language. But the Category drop-down menu also shows strings in the UI language whereas they should be in document language because this is where they will be inserted in the end.

Ideally, they should be in the insertion-position language but it is very difficult to determine which language to use in a multi-lingual document, though we can expect that captions will all be in document language for consistency.

I admit that language packs may not be installed as they are not necessary to type a document in any language. Language packs are only mandatory to change UI language. Without language packs, we lose functionality like spellchecking but this doesn't prevent from typing. So, captioning should try to "translate" the Category string if language pack is present and revert to UI language or en_US in last resort.

No sample file attached because the result depends on one's computer configuration not on the document.

Step to reproduce:

- configure LO fur different UI and document languages
1. create a new Writer document
2. Insert>Frame (any will do as we only caption it, just make it wide enough)
3. Insert>Caption

Result:
Caption category is in UI language

Expected result:
Caption category in document language

Version: 7.3.6.2
Build ID: 30(Build:2)
CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: kf5 (cairo+xcb)
Locale: fr-FR (fr_FR.UTF-8); UI: en-US
Calc: threaded
Comment 1 Dieter 2022-09-30 07:32:05 UTC
I confirm the described behaviour, but I don't see a big problem here, because you can add category in document language just with typing. This category is default category for all frames and is also available as category for captions in images. And you've also mentioned the problem of docments with mixed languages.

Anyway, it's more an enhancement request than a bug. So let's decide design-team

cc: Design-Team for further input and decision.
Comment 2 ajlittoz 2022-09-30 11:19:37 UTC
(In reply to Dieter from comment #1)
> you can add category in document language

Of course, but this is already considered advanced usage. This is the simplest solution to the problem but, since it requires some configuration, it is not immediate for newbies.

I submitted the report on behalf of a user asking on AskLO. Personally I would not mind if it is RESOLVED-WONTFIX/NOTABUG, your comment having reminded me about category customisation.
Comment 3 Dieter 2022-10-01 04:39:00 UTC
(In reply to ajlittoz from comment #2)
> (In reply to Dieter from comment #1)
> > you can add category in document language
> 
> Of course, but this is already considered advanced usage. This is the
> simplest solution to the problem but, since it requires some configuration,
> it is not immediate for newbies.

Yu only have to recognize, that you can type in category field. I wouldn't call this a "configuration". And even help says: "Select the caption category, or type a name to create a new category." https://help.libreoffice.org/7.4/en-GB/text/swriter/01/04060000.html?System=WIN&DbPAR=WRITER&HID=modules/swriter/ui/insertcaption/dialog-action_area1#bm_@@nowidget@@
Reading help page should always be possible.
Comment 4 Heiko Tietze 2022-10-07 09:28:23 UTC Comment hidden (off-topic)
Comment 5 Dieter 2022-10-07 10:23:05 UTC Comment hidden (off-topic)
Comment 6 Heiko Tietze 2022-10-07 10:28:39 UTC Comment hidden (off-topic)
Comment 7 Dieter 2022-10-07 10:39:44 UTC Comment hidden (off-topic)
Comment 8 Heiko Tietze 2022-10-07 10:45:19 UTC Comment hidden (off-topic)
Comment 9 Dieter 2022-10-07 10:58:17 UTC Comment hidden (off-topic)
Comment 10 Heiko Tietze 2022-10-07 11:36:05 UTC
Maybe I've read too many tickets about the assigned language. 

Anyway, the "document language" coming from tools > options is applied to the Default PS and subordinate PS, and should be used for the category labels. Using the PS language means to get on one paragraph "Drawing" and on the other "Zeichnung". Makes not much sense to me. And hard to imagine that generating a ToC for both names is possible and meaningful.

But using the UI language as today is also not a good solution. So the question boils down to what the "document language" is. Perhaps we always take what is define in tools > options and ignore the setting in PS/CS, which is rather meant for spellcheckers.

Alternatively, overwriting the category with "Ilustración" is very simple and does the trick, as Dieter commented in c1.
Comment 11 Eyal Rozenberg 2022-11-01 21:49:35 UTC
(In reply to Dieter from comment #1)
> but I don't see a big problem here

It's not a big problem, but it is _a_ problem, so setting this to "minor" rather than "enhancement".

> So the question boils down to what the "document language" is.

(In reply to ajlittoz from comment #0)
> LO offers the possibility to separate UI language (menu, toolbars, …) from
> document language (both set in Tools>Options, Language Settings>Languages).

Tools>Options, Language Settings>Languages doesn't set the document language, and, in fact, doesn't even set the _default_ language. How come? Suppose you choose English for the Western language group (LG) and Arabic for the RTL-CTL LG. Which of these is the default document language? Not clear.


> Ideally, they should be in the insertion-position language but it is very
> difficult to determine which language to use in a multi-lingual document,

Why? We have an indication for this right now in the bottom status bar...

(In reply to Heiko Tietze from comment #10)
> Anyway, the "document language" coming from tools > options is applied to
> the Default PS and subordinate PS, and should be used for the category
> labels.

See my comment above about that.

Also - do you mean PS as in Page Style, or Paragraph Style? The Page Style dialog does not have a language setting/indication anywhere.

> So the
> question boils down to what the "document language" is. Perhaps we always
> take what is define in tools > options and ignore the setting in PS/CS,
> which is rather meant for spellcheckers.

Nope, we need a proper document language. Does the ODF spec have one?
Comment 12 Heiko Tietze 2022-11-08 09:45:34 UTC
This topic was on the agenda of the design meeting but did not receive further input. The proposal might work in some scenarios but could be unwanted in other. Changing the string is very easy. Let's keep the ticket.
Comment 13 Eyal Rozenberg 2022-11-25 15:04:52 UTC
Well, apparently, we currently don't even have a document language, so it is impossible to set captions to the "document language". On the other hand, we could in principle have one, according to the ODF spec - but ignore that. See bug 151906 for a discussion of this mess.