(In reply to comment #0)
> If LO is installed for the first time with Russian system locale, there is
> an Ukrainian dictionary pre-selected.
Confirmed using 4.1.2.3. But it also pre-selects English, Spanish, German & French. Similar happens with English locale - It pre-selects Spanish & French. So it looks for me as an intentional. Also this is what MS Office installer does (I have only the English installer, don't know what the Russian one does), so looks like LO tries to mimic MS Office installer.

OK, seems like a follow-up of Bug 59370. I classify it as an enhancement, since that change was intentional.

Sophie/Andras/Jean-Baptiste/Michael: it seems this bugtracker is the opposite of tdf#59370.
Indeed tdf#59370 wants to add Ukrainian dictionary by default (+English one which hasn't been added for a reason I ignore), this one wants to remove Ukrainian dictionary by default.

I don't have opinion here and I can understand both. Which criteria should we use? I mean should we take a look at MsOffice? Should we ask LO Russian team?

I don't see any problems here. Let's keep it as is.

Many Ukrainian users use Russian UI, but they can work with Ukrainian texts

(In reply to Roman Kuznetsov from comment #6)
> I don't see any problems here. Let's keep it as is.
> 
> Many Ukrainian users use Russian UI, but they can work with Ukrainian texts

Noticing https://bugs.documentfoundation.org/show_bug.cgi?id=59370#c5, I suppose the goal is to avoid some overbloating.

As a French user, I noticed:
fr = "fr,es"
I suppose some would tell they never use Spanish or other would ask to add German or Italian dictionaries.
I don't know what rules should be followed or if there's some standard.

Perhaps should we only stick to official languages of the country by default?

(In reply to Julien Nabet from comment #7)
> (In reply to Roman Kuznetsov from comment #6)
> > I don't see any problems here. Let's keep it as is.
> > 
> > Many Ukrainian users use Russian UI, but they can work with Ukrainian texts
> 
> Noticing https://bugs.documentfoundation.org/show_bug.cgi?id=59370#c5, I
> suppose the goal is to avoid some overbloating.
> 

There was the same author as he is in this bug report

(In reply to Roman Kuznetsov from comment #8)
> (In reply to Julien Nabet from comment #7)
> ...
> There was the same author as he is in this bug report

Yes but that's still relevant, adding dictionaries may be useless for lots of people.
About previous proposition concerning official languages of the country, I think it would be neutral and quite objective. I mean mimicking MsOffice may not be the right choice and language teams may not be representative enough.

I would say that we should, to the contrary, simply install all languages (UI and dictionaries), and remove the choice altogether. The only problem here would be possible performance penalty, which should then be fixed properly, so that installed language modules don't harm performance.

Many people struggle installing dictionaries; they even don't know they should re-run installer and use advanced installation, and instead install extensions (which often gives them older dictionaries and/or problems). Having all bundled dictionaries installed is no worse than having all DLLs installed (which was always the case); and "We do not need that junk on their machines" is not an argument, because the increased space requirement is not significant for current standards, while gain for inexperienced users might be big.

For space-constrained (e.g. embedded) systems, there are separately-maintained packages anyway.

See also tdf#124992 with a similar proposal (also mine) wrt help.

(In reply to Mike Kaganski from comment #10)
> I would say that we should, to the contrary, simply install all languages
> (UI and dictionaries), and remove the choice altogether. The only problem
> here would be possible performance penalty, which should then be fixed
> properly, so that installed language modules don't harm performance.
It seems the same as opt-in/opt-out options for websites. Personally, I prefer opt-in instead of being forced to uncheck manually every element we don't want.

> 
> Many people struggle installing dictionaries; they even don't know they
> should re-run installer and use advanced installation, and instead install
> extensions (which often gives them older dictionaries and/or problems).
So in fact the real pb is the install process of additional dictionaries.
The opt-out/install everything process is a workaround of this install process pb.

> Having all bundled dictionaries installed is no worse than having all DLLs
> installed (which was always the case); and "We do not need that junk on
> their machines" is not an argument, because the increased space requirement
> is not significant for current standards, while gain for inexperienced users
> might be big.
> ...
It's not because SSD can contain several To that LO should become a kind of bloatware.

(In reply to Julien Nabet from comment #11)
> It's not because SSD can contain several To that LO should become a kind of
> bloatware.

It's a strong statement. Increased capacity of hardware comes not to just give a warm feeling "I have it more than had yesterday". It helps solving real problems. And there *is* a real problem that I mentioned above, that *can* be solved using the increased capacity of modern hardware. Calling this "bloatware" is simply trying to use emotional arguments instead of technical.

And no, it's not about easier configuration: it's about *no* configuration for something.

(In reply to Mike Kaganski from comment #12)
> (In reply to Julien Nabet from comment #11)
> > It's not because SSD can contain several To that LO should become a kind of
> > bloatware.
> 
> It's a strong statement. Increased capacity of hardware comes not to just
> give a warm feeling "I have it more than had yesterday". It helps solving
> real problems. And there *is* a real problem that I mentioned above, that
> *can* be solved using the increased capacity of modern hardware. Calling
> this "bloatware" is simply trying to use emotional arguments instead of
> technical.
Ok it was strong but it's because it's equivalent to tell me that every binary should be built with libs in static so no need to bother about dynamic libs and their versions. Yes it would work but your binaries become far bigger.

> 
> And no, it's not about easier configuration: it's about *no* configuration
> for something.
In this case, the real problem is the lack of the configuration mechanism, so a missing feature.

(In reply to Julien Nabet from comment #13)
> > And no, it's not about easier configuration: it's about *no* configuration
> > for something.
> In this case, the real problem is the lack of the configuration mechanism,
> so a missing feature.

I see that I am poor with communicating my ideas here.
What I mean is that I don't thing we need easier configuration here. I believe that we need to *remove* this configuration at all: any, however easy, configuration is necessarily more difficult than no configuration at all.

(Yes, it still may be available in advanced mode, but for practical uses, implementing my proposal is equivalent to make something to work for most people *without* *any* configuration.)

That is in contrast to

> So in fact the real pb is the install process of additional dictionaries

which implies that we could implement some *better* mechanism for installing dictionaries, which would "solve" "real" problem. But again: the real problem here is that users need to do something at all; and making this just work *is* the correct solution of the real problem.

Ok then.
I don't have more arguments than those I already provided, so we just disagree here, no big deal.
=> uncc myself since I suppose this bugtracker will be a wontfix (or would be "worst", I mean for the author, since there "may" be all dictionaries instead of 3).

Dear Urmas,

Please read this message in its entirety before proceeding.

Your bug report is being closed as INSUFFICIENTDATA due to inactivity and
a lack of information which is needed in order to accurately
reproduce and confirm the problem. We encourage you to retest
your bug against the latest release. If the issue is still
present in the latest stable release, we need the following
information (please ignore any that you've already provided):

a) Provide details of your system including your operating
   system and the latest version of LibreOffice that you have
   confirmed the bug to be present

b) Provide easy to reproduce steps – the simpler the better

c) Provide any test case(s) which will help us confirm the problem

d) Provide screenshots of the problem if you think it might help

e) Read all comments and provide any requested information

Once all of this is done, please set the bug back to UNCONFIRMED
and we will attempt to reproduce the issue. Please do not:

a) respond via email 

b) update the version field in the bug or any of the other details
   on the top section of our bug tracker

Warm Regards,
QA Team

MassPing-NeedInfo-FollowUp