The bug found in svn 1.8.3(r1516576) again :(
E:\svnmirrorD:\tools\svn-win32-1.8.3\bin\svnadmin.exe upgrade ZmccPrj
宸插��寰���搴瀹���?璇风�锛绾х�搴��介��瑕�涓�娈垫�堕�?..
完成升级。
E:\svnmirrorD:\tools\svn-win32-1.8.0\bin\svnadmin.exe upgrade ZmccPrj
已取得版本库锁定。
请稍候；升级版本库可能需要一段时间...
完成升级。
QXO qxodr...@gmail.com writes:
The bug found in svn 1.8.3(r1516576) again :(
E:\svnmirrorD:\tools\svn-win32-1.8.3\bin\svnadmin.exe upgrade ZmccPrj
宸插彇寰楃増鏈簱閿佸畾銆?璇风◢鍊欙紱鍗囩骇鐗堟湰搴撳彲鑳介渶瑕佷竴娈垫椂闂?..
完成升级。
E:\svnmirrorD:\tools\svn-win32-1.8.0\bin\svnadmin.exe upgrade ZmccPrj
已取得版本库锁定。
[bringing in dev@s.a.o]
QXO qxodr...@gmail.com 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
On Thu, May 23, 2013 at 4:17 PM, Philip Martin
philip.mar...@wandisco.com wrote:
[bringing in dev@s.a.o]
QXO qxodr...@gmail.com 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
Philip Martin philip.mar...@wandisco.com 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
On Thu, May 23, 2013 at 9:11 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Philip Martin philip.mar...@wandisco.com 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
On Thu, May 23, 2013 at 9:28 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Dongsheng Song dongsheng.s...@gmail.com writes:
On Thu, May 23, 2013 at 9:11 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Philip Martin philip.mar...@wandisco.com writes:
So it appears the UTF8 to native
Dongsheng Song dongsheng.s...@gmail.com writes:
On Thu, May 23, 2013 at 9:28 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Dongsheng Song dongsheng.s...@gmail.com writes:
On Thu, May 23, 2013 at 9:11 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Philip Martin
On Thu, May 23, 2013 at 10:06 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Dongsheng Song dongsheng.s...@gmail.com writes:
On Thu, May 23, 2013 at 9:28 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Dongsheng Song dongsheng.s...@gmail.com writes:
On Thu, May 23, 2013 at 9:11 PM,
sent from my phone
On May 23, 2013 4:43 PM, Dongsheng Song dongsheng.s...@gmail.com wrote:
On Thu, May 23, 2013 at 10:06 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Dongsheng Song dongsheng.s...@gmail.com writes:
On Thu, May 23, 2013 at 9:28 PM, Philip Martin
On Thu, May 23, 2013 at 11:02 PM, Erik Huelsmann ehu...@gmail.com wrote:
sent from my phone
On May 23, 2013 4:43 PM, Dongsheng Song dongsheng.s...@gmail.com wrote:
On Thu, May 23, 2013 at 10:06 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Dongsheng Song dongsheng.s...@gmail.com
Dongsheng Song dongsheng.s...@gmail.com 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
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 applications: e.g. in
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 ehu...@gmail.com wrote:
I think the best solution is: DO NOTconvert the GETTEXT(3) returned
messages, write it ***AS IS***, since
On Thu, May 23, 2013 at 11:38 PM, Erik Huelsmann ehu...@gmail.com 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.
On Thu, May 23, 2013 at 11:29 PM, Philip Martin
philip.mar...@wandisco.com wrote:
Dongsheng Song dongsheng.s...@gmail.com 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
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 dongsheng.s...@gmail.com wrote:
On Thu, May 23, 2013 at 11:38 PM,
On Fri, May 24, 2013 at 12:52 AM, Erik Huelsmann ehu...@gmail.com 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
Dongsheng Song dongsheng.s...@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
19 matches
Mail list logo
