Thread: BUG #7664: Program using libpq and ecpglib can not output native language
BUG #7664: Program using libpq and ecpglib can not output native language
From
chenhj@cn.fujitsu.com
Date:
The following bug has been logged on the website: Bug reference: 7664 Logged by: Chen Huajun Email address: chenhj@cn.fujitsu.com PostgreSQL version: 9.1.6 Operating system: Linux Description: = The error messages output by libpq or ecpglib is always be english. But my expect is my native language. Step: 1)compile my program which linked to libpq or ecpglib. 2)set my locale to native language. set LANG=3Dja_JP.UTF-8 set LC_ALL=3Dja_JP.UTF-8 3)run my program and let it raise an error. I knows reason. The default locale of a program is "C" in Linux,regardless the Environment Variables. if add the following line in my program,everything is OK. setlocale(LC_ALL, ""); But I found no document tell users should do so.And I think it's not a easy way.Can libpq and ecpglib do it for users? *=EF=BC=89Windows is OK.Solaris may has the same problem.
chenhj@cn.fujitsu.com writes: > I knows reason. The default locale of a program is "C" in Linux,regardless > the Environment Variables. > if add the following line in my program,everything is OK. > setlocale(LC_ALL, ""); > But I found no document tell users should do so.And I think it's not a easy > way.Can libpq and ecpglib do it for users? No, it would most certainly be inappropriate for a library to do that. setlocale could completely break a program that wasn't expecting it. The effects would be global across the whole process, not confined to the library. regards, tom lane
Re: BUG #7664: Program using libpq and ecpglib can not output native language
From
Chen Huajun
Date:
Hi,tom lane > No, it would most certainly be inappropriate for a library to do that. > setlocale could completely break a program that wasn't expecting it. > The effects would be global across the whole process, not confined to > the library. First,does you agree with the need of native language support without writing "setlocale(LC_ALL, "")"in user's program is rational$B!)(B If the answer is yes, let see if there is a mothod to solve it. Simply write "setlocale(LC_ALL, "")" in libpq and ecpglib may cause other problems as you said. But how about only call setlocale() before call dgettext(), and soon restore to the original value after called. *)Excuse me for my English. for example: libpq_gettext(const char *msgid): ===================================================== return dgettext(PG_TEXTDOMAIN("libpq"), msgid); ==> char *result; if(strcmp(setlocale(LC_MESSAGES,NULL),"C")==0) { setlocale(LC_MESSAGES, ""); result = dgettext(PG_TEXTDOMAIN("libpq"), msgid); setlocale(LC_MESSAGES, "C"); }else { result = dgettext(PG_TEXTDOMAIN("libpq"), msgid); } return result; ===================================================== (2012/11/16 13:22), Tom Lane wrote: > chenhj@cn.fujitsu.com writes: >> I knows reason. The default locale of a program is "C" in Linux,regardless >> the Environment Variables. >> if add the following line in my program,everything is OK. > >> setlocale(LC_ALL, ""); > >> But I found no document tell users should do so.And I think it's not a easy >> way.Can libpq and ecpglib do it for users? > > No, it would most certainly be inappropriate for a library to do that. > setlocale could completely break a program that wasn't expecting it. > The effects would be global across the whole process, not confined to > the library. > > regards, tom lane > > -- Best Regards, chen hujuan
Chen Huajun <chenhj@cn.fujitsu.com> writes: > First,does you agree with the need of native language support without writin > "setlocale(LC_ALL, "")"in user's program is rational? No, not particularly. The C language standard is quite clear about that. Nor does it seem like a particularly great idea from a user's standpoint for different sub-parts of a program to be operating in different locales. Even if I agreed with the concept, your idea of switching locale constantly is likely to be horrid from a performance standpoint. regards, tom lane
Re: BUG #7664: Program using libpq and ecpglib can not output native language
From
Chen Huajun
Date:
> No, not particularly. The C language standard is quite clear about > that. Nor does it seem like a particularly great idea from a user's > standpoint for different sub-parts of a program to be operating in > different locales. Even if I agreed with the concept, your idea of > switching locale constantly is likely to be horrid from a performance > standpoint. I just don't known way the default locale is "C" but not the value Set by Environment Variables in Linux. Maybe this is The C language standard. And may be this is a general knowledge known by most of people except for a few (just like me ). If someone does not know that,it's not too easy to solve it by him self. Whether it's better to do something to make using native language of libpq more easy? Even if write something in document. By the way, from a performance standpoint normally native language only needed for error message outputing where I think performance is not so important. Regards chen huajun