Martin
> *Cc:* Dongsheng Song; users@subversion.apache.org;
> d...@subversion.apache.org
> *Subject:* Re: svnadmin upgrade output message i18n issue
>
> ** **
>
> The bug found in svn 1.8.3(r1516576) again :(
>
> ** **
>
> ** **
>
> E:\svnmirror>D:\
.
Bert
From: QXO [mailto:qxodr...@gmail.com]
Sent: vrijdag 6 september 2013 08:49
To: Philip Martin
Cc: Dongsheng Song; users@subversion.apache.org; d...@subversion.apache.org
Subject: Re: svnadmin upgrade output message i18n issue
The bug found in svn 1.8.3(r1516576) again :(
E:\svnmirror&g
QXO writes:
> 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
> 已取得版本库锁定。
> 请稍候；升级版本库可能需要一段时间...
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
已取得版本库锁定。
请稍候；升级版本库可能需要一段时间...
完成升级
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_COD
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
prope
On Fri, May 24, 2013 at 12:52 AM, Erik Huelsmann wrote:
> One application has multiple active code page settings on Windows. Or course
> if your example was the only option, we would not be having this discussion.
>
Very interesting. In my mind, application only can have 1 active
locale in 1 thre
One application has multiple active code page settings on Windows. Or
course if your example was the only option, we would not be having this
discussion.
Bye,
Erik.
sent from my phone
On May 23, 2013 6:44 PM, "Dongsheng Song" wrote:
> On Thu, May 23, 2013 at 11:38 PM, Erik Huelsmann wrote:
>
On Thu, May 23, 2013 at 11:29 PM, Philip Martin
wrote:
> Dongsheng Song writes:
>
>> Even ALL the translations are UTF-8, GETTEXT(3) still return the
>> string encoded by the ***current locale's codeset***.
>>
>> Here is sniped from the GETTEXT(3) man pages:
>>
>> In both cases, the functions al
On Thu, May 23, 2013 at 11:38 PM, Erik Huelsmann wrote:
> That was not my point nor the point we discussed back then. As long as
> gettext tries to convert its translations to *any* encoding, it's flawed by
> design, because some systems have multiple active output encodings (e.g.
> Windows).
>
T
Found at least one of the related discussions:
http://svn.haxx.se/dev/archive-2004-05/0078.shtml
bye,
Erik.
On May 23, 2013 5:38 PM, "Erik Huelsmann" wrote:
>
> > >
> > >> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> > >> messages, write it ***AS IS***, since GETTEXT(3
> >
> >> I think the best solution is: DO NOTconvert the GETTEXT(3) returned
> >> messages, write it ***AS IS***, since GETTEXT(3) already do the
> >> correct conversion for us.
> >
> > Well, even though gettext may want us to believe otherwise, this doesn't
> > work for cross platform application
Dongsheng Song writes:
> Even ALL the translations are UTF-8, GETTEXT(3) still return the
> string encoded by the ***current locale's codeset***.
>
> Here is sniped from the GETTEXT(3) man pages:
>
> In both cases, the functions also use the LC_CTYPE locale facet in
> order to convert the tr
On Thu, May 23, 2013 at 11:02 PM, Erik Huelsmann wrote:
> sent from my phone
>
>
> On May 23, 2013 4:43 PM, "Dongsheng Song" wrote:
>>
>> On Thu, May 23, 2013 at 10:06 PM, Philip Martin
>> wrote:
>> > Dongsheng Song writes:
>> >
>> >> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
>> >> wrote:
sent from my phone
On May 23, 2013 4:43 PM, "Dongsheng Song" wrote:
>
> On Thu, May 23, 2013 at 10:06 PM, Philip Martin
> wrote:
> > Dongsheng Song writes:
> >
> >> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
> >> wrote:
> >>> Dongsheng Song writes:
> >>>
> On Thu, May 23, 2013 at 9:11
On Thu, May 23, 2013 at 10:06 PM, Philip Martin
wrote:
> Dongsheng Song writes:
>
>> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
>> wrote:
>>> Dongsheng Song writes:
>>>
On Thu, May 23, 2013 at 9:11 PM, Philip Martin
wrote:
> Philip Martin writes:
>
>> So it appears t
On 23.05.2013 16:06, Philip Martin wrote:
> Dongsheng Song writes:
>
>> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
>> wrote:
>>> Dongsheng Song writes:
>>>
On Thu, May 23, 2013 at 9:11 PM, Philip Martin
wrote:
> Philip Martin writes:
>
>> So it appears the UTF8 to nat
Dongsheng Song writes:
> On Thu, May 23, 2013 at 9:28 PM, Philip Martin
> wrote:
>> Dongsheng Song writes:
>>
>>> On Thu, May 23, 2013 at 9:11 PM, Philip Martin
>>> wrote:
Philip Martin writes:
> So it appears the UTF8 to native conversion is missing from
> repos_notify_hand
On Thu, May 23, 2013 at 9:28 PM, Philip Martin
wrote:
> Dongsheng Song writes:
>
>> On Thu, May 23, 2013 at 9:11 PM, Philip Martin
>> wrote:
>>> Philip Martin writes:
>>>
So it appears the UTF8 to native conversion is missing from
repos_notify_handler. I think repos_notify_handler sh
Dongsheng Song writes:
> On Thu, May 23, 2013 at 9:11 PM, Philip Martin
> wrote:
>> Philip Martin writes:
>>
>>> So it appears the UTF8 to native conversion is missing from
>>> repos_notify_handler. I think repos_notify_handler should be using
>>> svn_stream_printf_from_utf8 rather than svn_st
On Thu, May 23, 2013 at 9:11 PM, Philip Martin
wrote:
> Philip Martin writes:
>
>> So it appears the UTF8 to native conversion is missing from
>> repos_notify_handler. I think repos_notify_handler should be using
>> svn_stream_printf_from_utf8 rather than svn_stream_printf.
>
> I've fixed trunk
Philip Martin writes:
> So it appears the UTF8 to native conversion is missing from
> repos_notify_handler. I think repos_notify_handler should be using
> svn_stream_printf_from_utf8 rather than svn_stream_printf.
I've fixed trunk to use svn_cmdline_cstring_from_utf8 and proposed it
for 1.8.
-
On Thu, May 23, 2013 at 4:17 PM, Philip Martin
wrote:
> [bringing in dev@s.a.o]
>
> QXO writes:
>
>> os: windows
>> encoding:GBK ( chcp 936 )
>>
>> The svnadmin upgrade command output message first line encoding
>> issue(UTF-8 show in GBK),But the second line is right encoding!
>>
>> 宸插彇寰楃増鏈簱閿
[bringing in dev@s.a.o]
QXO writes:
> os: windows
> encoding:GBK ( chcp 936 )
>
> The svnadmin upgrade command output message first line encoding
> issue(UTF-8 show in GBK),But the second line is right encoding!
>
> 宸插彇寰楃増鏈簱閿佸畾銆?璇风◢鍊欙紱鍗囩骇鐗堟湰搴撳彲鑳介渶瑕佷竴娈垫椂闂?..
>
> 完成升级。
>
> if change console enc
I have download a binary package from win32svn[1], and confirmed your issue.
I check the subversion.mo file:
msgunfmt.exe subversion.mo -o subversion.po
It looks OK. Then I replaced the intl3_svn.dll file with gettext
0.18.2, it give me another output:
C:\var\tmp>svnadmin upgrade test
已取得版本库锁
os: windows
encoding:GBK ( chcp 936 )
The svnadmin upgrade command output message first line encoding
issue(UTF-8 show in GBK),But the second line is right encoding!
宸插��寰���搴瀹���?璇风�锛绾х�搴��介��瑕�涓�娈垫�堕�?..
完成升级。
if change console encoding to UTF-8 (chcp 65001),output m
26 matches
Mail list logo
