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.
Please, attach small document that demonstrates this problem
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.
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.
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)
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.
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é
We my switch language of UI to English, category "Table" will by default (Tools->Options, Language settings->Languages->User interface)
Well, alright. Seems like workarounds are preferred above clean code. Thank you for the trouble you took.
I can confirm this behaviour in the Swedish localization of LiO 4.2.4.2. 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".
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".
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.
Dear Bug Submitter, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INVALID due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team
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 4.2.7.2. 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.
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.0.5 or 5.1.2 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2016-04-16
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
Created attachment 134560 [details] cross reference exaple file
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. Regards, AnFr
*** Bug 112354 has been marked as a duplicate of this bug. ***
*** Bug 60360 has been marked as a duplicate of this bug. ***
Created attachment 138460 [details] Simple file created in spanish locale
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
*** Bug 109001 has been marked as a duplicate of this bug. ***
*** Bug 115856 has been marked as a duplicate of this bug. ***
@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
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.
(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.
*** Bug 119838 has been marked as a duplicate of this bug. ***
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.
(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.
(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.
Now I found a difference between my LO at work Version: 6.0.7.3 (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: 6.1.0.3 (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/6.0.7.3, there is a list of categories: [Keine] Abbildung Tabelle Text Zeichnung Figure Doing the same with LO/W10/6.1.0.3, there is a different list: [Keine] Abbildung Tabelle Text Zeichnung Abbildung 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.
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.
Dear André, 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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
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.
Created attachment 175186 [details] PDF export with LibreOffice 3.5.5.3
Created attachment 175187 [details] PDF export with LibreOffice 3.5.6.2
Hi, I've attached the PDF exports of the cross reference example file (2nd Attachment) generated with LibreOffice versions 3.5.5.3 and 3.5.6.2. 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.
*** Bug 128159 has been marked as a duplicate of this bug. ***
*** Bug 139971 has been marked as a duplicate of this bug. ***