################### # Problem description: ################### When creating a link pointing to another section of the same document, this link get broken if you change the Impress UI language. ################### # How to reproduce: ################### 1. Open Impress and set the UI language to English (Tools > Options > Language settings > Languages > Language Of (User Interface) = English (UK) 2. Click OK 3. Create 2 Slides. 4. On the first slide create 2 lines of text Ex: - English - Frensh 5. Hihgtlight English and press CTRL + K to create a link 6. Select Document and in target use the sight icon to select the slide N°2 for exemple. 7. Save the file 8. Repeate step 1 and 2 and select "Frensh" instead of "English (UK)" 9. Restart Impress and reopen the file. 10. Press F5 to start the presentation and try to click the link => It shouldn't work. 11. Now still on the first slide Hihgtlight "Frensh" and press CTRL + K to create a link 12. Select Document and in target use the sight icon to select the slide N°2 for exemple. (Notice the the link doesn't say "Slide 2" but "Diapo 2") 13. Save the file 14. Start the presentation and try to click the links: The frensh will work only when the UI is in frensh and the english only when the UI is in english.
Created attachment 168756 [details] Test file with bug
Reproduced and adjusted summary to reflect the root cause. As seen in the test file, the anchor is #Diapo 3, the default French name for the slide. If you explicitly rename the slide to something other than the default name, internal links will not break. Adding design team because I can't think of a good way to solve this. Arch Linux 64-bit Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: ac21d937690c1ef995df22e11384e0fab226472e CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded Built on 2 December 2021
We clearly need a non-translated URL <text:a xlink:href="#Slide 2" xlink:type="simple"> But #Slide<> becomes #Folie<> in German. Or Diapo in French. No idea if that's possible; the alternative is to iterate through all xlink:href, check whether it targets the document and translate default terms into the local language.
Geez.. why am I Cc'ed on every stupid implementation decision bug as soon as it involves localized content.. A programmatic anchor name that doesn't depend on UI language and doesn't get translated would be best. However, that still wouldn't help against the current translated link#anchor names, for the same reason that iterating and collecting anchor names and translating them to the current language wouldn't work: the originating translation is unknown. Only the current UI language's translation of "Slide" is known. However, the underlying problem is that the actual anchor is not written to file. While there is the xlink:href="#Slide 2" on the link, there is absolutely no indicator (in file) that the <draw:page draw:name="page2"> would be the corresponding target. That seems to be made up by Impress internally, using the then current UI name, which of course may not match. If the anchor target was saved and loaded, the actual translation wouldn't even matter. What then may get confusing is having several languages showing up as anchors in the dialog when editing links in different UI localizations, but that's just cosmetic and could be addressed by internally collecting the then known anchors under the current UI name (just a quick idea).
(In reply to Eike Rathke from comment #4) > Geez.. why am I Cc'ed on every stupid implementation decision bug as soon as > it involves localized content.. Happens when you are the expert ;-). But message received, will add you only at the interesting topics. Thanks for the comment.
Dear Gael Langlais, 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
- Reproduced in OOo 3.3 -> inherited. - Still reproduced in a recent trunk build, in Draw as well (although careful: if testing with the same two languages, French and English, "Page" is the same word, so might look like it does work in Draw :) ) - Likely needs the same solution as for bug 105282, but as that one focuses on form controls, keeping separate as the update mechanism might be different. - Interestingly, sd has at some stage been able to follow pages around and update hyperlinks accordingly, as seen prior to the "slide -> page" rename. Regression is in bug 160162. Maybe something interesting there?