D.J. Heap wrote:
> Branko Čibej wrote:
>> D.J. Heap wrote:
>>> @@ -453,6 +470,10 @@
>>> if self.dblibname:
>>> + # check if they wanted nls
>>> + if self.enable_nls:
>>> + fakedefines.append("ENABLE_NLS")
>>> return fakedefines
>> Do we want to use "ENABLE_NLS" rather than "SVN_ENABLE_NLS"?
> I was trying to follow the unix stuff -- or do you mean change it just
> in the Windows stuff and define ENABLE_NLS if SVN_ENABLE_NLS is defined?
I meant both Unix and Windows stuff, of course. I understand ENABLE_NLS
is the "standard" define, but that doesn't mean it's right :-)
>>> --- svn_private_config.hw (revision 9303)
>>> +++ svn_private_config.hw (working copy)
>>> @@ -48,8 +48,16 @@
>>> /* Defined to be the path to the installed binaries */
>>> #define SVN_BINARY_DIR "/usr/local/bin"
>>> -/* Until Win32 gets gettext functionality, leave these disabled. */
>>> +/* Setup gettext macros */
>>> #define N_(x) (x)
>>> +#ifdef ENABLE_NLS
>>> +#define PACKAGE_NAME "subversion"
>>> +#define SVN_LOCALE_DIR "C:\\Stuff\\gettext\\share\\locale"
>> Index: svn_private_config.hw
>> I know this is just a default (I expect you can override it in the
>> config file?), but even so...
>> Ah, the joys of Windows. :-)
> Yeah, I'll be addressing this somehow before committing -- you think a
> config file option would be preferable to using a relative path based
> on the (dynamically located with GetModuleFileName or something) path
> to the gettext dll? I'm not sure where exactly all that stuff needs
> to go on Windows...
Putting Subversion's message files somewhere relative to the gettext DLL
doesn't seem intuitive to me at all. Unlike on Unix, gettext doesn't
have a well-known home on Windows, and sice Subversion already has its
own dir structure there, it would be much more logical to put the po
Assuming Subversion binaries (and someday DLLs) are installed in
$SVN_HOME\bin, I'd put the po files in $SVN_HOME\share\locale, then the
path would be `dirname(GetModuleFileName(0))`/../share/locale.
Then one day, when _all_ clients use the same core runtime instead of
each installing its own... :-)
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Mon Apr 12 07:02:17 2004