https://bugs.documentfoundation.org/show_bug.cgi?id=139472
--- Comment #4 from Eike Rathke <[email protected]> --- 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). -- You are receiving this mail because: You are the assignee for the bug.
