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
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?
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.
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?
(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.
(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.
(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.
(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”
(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.
(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.
(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?
(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.
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.
*** Bug 154003 has been marked as a duplicate of this bug. ***