QGIS » QGIS Application

Correction - the query/edit issue applies only to GRASS vector layers. Polish chars are handled OK in case of Shapefiles tables.

As to Shapefiles, only the issue with saving it under a name with non-ASCII chars applies - eg. if I create a new Shapefile and try save it as "test_ąę", it will be saved as "test_".

Also I noticed that QGIS silently fails to create fields with non-ASCII chars when createing a new shapefile. Please issue an error instead.

Replying to [comment:3 timlinux]:

Please test the attached patch. It resolves the shp creation issues for me - I was able to create a shp with polish chars both in name and in field names. I havent tested with grass. I also dont know if the patch will have sideeffects for people in other locales or previously closed bugs.

Hm, from

#include <stdio.h>
#include <locale.h>

int main(int argc, char **argv) {
    const char *value = "123.456";
    const char *locale = setlocale(LC_ALL, NULL);
    const char *locales[] = {"C", "UTF-8", "foobar", "de_DE.UTF8", "foobar"};

    printf("initial locale: %s\
", locale);

    int i;
    for(i=0; i<sizeof(locales)/sizeof(*locales); i++) {
        double val;
        const char *res = setlocale(LC_ALL, locales[i]);
        if(!res)
          res="(null)";
        sscanf(value, "%lf", &val);
        printf("setlocale: argument=\\"%s\\" result=\\"%s\\" query=\\"%s\\" value=%.4lf\
",
            locales[i], res, setlocale(LC_ALL, NULL), val);
    }

    setlocale(LC_ALL, locale);
    printf("restored to \\"%s\\" locale: %s\
", locale, setlocale(LC_ALL, NULL));
}

I get:

initial locale: C
setlocale: argument="C" result="C" query="C" value=123.4560
setlocale: argument="UTF-8" result="(null)" query="C" value=123.4560
setlocale: argument="foobar" result="(null)" query="C" value=123.4560
setlocale: argument="de_DE.UTF8" result="de_DE.UTF8" query="de_DE.UTF8" value=123,0000
setlocale: argument="foobar" result="(null)" query="de_DE.UTF8" value=123,0000
restored to "C" locale: C

"C" is a predefined locale and valid (as "POSIX"). Looks like "UTF-8" isn't and setlocale() doesn't actually change anything in that case.

So you're reverting 2c95d648 (SVN r8693) and reopening #1120, without actually doing it ;)

I still don't see how 2c95d648 (SVN r8693) has an effect as the locale should be properly restored - it should only last for the OSRImportFromProj4 call.

Replying to [comment:5 jef]:

Maciej, could you please verify that both #1120 and #1141 are fixed? Please reopen, if either problem is still there.

in f3f933d0 (SVN r8760) that is.

Milestone Version 0.11.0 deleted