This is what is used:

raBox->setText(object->ra0().toHMSString(false, true));
decBox->setText(object->dec0().toDMSString(false, false, true));

So these function are not producing the correct results? Both above are using high-precision.

This seems proper indeed. Issue must be elsewhere, let me provide a scenario.

Issue might be related to QString::toDouble in dms::setFromString. Documentation in Qt11 doesn't mention any locale issue, so perhaps this is a version compatibility problem?

I reproduced the issue is more serious than I thought. The bug appears (also?) in the .esl load procedure! Could this be a regression introduced by the copy&paste of coordinates? This was working properly during August.

Coordinates end up "HH MM SS.SS" after conversion instead of "HHh MM' SS,SS"" in the RA/DEC boxes, and the "." character is not recognized properly, leading to offset'd positioning afterwards. With my locale, "." should be "," for the conversion to be successful.

Current code tree thus has loading of scheduler files broken.

I changed toDMSString in dms.cpp to this:

    QString dummy;
    char pm(' ');
    QChar zero('0');
    int dd = abs(degree());
    int dm = abs(arcmin());
    int ds = abs(arcsec());    

    if (Degrees() < 0.0)
        pm = '-';
    else if (forceSign && Degrees() > 0.0)
        pm = '+';

    if (machineReadable)
        return QString("%1%2:%3:%4").arg(pm)
                .arg(dd, 2, 10, QChar('0'))
                .arg(dm, 2, 10, QChar('0'))
                .arg(ds, 2, 10, QChar('0'));

    if (highPrecision)
    {
        double sec = arcsec() + marcsec() / 1000.;
        return QString("%1%2° %3\' %4\"").arg(pm)
                                         .arg(dd, 2, 10, zero)
                                         .arg(dm, 2, 10, zero)
                                         .arg(sec, 2, 'f', 2, zero);
    }

    return QString("%1%2° %3\' %4\"").arg(pm)
                                     .arg(dd, 2, 10, zero)
                                     .arg(dm, 2, 10, zero)
                                     .arg(ds, 2, 10, zero);


However, I am still getting decimal point even though I changed the language and then also changed the system locale and logged out then in again. I also briefly tried with QLocale().toString with same results. Can you find out what's wrong?

Read some Qt docs, and found the problem: all of our arg() and number() calls basically ignore locale. To properly support that, we can use "%L1" instead of "%1" for a float number for instance, or use toString(), which uses the current locale but is not very flexible. That also raises the problem of portable XML files, in which we should better choose the right QLocale before reading and writing. Plenty of changes everywhere, apparently.

I actually tried %L and it had no effect.

On my system, QString("%L1").arg(float_var) with float_var does produce "1,2", while QString("%1").arg(float_var) does produces "1.2".

I'm checking where all this should be used. I'll try to use the english locale when reading and writing XML files so we keep portability. We'll have interesting issues, as for instance with the float representing exposure duration that is used in capture file names.

I think the issue has been there for a long time actually. Besides, it might evantually relate to the issue forum user alacant had.

Tested with target "NGC 281", created a scheduler job, saved, loaded XML file, coordinates are wrong and, while easy to overlook, the nature of the problem is relatively obvious. NGC 281 has a fractional part for the seconds value. The resulting coordinates are not too far, but still completely wrong.

XML files are saved with the system locale, and loaded with no locale. This issue is in Scheduler and Capture modules. Besides, all control texts need rework to take locale into account properly.

I'm planning to:
- replace atof calls used to read XML numbers, which use the system locale, with QLocale::C string-to-type functions.
- make sure QString calls used to write XML numbers use the QLocale::C serialization.

Side not-so-related question: XML serialization is using the lilXML library, any plan to use QXMLStreamReader and QXMLStreamWriter at some point? This is compatible back to Qt4.3 and could possibly simplify some serialization code. In any case I think saving/loading configurations should be moved out of their related modules first.

I believe lilXML only supports C locale but I could be wrong. QXMLStreamWriter could be used to replace any use of lilXML in KStars. It was just that lilXML was easier to use since it was in INDI, and I don't believe QXMLStreamWriter was there back in 2003 when this was started.

Preliminary work in the Capture module at https://github.com/TallFurryMan/kstars, branch improve__support_decimal_locales.

One first step towards fixing this is in https://phabricator.kde.org/D15492

Scheduler fixes are in https://phabricator.kde.org/D15865