Bug 139472 - Adding internal hyperlinks to unnamed slides causes links to break when switching UI languages due to link anchors pointing to the localised names
Summary: Adding internal hyperlinks to unnamed slides causes links to break when switc...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.0.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Hyperlink-Dialog Languages
  Show dependency treegraph
 
Reported: 2021-01-07 15:05 UTC by Gael Langlais
Modified: 2021-12-07 06:54 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
Test file with bug (14.37 KB, application/octet-stream)
2021-01-07 17:22 UTC, Gael Langlais
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gael Langlais 2021-01-07 15:05:58 UTC
###################
# 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.
Comment 1 Gael Langlais 2021-01-07 17:22:07 UTC
Created attachment 168756 [details]
Test file with bug
Comment 2 Buovjaga 2021-12-02 12:21:29 UTC
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
Comment 3 Heiko Tietze 2021-12-06 09:55:33 UTC
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.
Comment 4 Eike Rathke 2021-12-06 18:12:08 UTC
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).
Comment 5 Heiko Tietze 2021-12-07 06:54:30 UTC Comment hidden (off-topic)