Bug 145730 - Flip Impress templates when locale setting is set to RTL language
Summary: Flip Impress templates when locale setting is set to RTL language
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Impress (show other bugs)
Version:
(earliest affected)
7.2.1.2 release
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: RTL-CTL DoAsExtension
  Show dependency treegraph
 
Reported: 2021-11-17 08:10 UTC by Daniel Hevron Pereh
Modified: 2021-12-09 07:23 UTC (History)
4 users (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Hevron Pereh 2021-11-17 08:10:39 UTC
Description:
Many templates do not have centered design, not in the background design (like the DNA template) and not in the textbox placement (e.g When they are aligned to the sides or following the background design).
Those templates are designed for LTR languages reading flow (e.g Title on left, subtitle on right). When using an RTL language it renders most of them useless for RTL users. Flipped designs exists almost everywhere now. For example, If you set Gnome to Hebrew the sidebar will move to the Right and the top bar will be flipped to fit users that read in the opposite direction.

SUGGESTION:
Calc has a tickbox on the "Sheet" dropdown to enable RTL table - flipping the table. 
Maybe it is possible to implement a similar feature in Impress?

Great appreciation and respect for the devs :) 

Steps to Reproduce:
1. Go to settings -> language settings -> languages
2. Under Formats, change "Locale setting" to Hebrew. apply and restart.
3. Go to Impress.
4. Load a template.

Actual Results:
Backgrounds and textboxes placements are not flipped.

Expected Results:
Backgrounds and textboxes placements are flipped.


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.2.2.2
Build ID: 20(Build:2)
CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: gtk3
Locale: he-IL (en_IL.UTF-8); UI: en-US
Calc: threaded
Comment 1 Aron Budea 2021-12-01 02:49:44 UTC
That's an interesting idea. UX team, do you think this would work as a simple "trick" for RTL languages, or are there pitfalls to look out for?
Comment 2 Heiko Tietze 2021-12-01 08:44:24 UTC
The reading direction is an attribute of paragraph settings. It has an option "Use superordinate settings" which is slide properties. The value here is defined by the locale from tools > options. So the "Text direction" under slide properties would mirror the master objects.

* Using "Text Direction" for the master layout is not self-explanatory.
* Some background images may fill the whole page and need to be mirrored while other are placed somewhere left-handed and should be moved.
* This fails for templates done with RTL in mind.

I would prefer to ship RTL variants of the templates.
Comment 3 Eyal Rozenberg 2021-12-01 11:41:47 UTC
I partially agree with Heiko.

RTL is not just about reading direction, it applies to writing and layout and possibly other things; and it is not an attribute of paragraphs only, it is also an attribute of  the page/slide and of the entire document (the latter - at least in principle).

However, as Heiko points out, we have some UI for changing the page direction and the paragraph direction. Calc doesn't really have the equivalent of Writer and Impress' paragraphs-in-pages, so a global "flip direction" command makes more sense in Calc and less sense in Writer and Impress.

Then again, switching the presentation direction or the page direction, should, IMHO, switch from an LTR variant of a template to its RTL variant, without the user having to manually switch templates. And we might even want this to happen on the page levels.

Thus, either:

1. Templates are made to be direction-sensitive and include contents/settings for both directions, or
2. Templates should be linked, with a direction change triggering a switch to the linked template.

> I would prefer to ship RTL variants of the templates.

