You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Collins-Sussman <su...@collab.net> on 2004/03/30 19:14:38 UTC
gettext integration (was Re: [PATCH] Do not use gettextize and
i18n round 2 Re: I18n: The gettext proposal)
On Tue, 2004-03-30 at 12:25, Justin Erenkrantz wrote:
> I do welcome your efforts to help with the i18n, but I'm not willing to see us
> compromise our build system in the process. -- justin
Let me focus the discussion here. We're trying to answer two questions
right now:
1. Which gettext do we use?
2. How do we integrate it into our build system?
Nicolas wants us to require the use of GNU's gettext. Justin wants us
to be able to use various gettext implementations... either GNU, or
whatever happens to be available.
I just spoke with Justin in IRC, and he's claiming that if we were to
require GNU gettext, we'd have to import 28 m4 files. (Is this really
true?) Justin also claims it would be much easier to write our own
little bit of m4 to detect either GNU gettext or some other native
gettext implementation... so that in essence, our build system would be
much *less* complicated if we allowed multiple gettext implementations.
Finally, Justin is claiming that there's no risk of chaos here: that
the various gettext implementations out there all share a common .po
format... only the .mo files (compiled .po's) are
implementation-specific, because well, the runtime library (libintl) is
implementation-specific as well, just as you'd expect. Not a big deal.
Anyway, does anyone care to refute Justin? :-) He's giving definite
answers to the question above (he's even supplied a patch for #2). I'd
just like to hear if there are any other sides to this story.
For example, I'd like to know why Nicolas thinks we should standardize
on just GNU gettext... does it offer specific features we need?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gettext integration (was Re: [PATCH] Do not use gettextize
and i18n round 2 Re: I18n: The gettext proposal)
Posted by Justin Erenkrantz <ju...@erenkrantz.com>.
--On Tuesday, March 30, 2004 2:03 PM -0600 Ben Collins-Sussman
<su...@collab.net> wrote:
>> It's not true. We could
>> 1) just add a call to aclocal somewhere (part of normal autoconf
>> infrastrcture)
>
> What do you mean by this? That we call out to the gettext a4 files that
> live somewhere else on the system?
FWIW, aclocal is a part of automake not autoconf. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gettext integration (was Re: [PATCH] Do not use gettextize and
i18n round 2 Re: I18n: The gettext proposal)
Posted by Ben Collins-Sussman <su...@collab.net>.
On Tue, 2004-03-30 at 13:45, Nicolás Lichtmaier wrote:
> >I just spoke with Justin in IRC, and he's claiming that if we were to
> >require GNU gettext, we'd have to import 28 m4 files. (Is this really
> >true?)
> >
> It's not true. We could
> 1) just add a call to aclocal somewhere (part of normal autoconf
> infrastrcture)
What do you mean by this? That we call out to the gettext a4 files that
live somewhere else on the system?
> 2) write a simpler version of these macros.
This sounds similar to what Justin is proposing...
> But when we add a bunch of
> hand-written subversion specific macros we are adopting a new child to
> feed =).
...but it seems like you're against the idea of writing svn-specific
macros in general. So I'm confused. Can you elaborate on your proposal
to "just add a call to aclocal"?
> But yes, we can target
> any gettext implementation, but doing so will be more complex because
> you never know which level of support each UNIX gettext has.
Is there a minimum set of features that all gettext implementations
support? If so, is it defined anywhere? Surely other projects have
gone down this road before, and have an idea of which gettext features
are portable and which aren't. I'd like to hear more about this.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: gettext integration (was Re: [PATCH] Do not use gettextize and
i18n round 2 Re: I18n: The gettext proposal)
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>Nicolas wants us to require the use of GNU's gettext. Justin wants us
>to be able to use various gettext implementations... either GNU, or
>whatever happens to be available.
>
>I just spoke with Justin in IRC, and he's claiming that if we were to
>require GNU gettext, we'd have to import 28 m4 files. (Is this really
>true?)
>
It's not true. We could
1) just add a call to aclocal somewhere (part of normal autoconf
infrastrcture)
2) write a simpler version of these macros.
>Justin also claims it would be much easier to write our own
>little bit of m4 to detect either GNU gettext or some other native
>gettext implementation... so that in essence, our build system would be
>much *less* complicated if we allowed multiple gettext implementations.
>
>
With these ideas, subversion is more and more complicated, as it
deviates from what everyone else does and without good reasons. If we
just use the standard build procedure, there's nothing subversion
specific a developer should care for. But when we add a bunch of
hand-written subversion specific macros we are adopting a new child to
feed =).
>Finally, Justin is claiming that there's no risk of chaos here: that
>the various gettext implementations out there all share a common .po
>format... only the .mo files (compiled .po's) are
>implementation-specific, because well, the runtime library (libintl) is
>implementation-specific as well, just as you'd expect. Not a big deal.
>
>Anyway, does anyone care to refute Justin? :-) He's giving definite
>answers to the question above (he's even supplied a patch for #2). I'd
>just like to hear if there are any other sides to this story.
>
>For example, I'd like to know why Nicolas thinks we should standardize
>on just GNU gettext... does it offer specific features we need?
>
>
One advantage I can think of is plurals handling. But yes, we can target
any gettext implementation, but doing so will be more complex because
you never know which level of support each UNIX gettext has. That's way
many projects are now just requiring the use of GNU gettext. NLS is an
optional feature anyway.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org