It is *expected*, that for respective locales, the support (checkboxes in Options->Languages and Locales->General) is enabled *automatically*, by default. Using Version: 24.2.3.2 (X86_64) / LibreOffice Community
Build ID: 433d9c2ded56988e8a90e6b2e771ee4e6a5ab2ba
CPU threads: 24; OS: Windows 10.0 Build 22631; UI render: Skia/Vulkan; VCL: win
Locale: ar-AE (ru_RU); UI: en-US
Calc: CL threaded

with a clean profile, choosing the ar-AE locale checks the CTL checkbox unconditionally (and even makes it inactive  it, so that I can't disable it). Setting locale to ja-JP does the same with Asian checkbox.

The locale is *by default* taken from OS. Thus, it is *expected* that the newly installed LibreOffice already enables support for the language groups that correspond to the user locale.

So:
1. If this doesn't work in general, this is a bug and a regression;
2. If it doesn't work for a specific locale, it is a bug;
3. If it doesn't work for some OS, this is a bug;
4. If this is not enough, this needs specific description of the problem and wanted behavior.

(In reply to Mike Kaganski from comment #1)
> with a clean profile, choosing the ar-AE locale checks the CTL checkbox
> unconditionally (and even makes it inactive  it, so that I can't disable
> it). Setting locale to ja-JP does the same with Asian checkbox.

Choosing where?

> The locale is *by default* taken from OS.

Do you mean the UI language?

(In reply to Eyal Rozenberg from comment #2)
> Choosing where?

I choose it in Options->Languages and Locales->General, to test hos locales affect this. For a just-installed LO instance, that option has a default value taken from OS.

> > The locale is *by default* taken from OS.
> 
> No, I mean locale. UI language is also taken from OS, true; but here, I only tested the effects of locale on this (and actually, I didn't test UI language effects, which might also exist).

(In reply to Mike Kaganski from comment #3)
> I choose it in Options->Languages and Locales->General, to test hos locales
> affect this.

That is not what I'm talking about. I'm taking about arranging it so that when I start a clean, empty profile - and I'm on a system and with a user profile or session which one can surmise involves use of RTL-CTL/CJK languages - then LibreOffice will start with full RTL-CTL / CJK support (respectively) enabled.

That does not seem to happen at the moment.

The user should not have to choose anything. Effects of active user choices are not what this bug is about

> For a just-installed LO instance, that option has a default
> value taken from OS.

Are you saying that:

1. Locale is taken from the US and
2. RTL-CTL/CJK toggles are set or unset based on that locale and lacking explicit user setting

I don't think so. Or at least, Not in my limited experience. Just tried this again on Windows with bother Hebrew and English (US) as the "locale for non-Unicode applications" (and with English and Hebrew as keyboard languages); RTL-CTL was not enabled. 

... but that is also not very relevant. I mean, locale is actually a multitude of setting: language, numeric, time, etc. ; and there's also the timezone; and there are locales which are themselves mixed. For example, if my (single) locale is say, en_HK - does that ensure both options get set? CJK because its Chinese, and RTL-CTL because of the Indonesian language plus Arabic for the Muslims?


Actually... what I said above makes me wonder if the component I chose is correct, i.e. is this an installation problem or a clean-profile-startup problem.

(In reply to Eyal Rozenberg from comment #4)
> (In reply to Mike Kaganski from comment #3)
> > I choose it in Options->Languages and Locales->General, to test hos locales
> > affect this.
> 
> That is not what I'm talking about. I'm taking about arranging it so that
> when I start a clean, empty profile - and I'm on a system and with a user
> profile or session which one can surmise involves use of RTL-CTL/CJK
> languages - then LibreOffice will start with full RTL-CTL / CJK support
> (respectively) enabled.
> 
> That does not seem to happen at the moment.
> 
> The user should not have to choose anything. Effects of active user choices
> are not what this bug is about

Are you specifically trying to behave as if you don't see what I meant? Bye.

(In reply to Mike Kaganski from comment #5)
> 
> Are you specifically trying to behave as if you don't see what I meant? Bye.

No, I just don't see what you meant.

AFAICT, "If this doesn't work in general, this is a bug" is the case. Am I mistaken? I might be.

If it works for Western languages, that doesn't count of course, because then, no action is needed, so nothing needs to work.

Changing the locale works as expected, confirming comment 1. If you talk about which locale is used as initial default it should of course take what is configured on the OS/DE.

(In reply to Heiko Tietze from comment #7)
> Changing the locale works as expected,

Not sure what you mean.

* What is "the" locale? 
* Changing it where?
* What is your expectation?

Now, I have to admit I am also guilty of not being clear about the locale part.

On a Windows system, there is the "language to use for non-Unicode programs" setting; there is the set of enabled keyboard layouts (and the default one), there is the choice of "country", there is "regional format" and maybe other settings.

On a Unix-like system, we have the different environment variables: LANG LANGUAGE LC_CTYPE LC_MESSAGES LC_ALL, and there's also /etc/timezone . We also have the DE UI language, and we have the set of keyboard layouts.


> confirming comment 1.

I didn't understand comment 1. If things "worked as expected" I would not file this bug.

I don't understand why you're dismissing this so blithely, this is actually a rather fundamental problem which came up in our chat with Jonathan (who I am CCing) as an example of something we are so used to having fixed personally long ago, so that we no longer notice its significance to new users.

(In reply to Eyal Rozenberg from comment #8)
> I didn't understand comment 1.

Oh?

I wrote there explicitly, what is *expected* to work. Specifically, I *cared* to mention, that the wanted "support" is *expected* to be enabled automatically, when the LibreOffice locale (the thing that is set in Options->Languages and Locales->General, "Locale setting") is set to a locale that needs that. I further said explicitly, that it is *expected* that this locale setting is *set* automatically according to the OS settings (whichever algorithm there is). I honestly believe, that you simply refuse to communicate.

I even wrote explicitly, that *if* it doesn't work for a *specific* OS, or a specific locale, then that is a bug - and someone slightly familiar with the bug tracker would indeed understand that the specific report is needed. like "I use OS ABC; my locale settings in the OS are XYZ; I install LO using this method; immediately after installation, I check the LibreOffice locale setting, and it is ...; and when I look at the Asian / CTL checkboxes there on the same options page, I see unexpected ... - my expectation is ..."

Me supported the request too, pending confirmation by QA. Don't think UX can contribute more to the topic.

(In reply to Heiko Tietze from comment #10)
> Don't think UX can contribute more to the topic.

Actually, UX can, at least in the following senses:

* Sometimes, enabling support is obvious; sometimes, there's no indication in favor of it; and sometimes, there's some indication (for example: You're using a Western locale, UI etc. in a country in which a fraction of the population is Muslim) . How far do we bias in favor of enabling RTL-CTL or CJK in such cases? i.e. where on the spectrum should we be?

* Is it acceptable and is it reasonable to place explicit checkboxes for RTL-CTL and for CJK in the installation program (assuming it's not a DEB/RPM and such)?

* Is it really better to apply a heuristic, or should we just always-enable as is suggested in bug 161258? Do the detriments of enabling support for all languages outweigh the benefit of potential use?

(In reply to Mike Kaganski from comment #9)

> I further said explicitly, that it is *expected*
> that this locale setting is *set* automatically according to the OS settings
> (whichever algorithm there is). 

Ok, so that's what I misunderstood.

Anyway, I'm not even sure that makes sense. I mean, if I download a localized version from the libreoffice.org website, shouldn't that locale trump whatever LO determines as the OS locale?

Regardless of what locale is set, there's the 


> I even wrote explicitly, that *if* it doesn't work for a *specific* OS, or a
> specific locale, then that is a bug

TBH I don't know whether it _ever_ works, as I always get Hindi CTL locale for some reason, and assumed that's some hard-coded default. Guess I'll go file that bug. Anyway, limiting the bug's scope to reflect what you've said.

(In reply to Eyal Rozenberg from comment #12)
> if I download a localized version from the libreoffice.org website, shouldn't
> that locale trump whatever LO determines as the OS locale?

There are no "localized versions" of LibreOffice. There is the program, and there are UI packages, that may be added on top of the program, in any number. The closest to a "localized version" is a set of the main program plus a single UI package. But note, that the most used packages - the Windows MSI, and the macOS DMG - are all-in-one packages, including *all* UI packaged bundled; while the Linux packages are actually not expected to be widely used at all, according to the philosophy of the project, which expects Linux distros to prepare own packages in their repositories, with own installation scripts taking care of UI packages. The set of individual sub-packages (both inside the main program RPM/DEB, and the individual UI packs) reflect the Linux distros' maintainers' idea of modularity, allowing those distro maintainers to only install subset of the program to suit some requirements - e.g., license (like PDF import depending on GPL), or library dependence (for different VCL backends), or bloat (like unneeded UI packs). Thus, Linux people installing LibreOffice from homepage are likely to have a somewhat incorrect idea of the intended UX - they have to manually do what their distro maintainer would normally automatize for them.

And then: the UI package is *the UI*, but has nothing to do with *locale*. It is OK to have a Russian UI, but Chinese locale. And the locale set doesn't depend on any UI package; it is built into the core. The logic of automatic locale choice is also built into the core; it depends on your OS, not on the installed UI packages.

So yes, please do file bugs for what specifically doesn't work. The bottom line of my previous comments was: what you asked for was already implemented - and if it doesn't work as intended, it is not a missing functionality, but a bug. And the point 4 in comment 1 is meant to tell, that there might be shortcomings in the implemented logic itself - then it needs to be discovered, what is not good in that logic, and improved.

(In reply to Mike Kaganski from comment #9)
> [...] *if* it doesn't work for a *specific* OS, or a
> specific locale, then that is a bug - and someone slightly familiar with the
> bug tracker would indeed understand that the specific report is needed. like
> "I use OS ABC; my locale settings in the OS are XYZ; I install LO using this
> method; immediately after installation, I check the LibreOffice locale
> setting, and it is ...; and when I look at the Asian / CTL checkboxes there
> on the same options page, I see unexpected ... - my expectation is ..."
Eyal, if the settings relevant to the system's locale are not turned by default, please provide precise information about your system and LO version so this bug can be actioned, as requested by Mike. So far, only Mike has provided some version info.
I feel like a lot of this discussion should have happened on Ask.LO, so a clearer report could have been opened here later.

(In reply to Stéphane Guillou (stragu) from comment #14)
> Eyal, if the settings relevant to the system's locale

This sentence goes to the heart of what this bug is about. If I understand what's been said, then - the setting currently depends (modulo any bugs) on the LO-determined locale, and only on that locale. This bug asks for an expansion of the heuristic to also depend on other things, as I mentioned in comment 8, e.g.:

* The set of enabled keyboard layouts
* The country the computer is currently in
* Finer choices of aspects of the locale/regional settings
* Whether or not a localization pack or help pack is installed for an RTL-CTL or CJK language

and never mind my specific situation with Hindi.

(In reply to Eyal Rozenberg from comment #15)
> (In reply to Stéphane Guillou (stragu) from comment #14)
> > Eyal, if the settings relevant to the system's locale
> 
> This sentence goes to the heart of what this bug is about. If I understand
> what's been said, then - the setting currently depends (modulo any bugs) on
> the LO-determined locale, and only on that locale. This bug asks for an
> expansion of the heuristic to also depend on other things, as I mentioned in
> comment 8, e.g.:
> 
> * The set of enabled keyboard layouts
> * The country the computer is currently in
> * Finer choices of aspects of the locale/regional settings
> * Whether or not a localization pack or help pack is installed for an
> RTL-CTL or CJK language
> 
> and never mind my specific situation with Hindi.

The request is controversial due to the things already mentioned in previous comments. The detection of system locale is already in place. I see the same dangers in the proposal as using country flags in UIs to denote languages. People can get upset when such well-meaning methods result in errors. Possibly you could discuss it on the l10n list.

(In reply to Buovjaga from comment #16)
> The request is controversial due to the things already mentioned in previous
> comments.

Well, there was a bunch of misunderstanding (a lot of it on my part) in previous comments... 

> The detection of system locale is already in place.

... and this bug is about using more than that "system locale" detection.

> I see the same
> dangers in the proposal as using country flags in UIs to denote languages.

Oh, that is _actually_ very dangerous. Enabling support for more languages is not likely to exhibit that danger; first, you're not given any particular message or direct visual signal, like "English means UK!"; you just see two language categories in the font selection dialog, which doesn't carry that same connotation. It's true that, in theory, if someone were to ask the developers "Why did I get RTL enabeled by default?" They could say "Well, you are in a country with a large fraction of RTL users" and that could be annoying to someone who dislikes that situation, but already this is quite a contrived example.

> People can get upset when such well-meaning methods result in errors.
> Possibly you could discuss it on the l10n list.

I'll do that, even though I believe the concern is not merited :-\