Bug 44451 - References ( Illustration, Tables) don't work if the file is open with a UI language different than the one used to create it
Summary: References ( Illustration, Tables) don't work if the file is open with a UI l...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected)
Inherited From OOo
Hardware: All All
: high major
Assignee: Not Assigned
: 60360 109001 112354 128159 (view as bug list)
Depends on:
Blocks: Fields-Cross-Reference Writer-UX Caption
  Show dependency treegraph
Reported: 2012-01-04 06:58 UTC by André
Modified: 2021-09-29 12:59 UTC (History)
23 users (show)

See Also:
Crash report or crash signature:

Problem demonstration/description (12.78 KB, application/vnd.oasis.opendocument.text)
2012-02-22 06:54 UTC, André
cross reference exaple file (376.40 KB, application/zip)
2017-07-09 17:03 UTC, AnFr
Simple file created in spanish locale (22.11 KB, application/vnd.oasis.opendocument.text)
2017-12-15 12:11 UTC, Xisco Faulí
PDF export with LibreOffice (54.94 KB, application/pdf)
2021-09-22 07:17 UTC, AnFr
PDF export with LibreOffice (54.90 KB, application/pdf)
2021-09-22 07:18 UTC, AnFr

Note You need to log in before you can comment on or make changes to this bug.
Description André 2012-01-04 06:58:38 UTC
In the German version of Writer the corresponding category for captions is "Tabelle". When writing English texts, an additional category "Table" is to be created by the author. This is possible during a session and everything works fine. When LibreOffice is closed and the document reopened everythings seems to fine still. But upon F9 (refreshing fields) references to "Table" turn into "Tabelle" and the category "Table" has disappeared, existing captions are linked to "Tabelle". This happens ONLY with caption "Table". All other self-created captions seem to work as supposed to.
Comment 1 sasha.libreoffice 2012-02-16 03:20:29 UTC
Please, attach small document that demonstrates this problem
Comment 2 André 2012-02-22 06:54:14 UTC
Created attachment 57467 [details]
Problem demonstration/description

Hi Sasha,
I included a document, the problem has changed somewhat. The caption categories "Table" (newly created) and "Tabelle" (German default option) are still somehow interlinked and not clearly seperated.
Comment 3 sasha.libreoffice 2012-02-22 21:30:21 UTC
Thanks for attachment.
I see in document 2 pictures in frames. So, I have question:
How this document created? Please, write step-by-step instruction.
Comment 4 André 2012-02-23 05:42:29 UTC
The tables themselves were pasted as GDI-Meta files (Ctrl+C in Calc, Ctrl+B-->H in Writer), which I like to do. Following that I mark the tables (GDI-images) and give it a caption (via right-click or Insert-->Caption). In the caption-window I can choose "Tabelle" (in German). Instead I create the new category "Table".

When I make a table in Writer itself, Insert-->Caption doesn't work (which is another issue or maybe my stupidity)
Comment 5 sasha.libreoffice 2012-02-23 07:09:15 UTC
Thanks for additional explanations. Described behaviour reproduced in Russian locale. Word "Table" indeed is reserved word. It automatically translated.
And where is problem? Word "Table" need be typed each time when document is opened?

To add caption to table, just place cursor into table and right click->Caption. Caption appears below of table. No frame appears. If frame needed, select caption with table and Insert->Frame, then check there "Automatic" for Width, press Ok.
Comment 6 André 2012-02-23 08:36:15 UTC
Ok, adding captions to a table created in Writer works. I swear it didn't work yesterday. But that's not the problem.

The problem is, that the newly created category "Table" does not appear in the dropdown menu for captions after saving and reopening the document. When I create it again, numbering starts from 1. After saving and reopening and F9, numbering is ok (so it is no longer a serious problem (as it used to be until a few months ago), only anoying)

