[KevinH]

No, you misunderstand. It is not difficult, but if the xhtml files do not have lang or xml:lang, then surely the opf can be used to get the language of the text (both primary and secondary from existing dc:language metadata tags) as needed.

So my reluctance is to change a long standing api for something that can be extracted locally from the epub itself and be more accurate that what the user defaulted to.

That is what is done inside Sigil when a full spellcheck dialog is used. It uses the actual language tags and fallsback to the opf. Only the on the fly red-squiggly spellcheck version uses primary and secondary for pure speed.

I would be happy to create a python snippet to use the opf to determine primary and secondary languages which when combined with the dictionary_dirs list if that would help instead.

I am just loathe to change a minimalist interface (designed that way on purpose) to add things that can be derived in better ways inside the plugin (and I do not mean parsing the sigil ini files here).

If not, then let me know and I will add that requested interface when I get some free time and it will be available in a future version of Sigil.

But it kind of defeats that minimalist design approach to interface to a plugin which is why I was so hesitant.