[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: QXO <qxodream_at_gmail.com>
Date: Wed, 19 Jun 2013 10:54:03 +0800

The bug fixed in svn 1.8.0,Thanks:)

2013/5/24 Philip Martin <philip.martin_at_wandisco.com>

> 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-06-19 07:34:58 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.