Description: As a follow-up to bug report #143290: Currently, LO is installed with a file »/home/username/.config/libreoffice/4/user/wordbook/standard.dic«. (I cannot ascertain its relation to »/home/username/.config/libreoffice/4/user/pack/wordbook/standard.dic« as I cannot unpack this.) It contains the line 'lang: <none>'. It is offered to be used as custom dictionary. However, it seduces the user to store data of different languages, which leads to confusion. Suggestion: Instead of installing this standard. dic, install a custom dictionary for the same language(s) that the user selects in 'Options > Language Settings > Languages > Default Languages for Documents'. Instead of 'standard', it may be called 'custom_ab-XY', where 'ab-XY' is something like 'en-GB'. The user may then create more custom dictionaries according to the same pattern. Steps to Reproduce: 1. Install LO. Actual Results: /home/username/.config/libreoffice/4/user/wordbook/standard.dic is installed. Expected Results: LO should wait for the user to specify 'Options > Language Settings > Languages > Default Languages for Documents' then install a language-specific custom dictionary and pre-select it in the settings. Reproducible: Always User Profile Reset: Yes Additional Info: Mixing languages in a dictionary reduces its usefulness.
Wouldn't this require multiple installation packages, one for each language? Quite an effort not only for the package manager but also when you download the application. Cloph, what do you think?
If I may briefly intervene: No. 1) The use of a language in a document is independent of the language of the LO user interface. This must be so, otherwise a user could never compose documents in different languages. 2) The use of a 'user-defined' dictionary of a particular language does indeed seem to depend on the prior installation of the corresponding LO language module. Otherwise Writer appears to ignore the availability of a user-defined dictionary of the same language. However, this would not seem to be an obstacle to my proposal. Before composing his own custom dictionary of a language, the user will typically install the appropriate LO language module.
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Christian Lehmann from comment #0) > Expected Results: > LO should wait for the user to specify > 'Options > Language Settings > Languages > Default Languages for Documents' > then install a language-specific custom dictionary and pre-select it in the > settings. This might be desired by the user, yes. And while I'd appreciate a higher flexibility in the installation and more post-hoc customization, I'm afraid it's not possible to solve without huge effort.
(In reply to Heiko Tietze from comment #4) > (In reply to Christian Lehmann from comment #0) > > Expected Results: > > LO should wait for the user to specify > > 'Options > Language Settings > Languages > Default Languages for Documents' > > then install a language-specific custom dictionary and pre-select it in the > > settings. > > This might be desired by the user, yes. And while I'd appreciate a higher > flexibility in the installation and more post-hoc customization, I'm afraid > it's not possible to solve without huge effort. Heiko, I remember having seen this kind of comment from you before. You are certainly aware that it is a standard way of discouraging users from proposing enhancements. As for the specific proposal made here, please remember that it is intended as a solution for the untenable situation reported in bug 143290.
(In reply to Christian Lehmann from comment #5) > it is a standard way of discouraging users from proposing enhancements. Hopefully not, otherwise apologies. Point is that not all ideas can be implemented due to effort-benefit balance, some ideas are very special and seen by many other as feature-creep, we have to take care of the document standard, have to consider usability and accessibility etc. Ideally you describe a scenario, a use case, what you try to achieve. That's way more easy to agree on than a particular solution. Not saying the idea in this ticket is bad.
*** Bug 159470 has been marked as a duplicate of this bug. ***