Thanx. André
Comment 7 sasha.libreoffice 2012-02-23 21:19:29 UTC
We my switch language of UI to English, category "Table" will by default
(Tools->Options, Language settings->Languages->User interface)
Comment 8 André 2012-02-24 01:48:44 UTC
Well, alright. Seems like workarounds are preferred above clean code.
Thank you for the trouble you took.
Comment 9 Daniel 2014-07-07 14:08:20 UTC
I can confirm this behaviour in the Swedish localization of LiO I do not think switching the UI to English can be considered a "solution" for this. For me, this bug is specially irritating in conjunction with cross references. Here is what happens:
1. Create an english text document using the Swedish UI
2. Create a table, insert a caption. In the dialog, I chose "Table" as caption, as opposed to "Tabell" which is the Swedish default.
3. The caption displays fine as "Table 1: ...".
4. Insert a cross reference to the table, with caption and number. Displays as expected as "Table 1".
5. Close and re-open the document. The cross reference now displays as "1", i.e. the caption has gone.
6. Investigating the field at the table, it turns out that the counter category has changed from "Table" to "Tabell". Since the captions still is "Table 1: ..." (i.e. the counter name is different from the text before the "1"), the reference only shows the number.
7. If I change the text before the numbered field in the table caption from "Table" to "Tabell", the cross reference again displays the caption and number ("Tabell 1"), but this is not what I want. I need it in English.

This bug makes is impossible to write English documents in a UI other than English, which essentially renders the effort of localizing the UI useless. Therefore, I do not think this bug should be "resolved".
Comment 10 sasha.libreoffice 2014-07-08 11:03:32 UTC
Possible workaround: use Greek Tau instead of Latin T in word "Table".
It may be done for example so: in text use Insert->Special character, then insert character U+03A4, then copy it and then use Insert->Caption and paste it instead of T in word "Table".
Comment 11 Jochen 2014-08-02 17:05:34 UTC
Hi André,
I can´t confirm a bug (LO 4.2.4; OS: Windows 8.1)
Your example works fine for me.
If you want discuss your problem on the german de-discuss-ML: describe in German the problem and all steps (step-by-stp). Note also 1) link to this bug (44451); 2) REOPEN-Status (now NEEDINFO); 3) my recommendation to discuss on the german de-discuss-ML and not on the german de-user-ML.
CAVE: on de-discuss-ML attachments are not possible.
Comment 12 QA Administrators 2015-04-01 14:47:05 UTC Comment hidden (obsolete)
Comment 13 Daniel 2015-04-02 07:09:50 UTC
I cannot see why this bug is in NEEDINFO status. In comment 9 I gave a detailed description of what happens in my LiO, and this behaviour is still valid in Moreover, the only solutions presented are workarounds, implying switching the UI language to English. This is not an accepted solution.
If more info is needed, please specify more in detail what you need. Setting to NEW again, because I consider this bug is confirmed since it affects multiple users.
Comment 14 tommy27 2016-04-16 07:26:26 UTC Comment hidden (obsolete)
Comment 15 QA Administrators 2017-05-22 13:22:20 UTC Comment hidden (obsolete)
Comment 16 AnFr 2017-07-09 17:03:36 UTC
Created attachment 134560 [details]
cross reference exaple file
Comment 17 AnFr 2017-07-09 17:18:27 UTC
Due to change from AOO to LibreOffice I've discovered the same BUG.

The cross-reference 'Category' depends on the UI language.
The Attached ZIP includes the ODT file and PDF exports out from different LibreOffice revisions and the AOO 4.1.1.

From OpenOffice.org up to LibreOffice 3.5 and AOO the referenced Category Text is the Text before the Numbering Field to begin of the line or begin of the cell.

Beginning with LibreOffice 3.6 the referenced Category Text is the UI language depending Category.
The Category and the Text in front of the Numbering Field must contain the exact Category Name. Else only the Number is referenced.

Looking into the attached example the Cross-References are not clearly to identify as Table or Illustration a printed version.


