Return-Path: X-Original-To: apmail-subversion-users-archive@minotaur.apache.org Delivered-To: apmail-subversion-users-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id C0B4C105AB for ; Fri, 6 Sep 2013 14:02:18 +0000 (UTC) Received: (qmail 91609 invoked by uid 500); 6 Sep 2013 14:02:16 -0000 Delivered-To: apmail-subversion-users-archive@subversion.apache.org Received: (qmail 91565 invoked by uid 500); 6 Sep 2013 14:02:15 -0000 Mailing-List: contact users-help@subversion.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Delivered-To: mailing list users@subversion.apache.org Received: (qmail 91552 invoked by uid 99); 6 Sep 2013 14:02:13 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Sep 2013 14:02:13 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of qxodream@gmail.com designates 209.85.215.176 as permitted sender) Received: from [209.85.215.176] (HELO mail-ea0-f176.google.com) (209.85.215.176) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 06 Sep 2013 14:02:07 +0000 Received: by mail-ea0-f176.google.com with SMTP id q16so1613763ead.7 for ; Fri, 06 Sep 2013 07:01:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9/75l9BGDl2hoJG/vYIC6yiqAmFJjvDic7jOTzFHtis=; b=P1fzLgzuiIj0TvEt6cUcdkuQS3mQdJA3mDZsYvBRNXEOF/F3bisNyMP3R8EZ2Iqz1G HfoBtZirC1s5EZhoi+KkTQwkY9KbP+Ro2ICymneI91PynYMvyIg23BKZP5BRD2xvDt7/ ObdR+NXQhA4PYOT9ZssSN7eUIZgY3fWgdWFQcxpfSZeMrcHfdJ5/8nKsI/mSsMhlYkOe 4CTZ+Dym/JG6tM3DLDQtkXem9ksqaFE+nRhFetTdhLSbApaf3oySF2kW7w0VoDmU4IXG TeRywq/1TTBl8OQIx+47pytFM74XgATlByBrf/tdWrGH3BmAff5rON0nF7N+nI+p1X2l U0HA== MIME-Version: 1.0 X-Received: by 10.14.89.72 with SMTP id b48mr4346782eef.43.1378476107440; Fri, 06 Sep 2013 07:01:47 -0700 (PDT) Received: by 10.223.64.146 with HTTP; Fri, 6 Sep 2013 07:01:47 -0700 (PDT) In-Reply-To: <02a501ceaae1$9d9d7a70$d8d86f50$@qqmail.nl> References: <878v36az5p.fsf@ntlworld.com> <87txltaljc.fsf@ntlworld.com> <87ppwhakqq.fsf@ntlworld.com> <87ehcxaiz0.fsf@ntlworld.com> <874ndtaf4l.fsf@ntlworld.com> <87wqqp8uxw.fsf@ntlworld.com> <02a501ceaae1$9d9d7a70$d8d86f50$@qqmail.nl> Date: Fri, 6 Sep 2013 22:01:47 +0800 Message-ID: Subject: Re: svnadmin upgrade output message i18n issue From: QXO To: Bert Huijben Cc: Dongsheng Song , users@subversion.apache.org, Philip Martin Content-Type: multipart/alternative; boundary=001a11c29d22b7482204e5b77a79 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c29d22b7482204e5b77a79 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: quoted-printable http://sourceforge.net/projects/win32svn/ 2013/9/6 Bert Huijben > Which build of the Windows binaries do you use?**** > > ** ** > > The Subversion project doesn=A1=AFt produce binaries, so can=A1=AFt reall= y support > build issues.**** > > ** ** > > Personally I do build the SlikSvn binaries (http://sliksvn.com/en/downloa= d), > so if you find issues in that I might be able to help you.**** > > ** ** > > Bert**** > > ** ** > > *From:* QXO [mailto:qxodream@gmail.com] > *Sent:* vrijdag 6 september 2013 08:49 > *To:* Philip Martin > *Cc:* Dongsheng Song; users@subversion.apache.org; > dev@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***= * > > =E5=B7=B2=E5=8F=96=E5=BE=97=E7=89=88=E6=9C=AC=E5=BA=93=E9=94=81=E5=AE=9A= =E3=80?=E8=AF=B7=E7=A8=8D=E5=80=99=EF=BC=9B=E5=8D=87=E7=BA=A7=E7=89=88=E6= =9C=AC=E5=BA=93=E5=8F=AF=E8=83=BD=E9=9C=80=E8=A6=81=E4=B8=80=E6=AE=B5=E6=97= =B6=E9=97?..**** > > ** ** > > =CD=EA=B3=C9=C9=FD=BC=B6=A1=A3**** > > ** ** > > ** ** > > E:\svnmirror>D:\tools\svn-win32-1.8.0\bin\svnadmin.exe upgrade ZmccPrj***= * > > =D2=D1=C8=A1=B5=C3=B0=E6=B1=BE=BF=E2=CB=F8=B6=A8=A1=A3**** > > =C7=EB=C9=D4=BA=F2=A3=BB=C9=FD=BC=B6=B0=E6=B1=BE=BF=E2=BF=C9=C4=DC=D0=E8= =D2=AA=D2=BB=B6=CE=CA=B1=BC=E4...**** > > ** ** > > =CD=EA=B3=C9=C9=FD=BC=B6=A1=A3**** > > ** ** > > ** ** > > ** ** > > 2013/6/19 QXO **** > > The bug fixed in svn 1.8.0,Thanks:)**** > > ** ** > > 2013/5/24 Philip Martin **** > > Dongsheng Song 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**** > > ** ** > > ** ** > --001a11c29d22b7482204e5b77a79 Content-Type: text/html; charset=GB2312 Content-Transfer-Encoding: quoted-printable


