[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: Bert Huijben <bert_at_qqmail.nl>
Date: Fri, 6 Sep 2013 11:15:21 +0200

Which build of the Windows binaries do you use?
 
The Subversion project doesn’t produce binaries, so can’t really support build issues.
 
Personally I do build the SlikSvn binaries (http://sliksvn.com/en/download), so if you find issues in that I might be able to help you.
 
                Bert
 
From: QXO [mailto:qxodream_at_gmail.com]
Sent: vrijdag 6 september 2013 08:49
To: Philip Martin
Cc: Dongsheng Song; users_at_subversion.apache.org; dev_at_subversion.apache.org
Subject: Re: svnadmin upgrade output message i18n issue
 
The bug found in svn 1.8.3(r1516576) again :(
 
 
E:\svnmirror>D:\tools\svn-win32-1.8.3\bin\svnadmin.exe upgrade ZmccPrj
宸插彇寰楃増鏈簱閿佸畾銆?璇风◢鍊欙紱鍗囩骇鐗堟湰搴撳彲鑳介渶瑕佷竴娈垫椂闂?..
 
完成升级。
 
 
E:\svnmirror>D:\tools\svn-win32-1.8.0\bin\svnadmin.exe upgrade ZmccPrj
已取得版本库锁定。
请稍候;升级版本库可能需要一段时间...
 
完成升级。
 
 
 
2013/6/19 QXO < <mailto:qxodream_at_gmail.com> qxodream_at_gmail.com>
The bug fixed in svn 1.8.0,Thanks:)
 
2013/5/24 Philip Martin < <mailto:philip.martin_at_wandisco.com> philip.martin_at_wandisco.com>
Dongsheng Song < <mailto:dongsheng.song_at_gmail.com> 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> http://www.wandisco.com/subversion/download
 
 
Received on 2013-09-06 11:16:25 CEST

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

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