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

Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal

From: Justin Erenkrantz <justin_at_erenkrantz.com>
Date: 2004-03-31 02:13:53 CEST

--On Tuesday, March 30, 2004 1:36 PM -0800 Greg Stein <gstein@lyra.org> wrote:

> You don't mention the ALL_LINGUAS variable. And that is one that I'd like
> to complain about :-)
>
> I would *much* prefer that we put the "po" path into build.conf and have
> gen-build look in that directory for .po files. Then it can create a bunch
> of dependency lines for the files, create some roll-up symbols, and then
> we can use that simple dependency mechanism in the top-level Makefile.
>
> Basically, I think if you have a 'for' loop in a Makefile, then you're not
> using 'make' and gen-build as well as we could.

Heh. You want to go even further than I did. ;-) But, yes, we should go all
out and use build.conf. In the interest of making progress, I *might* just go
check it in with ALL_LINGUAS and come back later and refactor out once we're
settled down. But, I think we need a handle on our detection and usage of
gettext first. I'll have to see how much progress I can make tonight...

>> ...
>> +PACKAGE_NAME=@PACKAGE_NAME@
>> +PACKAGE_VERSION=@PACKAGE_VERSION@
>
> PACKAGE_VERSION isn't used. I also worry about a single PACKAGE_NAME,
> given Nicolas' point about libraries vs executables. Can we get away with
> a single package name? Or will we need to use, say, 'subversion' and
> 'libsvn' ?

Well, those are the defines coming from autoconf. I just added
PACKAGE_VERSION for symmetry.

I think a single 'domain' name (gettext parlance) is what we'd want - not two
domains. Otherwise, we'd have to switch our domains depending upon where it
is being called. I think that would complicate things too much and could slow
us down if we had to check where we're coming from.

> These ought to be redone in favor of gen-build producing deps for us.

*nod*

>> ...
>> +++ configure.in (working copy)
>> ...
>> +dnl I18n -------------------
>>
>> +localedir='${datadir}/locale'
>> +localedir="${localedir}/subversion-${svn_version}"
>> +AC_SUBST(localedir)
>
> That doesn't seem to follow the pattern on my RedHat 9.0 box. I have:
>
> /usr/share/locale/$(LANGUAGE)/LC_MESSAGES/$(PACKAGE).mo
>
> I'm not sure about the best way to handle this, given the different
> platform and implementation layouts.

As I have it now, it'd install to
$localedir/$(LANGUAGE)/LC_MESSAGES/$(PACKAGE).mo. That would typically make
it:

$prefix/share/subversion-1.1.0/$(LANGUAGE)/LC_MESSAGES/$(PACKAGE).mo

Note that the $(LANGUAGE)/LC_MESSAGES/$(PACKAGE) part is right now in the
makefile install target. And, the path to bindtextdomain needs to be
$localedir not the full patch with the LANGUAGE and PACKAGE.

I think this is acceptable given how we're installing everything else. We
could drop the version, but how would we handle multiple installs, then?

> I think you'll have to add this to the svn_private_config.hw file.
> Alternatively, this kind of stuff can go into second file which then gets
># include'd from the (two) svn_private_config.h files.

*nod*

> I think your changes will need to go into svn_cmdline_init(), and be
> coordinated with the setlocale() call in there.

Oh, is there an invocation in svn_cmdline_init()? That's probably a better
place, then. ;-)

Thanks! -- justin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Mar 31 02:14:06 2004

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

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