Download it now!
Bug 70659 - Ukrainian dictionary is preselected in Russian locale
Summary: Ukrainian dictionary is preselected in Russian locale
Status: NEEDINFO
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
4.1.2.1 rc
Hardware: Other Windows (All)
: low enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: Dictionaries Installer
  Show dependency treegraph
 
Reported: 2013-10-20 03:28 UTC by Urmas
Modified: 2020-08-06 20:09 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Urmas 2013-10-20 03:28:46 UTC
If LO is installed for the first time with Russian system locale, there is an Ukrainian dictionary pre-selected. Please fix this.
Comment 1 Maxim Monastirsky 2013-10-20 14:53:30 UTC
(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.
Comment 2 Maxim Monastirsky 2013-10-20 15:55:56 UTC
OK, seems like a follow-up of Bug 59370. I classify it as an enhancement, since that change was intentional.
Comment 3 IxI_JOKER_IxI 2014-11-27 20:14:46 UTC Comment hidden (off-topic)
Comment 4 Urmas 2014-11-27 21:10:48 UTC Comment hidden (off-topic)
Comment 5 Julien Nabet 2020-08-06 10:53:56 UTC
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?
Comment 6 Roman Kuznetsov 2020-08-06 11:20:59 UTC
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
Comment 7 Julien Nabet 2020-08-06 11:32:52 UTC
(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?
Comment 8 Roman Kuznetsov 2020-08-06 11:42:18 UTC
(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
Comment 9 Julien Nabet 2020-08-06 12:44:44 UTC
(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.
Comment 10 Mike Kaganski 2020-08-06 16:12:06 UTC
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.
Comment 11 Julien Nabet 2020-08-06 18:11:48 UTC
(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.
Comment 12 Mike Kaganski 2020-08-06 19:02:17 UTC
(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.
Comment 13 Julien Nabet 2020-08-06 19:16:05 UTC
(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.
Comment 14 Mike Kaganski 2020-08-06 19:56:45 UTC
(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.
Comment 15 Julien Nabet 2020-08-06 20:09:00 UTC
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).