[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svnadmin upgrade output message i18n issue

From: Philip Martin <philip.martin_at_wandisco.com>
Date: Thu, 23 May 2013 18:31:07 +0100

Dongsheng Song <dongsheng.song_at_gmail.com> writes:

>> We do call bind_textdomain_codeset if it is available so we should be
>> getting UTF8 translations.
>>
>
> For non-autotools system, e.g. Windows, user may not define
> HAVE_BIND_TEXTDOMAIN_CODESET.

If you build the software with the wrong settings it may not work
properly. The solution is to build it with the correct settings.
Perhaps you can improve the Windows build.

> Or we should call bind_textdomain_codeset as possible, and warn the
> user if HAVE_BIND_TEXTDOMAIN_CODESET not defined:
>
> #ifdef HAVE_BIND_TEXTDOMAIN_CODESET
> bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
> #else
> fprintf(sdterr, "bind_textdomain_codeset not available, or not
> configured. Non-UTF8 locales maybe see garbled output.\n");
> #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */

That error would be annoying if it was a false alarm. Perhaps we could
verify the correct behaviour: call gettext and check whether the
returned string is valid UTF8? However, we are not getting reports of
problems so it's probably not worth the effort. The bug that started
this thread is about the exact opposite: gettext was returning UTF8 and
the output code was failing to convert to locale encoding.

-- 
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Received on 2013-05-23 19:31:45 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.