Created attachment 294726 [details] [review]
Properly handle languages that can't be spellchecked

Generic languages like en don't have spell checking dictionaries.
Currently, spellchecking these languages silently fails.

* Only attempt to enable spell checking for specific dialects like en_US.
* Actually display in the UI when a language cannot be spellchecked.

Review of attachment 294726 [details] [review]:

::: lib/ephy-langs.h
@@ +43,3 @@
+GHashTable		    *ephy_langs_iso_3166_table	   (void);
+
+gboolean		     ephy_lang_supports_spellcheck (char *);

Do not omit argument names in header protoypes. ephy_langs is the prefix, this should be ephy_langs_lang_support_spellcheck(), however I wonder if we should move to ephy-langs the normalize helper, with a less confusing name, ephy_langs_normalize_languages_for_spellchecking() or something like that, and supports_spellcheck would be a private function here.

::: src/prefs-dialog.c
@@ +545,3 @@
+		 */
+		name = g_strdup_printf (C_("language", "%s (Generic; no spell checking)"),
+					dgettext (ISO_639_DOMAIN, langname));

Could you show a screenshot of how this look?

Created attachment 296037 [details]
screenshot

I will ping Allan; maybe he has a better idea.

(In reply to comment #2)
> Do not omit argument names in header protoypes. ephy_langs is the prefix, this
> should be ephy_langs_lang_support_spellcheck(), however I wonder if we should
> move to ephy-langs the normalize helper, with a less confusing name,
> ephy_langs_normalize_languages_for_spellchecking() or something like that, and
> supports_spellcheck would be a private function here.

It looks like neither function needs to be in ephy-langs, but it feels like a good place for both of them; what do you think? I probably put _supports_spellcheck in ephy-langs because it was needed from the preferences dialog for an earlier iteration of the patch.

Anyway, we shouldn't commit anything here until we have a story for installation of missing dictionaries. I can handle this once we decide what, if any, API we will add to WebKit.

The problem is this: in Epiphany we have an Add Language dialog under Preferences -> Language -> Add. The language selected here will be sent in HTTP headers to suggest web sites send a page in that language. (You can actually add multiple languages, and it will be sent as a list of preferences.) It MAY also be used for spell checking (for which you can also have multiple languages), but the set of languages we want to support for HTTP headers is larger than the set with spell checking dictionaries available. In particular, generic languages like "English" will never support spell checking; spell checking is only possibly available for specific locales like "English (United States)". But we want to let the user pick the generic language anyway, especially since there are generic languages with no corresponding specific locales, like Abkhazian.

Of course, some specific locales may not support spell checking at all, either. And for others, spell checking may be supported but with no way to install a spell checking dictionary. So this is a pretty confusing situation. Currently we just silently fail if there is no spell checking dictionary installed for the language the user picked, but we should do better. If you have any suggestions on how our UI could help the user navigate through this, that would be great.

Another option would be to give up on using the same list of languages for both HTTP headers and spell checking, and have separate UI for these. It feels simpler to have just one list, but maybe it's not really.

-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/254.