2013/9/6 Bert Huijben <bert@qqmail.nl>

Which build of the Windows binaries do you u= se?

 

The Subversion proj= ect doesn’t produce binaries, so can’t really support build iss= ues.

 

Personally I do bui= ld the SlikSvn binaries (http://sliksvn.com/en/download), so if you find= issues in that I might be able to help you.

 

  &= nbsp;           &nbs= p; Bert

 

From: QXO [mailto:qxodream@gmail.com]
Sent: vrijdag 6 september 2013 08:49
To: Philip Martin
= Cc: Dongsheng Song; users@subversion.apache.org; dev@subversion.apache.org
Subject: Re: svnadmin upgrade output message i18n issue

 

Th= e bug found in svn 1.8.3(r1516576) again :(

 

 

E:\svnmirror>D:\tools\svn-win32-1.8.3\bin= \svnadmin.exe upgrade ZmccPrj

=E5=B7=B2=E5= =8F=96=E5=BE=97=E7=89=88=E6=9C=AC=E5=BA=93=E9= =94=81=E5=AE=9A=E3=80?=E8=AF=B7=E7=A8=8D= =E5=80=99=EF=BC=9B=E5=8D=87=E7=BA=A7=E7=89=88=E6=9C=AC= =E5=BA=93=E5=8F=AF=E8=83=BD=E9=9C=80=E8=A6=81=E4=B8=80=E6=AE=B5=E6=97=B6=E9= =97?..

 

=CD=EA=B3=C9=C9=FD=BC=B6=A1=A3<= /span>

 

 

E:\svnmirror>D:\tools\svn-win32-1.8.0\bin\svnadmin.exe upgrade Zm= ccPrj

=D2=D1=C8=A1=B5=C3=B0=E6=B1=BE=BF=E2=CB=F8=B6=A8=A1=A3

=C7=EB=C9=D4= =BA=F2=A3=BB=C9=FD=BC=B6=B0=E6=B1=BE=BF=E2=BF=C9=C4=DC=D0=E8=D2=AA=D2=BB=B6= =CE=CA=B1=BC=E4...

 

=CD=EA=B3=C9=C9=FD=BC=B6=A1=A3

 

 

=  

2013/6/19 QXO <qxodream@gmail.com>

The bug fixed in svn 1.8.0,Thanks:)<= /u>

 

2= 013/5/24 Philip Martin <philip.martin@wandisco.com= >

Dongsheng Song <dongsheng.song= @gmail.com> writes:

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

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


> O= r we should call bind_textdomain_codeset as possible, and warn the
> = user if HAVE_BIND_TEXTDOMAIN_CODESET not defined:
>
> #ifdef HA= VE_BIND_TEXTDOMAIN_CODESET
>   bind_textdomain_codeset(PACKAGE_NAME, "UTF-8");
&g= t; #else
>   fprintf(sdterr, "bind_textdomain_codeset not a= vailable, or not
> configured.  Non-UTF8 locales maybe see garbl= ed output.\n");
> #endif /* HAVE_BIND_TEXTDOMAIN_CODESET */

That error would be annoying if it was a fal= se alarm.  Perhaps we could
verify the correct behaviour: call gett= ext 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 U= TF8 and
the output code was failing to convert to locale encoding.


--
Certified & Su= pported Apache Subversion Downloads:
http://www.wandisco.com= /subversion/download

 

 


--001a11c29d22b7482204e5b77a79--