[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: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-03-30 19:57:14 CEST

Nicolas and Justin --

I'm really excited that the two of you have started working on l10n. It
was already on my plate as something to start researching post-1.0. I
just read the beginning of the gettext manual, as well as Nicolas'
introductory email, and now this thread. It's all pretty new, pretty
cool stuff to me!

On Tue, 2004-03-30 at 11:17, Justin Erenkrantz wrote:

> but I'm still skeptical long-term that we're not going to
> introduce a dependency.
>

I've always assumed that localizing Subversion means we're going to add
a new runtime library dependency, as well a number of compile-time
dependencies on specific tools. Is this a problem? Is it not worth the
pain? It certainly doesn't bother me. Is there disagreement among
developers on this point?

> I think my biggest concern for i18n adoption is that we will no longer be able
> to use constant char *'s for our error strings (the big help structs). A lot
> of our help code and error strings rely upon that, so I don't know how we're
> going to refactor that.

I don't understand... can you elaborate? In Nicolas' email, he
explained how a number of code changes would be required to work with
the xgettext scanner. Is this another one to add to that list?

Also, while I'm here, let me suggest a strategy for moving forward:

0. Start a completely new mail thread about what we do/don't have to do
regarding linking to LGPL libraries like libneon or libintl. We've had
this problem for years with neon -- and it's fine to discuss it now --
but I don't want to blur that issue into gettext "how to" discussions.
It needs to be a separate thread.

1. Get gettexty tools fully integrated into our build-system, and make
sure they work exactly the way we want on all our different platforms.
This can be done in a series of trunk commits; I don't think we need a
branch.

2. After all the build-system work is complete, *then* we start
refactoring our stringy code for the scanner.

3. When steps 1 and 2 are finished, we'll finally have a complete .pot
template, and we can let volunteers start producing .po files.

I think Karl might be willing to do step #0; and it looks like Justin
has already started on #1. I'm not knowledgeable enough to evaluate
Justin's build-system patch, though. I might ask Justin, however, if
he'd be willing to trim down his patch to *just* build-system changes,
and not _() changes. I beg for smaller patches, easier for newbies like
me to understand. No power plants. :-)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 30 19:58:28 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.