[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [TSVN] TortoiseSVN codepage considerations

From: SteveKing <steveking_at_gmx.ch>
Date: 2005-05-18 22:44:32 CEST

Norbert Unterberg wrote:
> SteveKing schrieb:
>
>> If we don't set the thread locale, then the Subversion messages won't
>> show up correctly. Subversion uses gettext, and gettext determines which
>> translated strings to use depending on the locale set.
>>
>>
> All this multi-language-codepage-locale-conversion stuff gives me a
> headache.

Me too - that's why I stopped worrying about it until someone who
actually *has* such a systems steps up to help. These kind of problems
can't be solved (tested) on OS with 'normal' chars.

>> It will only fail if they run TSVN in english (or another non-native
>> language). If they set the correct language in the settings, it would
>> have worked. (And it also was reported that it works then).
>>
> Problem is that this combines the application's appearance (language of
> messages) with the application's function (code page and encoding),
> which I do not really like.

Me neither. That's why I made the language selection of TSVN completely
independent of that. But when Subversion introduced other languages with
gettext, I had to change the locale to make that work.

>> If you have an idea on how to force gettext to use a specific language
>> and not the one set by the thread locale, we could get rid of that...
>>
> I have never looked at gettext, so I do not know.
> I see a few options here:
> * Let TortoiseProc use the default locale, and encapsulate every
> subversion call that might returns errors with a SetThreadLocale()
> function pair (and possibly the callbacks as well).

That looks like a good idea. I have a look tomorrow and see if it's
possible to do and what might go wrong if we do that.

> * Set the code page as you do now, but do not use any windows or library
> function that might rely on the current locale. That would mean never
> mix CStringA and CStringW, or do the conversions manually.

That will be hard to do. It's difficult to find all the places in our
sourcecode where we do that...

> * Leave everything as it is now ... until the next person complains

:)

> Can't we force everyone to use unicode? Developing for non-western
> laguages can give you the creeps!

TSVN 1.2 will only be available for Win2k and later. No Win98/Me/NT
support anymore. So we only ship the UNICODE build.
But: Subversion isn't UNICODE. At least not everywhere. It uses UTF8
internally, but e.g. diff/blame/... (all functions dealing with text
files) won't convert the file data at all, so those strings won't be
UTF8 encoded.

Stefan

-- 
        ___
   oo  // \\      "De Chelonian Mobile"
  (_,\/ \_/ \     TortoiseSVN
    \ \_/_\_/>    The coolest Interface to (Sub)Version Control
    /_/   \_\     http://tortoisesvn.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Wed May 18 22:46:25 2005

This is an archived mail posted to the TortoiseSVN Dev mailing list.

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