Bug report #1141

broken Polish characters support since r8592

Added by Maciej Sieczka - about 12 years ago. Updated about 11 years ago.

Status:Closed
Priority:Low
Assignee:Tim Sutton
Category:-
Affected QGIS version: Regression?:No
Operating System:Debian Easy fix?:No
Pull Request or Patch supplied: Resolution:fixed
Crashes QGIS or corrupts data: Copied to github as #:11201

Description

QGIS no longer displays Polish (pl UTF-8 locale) characters in the table, labels and query results. It also fails to save a newly created shapefile if it's name contains Polish chars like ąęćń etc.

The last QGIS SVN trunk revision which handles Polish chars correctly is r8591. r8592 is when things went funky. Jürgen was the author.

ticket_1141.jpeg - Example of error message when creating a shp (10.6 KB) Tim Sutton, 2008-07-11 07:19 AM

ticket_1141_patch.diff Magnifier - Patch which fixes the issue for me (1.75 KB) Tim Sutton, 2008-07-11 05:12 PM

Associated revisions

Revision b7ee1e84
Added by Jürgen Fischer about 12 years ago

fix #1141 by fixing #1120 differently.

I still don't see why r8592 has an effect, except calling OSRImportFromProj4()
in locale "C". Just setting LC_NUMERIC probably resolves the side effects
leading to #1141 without reopening #1120.

But there might be - even more subtle - side effects left - watch out.

git-svn-id: http://svn.osgeo.org/qgis/trunk/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

Revision f3f933d0
Added by Jürgen Fischer about 12 years ago

fix #1141 by fixing #1120 differently.

I still don't see why r8592 has an effect, except calling OSRImportFromProj4()
in locale "C". Just setting LC_NUMERIC probably resolves the side effects
leading to #1141 without reopening #1120.

But there might be - even more subtle - side effects left - watch out.

git-svn-id: http://svn.osgeo.org/qgis/[email protected] c8812cc2-4d05-0410-92ff-de0c093fc19c

History

#1 Updated by Maciej Sieczka - about 12 years ago

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.

#2 Updated by Tim Sutton about 12 years ago

  • Status changed from Open to In Progress

#3 Updated by Tim Sutton about 12 years ago

  • Status changed from In Progress to Open

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.

Please test and provide feedback.

Regards

Tim

#4 Updated by Jürgen Fischer about 12 years ago

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.

#5 Updated by Jürgen Fischer about 12 years ago

  • Status changed from Open to Closed
  • Resolution set to fixed

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

#6 Updated by Jürgen Fischer about 12 years ago

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.

#7 Updated by Anonymous about 11 years ago

Milestone Version 0.11.0 deleted

Also available in: Atom PDF