Comment 18 Xisco Faulí 2017-12-15 12:06:21 UTC
*** Bug 112354 has been marked as a duplicate of this bug. ***
Comment 19 Xisco Faulí 2017-12-15 12:07:32 UTC
*** Bug 60360 has been marked as a duplicate of this bug. ***
Comment 20 Xisco Faulí 2017-12-15 12:11:04 UTC
Created attachment 138460 [details]
Simple file created in spanish locale
Comment 21 Xisco Faulí 2017-12-15 12:16:04 UTC
Hi Tamás,
I see you have done some works with cross-references recently.
Do you think you could take a look at this bug at some point?
IMHO, it's quite critical as the document as broken if they are open in LibreOffice using a different language than the one used to create them
Comment 22 Xisco Faulí 2018-01-22 15:04:24 UTC
*** Bug 109001 has been marked as a duplicate of this bug. ***
Comment 23 Xisco Faulí 2018-02-23 11:50:41 UTC
*** Bug 115856 has been marked as a duplicate of this bug. ***
Comment 24 Xisco Faulí 2018-02-23 11:54:49 UTC
@Miklos, @Mike, @Michael, any thought here?
From my point of view, it's a major issue as the references get broken if the document is opened with LibreOffice in another language
Comment 25 Miklos Vajna 2018-02-23 12:49:20 UTC
This is not the only area where this happens, e.g. if you use formulas in Writer tables, then there is no code to translate between localized UI formulas and in-file English formulas.

