Bug 168080 - Do not use localized dummy text for master slide templates
Summary: Do not use localized dummy text for master slide templates
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
25.2.5.2 release
Hardware: All All
: high normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevAdvice
Depends on:
Blocks: Master-Slide
  Show dependency treegraph
 
Reported: 2025-08-23 19:26 UTC by Eyal Rozenberg
Modified: 2025-09-11 09:11 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
LO 25.2 Before-and-after expansion of Insert menu (160.42 KB, image/png)
2025-08-25 09:05 UTC, Eyal Rozenberg
Details
A template with Hungarian placeholder text (2.80 MB, application/vnd.oasis.opendocument.presentation-template)
2025-09-10 18:30 UTC, Eyal Rozenberg
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eyal Rozenberg 2025-08-23 19:26:55 UTC
Steps to reproduce:

1. Download the LibOCon 2025 presentation template: https://nc.xport.hu/s/27bPKpqSPrJdecK
2. Create a new presentation with the template, or open the template for editing
3. View > Master Slides
4. Choose some master

Expected result:
Placeholder text shown in the language of your LibreOffice UI.

Actual result:
Placeholder text shown in Hungraian. Not sure where exactly that originated, but the template was created by people in Hungary, so, they had Hungarian chosen in all sorts of places I suppose.

And - you can't make it switch to English (or your LO UI language) either!
Comment 1 Heiko Tietze 2025-08-25 08:28:51 UTC
I agree with the use case. Sometimes you might want to configure a template for a certain language but often it should be using the setting from the workstation.

Text boxes take the language defined for new documents in tools > options > language & locales. We could either not store resp. remove the locale settings (as Laurent did manually for the shipped templates). In this case you cannot create a template for a certain language, which is odd. Or we introduce some "Automatic" language option (or some other flag), and do not store the attributes then.
Comment 2 Eyal Rozenberg 2025-08-25 08:46:40 UTC
(In reply to Heiko Tietze from comment #1)

> I agree with the use case. Sometimes you might want to configure a template
> for a certain language but often it should be using the setting from the
> workstation.

Let us think about the first part of that statement. When we're talking about placeholder text - which the user has not even entered themselves and was just generated by LO - when is it ever the case that the creator of the template wants to force other people to see the placeholder text in the creator's language? I can't think of such a situation, or of the benefit. (If it were the creator providing the placeholder text, that would be something else.)

> Text boxes take the language defined for new documents in tools > options >
> language & locales.

1. I am reminded of bug 144814 ...
2. Which language exactly, within that part of the options dialog?
3. Isn't it the case that _no_ language is taken, because of the language trichotomy? i.e. what's taken is only the choice of language within each group
4. Is this is true for the choice of language in placeholder text as well?

> We could either not store resp. remove the locale
> settings (as Laurent did manually for the shipped templates). In this case
> you cannot create a template for a certain language, which is odd.

... although it's already actually the case, because of the language trichotomy, IIANM.

> Or we
> introduce some "Automatic" language option (or some other flag), and do not
> store the attributes then.

Do you mean introduce a property for objects?

But - why should placeholder text respect the language/locale of the object in which it's rendered? And what if that language doesn't support freestyle text, e.g. it's music, or a programming language?

---

Finally, I believe this counts as a bug: This behavior is not something the creator intended; nor something the user of the template or presentation wants. It might not be a coding bug, but a planning/feature design bug - and still, a bug.
Comment 3 Eyal Rozenberg 2025-08-25 09:05:45 UTC
Created attachment 202498 [details]
LO 25.2 Before-and-after expansion of Insert menu

In this example, the vertical screen resolution is 800 pixels, and LO is not maximized (but does take up over 80% of screen height). We see:

* Upwards expansion to fit the full menu
* A covering of the "Insert" menu item, and several other menu items as well
* A covering of the title bar
* An inadvertant expansion of a submenu which the user did not intend


So, it's not just the expansion itself, it's also the weird and confusing horizontal placement. Heiko, if you like, we could separate the two bug reports - vertical aspect and horizontal aspect.
Comment 4 Eyal Rozenberg 2025-09-10 18:30:31 UTC
Created attachment 202783 [details]
A template with Hungarian placeholder text

This template was created in a Hugarian locale - and we see the placeholder text in Hungarian even if we open the presentation with an English locale.
Comment 5 Heiko Tietze 2025-09-11 09:11:15 UTC
The presentation contains for example <draw:frame presentation:style-name="Mpr2"...presentation:class="title"><draw:text-box><text:p>Címszöveg formátumának szerkesztése</text:p>. These placeholder text must not be localized neither in the normal view ("Click to add Title" works for me) nor in the master view ("Címszöveg formátumának szerkesztése" doesn't). => bug