Does that mean you would support my second alternative?
Comment 4 Heiko Tietze 2021-12-02 09:23:27 UTC
(In reply to Eyal Rozenberg from comment #3)
> 1. Templates are made to be direction-sensitive and include
> contents/settings for both directions, or
> 2. Templates should be linked, with a direction change triggering a switch
> to the linked template.
> 
> > I would prefer to ship RTL variants of the templates.
> 
> Does that mean you would support my second alternative?

Don't get the "linked" argument. #1 means we care to make automatic switching possible (bound to slide properties > text direction) while #2 probably means to pick either <Candy>_LTR or <Candy>_RTL. 

I wouldn't do any automatic selection but pack different templates into the binary. It would be the duty of the l10n team to make sure RTL is covered properly.
Comment 5 Daniel Hevron Pereh 2021-12-02 09:37:23 UTC
(In reply to Heiko Tietze from comment #4)
> (In reply to Eyal Rozenberg from comment #3)
> > 1. Templates are made to be direction-sensitive and include
> > contents/settings for both directions, or
> > 2. Templates should be linked, with a direction change triggering a switch
> > to the linked template.
> > 
> > > I would prefer to ship RTL variants of the templates.
> > 
> > Does that mean you would support my second alternative?
> 
> Don't get the "linked" argument. #1 means we care to make automatic
> switching possible (bound to slide properties > text direction) while #2
> probably means to pick either <Candy>_LTR or <Candy>_RTL. 
> 
> I wouldn't do any automatic selection but pack different templates into the
> binary. It would be the duty of the l10n team to make sure RTL is covered
> properly.

As an RTL power user. LO is confusing enough for the average user to understand how to set it up for his locale. Could you believe that I didn’t know, up until now, the slide property you mentioned? If we talk accessibility- automatic selection is a better way to go. Most users just want to open the software, choose a template and have it corrected to his locale needs.
Comment 6 Heiko Tietze 2021-12-02 09:43:02 UTC
(In reply to Daniel Hevron Pereh from comment #5)
> If we talk accessibility- automatic selection is a better way to go. 

Text direction in slide properties is set automatically depending on your tools > options > language > locale setting.
Comment 7 Daniel Hevron Pereh 2021-12-02 09:46:55 UTC
(In reply to Daniel Hevron Pereh from comment #5)
> (In reply to Heiko Tietze from comment #4)
> > (In reply to Eyal Rozenberg from comment #3)
> > > 1. Templates are made to be direction-sensitive and include
> > > contents/settings for both directions, or
> > > 2. Templates should be linked, with a direction change triggering a switch
> > > to the linked template.
> > > 
> > > > I would prefer to ship RTL variants of the templates.
> > > 
> > > Does that mean you would support my second alternative?
> > 
> > Don't get the "linked" argument. #1 means we care to make automatic
> > switching possible (bound to slide properties > text direction) while #2
> > probably means to pick either <Candy>_LTR or <Candy>_RTL. 
> > 
> > I wouldn't do any automatic selection but pack different templates into the
> > binary. It would be the duty of the l10n team to make sure RTL is covered
> > properly.
> 
> As an RTL power user. LO is confusing enough for the average user to
> understand how to set it up for his locale. Could you believe that I didn’t
> know, up until now, the slide property you mentioned? If we talk
> accessibility- automatic selection is a better way to go. Most users just
> want to open the software, choose a template and have it corrected to his
> locale needs.

Sorry for cluttering. I take that back. Actually the second option is better. Maybe not with duplicates with suffix but choosing a template and having a checkbox at the bottom of the dialog for “RTL version”
Comment 8 Daniel Hevron Pereh 2021-12-02 09:48:21 UTC
(In reply to Heiko Tietze from comment #6)
> (In reply to Daniel Hevron Pereh from comment #5)
> > If we talk accessibility- automatic selection is a better way to go. 
> 
> Text direction in slide properties is set automatically depending on your
> tools > options > language > locale setting.

It is not.. at least for en_IL. I submitted a separate bug report for that.
Comment 9 Eyal Rozenberg 2021-12-02 20:26:39 UTC
(In reply to Heiko Tietze from comment #4)
> (In reply to Eyal Rozenberg from comment #3)
> Don't get the "linked" argument. #1 means we care to make automatic
> switching possible (bound to slide properties > text direction) while #2
> probably means to pick either <Candy>_LTR or <Candy>_RTL. 

But then, what if you have an RTL page in your presentation followed by an LTR one?

I meant the app would be aware of 2 separate templates, with each of the templates being fully-RTL or fully-LTR. Although, granted, it's a very problematic solution. What you suggest improves the current state of affairs somewhat - but I don't know if it's enough, since this isn't that important to me.
Comment 10 Heiko Tietze 2021-12-03 08:28:26 UTC
(In reply to Eyal Rozenberg from comment #9)
> But then, what if you have an RTL page in your presentation followed by an
> LTR one?

Good point. How about taking care of LTR/RTL in master slides so you can switch from one to the other but manually?
Comment 11 Eyal Rozenberg 2021-12-03 08:59:29 UTC
(In reply to Heiko Tietze from comment #10)
> (In reply to Eyal Rozenberg from comment #9)
> > But then, what if you have an RTL page in your presentation followed by an
> > LTR one?
> 
> Good point. How about taking care of LTR/RTL in master slides so you can
> switch from one to the other but manually?

You mean, with different master slides linked to different templates? Or with masters with different directionality in the same template? This sound like a homunculus suggestion. Anyway, I don't really see most users altering master slides; my (anecdotal) experience suggests that most people are deterred from working with them.
Comment 12 Heiko Tietze 2021-12-09 07:23:18 UTC
The topic was on the agenda of the design meeting but did not receive further input.

Having such a function fully automatic likely fails. Content might not be switchable, buggy RTL detection, etc. And while I'd prefer to ship dedicated RTL master slides (or have special RTL templates) the idea is tempting. Would suggest to realize this per extension.