I agree that it's annoying and needs fixing, but it's not new at all.
Comment 26 Mike Kaganski 2018-02-23 16:15:24 UTC
(In reply to Miklos Vajna from comment #25)
> e.g. if you use formulas in
> Writer tables, then there is no code to translate between localized UI
> formulas and in-file English formulas.

I am unsure if we can use localized formulas in Writer - cf. tdf#61228.
Comment 27 Xisco Faulí 2018-09-13 09:04:18 UTC
*** Bug 119838 has been marked as a duplicate of this bug. ***
Comment 28 Robert 2019-01-07 12:49:42 UTC
For me this bug is not (only) a problem of the UI language. I use Libre Office version 6... (German) on two computers, one with Windows 10 at home and another with Windows 7 at work. I cannot use the same files (...ODT) on both computers with Libre Office. I should mention, that it works with Apache Open Office, so at the time, I use AOO at work and LO at home with the same files (without problems, this is my current workaround).
If I create a new document at work with LO and create some pictures using a new category "Abbildung" and then open this document at home, at the first view, everything seems to be ok. Than I simply copy one picture (including frame and caption) and see, that the number is not increased. So I have two "Abbildung" with the same number. Creating a new picture with caption now offers two "Abbildung" in the selection of caption categories (beside Text, Figure, etc.). So they are not distinguished by language (may be by font ??? But I use Arial on both computers).

Next test: I create a new document at home with "Abbildung". Then I open this document at work and the catagory is not seen in the text at the references, only the number is shown (to remind, with AOO it is opened without such problems on the same computer). The full caption is ok, "Abbildung" is shown in the list of references and I can also select the whole caption e.g. "Abbildung 5: Schaltung XY". But it is not possible to get only "Abbildung 5", there will be always only "5".
For me this problem is new since I have a new computer at home (64 bit Windows 10 instead of 32 bit Windows 7) with a new installed Libre Office.

I hope, someone finds this bug.
Comment 29 Robert 2019-01-09 06:31:05 UTC
(Extension to Robert from comment #28)
Because it is ok with AAO but not with LO on my W7 computer, I try to find differences between LO and AAO with the same document.
This morning I have detected, that the Tool Tip (mouse positioned on an object) showing the number itself at the captions number is missing with LO, but present with AAO.
I think, that is a hint for some information missing from the caption prepared in the management of LO, so there is no link between the reference and the captions and the category "Abbildung" is not restored in the text.
The Tool Tip on the reference number is "Figure", in LO and in AAO. Because AAO shows the correct "Abbildung" in the reference, the bug ia not with the caption stored in the document but with the preparation of handling the caption in LO.
The list of captions in the menue is the same with both, AAO and LO.
Comment 30 Robert 2019-01-09 06:43:04 UTC
(a little correction to comment #29)
There are 4 figures in my document. The Tool Tip is only missing on the captions of number 3 and 4, 1 and 2 shows the Tool Tip. AAO shows the Tool Tip at all numbers.
Comment 31 Robert 2019-01-17 07:46:30 UTC
Now I found a difference between my LO at work
Version: (x64)
Build-ID: dc89aa7a9eabfd848af146d5086077aeed2ae4a5
CPU-Threads: 4; BS: Windows 6.1; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group
and my LO at home
Version: (x64)
Build-ID: efb621ed25068d70781dc026f7e9c5187a4decd1
CPU-Threads: 8; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: CL

When I create a new caption for a picture with LO/W7/, there is a list of categories:

Doing the same with LO/W10/, there is a different list:

So instead of "Abbildung" and "Figure" in one list I have two "Abbildung", which from my point of view cannot be OK.

When I create a caption Abbildung with LO/W7/... and copy the frame, the caption number is increased. Now opening the same file with LO/W10/... and copy a frame, the numbering of "Abbildung" starts with "1". So obviously, the two LOs do not use the same instance. One uses an instance of "Abbildung" and names ist "Abbildung" and the other uses an instance of "Figure" and names ist also "Abbildung" (or something like that).

I hope, this is a valuable hint for the experts.
I do not dare to update LO on my W7 computer, because it feels, that the older version with "Abbildung" and "Figure" is more correct.
Comment 32 Robert 2019-01-17 08:48:24 UTC
Sorry, I did not recognize that there is a new version.
With 6.1.3 there is a new category "Schaubild" instead of the second "Abbildung".
I will test everything later, now I have to do my work with LO.
Thank You very much (!!!!!) for being so engaged.
Comment 33 QA Administrators 2021-07-06 04:00:07 UTC Comment hidden (obsolete)
Comment 34 RGB 2021-07-06 14:40:49 UTC
Problem still present in recent versions, including 7.2 beta 1.

Steps to reproduce:

- Create a document with a figure and a table with Spanish UI
- Insert cross-references to them as "Categoría y número" (Category and Number). You'll see the fields "Figura 1" and "Tabla 1" correctly inserted
- Change the language UI to English and reopen the document

When reopened, everything looks OK, but as soon as you make ANY change in the document, the category is deleted and only the number remains: "Figura 1" turns into just "1" and "Tabla 1" turn into just "1." Inserting again the cross-reference is also broken: even if you select "category and number" only the number is inserted. 

Going back to the Spanish UI is the other way round: as soon as you make any change, the fields get fixed.
Comment 35 AnFr 2021-09-22 07:17:35 UTC
Created attachment 175186 [details]
PDF export with LibreOffice
Comment 36 AnFr 2021-09-22 07:18:23 UTC
Created attachment 175187 [details]
PDF export with LibreOffice
Comment 37 AnFr 2021-09-22 08:05:04 UTC

I've attached the PDF exports of the cross reference example file (2nd Attachment) generated with LibreOffice versions and

My observations: 
1) The change is done between the 3.5.5 and 3.5.6 versions and is not inherited from OOo.
2) Up to LibreOffice 3.5.5 by selecting 'category' and 'number' in a cross-reference results in the text before the referenced numbering field and the number in the category.
3) Beginning from LibreOffice 3.5.6/3.6.x by selecting 'category' and 'number' in a cross-reference results in the category name and the number in the category. But the category name is not visibly used in the reference field.
Comment 38 Timur 2021-09-29 12:59:44 UTC
*** Bug 128159 has been marked as a duplicate of this bug. ***