KSaneCore::Interface::getOptionsMap() contains localized values

[Tobias Leupold]

Hi all, esp. the fellow KSaneCore devs :-)

I'm just messing a bit with Scandoc, which directly uses KSaneCore. I save and 
restore the chosen settings using KSaneCore::Interface::getOptionsMap() and 
setOptionsMap().

What I noticed now is that some option values are provided localized, e.g. for 
"mode" or "source".

The list options holding the respective selection provide two lists of 
possible values, accessible via ListOption::valueList() and 
internalValueList(), where internalValueList() returns unlocalized values.

For example, the "mode" option returns ("Farbe", "Graustufen") and ("Color", 
"Gray"), for "source", it's ("Flachbett", "Automatischer Dokumenteneinzug") 
and ("Flatbed", "ADF").

However, in the getOptionsMap() output, I see e.g. ("mode", "Farbe") and 
("source", "Flachbett"). I would have expected to see the unlocalized strings 
there. Interestingly, restoring those values works without a problem. If I 
change the saved values to their unlocalized counterparts manually, they are 
restored correctly as well. So, apparently, somewhere under the hood, we don't 
only search for the "raw" values but for translated strings as well when 
setting them. I'm pretty sure this will break as soon as I change the 
language. I haven't tested this though.

Looking at the KSaneCore sources, I'm not really sure if I get it correctly 
due to lack of SANE knowledge. However, I think it's caused by 
ListOption::readValue(). There, we have:

    ...
    case SANE_TYPE_STRING:
        newValue = sane_i18n(reinterpret_cast<char *>(data.data()));
        break;
    ...

    if (newValue != m_currentValue) {
        m_currentValue = newValue;
        Q_EMIT valueChanged(m_currentValue);
    }

The option's value is passed through sane_i18n() if it's a string.

I think we should not use translated strings for storing settings, but only 
for displaying, no? I must admit that I didn't notice this until now, because 
apparently, all the respective strings of all scanners I dealt with yielded a 
C locale string. Most probably due to a lack of translation. But this is not 
the case for the Brother MFC-L2800DW IPP everywhere multi function printer I 
recently bought apparently.

If we have to keep this behavior, I would suggest to not only cache 
m_currentValue, but something like m_currentInternalValue or such holding the 
"raw" value. Along with some access function like internalValue() returning 
it, so that it can be used by Interface::getOptionsMap().

I'm not sure how to do it correctly, so I thought I'd ask here first before 
coding around without knowing where to go and filing a MR.

What do you think?

Cheers, Tobias