D18317: Don't fail if defaultLanguage dictionary can't be loaded

[Ahmad Samir]

ahmadsamir added a comment.


  In D18317#395928 <https://phabricator.kde.org/D18317#395928>, @loh.tar wrote:
  
  > Just my thoughts:
  >
  > - I think there shouldn't be the (default) dictionary changed by some smart logic. Just hint the user that the setting is not applicable.
  
  
  The user will open the sonnet config dialog and see that the dictionary he wants is already selected (e.g. the dictionary files have just been renamed, but it's the same dictionary); that is confusing, as can be gleaned from the linked bug report.
  
  > - To set the dict to the system locale seems to me the less smartest trick. If everybody want such "auto-fix" should then the bad setting investigated and tried to find some similar setting, e.g. Bad "de_AT_ost" -> "de_AT" -> "de_DE". Why? Someone may have a locale of "de_DE" but a dict setting "en_US" for whatever reason. Besides I guess Loader::createSpeller is not only called when the default dict will loaded. IIRC has Sonnet some functionallity to guess a language and choose a fitting dict (May that help?)
  
  It's what sonnet settings default to initially:
  https://cgit.kde.org/sonnet.git/tree/src/core/settings.cpp#n291:
  
    d->defaultLanguage = settings.value(QStringLiteral("defaultLanguage"),
                                            QLocale::system().name()).toString();
  
  Language auto detection seems to cause some havoc: https://bugs.kde.org/show_bug.cgi?id=386611
  
  > - The Config-GUI should show some hint in case of trouble, src/ui/configui.ui
  
  [..]
  
  > - Don't overwrite permanently some bad setting with a new value. Perhaps has the user just set up a new system and only missed to install some package
  
  Same problem as above, the user opens the config dialog and the dictionary he wants is already selected....
  
  [...]

REPOSITORY
  R246 Sonnet

REVISION DETAIL
  https://phabricator.kde.org/D18317

To: ahmadsamir, sandsmark, loh.tar
Cc: pino, kde-frameworks-devel, michaelh, ngraham, bruns
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20190119/5d01e893/attachment.html>