You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Justin Erenkrantz <ju...@erenkrantz.com> on 2004/03/30 09:49:16 UTC
[PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext
proposal
--On Tuesday, March 30, 2004 12:55 AM -0300 Nicolás Lichtmaier
<ni...@reloco.com.ar> wrote:
> Hi, I propose to use gettext for i18n.
This would add a new build and run-time dependency that I think we have to be
very careful about handling. I really wish this could be made optional rather
than being a mandatory requirement. As an aside, we would have to disable
static linking if we import gettext as LGPL forbids any static binaries
created with LGPL functionality. (Hmm, we'd have to do the same for neon -
are we?)
The biggest problem is that GNU gettext expects us to be using automake, which
isn't going to be used. I think the best course of action is to just discard
everything that gettextize does and write our own configure checks and
Makefile. This should have the added bonus of allowing us to work against
non-GNU gettext and with non-GNU makes.
Regarding the patch you posted earlier:
* svn:ignores: This change can go away with some tweaking to remove the
'dependency' on aclocal.m4; however, we'd have to compensate in autogen.sh by
copying all of the 'right' files over.
* Makefile.in: With the exception of the i18n targets, these changes are
entirely bogus. DEFS and the LOCALEDIR are most certainly not options that
should be passed to the compiler, but rather to the preprocessor. The
makefile should not have targets for configure, config.status, etc. (I have a
hunch you are going to try to get us to use automake.)
* configure.in: I see no reason why gettext needs us to define PACKAGE or
VERSION.
* po/Makefile.in.in: We're not using automake, so we need to construct our own
customized Makefile.in.
* po/ChangeLog: we don't use a ChangeLog file; please remove.
* subversion/*.c: We do not protect includes of svn_private_config.h as it is
always available (even on Win32). You are also using the incorrect syntax (<>
vs "") and including it in the wrong place out-of-order (should not be at the
top of the file) - see our other files for the 'right' place to include it.
* subversion/clients/cmdline/main.c: The signal thing isn't relevant.
From a build system perspective, I think actually our best approach here is
going to be to toss GNU gettext's awful m4 and Makefile.in.in files (which
don't work on non-GNU makes) and roll our own detection code to support
gettext. GNU xgettext probably would still be best for creating the .po
files as it supports the --keyword flag, but Solaris's msgfmt can still
read those. (We'd check in the .po files, so that there isn't a dependency
on the developers to have a 'sane' xgettext.)
So, in an effort to put my word where my mouth is, the following patch
addresses these issues with your patch and builds for me on Solaris without
GNU gettext. This probably still needs work to bring in libintl for GNU
gettext though.
% ./svn
Type 'svn help' for usage.
% LC_ALL=C ./svn
Type 'svn help' for usage.
% LC_ALL=fr ./svn
Typo me 'svn' help' for na-na-na usage.
I don't have the 'es' locale installed, so I tweaked it to be 'fr' for me with
the non-sensical help message. -- justin
* Makefile.in: Add localedir, MSGFMT, PACKAGE_NAME, PACKAGE_VERSION substs from
configure; add in build-i18n and install-i18n targets
[installs to right location for Solaris; no clue about GNU gettext]
* configure.in: Remove old placeholder for GNU gettext and move down to a
more sensible location; add in i18n config section which enables NLS iff
msgfmt is found; export SVN_LOCALE_DIR properly escaped so main.c can use;
if i18n enabled, add in build-i18n and install-i18n targets
[the double eval is funny, but there isn't a clean way to fully expand here.
There are some M4 macros in apr or httpd for this though.]
* subversion/clients/cmdline/main.c: Include svn_private_config.h, _()-escape
some strings
(main): call setlocale, bindtextdomain, and textdomain to initialize gettext
* subversion/libsvn_wc/relocate.c, subversion/libsvn_wc/entries.c
subversion/libsvn_wc/copy.c, subversion/libsvn_wc/lock.c
subversion/libsvn_wc/translate.c,
subversion/clients/cmdline/props.c, subversion/clients/cmdline/mkdir-cmd.c
subversion/clients/cmdline/blame-cmd.c, subversion/clients/cmdline/log-cmd.c
subversion/clients/cmdline/delete-cmd.c, subversion/clients/cmdline/notify.c
subversion/clients/cmdline/export-cmd.c,
subversion/clients/cmdline/info-cmd.c: Include "svn_private_config.h" and
_()-escape strings which we can handle via xgettext and i18n. [From
Nicolás's earlier patch with correct include's though.]
* subversion/libsvn_subr/opt.c (svn_opt_print_help): Add _() to the 'default'
case when there are no arguments.
* po/es.po: Delta against Nicolás's earlier es.po file which adds the default
help string with a pointless translation.
Index: Makefile.in
===================================================================
--- Makefile.in (revision 9230)
+++ Makefile.in (working copy)
@@ -57,6 +57,7 @@
infodir = @infodir@
datadir = @datadir@
docdir = @docdir@
+localedir = @localedir@
# where to install libsvn_swig_*
swig_py_libdir = @libdir@
@@ -78,7 +79,10 @@
TEXI2DVI = texi2dvi
DVIPS = dvips
DVIPDF = dvipdf
+MSGFMT = @MSGFMT@
+PACKAGE_NAME=@PACKAGE_NAME@
+PACKAGE_VERSION=@PACKAGE_VERSION@
CC = @CC@
CXX = @CXX@
@@ -511,3 +515,17 @@
echo "$(INSTALL_DATA) $$file $(DESTDIR)$(infodir)/$$inst"; \
$(INSTALL_DATA) $$file $(DESTDIR)$(infodir)/$$inst; \
done
+
+ALL_LINGUAS=@ALL_LINGUAS@
+build-i18n:
+ @list='$(ALL_LINGUAS)'; \
+ for i in $$list; do \
+ $(MSGFMT) -o po/$$i.mo $(srcdir)/po/$$i.po; \
+ done
+
+install-i18n:
+ $(MKDIR) $(DESTDIR)$(localedir)
+ @list='$(ALL_LINGUAS)'; \
+ for i in $$list; do \
+ $(INSTALL_DATA) po/$$i.mo
$(DESTDIR)$(localedir)/$$i/LC_MESSAGES/$(PACKAGE_NAME).mo; \
+ done
Index: configure.in
===================================================================
--- configure.in (revision 9230)
+++ configure.in (working copy)
@@ -73,11 +73,6 @@
dnl (We can add custom defines by creating ./acconfig.h if we wish.)
AC_CONFIG_HEADER(svn_private_config.h)
-dnl Todo: we're English-only now, but GNU Gettext eventually?
-dnl Set of available languages.
-dnl ALL_LINGUAS="de fr es ko nl no pl pt sl sv"
-dnl I volunteer for this ^^ translation :-) -xbc
-
dnl Check for programs ---------------------
dnl Look for a C compiler (before anything can set CFLAGS)
@@ -255,7 +250,43 @@
SVN_LIB_BERKELEY_DB($SVN_FS_WANT_DB_MAJOR, $SVN_FS_WANT_DB_MINOR,
$SVN_FS_WANT_DB_PATCH, [db4 db])
+dnl I18n -------------------
+localedir='${datadir}/locale'
+localedir="${localedir}/subversion-${svn_version}"
+AC_SUBST(localedir)
+
+dnl Set of available languages.
+dnl ALL_LINGUAS="de fr es ko nl no pl pt sl sv"
+dnl I volunteer for this ^^ translation :-) -xbc
+ALL_LINGUAS="es"
+AC_SUBST(ALL_LINGUAS)
+
+USE_NLS="no"
+AC_PATH_PROG(MSGFMT, msgfmt, none)
+if test "$MSGFMT" != "none"; then
+ AC_DEFINE(ENABLE_NLS, 1,
+ [Define to 1 if translation of program messages to the user's
+ native language is requested.])
+ dnl Must expand twice at least to get prefix expanded!
+ svn_localedir="`eval echo ${localedir}`"
+ svn_localedir="`eval echo ${svn_localedir}`"
+ AC_DEFINE_UNQUOTED(SVN_LOCALE_DIR, "${svn_localedir}",
+ [Defined to be the path to the installed locale dirs])
+ USE_NLS="yes"
+fi
+
+AH_BOTTOM(
+#define N_(x) (x)
+#ifdef ENABLE_NLS
+#include <locale.h>
+#include <libintl.h>
+#define _(x) dgettext(PACKAGE_NAME, x)
+#else
+#define _(x) (x)
+#endif
+)
+
# Only add *_APACHE_RULE if we also have db, since mod_dav_svn depends on it.
INSTALL_STATIC_RULES="install-bin install-docs"
INSTALL_RULES="install-base-lib install-lib install-include install-static"
@@ -274,6 +305,11 @@
INSTALL_RULES="`echo $INSTALL_RULES | sed 's/install-lib/install-dav-lib
install-lib/'`"
fi
+if test "$USE_NLS" = "yes"; then
+ BUILD_RULES="$BUILD_RULES build-i18n"
+ INSTALL_RULES="$INSTALL_RULES install-i18n"
+fi
+
AC_SUBST(BUILD_RULES)
AC_SUBST(INSTALL_STATIC_RULES)
AC_SUBST(INSTALL_RULES)
Index: subversion/libsvn_wc/relocate.c
===================================================================
--- subversion/libsvn_wc/relocate.c (revision 9230)
+++ subversion/libsvn_wc/relocate.c (working copy)
@@ -30,6 +31,8 @@
#include "entries.h"
#include "props.h"
+#include "svn_private_config.h"
+
svn_error_t *
svn_wc_relocate (const char *path,
@@ -62,7 +65,7 @@
return svn_error_create (SVN_ERR_ENTRY_NOT_FOUND, NULL, NULL);
if (! entry->url)
return svn_error_createf (SVN_ERR_ENTRY_MISSING_URL, NULL,
- "Entry '%s' has no URL", path);
+ _("Entry '%s' has no URL"), path);
if (! strncmp (entry->url, from, from_len))
{
Index: subversion/libsvn_wc/entries.c
===================================================================
--- subversion/libsvn_wc/entries.c (revision 9230)
+++ subversion/libsvn_wc/entries.c (working copy)
@@ -35,6 +36,8 @@
#include "adm_ops.h"
#include "entries.h"
+#include "svn_private_config.h"
+
/** Overview **/
@@ -114,7 +117,7 @@
SVN_WC__ENTRIES_TOPLEVEL);
SVN_ERR_W (svn_io_file_write_full (f, accum->data, accum->len, NULL, pool),
- apr_psprintf (pool, "Error writing entries file for '%s'",
path));
+ apr_psprintf (pool, _("Error writing entries file for '%s'"),
path));
/* Now we have a `entries' file with exactly one entry, an entry
for this dir. Close the file and sync it up. */
@@ -215,7 +218,7 @@
else
return svn_error_createf
(SVN_ERR_NODE_UNKNOWN_KIND, NULL,
- "Entry '%s' has invalid node kind",
+ _("Entry '%s' has invalid node kind"),
(name ? name : SVN_WC_ENTRY_THIS_DIR));
*modify_flags |= SVN_WC__ENTRY_MODIFY_KIND;
}
@@ -240,7 +243,7 @@
else
return svn_error_createf
(SVN_ERR_ENTRY_ATTRIBUTE_INVALID, NULL,
- "Entry '%s' has invalid '%s' value",
+ _("Entry '%s' has invalid '%s' value"),
(name ? name : SVN_WC_ENTRY_THIS_DIR),
SVN_WC__ENTRY_ATTR_SCHEDULE);
@@ -290,7 +293,7 @@
else
return svn_error_createf
(SVN_ERR_ENTRY_ATTRIBUTE_INVALID, NULL,
- "Entry '%s' has invalid '%s' value",
+ _("Entry '%s' has invalid '%s' value"),
(name ? name : SVN_WC_ENTRY_THIS_DIR),
SVN_WC__ENTRY_ATTR_COPIED);
@@ -330,7 +333,7 @@
else
return svn_error_createf
(SVN_ERR_ENTRY_ATTRIBUTE_INVALID, NULL,
- "Entry '%s' has invalid '%s' value",
+ _("Entry '%s' has invalid '%s' value"),
(name ? name : SVN_WC_ENTRY_THIS_DIR),
SVN_WC__ENTRY_ATTR_DELETED);
@@ -357,7 +360,7 @@
else
return svn_error_createf
(SVN_ERR_ENTRY_ATTRIBUTE_INVALID, NULL,
- "Entry '%s' has invalid '%s' value",
+ _("Entry '%s' has invalid '%s' value"),
(name ? name : SVN_WC_ENTRY_THIS_DIR),
SVN_WC__ENTRY_ATTR_ABSENT);
@@ -384,7 +387,7 @@
else
return svn_error_createf
(SVN_ERR_ENTRY_ATTRIBUTE_INVALID, NULL,
- "Entry '%s' has invalid '%s' value",
+ _("Entry '%s' has invalid '%s' value"),
(name ? name : SVN_WC_ENTRY_THIS_DIR),
SVN_WC__ENTRY_ATTR_INCOMPLETE);
@@ -565,17 +568,17 @@
if (! default_entry)
return svn_error_create (SVN_ERR_ENTRY_NOT_FOUND,
NULL,
- "Missing default entry");
+ _("Missing default entry"));
if (default_entry->revision == SVN_INVALID_REVNUM)
return svn_error_create (SVN_ERR_ENTRY_MISSING_REVISION,
NULL,
- "Default entry has no revision number");
+ _("Default entry has no revision number"));
if (! default_entry->url)
return svn_error_create (SVN_ERR_ENTRY_MISSING_URL,
NULL,
- "Default entry is missing URL");
+ _("Default entry is missing URL"));
/* Then use it to fill in missing information in other entries. */
@@ -663,7 +666,7 @@
SVN_ERR_W (svn_xml_parse (svn_parser, buf, bytes_read,
err && APR_STATUS_IS_EOF(err->apr_err)),
apr_psprintf (pool,
- "XML parser failed in '%s'",
+ _("XML parser failed in '%s'"),
svn_wc_adm_access_path (adm_access)));
} while (! err);
@@ -752,7 +755,7 @@
if (! default_entry)
return svn_error_createf
(SVN_ERR_WC_CORRUPT, NULL,
- "Corrupt working copy: '%s' has no default entry", path);
+ _("Corrupt working copy: '%s' has no default entry"), path);
/* Validate DEFAULT_ENTRY's current schedule. */
switch (default_entry->schedule)
@@ -768,7 +771,7 @@
/* This is an invalid state */
return svn_error_createf
(SVN_ERR_WC_CORRUPT, NULL,
- "Corrupt working copy: directory '%s' has an invalid schedule",
+ _("Corrupt working copy: directory '%s' has an invalid schedule"),
path);
}
@@ -802,8 +805,8 @@
/* This is an invalid state */
return svn_error_createf
(SVN_ERR_WC_CORRUPT, NULL,
- "Corrupt working copy: "
- "'%s' in directory '%s' has an invalid schedule",
+ _("Corrupt working copy: "
+ "'%s' in directory '%s' has an invalid schedule"),
name, path);
}
@@ -811,24 +814,24 @@
&& (this_entry->schedule != svn_wc_schedule_add))
return svn_error_createf
(SVN_ERR_WC_CORRUPT, NULL,
- "Corrupt working copy: '%s' in directory '%s' (which is scheduled "
- "for addition) is not itself scheduled for addition",
+ _("Corrupt working copy: '%s' in directory '%s' (which is
scheduled "
+ "for addition) is not itself scheduled for addition"),
name, path);
if ((default_entry->schedule == svn_wc_schedule_delete)
&& (this_entry->schedule != svn_wc_schedule_delete))
return svn_error_createf
(SVN_ERR_WC_CORRUPT, NULL,
- "Corrupt working copy: '%s' in directory '%s' (which is scheduled "
- "for deletion) is not itself scheduled for deletion",
+ _("Corrupt working copy: '%s' in directory '%s' (which is
scheduled "
+ "for deletion) is not itself scheduled for deletion"),
name, path);
if ((default_entry->schedule == svn_wc_schedule_replace)
&& (this_entry->schedule == svn_wc_schedule_normal))
return svn_error_createf
(SVN_ERR_WC_CORRUPT, NULL,
- "Corrupt working copy: '%s' in directory '%s' (which is scheduled "
- "for replacement) has in invalid schedule",
+ _("Corrupt working copy: '%s' in directory '%s' (which is
scheduled "
+ "for replacement) has in invalid schedule"),
name, path);
}
@@ -1106,7 +1109,7 @@
/* If there is no "this dir" entry, something is wrong. */
if (! this_dir)
return svn_error_createf (SVN_ERR_ENTRY_NOT_FOUND, NULL,
- "No default entry in directory '%s'",
+ _("No default entry in directory '%s'"),
svn_wc_adm_access_path (adm_access));
/* Open entries file for writing. It's important we don't use APR_EXCL
@@ -1159,7 +1162,7 @@
SVN_ERR_W (svn_io_file_write_full (outfile, bigstr->data,
bigstr->len, NULL, pool),
apr_psprintf (pool,
- "Error writing to '%s'",
+ _("Error writing to '%s'"),
svn_wc_adm_access_path (adm_access)));
err = svn_wc__close_adm_file (outfile,
@@ -1371,7 +1374,7 @@
else
return
svn_error_createf (SVN_ERR_WC_SCHEDULE_CONFLICT, NULL,
- "'%s' is not under version control",
+ _("'%s' is not under version control"),
name);
}
@@ -1398,14 +1401,14 @@
if (*schedule == svn_wc_schedule_add)
return
svn_error_createf (SVN_ERR_WC_SCHEDULE_CONFLICT, NULL,
- "Can't add '%s' to deleted directory; "
- "try undeleting its parent directory first",
+ _("Can't add '%s' to deleted directory; "
+ "try undeleting its parent directory first"),
name);
if (*schedule == svn_wc_schedule_replace)
return
svn_error_createf (SVN_ERR_WC_SCHEDULE_CONFLICT, NULL,
- "Can't replace '%s' in deleted directory; "
- "try undeleting its parent directory first",
+ _("Can't replace '%s' in deleted directory; "
+ "try undeleting its parent directory first"),
name);
}
@@ -1413,7 +1416,7 @@
{
return svn_error_createf
(SVN_ERR_WC_SCHEDULE_CONFLICT, NULL,
- "'%s' is marked as absent, so it cannot be scheduled for addition",
+ _("'%s' is marked as absent, so it cannot be scheduled for
addition"),
name);
}
@@ -1442,7 +1445,7 @@
return
svn_error_createf
(SVN_ERR_WC_SCHEDULE_CONFLICT, NULL,
- "Entry '%s' is already under version control", name);
+ _("Entry '%s' is already under version control"), name);
}
break;
@@ -1534,7 +1537,7 @@
return
svn_error_createf
(SVN_ERR_WC_SCHEDULE_CONFLICT, NULL,
- "Entry '%s' has illegal schedule", name);
+ _("Entry '%s' has illegal schedule"), name);
}
return SVN_NO_ERROR;
}
@@ -1650,7 +1653,7 @@
entry = apr_hash_get (entries, name, APR_HASH_KEY_STRING);
if (! entry)
return svn_error_createf (SVN_ERR_ENTRY_NOT_FOUND, NULL,
- "No such entry: '%s'", name);
+ _("No such entry: '%s'"), name);
if (new_url != NULL
&& (! entry->url || strcmp (new_url, entry->url)))
@@ -1716,7 +1719,7 @@
APR_HASH_KEY_STRING);
if (! dot_entry)
return svn_error_createf (SVN_ERR_ENTRY_NOT_FOUND, NULL,
- "Directory '%s' has no THIS_DIR entry",
+ _("Directory '%s' has no THIS_DIR entry"),
dirpath);
SVN_ERR (walk_callbacks->found_entry (dirpath, dot_entry, walk_baton,
pool));
@@ -1773,7 +1776,7 @@
if (! entry)
return svn_error_createf (SVN_ERR_UNVERSIONED_RESOURCE, NULL,
- "'%s' is not under version control", path);
+ _("'%s' is not under version control"), path);
if (entry->kind == svn_node_file)
return walk_callbacks->found_entry (path, entry, walk_baton, pool);
@@ -1784,7 +1787,7 @@
else
return svn_error_createf (SVN_ERR_NODE_UNKNOWN_KIND, NULL,
- "'%s' has an unrecognized node kind", path);
+ _("'%s' has an unrecognized node kind"), path);
}
@@ -1819,6 +1822,6 @@
}
else
return svn_error_createf (SVN_ERR_WC_PATH_FOUND, NULL,
- "Unexpectedly found '%s': "
- "path is marked 'missing'", path);
+ _("Unexpectedly found '%s': "
+ "path is marked 'missing'"), path);
}
Index: subversion/libsvn_wc/copy.c
===================================================================
--- subversion/libsvn_wc/copy.c (revision 9230)
+++ subversion/libsvn_wc/copy.c (working copy)
@@ -33,6 +34,8 @@
#include "adm_files.h"
#include "props.h"
+#include "svn_private_config.h"
+
/*** Code. ***/
@@ -142,7 +145,7 @@
SVN_ERR (svn_io_check_path (dst_path, &dst_kind, pool));
if (dst_kind != svn_node_none)
return svn_error_createf (SVN_ERR_ENTRY_EXISTS, NULL,
- "'%s' already exists and is in the way",
+ _("'%s' already exists and is in the way"),
dst_path);
/* Even if DST_PATH doesn't exist it may still be a versioned file; it
@@ -154,12 +157,12 @@
{
if (dst_entry->schedule == svn_wc_schedule_delete)
return svn_error_createf (SVN_ERR_ENTRY_EXISTS, NULL,
- "'%s' is scheduled for deletion; it must"
- " be committed before being overwritten",
+ _("'%s' is scheduled for deletion; it must"
+ " be committed before being overwritten"),
dst_path);
else
return svn_error_createf (SVN_ERR_ENTRY_EXISTS, NULL,
- "There is already a versioned item '%s'",
+ _("There is already a versioned item '%s'"),
dst_path);
}
@@ -170,15 +173,15 @@
if (! src_entry)
return svn_error_createf
(SVN_ERR_UNVERSIONED_RESOURCE, NULL,
- "Cannot copy or move '%s': it's not under version control",
+ _("Cannot copy or move '%s': it's not under version control"),
src_path);
if ((src_entry->schedule == svn_wc_schedule_add)
|| (! src_entry->url)
|| (src_entry->copied))
return svn_error_createf
(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
- "Cannot copy or move '%s': it's not in the repository yet; "
- "try committing first",
+ _("Cannot copy or move '%s': it's not in the repository yet; "
+ "try committing first"),
src_path);
/* Now, make an actual copy of the working file. */
@@ -286,14 +289,14 @@
if (! src_entry)
return svn_error_createf
(SVN_ERR_ENTRY_NOT_FOUND, NULL,
- "'%s' is not under version control", src_path);
+ _("'%s' is not under version control"), src_path);
if ((src_entry->schedule == svn_wc_schedule_add)
|| (! src_entry->url)
|| (src_entry->copied))
return svn_error_createf
(SVN_ERR_UNSUPPORTED_FEATURE, NULL,
- "Not allowed to copy or move '%s': it is not in the repository yet; "
- "try committing first",
+ _("Not allowed to copy or move '%s': it is not in the repository yet; "
+ "try committing first"),
src_path);
/* Recursively copy the whole directory over. This gets us all
Index: subversion/libsvn_wc/lock.c
===================================================================
--- subversion/libsvn_wc/lock.c (revision 9230)
+++ subversion/libsvn_wc/lock.c (working copy)
@@ -28,6 +28,8 @@
#include "adm_files.h"
#include "questions.h"
+#include "svn_private_config.h"
+
struct svn_wc_adm_access_t
@@ -153,7 +155,7 @@
}
return svn_error_createf (SVN_ERR_WC_LOCKED, NULL,
- "Working copy '%s' locked",
+ _("Working copy '%s' locked"),
svn_path_local_style (adm_access->path, pool));
}
@@ -273,7 +275,7 @@
{
return svn_error_createf
(SVN_ERR_WC_BAD_PATH, NULL,
- "Path '%s' ends in '%s', which is unsupported for this
operation",
+ _("Path '%s' ends in '%s', which is unsupported for this
operation"),
svn_path_local_style (path, pool), base_name);
}
@@ -350,7 +352,7 @@
locked: if it's not locked call svn_wc_adm_open, if it is locked
call svn_wc_adm_retrieve. */
return svn_error_createf (SVN_ERR_WC_LOCKED, NULL,
- "Working copy '%s' locked",
+ _("Working copy '%s' locked"),
path);
}
@@ -368,7 +370,7 @@
/* Should we attempt to distinguish certain errors? */
svn_error_clear (err);
return svn_error_createf (SVN_ERR_WC_NOT_DIRECTORY, NULL,
- "'%s' is not a working copy",
+ _("'%s' is not a working copy"),
svn_path_local_style (path, pool));
}
@@ -593,7 +595,7 @@
{
svn_error_clear (err);
return svn_error_createf (SVN_ERR_WC_NOT_DIRECTORY, NULL,
- "'%s' is not a working copy",
+ _("'%s' is not a working copy"),
svn_path_local_style (path, pool));
}
else
@@ -641,7 +643,7 @@
for NULL batons. */
if (! *adm_access)
return svn_error_createf (SVN_ERR_WC_NOT_LOCKED, NULL,
- "Working copy '%s' not locked",
+ _("Working copy '%s' not locked"),
path);
return SVN_NO_ERROR;
@@ -835,14 +837,14 @@
SVN_ERR (svn_wc_locked (&locked, adm_access->path,
adm_access->pool));
if (! locked)
return svn_error_createf (SVN_ERR_WC_NOT_LOCKED, NULL,
- "Write-lock stolen in '%s'",
+ _("Write-lock stolen in '%s'"),
adm_access->path);
}
}
else
{
return svn_error_createf (SVN_ERR_WC_NOT_LOCKED, NULL,
- "No write-lock in '%s'", adm_access->path);
+ _("No write-lock in '%s'"),
adm_access->path);
}
return SVN_NO_ERROR;
@@ -862,7 +864,7 @@
*locked = FALSE;
else
return svn_error_createf (SVN_ERR_WC_LOCKED, NULL,
- "Lock file '%s' is not a regular file",
+ _("Lock file '%s' is not a regular file"),
lockfile);
return SVN_NO_ERROR;
Index: subversion/libsvn_wc/translate.c
===================================================================
--- subversion/libsvn_wc/translate.c (revision 9230)
+++ subversion/libsvn_wc/translate.c (working copy)
@@ -45,6 +46,7 @@
#include "adm_files.h"
#include "translate.h"
+#include "svn_private_config.h"
svn_error_t *
svn_wc_translated_file (const char **xlated_p,
@@ -122,7 +124,7 @@
{
return svn_error_createf
(SVN_ERR_IO_UNKNOWN_EOL, NULL,
- "'%s' has unknown value for svn:eol-style property",
+ _("'%s' has unknown value for svn:eol-style property"),
vfile);
}
Index: subversion/libsvn_subr/opt.c
===================================================================
--- subversion/libsvn_subr/opt.c (revision 9230)
+++ subversion/libsvn_subr/opt.c (working copy)
@@ -36,6 +36,8 @@
#include "svn_utf.h"
#include "svn_time.h"
+#include "svn_private_config.h"
+
/*** Code. ***/
@@ -735,7 +737,7 @@
pool,
stdout);
else /* unknown option or cmd */
- fprintf (stderr, "Type '%s help' for usage.\n", pgm_name);
+ fprintf (stderr, _("Type '%s help' for usage.\n"), pgm_name);
return SVN_NO_ERROR;
}
Index: subversion/clients/cmdline/props.c
===================================================================
--- subversion/clients/cmdline/props.c (revision 9230)
+++ subversion/clients/cmdline/props.c (working copy)
@@ -33,6 +33,7 @@
#include "svn_subst.h"
#include "cl.h"
+#include "svn_private_config.h"
@@ -41,8 +42,8 @@
{
return svn_error_create
(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
- "Must specify revision explicitly when operating on a "
- "revision property");
+ _("Must specify revision explicitly when operating on a "
+ "revision property"));
}
Index: subversion/clients/cmdline/mkdir-cmd.c
===================================================================
--- subversion/clients/cmdline/mkdir-cmd.c (revision 9230)
+++ subversion/clients/cmdline/mkdir-cmd.c (working copy)
@@ -31,6 +31,7 @@
#include "svn_error.h"
#include "cl.h"
+#include "svn_private_config.h"
/*** Code. ***/
@@ -70,7 +71,7 @@
{
if (err->apr_err == APR_EEXIST)
return svn_error_quick_wrap
- (err, "Try 'svn add' or 'svn add --non-recursive' instead?");
+ (err, _("Try 'svn add' or 'svn add --non-recursive' instead?"));
else
return err;
}
Index: subversion/clients/cmdline/blame-cmd.c
===================================================================
--- subversion/clients/cmdline/blame-cmd.c (revision 9230)
+++ subversion/clients/cmdline/blame-cmd.c (working copy)
@@ -25,6 +26,8 @@
#include "svn_time.h"
#include "cl.h"
+#include "svn_private_config.h"
+
typedef struct
{
svn_cl__opt_state_t *opt_state;
@@ -137,7 +140,7 @@
{
if (err->apr_err == SVN_ERR_CLIENT_IS_BINARY_FILE)
{
- printf ("Skipping binary file: '%s'\n", target);
+ printf (_("Skipping binary file: '%s'\n"), target);
svn_error_clear (err);
}
else
Index: subversion/clients/cmdline/log-cmd.c
===================================================================
--- subversion/clients/cmdline/log-cmd.c (revision 9230)
+++ subversion/clients/cmdline/log-cmd.c (working copy)
@@ -39,6 +39,8 @@
#include "svn_subst.h"
#include "cl.h"
+#include "svn_private_config.h"
+
/*** Code. ***/
@@ -203,7 +205,7 @@
for more on the fallback fuzzy conversions below. */
if (author == NULL)
- author = "(no author)";
+ author = _("(no author)");
err = svn_cmdline_cstring_from_utf8 (&author_stdout, author, pool);
if (err && (APR_STATUS_IS_EINVAL (err->apr_err)))
@@ -225,7 +227,7 @@
SVN_ERR (svn_cmdline_cstring_from_utf8 (&date_stdout, date_utf8, pool));
}
else
- date_stdout = "(no date)";
+ date_stdout = _("(no date)");
if (! lb->omit_log_message)
{
Index: subversion/clients/cmdline/delete-cmd.c
===================================================================
--- subversion/clients/cmdline/delete-cmd.c (revision 9230)
+++ subversion/clients/cmdline/delete-cmd.c (working copy)
@@ -31,6 +31,7 @@
#include "svn_pools.h"
#include "cl.h"
+#include "svn_private_config.h"
/*** Code. ***/
@@ -45,7 +46,7 @@
/* Should this svn_error_compose a new error number? Probably not,
the error hasn't changed. */
err = svn_error_quick_wrap (err,
- "Use --force to override this restriction"
);
+ _("Use --force to override this
restriction") );
}
return err;
Index: subversion/clients/cmdline/notify.c
===================================================================
--- subversion/clients/cmdline/notify.c (revision 9230)
+++ subversion/clients/cmdline/notify.c (working copy)
@@ -32,6 +32,8 @@
#include "svn_pools.h"
#include "cl.h"
+#include "svn_private_config.h"
+
/* Baton for notify and friends. */
struct notify_baton
@@ -66,7 +68,7 @@
err = svn_cmdline_path_local_style_from_utf8 (&path_stdout, path, nb->pool);
if (err)
{
- printf ("WARNING: error decoding UTF-8 for ?\n");
+ printf (_("WARNING: error decoding UTF-8 for ?\n"));
svn_pool_clear (nb->pool);
svn_error_clear (err);
return;
@@ -75,9 +77,9 @@
{
case svn_wc_notify_skip:
if (content_state == svn_wc_notify_state_missing)
- printf ("Skipped missing target: '%s'\n", path_stdout);
+ printf (_("Skipped missing target: '%s'\n"), path_stdout);
else
- printf ("Skipped '%s'\n", path_stdout);
+ printf (_("Skipped '%s'\n"), path_stdout);
break;
case svn_wc_notify_update_delete:
@@ -91,19 +93,19 @@
break;
case svn_wc_notify_restore:
- printf ("Restored '%s'\n", path_stdout);
+ printf (_("Restored '%s'\n"), path_stdout);
break;
case svn_wc_notify_revert:
- printf ("Reverted '%s'\n", path_stdout);
+ printf (_("Reverted '%s'\n"), path_stdout);
break;
case svn_wc_notify_failed_revert:
- printf ("Failed to revert '%s' -- try updating instead.\n",
path_stdout);
+ printf (_("Failed to revert '%s' -- try updating instead.\n"),
path_stdout);
break;
case svn_wc_notify_resolved:
- printf ("Resolved conflicted state of '%s'\n", path_stdout);
+ printf (_("Resolved conflicted state of '%s'\n"), path_stdout);
break;
case svn_wc_notify_add:
@@ -162,7 +164,7 @@
case svn_wc_notify_update_external:
/* Currently this is used for checkouts and switches too. If we
want different output, we'll have to add new actions. */
- printf ("\nFetching external item into '%s'\n", path_stdout);
+ printf (_("\nFetching external item into '%s'\n"), path_stdout);
/* Remember that we're now "inside" an externals definition. */
nb->in_external = TRUE;
@@ -197,8 +199,7 @@
else /* no revision */
{
if (nb->is_export)
- printf ("%sxport complete.\n",
- nb->in_external ? "External e" : "E");
+ printf (nb->in_external ? _("External export complete.\n")
: _("Export complete.\n"));
else if (nb->is_checkout)
printf ("%sheckout complete.\n",
nb->in_external ? "External c" : "C");
@@ -214,7 +215,7 @@
break;
case svn_wc_notify_status_external:
- printf ("\nPerforming status on external item at '%s'\n", path_stdout);
+ printf (_("\nPerforming status on external item at '%s'\n"),
path_stdout);
break;
case svn_wc_notify_status_completed:
@@ -223,7 +224,7 @@
break;
case svn_wc_notify_commit_modified:
- printf ("Sending %s\n", path_stdout);
+ printf (_("Sending %s\n"), path_stdout);
break;
case svn_wc_notify_commit_added:
@@ -238,13 +239,13 @@
break;
case svn_wc_notify_commit_replaced:
- printf ("Replacing %s\n", path_stdout);
+ printf (_("Replacing %s\n"), path_stdout);
break;
case svn_wc_notify_commit_postfix_txdelta:
if (! nb->sent_first_txdelta)
{
- printf ("Transmitting file data ");
+ printf (_("Transmitting file data "));
nb->sent_first_txdelta = TRUE;
}
Index: subversion/clients/cmdline/export-cmd.c
===================================================================
--- subversion/clients/cmdline/export-cmd.c (revision 9230)
+++ subversion/clients/cmdline/export-cmd.c (working copy)
@@ -29,6 +29,8 @@
#include "svn_path.h"
#include "cl.h"
+#include "svn_private_config.h"
+
/*** Code. ***/
@@ -73,8 +75,8 @@
opt_state->force, ctx, pool);
if (err && err->apr_err == SVN_ERR_WC_OBSTRUCTED_UPDATE &&
!opt_state->force)
SVN_ERR_W (err,
- "Destination directory exists; please remove "
- "the directory or use --force to overwrite");
+ _("Destination directory exists; please remove "
+ "the directory or use --force to overwrite"));
else
SVN_ERR (err);
Index: subversion/clients/cmdline/main.c
===================================================================
--- subversion/clients/cmdline/main.c (revision 9230)
+++ subversion/clients/cmdline/main.c (working copy)
@@ -47,6 +47,8 @@
#include "svn_auth.h"
#include "cl.h"
+#include "svn_private_config.h"
+
/*** Option Processing ***/
@@ -629,7 +631,7 @@
svn_cl__check_cancel (void *baton)
{
if (cancelled)
- return svn_error_create (SVN_ERR_CANCELLED, NULL, "Caught signal");
+ return svn_error_create (SVN_ERR_CANCELLED, NULL, _("Caught signal"));
else
return SVN_NO_ERROR;
}
@@ -656,6 +658,10 @@
svn_cl__cmd_baton_t command_baton;
svn_auth_baton_t *ab;
svn_config_t *cfg;
+
+ setlocale (LC_ALL, "");
+ bindtextdomain (PACKAGE_NAME, SVN_LOCALE_DIR);
+ textdomain (PACKAGE_NAME);
/* Initialize the app. */
if (svn_cmdline_init ("svn", stderr) != EXIT_SUCCESS)
@@ -720,8 +726,8 @@
{
err = svn_error_create
(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
- "Multiple revision arguments encountered; "
- "try '-r M:N' instead of '-r M -r N'");
+ _("Multiple revision arguments encountered; "
+ "try '-r M:N' instead of '-r M -r N'"));
svn_handle_error (err, stderr, FALSE);
svn_error_clear (err);
svn_pool_destroy (pool);
@@ -735,7 +741,7 @@
if (! err)
err = svn_error_createf
(SVN_ERR_CL_ARG_PARSING_ERROR, NULL,
- "Syntax error in revision argument '%s'",
+ _("Syntax error in revision argument '%s'"),
utf8_opt_arg);
svn_handle_error (err, stderr, FALSE);
svn_error_clear (err);
@@ -909,8 +915,8 @@
if (opt_state.no_autoprops)
{
err = svn_error_create (SVN_ERR_CL_MUTUALLY_EXCLUSIVE_ARGS, NULL,
- "--auto-props and --no-auto-props are "
- "mutually exclusive");
+ _("--auto-props and --no-auto-props are "
+ "mutually exclusive"));
svn_handle_error (err, stderr, FALSE);
svn_error_clear (err);
svn_pool_destroy (pool);
@@ -922,8 +928,8 @@
if (opt_state.autoprops)
{
err = svn_error_create (SVN_ERR_CL_MUTUALLY_EXCLUSIVE_ARGS, NULL,
- "--auto-props and --no-auto-props are "
- "mutually exclusive");
+ _("--auto-props and --no-auto-props are "
+ "mutually exclusive"));
svn_handle_error (err, stderr, FALSE);
svn_error_clear (err);
svn_pool_destroy (pool);
@@ -970,7 +976,7 @@
{
if (os->ind >= os->argc)
{
- fprintf (stderr, "subcommand argument required\n");
+ fprintf (stderr, _("subcommand argument required\n"));
svn_cl__help (NULL, NULL, pool);
svn_pool_destroy (pool);
return EXIT_FAILURE;
@@ -982,7 +988,7 @@
first_arg);
if (subcommand == NULL)
{
- fprintf (stderr, "unknown command: '%s'\n", first_arg);
+ fprintf (stderr, _("unknown command: '%s'\n"), first_arg);
svn_cl__help (NULL, NULL, pool);
svn_pool_destroy (pool);
return EXIT_FAILURE;
@@ -1009,8 +1015,8 @@
svn_opt_get_option_from_code (opt_id, svn_cl__options);
svn_opt_format_option (&optstr, badopt, FALSE, pool);
fprintf (stderr,
- "subcommand '%s' doesn't accept option '%s'\n"
- "Type 'svn help %s' for usage.\n",
+ _("subcommand '%s' doesn't accept option '%s'\n"
+ "Type 'svn help %s' for usage.\n"),
subcommand->name, optstr, subcommand->name);
svn_pool_destroy (pool);
return EXIT_FAILURE;
@@ -1043,8 +1049,8 @@
{
err = svn_error_create
(SVN_ERR_CL_LOG_MESSAGE_IS_VERSIONED_FILE,
NULL,
- "Log message file is a versioned file; "
- "use '--force-log' to override");
+ _("Log message file is a versioned
file; "
+ "use '--force-log' to override"));
svn_handle_error (err, stderr, FALSE);
svn_error_clear (err);
svn_pool_destroy (pool);
@@ -1063,9 +1069,9 @@
APR_FINFO_MIN, pool) == APR_SUCCESS)
{
err = svn_error_create (SVN_ERR_CL_LOG_MESSAGE_IS_PATHNAME,
NULL,
- "The log message is a pathname "
+ _("The log message is a pathname "
"(was -F intended?); use '--force-log' "
- "to override");
+ "to override"));
svn_handle_error (err, stderr, FALSE);
svn_error_clear (err);
svn_pool_destroy (pool);
@@ -1274,8 +1278,8 @@
for (tmp_err = err; tmp_err; tmp_err = tmp_err->child)
if (tmp_err->apr_err == SVN_ERR_WC_LOCKED)
{
- fputs ("svn: run 'svn cleanup' to remove locks"
- " (type 'svn help cleanup' for details)\n", stderr);
+ fputs (_("svn: run 'svn cleanup' to remove locks"
+ " (type 'svn help cleanup' for details)\n"), stderr);
break;
}
Index: subversion/clients/cmdline/info-cmd.c
===================================================================
--- subversion/clients/cmdline/info-cmd.c (revision 9230)
+++ subversion/clients/cmdline/info-cmd.c (working copy)
@@ -31,6 +31,8 @@
#include "svn_time.h"
#include "cl.h"
+#include "svn_private_config.h"
+
/*** Code. ***/
@@ -59,7 +61,7 @@
/* Get a non-UTF8 version of the target. */
SVN_ERR (svn_cmdline_path_local_style_from_utf8 (&name_stdout, target,
pool));
- printf ("Path: %s\n", name_stdout);
+ printf (_("Path: %s\n"), name_stdout);
/* Note: we have to be paranoid about checking that these are
valid, since svn_wc_entry() doesn't fill them in if they
@@ -69,25 +71,25 @@
{
SVN_ERR (svn_cmdline_cstring_from_utf8 (&name_stdout,
entry->name, pool));
- printf ("Name: %s\n", name_stdout);
+ printf (_("Name: %s\n"), name_stdout);
}
if (entry->url)
{
SVN_ERR (svn_cmdline_cstring_from_utf8 (&name_stdout, entry->url,
pool));
- printf ("URL: %s\n", name_stdout);
+ printf (_("URL: %s\n"), name_stdout);
}
if (entry->repos)
{
SVN_ERR (svn_cmdline_cstring_from_utf8 (&name_stdout,
entry->repos, pool));
- printf ("Repository: %s\n", name_stdout);
+ printf (_("Repository: %s\n"), name_stdout);
}
if (entry->uuid)
{
- printf ("Repository UUID: %s\n", entry->uuid);
+ printf (_("Repository UUID: %s\n"), entry->uuid);
}
if (SVN_IS_VALID_REVNUM (entry->revision))
@@ -96,7 +98,7 @@
switch (entry->kind)
{
case svn_node_file:
- printf ("Node Kind: file\n");
+ printf (_("Node Kind: file\n"));
{
const char *dir_name;
svn_path_split (target, &dir_name, NULL, pool);
@@ -106,37 +108,37 @@
break;
case svn_node_dir:
- printf ("Node Kind: directory\n");
+ printf (_("Node Kind: directory\n"));
SVN_ERR (svn_wc_conflicted_p (&text_conflict, &props_conflict,
target, entry, pool));
break;
case svn_node_none:
- printf ("Node Kind: none\n");
+ printf (_("Node Kind: none\n"));
break;
case svn_node_unknown:
default:
- printf ("Node Kind: unknown\n");
+ printf (_("Node Kind: unknown\n"));
break;
}
switch (entry->schedule)
{
case svn_wc_schedule_normal:
- printf ("Schedule: normal\n");
+ printf (_("Schedule: normal\n"));
break;
case svn_wc_schedule_add:
- printf ("Schedule: add\n");
+ printf (_("Schedule: add\n"));
break;
case svn_wc_schedule_delete:
- printf ("Schedule: delete\n");
+ printf (_("Schedule: delete\n"));
break;
case svn_wc_schedule_replace:
- printf ("Schedule: replace\n");
+ printf (_("Schedule: replace\n"));
break;
default:
@@ -150,7 +152,7 @@
SVN_ERR (svn_cmdline_cstring_from_utf8 (&name_stdout,
entry->copyfrom_url,
pool));
- printf ("Copied From URL: %s\n", name_stdout);
+ printf (_("Copied From URL: %s\n"), name_stdout);
}
if (SVN_IS_VALID_REVNUM (entry->copyfrom_rev))
@@ -162,7 +164,7 @@
{
SVN_ERR (svn_cmdline_cstring_from_utf8 (&name_stdout,
entry->cmt_author, pool));
- printf ("Last Changed Author: %s\n", name_stdout);
+ printf (_("Last Changed Author: %s\n"), name_stdout);
}
if (SVN_IS_VALID_REVNUM (entry->cmt_rev))
@@ -170,49 +172,49 @@
if (entry->cmt_date)
SVN_ERR (svn_cl__info_print_time (entry->cmt_date,
- "Last Changed Date", pool));
+ _("Last Changed Date"), pool));
if (entry->text_time)
SVN_ERR (svn_cl__info_print_time (entry->text_time,
- "Text Last Updated", pool));
+ _("Text Last Updated"), pool));
if (entry->prop_time)
SVN_ERR (svn_cl__info_print_time (entry->prop_time,
- "Properties Last Updated", pool));
+ _("Properties Last Updated"), pool));
if (entry->checksum)
{
SVN_ERR (svn_cmdline_cstring_from_utf8 (&name_stdout,
entry->checksum, pool));
- printf ("Checksum: %s\n", name_stdout);
+ printf (_("Checksum: %s\n"), name_stdout);
}
if (text_conflict && entry->conflict_old)
{
SVN_ERR (svn_cmdline_path_local_style_from_utf8
(&name_stdout, entry->conflict_old, pool));
- printf ("Conflict Previous Base File: %s\n", name_stdout);
+ printf (_("Conflict Previous Base File: %s\n"), name_stdout);
}
if (text_conflict && entry->conflict_wrk)
{
SVN_ERR (svn_cmdline_path_local_style_from_utf8
(&name_stdout, entry->conflict_wrk, pool));
- printf ("Conflict Previous Working File: %s\n", name_stdout);
+ printf (_("Conflict Previous Working File: %s\n"), name_stdout);
}
if (text_conflict && entry->conflict_new)
{
SVN_ERR (svn_cmdline_path_local_style_from_utf8
(&name_stdout, entry->conflict_new, pool));
- printf ("Conflict Current Base File: %s\n", name_stdout);
+ printf (_("Conflict Current Base File: %s\n"), name_stdout);
}
if (props_conflict && entry->prejfile)
{
SVN_ERR (svn_cmdline_path_local_style_from_utf8
(&name_stdout, entry->prejfile, pool));
- printf ("Conflict Properties File: %s\n", name_stdout);
+ printf (_("Conflict Properties File: %s\n"), name_stdout);
}
/* Print extra newline separator. */
@@ -289,7 +291,7 @@
SVN_ERR (svn_cmdline_path_local_style_from_utf8
(&target_stdout, target, subpool));
- printf ("%s: (Not a versioned resource)\n\n", target_stdout);
+ printf (_("%s: (Not a versioned resource)\n\n"), target_stdout);
continue;
}
--- po/es.po Tue Mar 30 01:38:39 2004
+++ po/es.po Tue Mar 30 01:16:34 2004
@@ -502,3 +502,6 @@
#, c-format
msgid "'%s' has unknown value for svn:eol-style property"
msgstr "'%s' tiene un valor desconocido para la propiedad svn:eol-style"
+
+msgid "Type '%s help' for usage.\n"
+msgstr "Typo me '%s' help' for na-na-na usage.\n"
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> No. Many of the changes you made to the build system were superfluous
> (adding make targets for configure et al.), or introduced a dependency
> upon automake and GNU make (like the po/Makefile.in.in file). As my
> patch demonstrated, they are unnecessary to support gettext.
>
> 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
Nicolás, let me say what Justin's saying in another way:
We don't want to mix unrelated changes. Supporting i18n via gettext
is one logical set of changes. There may be other "improvements" you
want to make to the build system, but if they are not necessary for
the i18n work, then they should not be mixed into the i18n patches.
*Even* if everyone agreed that they were improvements, they would
still need to be evaluated as independent changes (but clearly, not
everyone agrees, so they'd need discussion first anyway).
So the point is: try to keep the i18n changes as small as possible,
and don't mix them with other goals. When people review the i18n
changes, they will assume that everything they see is directly related
to the single i18n goal -- if any part of the change falls outside
that scope, it makes review much more difficult.
Thanks,
-Karl
---------------------------------------------------------------------
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
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 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: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The
gettext proposal
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
Justin Erenkrantz wrote:
>> IMO you have yo have a very good reason for, in a project already using
>> autoconf, discarding all the already made infrastructure. I haven't
>> read a
>> valid reason so far. These kind of things make the life of new
>> developers
>> more miserable... IMHO of course. =)
>
> No. Many of the changes you made to the build system were superfluous
> (adding make targets for configure et al.),
That was a convenience for me, I even planned to post those changes in a
separate patch. You can safely ignore them, they are not related in any
way with the i18n thing.
> or introduced a dependency upon automake and GNU make (like the
> po/Makefile.in.in file). As my patch demonstrated, they are
> unnecessary to support gettext.
This is silly, I haven't used automake either. I have an
internationalized "svn" without invoking automake once. Prove me I'm
introducing such dependency.
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
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 3:06 PM -0300 Nicolás Lichtmaier
<ni...@reloco.com.ar> wrote:
> IMO you have yo have a very good reason for, in a project already using
> autoconf, discarding all the already made infrastructure. I haven't read a
> valid reason so far. These kind of things make the life of new developers
> more miserable... IMHO of course. =)
No. Many of the changes you made to the build system were superfluous (adding
make targets for configure et al.), or introduced a dependency upon automake
and GNU make (like the po/Makefile.in.in file). As my patch demonstrated,
they are unnecessary to support gettext.
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The
gettext proposal
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>> Hi, I propose to use gettext for i18n.
>
>
> This would add a new build and run-time dependency that I think we
> have to be
> very careful about handling. I really wish this could be made
> optional rather
> than being a mandatory requirement.
That's not true. Gettext is designed so as not to have this build or
runtime dependency. If there's no gettext available, the build will just
fall back to a non-internationalized version.
> The biggest problem is that GNU gettext expects us to be using
> automake, which
> isn't going to be used. I think the best course of action is to just
> discard
> everything that gettextize does and write our own configure checks and
> Makefile. This should have the added bonus of allowing us to work
> against
> non-GNU gettext and with non-GNU makes.
That's not true. There's nothing in the code I've posted which requires
automake. It does require autoconf though. And we don't want to support
non-GNU gettext's, thery are not as featureful.
> * Makefile.in: With the exception of the i18n targets, these changes are
> entirely bogus. DEFS and the LOCALEDIR are most certainly not options
> that
> should be passed to the compiler, but rather to the preprocessor.
Well... the compiler is the one calling the preprocessor, isn't it?
> The makefile should not have targets for configure, config.status,
> etc. (I have a
> hunch you are going to try to get us to use automake.)
This is totally unfounded FUD. Where did I said or post something
remotely related to automake? Those targets I've added are just to
enable the proper regeneration of the autoconf files. With these targets
you can edit configure.in and just type "make".
> * configure.in: I see no reason why gettext needs us to define PACKAGE or
> VERSION.
So that we can just use the unmodified Makefile.in.in file.
> * po/Makefile.in.in: We're not using automake, so we need to construct
> our own
> customized Makefile.in.
That's bogus.
> * subversion/*.c: We do not protect includes of svn_private_config.h
> as it is
> always available (even on Win32).
Well... is autoconf tradition. I suppos that it's like that so that you
can take out any file and compile in other environment without worrying
of the missing config.h file.
IMO you have yo have a very good reason for, in a project already using
autoconf, discarding all the already made infrastructure. I haven't read
a valid reason so far. These kind of things make the life of new
developers more miserable... IMHO of course. =)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by Ben Reser <be...@reser.org>.
On Tue, Mar 30, 2004 at 01:49:16AM -0800, Justin Erenkrantz wrote:
> This would add a new build and run-time dependency that I think we
> have to be very careful about handling. I really wish this could be
> made optional rather than being a mandatory requirement. As an aside,
> we would have to disable static linking if we import gettext as LGPL
> forbids any static binaries created with LGPL functionality. (Hmm,
> we'd have to do the same for neon - are we?)
This isn't accurate. The LGPL does not disallow static linking. It
restricts you to complying with a certain set of terms if you statically
link. There are some cases where statically linked binaries are not
going to be allowed. So let's look at the key sections that apply here,
Sections 5 & 6:
>>>>
5. A program that contains no derivative of any portion of the
Library, but is designed to work with the Library by being compiled or
linked with it, is called a "work that uses the Library". Such a
work, in isolation, is not a derivative work of the Library, and
therefore falls outside the scope of this License.
However, linking a "work that uses the Library" with the Library
creates an executable that is a derivative of the Library (because it
contains portions of the Library), rather than a "work that uses the
library". The executable is therefore covered by this License.
Section 6 states terms for distribution of such executables.
When a "work that uses the Library" uses material from a header file
that is part of the Library, the object code for the work may be a
derivative work of the Library even though the source code is not.
Whether this is true is especially significant if the work can be
linked without the Library, or if the work is itself a library. The
threshold for this to be true is not precisely defined by law.
If such an object file uses only numerical parameters, data
structure layouts and accessors, and small macros and small inline
functions (ten lines or less in length), then the use of the object
file is unrestricted, regardless of whether it is legally a derivative
work. (Executables containing this object code plus portions of the
Library will still fall under Section 6.)
Otherwise, if the work is a derivative of the Library, you may
distribute the object code for the work under the terms of Section 6.
Any executables containing that work also fall under Section 6,
whether or not they are linked directly with the Library itself.
6. As an exception to the Sections above, you may also combine or
link a "work that uses the Library" with the Library to produce a
work containing portions of the Library, and distribute that work
under terms of your choice, provided that the terms permit
modification of the work for the customer's own use and reverse
engineering for debugging such modifications.
You must give prominent notice with each copy of the work that the
Library is used in it and that the Library and its use are covered by
this License. You must supply a copy of this License. If the work
during execution displays copyright notices, you must include the
copyright notice for the Library among them, as well as a reference
directing the user to the copy of this License. Also, you must do one
of these things:
a) Accompany the work with the complete corresponding
machine-readable source code for the Library including whatever
changes were used in the work (which must be distributed under
Sections 1 and 2 above); and, if the work is an executable linked
with the Library, with the complete machine-readable "work that
uses the Library", as object code and/or source code, so that the
user can modify the Library and then relink to produce a modified
executable containing the modified Library. (It is understood
that the user who changes the contents of definitions files in the
Library will not necessarily be able to recompile the application
to use the modified definitions.)
b) Use a suitable shared library mechanism for linking with the
Library. A suitable mechanism is one that (1) uses at run time a
copy of the library already present on the user's computer system,
rather than copying library functions into the executable, and (2)
will operate properly with a modified version of the library, if
the user installs one, as long as the modified version is
interface-compatible with the version that the work was made with.
c) Accompany the work with a written offer, valid for at
least three years, to give the same user the materials
specified in Subsection 6a, above, for a charge no more
than the cost of performing this distribution.
d) If distribution of the work is made by offering access to copy
from a designated place, offer equivalent access to copy the above
specified materials from the same place.
e) Verify that the user has already received a copy of these
materials or that you have already sent this user a copy.
For an executable, the required form of the "work that uses the
Library" must include any data and utility programs needed for
reproducing the executable from it. However, as a special exception,
the materials to be distributed need not include anything that is
normally distributed (in either source or binary form) with the major
components (compiler, kernel, and so on) of the operating system on
which the executable runs, unless that component itself accompanies
the executable.
It may happen that this requirement contradicts the license
restrictions of other proprietary libraries that do not normally
accompany the operating system. Such a contradiction means you cannot
use both them and the Library together in an executable that you
distribute.
<<<<<
subversion's license doesn't conflict because of static linking. It is
possible to statically link and still comply with both licenses with
regards to the linking stuff. subversion's license doesn't require
including the source, but there's nothing stopping you from doing so.
The exception here is Windows or potentially other commercial platforms.
If you use non-free compilers and libraries in making your statically
linked binary, then you can't comply with the LGPL because you can't
make those tools/libs (or their source code) available.
You can make executables that dynamically load the LGPL library, but
statically link to the non-LGPL libraries. The LGPL has cases for
including portions of the library or not including portions of the
library but Section 5 makes an exception for cases where only in essence
the header files are used. So dynamically loading the LGPL lib would be
possible under Section 5 on these platforms, but full statics would fail
the requirements of Section 6 on these platforms.
On other platforms the copyright statement's need to be modified if we
statically link to mention the LGPL licensed software and their
copyright statement.
Frankly, I don't think any of this is a concern for us except for the
binaries that we distribute. We should not be distributing binaries
that statically link LGPL libs for any platform. But this is a concern
for the packager not this project. I would argue that attempting to
disallow this might open us for liability for packagers which don't
comply with the LGPL.
However, the LGPL does still present the same potential problem that the
GPL does:
>>>>
10. Each time you redistribute the Library (or any work based on the
Library), the recipient automatically receives a license from the
original licensor to copy, distribute, link with or modify the Library
subject to these terms and conditions. You may not impose any further
restrictions on the recipients' exercise of the rights granted herein.
You are not responsible for enforcing compliance by third parties with
this License.
<<<<
The FSF has (controversially I'll add) held that clauses like our 3, 4
and 5 are adding additional restrictions. If you accept this
interpretation then we conflict with the LGPL just as much as we
conflict with the GPL.
CollabNet's stated policy on this is (someone correct me if I misstate
this):
1) They don't believe they conflict with the GPL because they don't
accept the FSF's interpretation.
2) They will not object if someone links subversion against GPL licensed
code (and under CollabNet's interpretation of the GPL) is thereby
relicensed under the GPL (and by extension has the extra clauses
removed). I'm guessing they're okay with the LGPL as well since they
include code that links against libneon which is LGPL.
Regarding the situation with libintl. I don't think it is really
different than the issues with libneon. Binary packagers should be
reading the licenses of the tools we're using and considering their
licenses carefully before they build statics. I don't think we should
try and limit ourselves to software that might create problems for some
particular packaging cases.
If we do anything we might want to include a comment in our INSTALL
document point out the potential issue with static linking, maybe making
an option in our configure/Windows build system to build things in a way
that does comply with the license.
So in summary:
Static linking is permitted, but care must be taken to comply with the
license. On platforms such as Windows, it will not be possible to
create a fully statically linked executable, you must dynamically link
the LGPL libraries.
CollabNet doesn't agree with the FSF about the additional restrictions
problem and so is ignoring the issue.
I hope this clears up the licensing issues.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by kf...@collab.net.
Ben Reser <be...@reser.org> writes:
> I really should finish reading the thread before I reply. Sorry if I
> duplicated anything or starting the LGPL discussion under this thread.
No problem, I think your posts only contributed to the discussion.
Note that when I did post my analysis, it was under this thread:
"Subject: using LGPL'd code with Subversion"
(in case you wanted to take a look).
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by Ben Reser <be...@reser.org>.
On Tue, Mar 30, 2004 at 11:39:08AM -0600, kfogel@collab.net wrote:
> Ben Collins-Sussman <su...@collab.net> writes:
> > 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.
> >
> > [...]
> >
> > I think Karl might be willing to do step #0;
>
> Yes, as soon as I finish reading LGPL.
I really should finish reading the thread before I reply. Sorry if I
duplicated anything or starting the LGPL discussion under this thread.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by kf...@collab.net.
Ben Collins-Sussman <su...@collab.net> writes:
> 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.
>
> [...]
>
> I think Karl might be willing to do step #0;
Yes, as soon as I finish reading LGPL.
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The
gettext proposal
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
>I'm still confused. There are two statements here:
>
> > You can't add a function call anywhere in the code. You can't add
> > a function call in a static initializer ...
>
>How is the first statement true?
>
>Regarding the second statement, does it matter for Subversion? We
>have few such initializations, and those we do have may not need to be
>translated. At worst, we might have to change some code. It doesn't
>seem like a showstopper, anyway.
>
>
Subversion has such cases. See svn_cl__cmd_table in "svn"'s main.c . But
it's handled the way I've said earlier. By marking those occurences with
a NOOP macro (so that xgettext sees them) and by adding a gettext call
where these values are used.
>(I understand that you were just explaining things. My confusion is
>really about the assertion that Subversion strings will have a
>problem, which originated with Justin, I think, not you.)
>
>
And there's no such problem at all... =)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by kf...@collab.net.
Nicolás Lichtmaier <ni...@reloco.com.ar> writes:
> Yes. This is the issue:
>
> You can't add a function call anywhere in the code. You can't add a
> function call in a static initializer, like:
>
> char *global_greetings[] = { _("Hello"), _("Hi"), NULL };
>
> This won't compile. The solution is to have a macro which does
> nothing: "N_":
>
> #define N_(x) (x)
>
> char *global_greetings[] = { N_("Hello"), N_("Hi"), NULL };
>
> This will be caught by xgettext and it will be put in the .pot file,
> but global_greeting will still have the English messages. We fix that
> by calling "gettext" on the string:
>
> for(p=global_greetings;p;p++)
> printf(gettext(global_greeting));
>
> We use "gettext" here so as not to trigger xgettext.
>
> That's it!
I'm still confused. There are two statements here:
> You can't add a function call anywhere in the code. You can't add
> a function call in a static initializer ...
How is the first statement true?
Regarding the second statement, does it matter for Subversion? We
have few such initializations, and those we do have may not need to be
translated. At worst, we might have to change some code. It doesn't
seem like a showstopper, anyway.
(I understand that you were just explaining things. My confusion is
really about the assertion that Subversion strings will have a
problem, which originated with Justin, I think, not you.)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The
gettext proposal
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
Ben Collins-Sussman wrote:
>>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?
>
>
Yes. This is the issue:
You can't add a function call anywhere in the code. You can't add a
function call in a static initializer, like:
char *global_greetings[] = { _("Hello"), _("Hi"), NULL };
This won't compile. The solution is to have a macro which does nothing:
"N_":
#define N_(x) (x)
char *global_greetings[] = { N_("Hello"), N_("Hi"), NULL };
This will be caught by xgettext and it will be put in the .pot file, but
global_greeting will still have the English messages. We fix that by
calling "gettext" on the string:
for(p=global_greetings;p;p++)
printf(gettext(global_greeting));
We use "gettext" here so as not to trigger xgettext.
That's it!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
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:42 PM -0600 Ben Collins-Sussman
<su...@collab.net> wrote:
> Grumble, grumble... Mulberry on OSX is line-wrapping your patch. :-(
I didn't paste that patch right. I did for the earlier one. Sorry. =(
> Testing the patch on RH9 with GNU gettext 0.13...
>> +
>> +install-i18n:
>> + $(MKDIR) $(DESTDIR)$(localedir)
>
> You need a "; \" at the end of this line, right? This is probably a
> typo?
Nah, the mkdir can execute in its own subshell.
> Otherwise, on my system, the patch seems to "work"... I think. I have
> no es.po file, so I'm not totally sure. ./configure finds msgfmt, but
> then when I 'make', I see nothing special happening. I assume that the
> build-i18n is doing nothing, because es.po doesn't exist?
Right, you need the es.po file present. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n:
The gettext proposal
Posted by Ben Collins-Sussman <su...@collab.net>.
Grumble, grumble... Mulberry on OSX is line-wrapping your patch. :-(
Testing the patch on RH9 with GNU gettext 0.13...
On Tue, 2004-03-30 at 12:28, Justin Erenkrantz wrote:
> +
> +install-i18n:
> + $(MKDIR) $(DESTDIR)$(localedir)
You need a "; \" at the end of this line, right? This is probably a
typo?
Otherwise, on my system, the patch seems to "work"... I think. I have
no es.po file, so I'm not totally sure. ./configure finds msgfmt, but
then when I 'make', I see nothing special happening. I assume that the
build-i18n is doing nothing, because es.po doesn't exist?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
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 1:36 PM -0800 Greg Stein <gs...@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
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by Greg Stein <gs...@lyra.org>.
On Tue, Mar 30, 2004 at 10:28:42AM -0800, Justin Erenkrantz wrote:
>...
> * Makefile.in: Add localedir, MSGFMT, PACKAGE_NAME, PACKAGE_VERSION substs from
> configure; add in build-i18n and install-i18n targets
> [installs to right location for Solaris; no clue about GNU gettext]
> * configure.in: Remove old placeholder for GNU gettext and move down to a
> more sensible location; add in i18n config section which enables NLS iff
> msgfmt is found; export SVN_LOCALE_DIR properly escaped so main.c can use;
> if i18n enabled, add in build-i18n and install-i18n targets
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.
>...
> +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' ?
>...
> +build-i18n:
> + @list='$(ALL_LINGUAS)'; \
> + for i in $$list; do \
> + $(MSGFMT) -o po/$$i.mo $(srcdir)/po/$$i.po; \
> + done
> +
> +install-i18n:
> + $(MKDIR) $(DESTDIR)$(localedir)
> + @list='$(ALL_LINGUAS)'; \
> + for i in $$list; do \
> + $(INSTALL_DATA) po/$$i.mo
> $(DESTDIR)$(localedir)/$$i/LC_MESSAGES/$(PACKAGE_NAME).mo; \
> + done
These ought to be redone in favor of gen-build producing deps for us.
>...
> +++ 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.
> +dnl Set of available languages.
> +dnl ALL_LINGUAS="de fr es ko nl no pl pt sl sv"
> +dnl I volunteer for this ^^ translation :-) -xbc
> +ALL_LINGUAS="es"
> +AC_SUBST(ALL_LINGUAS)
See above about this.
>...
> +AH_BOTTOM(
> +#define N_(x) (x)
> +#ifdef ENABLE_NLS
> +#include <locale.h>
> +#include <libintl.h>
> +#define _(x) dgettext(PACKAGE_NAME, x)
> +#else
> +#define _(x) (x)
> +#endif
> +)
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.
>...
> +++ subversion/clients/cmdline/main.c (working copy)
>...
> @@ -656,6 +658,12 @@
> svn_cl__cmd_baton_t command_baton;
> svn_auth_baton_t *ab;
> svn_config_t *cfg;
> +
> +#ifdef ENABLE_NLS
> + setlocale (LC_ALL, "");
> + bindtextdomain (PACKAGE_NAME, SVN_LOCALE_DIR);
> + textdomain (PACKAGE_NAME);
> +#endif
>
> /* Initialize the app. */
> if (svn_cmdline_init ("svn", stderr) != EXIT_SUCCESS)
I think your changes will need to go into svn_cmdline_init(), and be
coordinated with the setlocale() call in there.
Cheers,
-g
--
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The
gettext proposal
Posted by Nicolás Lichtmaier <ni...@reloco.com.ar>.
> --- subversion/libsvn_subr/opt.c (revision 9230)
> +++ subversion/libsvn_subr/opt.c (working copy)
> @@ -36,6 +36,8 @@
> #include "svn_utf.h"
> #include "svn_time.h"
>
> +#include "svn_private_config.h"
> +
>
Autoconf's "config.h" is supposed to be included *before* any other
header. This is how every other package (except subversion) does it.
It's even recommended in the autoconf manual:
> The package should `#include' the configuration header file before
> any other header files, to prevent inconsistencies in declarations (for
> example, if it redefines `const'). Use `#include <config.h>' instead
> of `#include "config.h"', and pass the C compiler a `-I.' option (or
> `-I..'; whichever directory contains `config.h'). That way, even if
> the source directory is configured itself (perhaps to make a
> distribution), other build directories can also be configured without
> finding the `config.h' from the source directory.
Some macros even depend of defining things before system include headers
too, e.g. the ones providing large file (>2Gb) support on Linux.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
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 11:57 AM -0600 Ben Collins-Sussman
<su...@collab.net> wrote:
> 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?
My only desire in this whole i18n effort is not to introduce a build or
runtime dependency on GNU gettext. The patch that I submitted last night
works with Solaris's gettext, which is integrated into Solaris's libc and
doesn't suffer from being LGPLed.
So, as far as I'm concerned, I'm mostly happy...for now. ;-)
>> 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?
Okay, so the problem is that we have a very common paradigm like:
in subversion/clients/cmdline/help-cmd.c:
const char svn_cl__help_header[] =
"usage: svn <subcommand> [options] [args]\n"
"Type \"svn help <subcommand>\" for help on a specific subcommand.\n"
"\n"
"Most subcommands take file and/or directory arguments, recursing\n"
"on the directories. If no arguments are supplied to such a\n"
"command, it will recurse on the current directory (inclusive) by\n"
"default.\n"
"\n"
"Available subcommands:\n";
These are compiled-in constant strings. However, with the i18n requirement
and the way gettext operates, these can't be compiled-in constants anymore as
the translation needs to occur at run-time to the 'correct' translation.
We'll have to rethink somewhat how we treat such constants.
> 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
...
> 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.
+1. Sounds sane.
> 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. :-)
Heh. Just drop most of the .c file changes. I've attached a trimmed-down
version here that also includes the fixup for main.c. It also includes the
_() for the default error in opt.c - that's a quick way to test if everything
is working.
I'd just need to test this against a GNU gettext install. If it works, would
there be any reason not to commit the build infrastructure to the trunk? I
can probably get to this tonight, I guess. -- justin
* Makefile.in: Add localedir, MSGFMT, PACKAGE_NAME, PACKAGE_VERSION substs from
configure; add in build-i18n and install-i18n targets
[installs to right location for Solaris; no clue about GNU gettext]
* configure.in: Remove old placeholder for GNU gettext and move down to a
more sensible location; add in i18n config section which enables NLS iff
msgfmt is found; export SVN_LOCALE_DIR properly escaped so main.c can use;
if i18n enabled, add in build-i18n and install-i18n targets
[the double eval is funny, but there isn't a clean way to fully expand here.
There are some M4 macros in apr or httpd for this though.]
* subversion/clients/cmdline/main.c: Include svn_private_config.h, _()-escape
some strings
(main): call setlocale, bindtextdomain, and textdomain to initialize gettext
* subversion/libsvn_subr/opt.c (svn_opt_print_help): Add _() to the 'default'
case when there are no arguments.
Index: Makefile.in
===================================================================
--- Makefile.in (revision 9230)
+++ Makefile.in (working copy)
@@ -57,6 +57,7 @@
infodir = @infodir@
datadir = @datadir@
docdir = @docdir@
+localedir = @localedir@
# where to install libsvn_swig_*
swig_py_libdir = @libdir@
@@ -78,7 +79,10 @@
TEXI2DVI = texi2dvi
DVIPS = dvips
DVIPDF = dvipdf
+MSGFMT = @MSGFMT@
+PACKAGE_NAME=@PACKAGE_NAME@
+PACKAGE_VERSION=@PACKAGE_VERSION@
CC = @CC@
CXX = @CXX@
@@ -511,3 +515,17 @@
echo "$(INSTALL_DATA) $$file $(DESTDIR)$(infodir)/$$inst"; \
$(INSTALL_DATA) $$file $(DESTDIR)$(infodir)/$$inst; \
done
+
+ALL_LINGUAS=@ALL_LINGUAS@
+build-i18n:
+ @list='$(ALL_LINGUAS)'; \
+ for i in $$list; do \
+ $(MSGFMT) -o po/$$i.mo $(srcdir)/po/$$i.po; \
+ done
+
+install-i18n:
+ $(MKDIR) $(DESTDIR)$(localedir)
+ @list='$(ALL_LINGUAS)'; \
+ for i in $$list; do \
+ $(INSTALL_DATA) po/$$i.mo
$(DESTDIR)$(localedir)/$$i/LC_MESSAGES/$(PACKAGE_NAME).mo; \
+ done
Index: configure.in
===================================================================
--- configure.in (revision 9230)
+++ configure.in (working copy)
@@ -73,11 +73,6 @@
dnl (We can add custom defines by creating ./acconfig.h if we wish.)
AC_CONFIG_HEADER(svn_private_config.h)
-dnl Todo: we're English-only now, but GNU Gettext eventually?
-dnl Set of available languages.
-dnl ALL_LINGUAS="de fr es ko nl no pl pt sl sv"
-dnl I volunteer for this ^^ translation :-) -xbc
-
dnl Check for programs ---------------------
dnl Look for a C compiler (before anything can set CFLAGS)
@@ -255,7 +250,43 @@
SVN_LIB_BERKELEY_DB($SVN_FS_WANT_DB_MAJOR, $SVN_FS_WANT_DB_MINOR,
$SVN_FS_WANT_DB_PATCH, [db4 db])
+dnl I18n -------------------
+localedir='${datadir}/locale'
+localedir="${localedir}/subversion-${svn_version}"
+AC_SUBST(localedir)
+
+dnl Set of available languages.
+dnl ALL_LINGUAS="de fr es ko nl no pl pt sl sv"
+dnl I volunteer for this ^^ translation :-) -xbc
+ALL_LINGUAS="es"
+AC_SUBST(ALL_LINGUAS)
+
+USE_NLS="no"
+AC_PATH_PROG(MSGFMT, msgfmt, none)
+if test "$MSGFMT" != "none"; then
+ AC_DEFINE(ENABLE_NLS, 1,
+ [Define to 1 if translation of program messages to the user's
+ native language is requested.])
+ dnl Must expand twice at least to get prefix expanded!
+ svn_localedir="`eval echo ${localedir}`"
+ svn_localedir="`eval echo ${svn_localedir}`"
+ AC_DEFINE_UNQUOTED(SVN_LOCALE_DIR, "${svn_localedir}",
+ [Defined to be the path to the installed locale dirs])
+ USE_NLS="yes"
+fi
+
+AH_BOTTOM(
+#define N_(x) (x)
+#ifdef ENABLE_NLS
+#include <locale.h>
+#include <libintl.h>
+#define _(x) dgettext(PACKAGE_NAME, x)
+#else
+#define _(x) (x)
+#endif
+)
+
# Only add *_APACHE_RULE if we also have db, since mod_dav_svn depends on it.
INSTALL_STATIC_RULES="install-bin install-docs"
INSTALL_RULES="install-base-lib install-lib install-include install-static"
@@ -274,6 +305,11 @@
INSTALL_RULES="`echo $INSTALL_RULES | sed 's/install-lib/install-dav-lib
install-lib/'`"
fi
+if test "$USE_NLS" = "yes"; then
+ BUILD_RULES="$BUILD_RULES build-i18n"
+ INSTALL_RULES="$INSTALL_RULES install-i18n"
+fi
+
AC_SUBST(BUILD_RULES)
AC_SUBST(INSTALL_STATIC_RULES)
AC_SUBST(INSTALL_RULES)
Index: subversion/libsvn_subr/opt.c
===================================================================
--- subversion/libsvn_subr/opt.c (revision 9230)
+++ subversion/libsvn_subr/opt.c (working copy)
@@ -36,6 +36,8 @@
#include "svn_utf.h"
#include "svn_time.h"
+#include "svn_private_config.h"
+
/*** Code. ***/
@@ -735,7 +737,7 @@
pool,
stdout);
else /* unknown option or cmd */
- fprintf (stderr, "Type '%s help' for usage.\n", pgm_name);
+ fprintf (stderr, _("Type '%s help' for usage.\n"), pgm_name);
return SVN_NO_ERROR;
}
Index: subversion/clients/cmdline/main.c
===================================================================
--- subversion/clients/cmdline/main.c (revision 9230)
+++ subversion/clients/cmdline/main.c (working copy)
@@ -47,6 +47,8 @@
#include "svn_auth.h"
#include "cl.h"
+#include "svn_private_config.h"
+
/*** Option Processing ***/
@@ -656,6 +658,12 @@
svn_cl__cmd_baton_t command_baton;
svn_auth_baton_t *ab;
svn_config_t *cfg;
+
+#ifdef ENABLE_NLS
+ setlocale (LC_ALL, "");
+ bindtextdomain (PACKAGE_NAME, SVN_LOCALE_DIR);
+ textdomain (PACKAGE_NAME);
+#endif
/* Initialize the app. */
if (svn_cmdline_init ("svn", stderr) != EXIT_SUCCESS)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The
gettext proposal
Posted by Ben Collins-Sussman <su...@collab.net>.
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
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> 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. It's not something I
> want to do. -- justin
Why wouldn't we be able to continue using const char * strings?
I thought the Gettext Way was just to prefix each one with an
underscore. Then gettext does
#define _" SOME_GETTEXT_MAGIC
and the preprocessor replaces each string with a call to
gettext(string), which copies the string out to a table, and the human
translators use the entries in that table as the index side of their
.po files, etc, etc.
In other words, I thought the whole point of gettext was that it
allows you to continue using the same const char * strings in your
source code. I might be very ignorant though. If I am, blame Ben
Collins-Sussman, who just explained gettext to me :-)
-Karl
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
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 12:29 PM +0100 Max Bowsher <ma...@ukf.net> wrote:
> Most things that use gettext do so optionally.
> IIRC, "#define _(x) x", "#ifdef"-ing out all calls to libintl, and not
> linking with libintl is all that is required.
That's what most people say they do, but in practice, I've found it almost
impossible to avoid installing GNU gettext for most GNU i18n'd packages. That
said, the call in main.c for setlocale, etc needs to be protected by #ifdef
ENABLE_NLS. Yet, other than that one tweak, what I posted last night might
make us optional, but I'm still skeptical long-term that we're not going to
introduce a dependency.
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. It's not something I want to do. -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by Max Bowsher <ma...@ukf.net>.
Justin Erenkrantz wrote:
> --On Tuesday, March 30, 2004 12:55 AM -0300 Nicolás Lichtmaier
> <ni...@reloco.com.ar> wrote:
>
>> Hi, I propose to use gettext for i18n.
>
> This would add a new build and run-time dependency that I think we have to
be
> very careful about handling. I really wish this could be made optional
rather
> than being a mandatory requirement.
Most things that use gettext do so optionally.
IIRC, "#define _(x) x", "#ifdef"-ing out all calls to libintl, and not
linking with libintl is all that is required.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> This has been a long-standing point of disagreement between me and the
> svn source code base. As I understand it, the difference between
> #include "foo" and #include <foo> is that the former searches the source
> code file's directory before the include path, and that's it. By
> implication, the only files we should be including with "foo" are the
> directory-private headers like wc.h. But we seem to include all of our
> own headers with "foo".
Wouldn't object to a change, if it bothers you. (I'm not sure how we
settled on the current convention. Your understanding of "" vs <> is
exactly the same as mine... and as K&R's (2nd ed, 4.11.1, p. 88) :-) ).
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by "Peter S. Housel" <ho...@acm.org>.
<kf...@collab.net> writes:
> Justin Erenkrantz <ju...@erenkrantz.com> writes:
> > > That's not necessarily our problem, as long as we don't ourselves
> > > distribute the static binary. If a user wishes to create a static
> > > binary and use it without distributing it, the LGPL restrictions on
> > > distributing static binaries don't come into play.
> >
> > Well, I thought I just saw a thread about trying to promote creating
> > binaries for Subversion rather than distributing source. *shrug*
>
> Not "rather than" but "in addition to", yeah.
>
> (I'm reading the LGPL and gettext's use of it carefully now, would
> like a first-hand understanding of the restrictions here.)
The gettext file format is documented in the gettext info files; it's not
exactly rocket science. I suggest writing a new gettext runtime that could
be included in apr or apr-utils; the build could continue to use the GNU
gettext utilites, of course. This approach would also allow better
integration with apr_iconv and the like.
-Peter-
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The gettext proposal
Posted by kf...@collab.net.
Justin Erenkrantz <ju...@erenkrantz.com> writes:
> > That's not necessarily our problem, as long as we don't ourselves
> > distribute the static binary. If a user wishes to create a static
> > binary and use it without distributing it, the LGPL restrictions on
> > distributing static binaries don't come into play.
>
> Well, I thought I just saw a thread about trying to promote creating
> binaries for Subversion rather than distributing source. *shrug*
Not "rather than" but "in addition to", yeah.
(I'm reading the LGPL and gettext's use of it carefully now, would
like a first-hand understanding of the restrictions here.)
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
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 11:35 AM -0500 Greg Hudson <gh...@MIT.EDU>
wrote:
> That's not necessarily our problem, as long as we don't ourselves
> distribute the static binary. If a user wishes to create a static
> binary and use it without distributing it, the LGPL restrictions on
> distributing static binaries don't come into play.
Well, I thought I just saw a thread about trying to promote creating binaries
for Subversion rather than distributing source. *shrug*
> This has been a long-standing point of disagreement between me and the
> svn source code base. As I understand it, the difference between
># include "foo" and #include <foo> is that the former searches the source
> code file's directory before the include path, and that's it. By
> implication, the only files we should be including with "foo" are the
> directory-private headers like wc.h. But we seem to include all of our
> own headers with "foo".
*shrug*
It just seems to be our convention to include our own headers via "" and
external headers via <>. But, I'm just following our convention not altering
our precedent. More importantly, Nicolás had a bogus define protecting the
include's which prevented it from being included (we purposely don't define
HAVE_CONFIG_H), and the include line was in the wrong location (too high up in
the file). -- justin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: [PATCH] Do not use gettextize and i18n round 2 Re: I18n: The
gettext proposal
Posted by Greg Hudson <gh...@MIT.EDU>.
On Tue, 2004-03-30 at 04:49, Justin Erenkrantz wrote:
> This would add a new build and run-time dependency that I think we have to be
> very careful about handling. I really wish this could be made optional rather
> than being a mandatory requirement. As an aside, we would have to disable
> static linking if we import gettext as LGPL forbids any static binaries
> created with LGPL functionality. (Hmm, we'd have to do the same for neon -
> are we?)
That's not necessarily our problem, as long as we don't ourselves
distribute the static binary. If a user wishes to create a static
binary and use it without distributing it, the LGPL restrictions on
distributing static binaries don't come into play.
Also, the LGPL does not forbid static binaries; it just places some
conditions on their distribution. Those conditions are mildly onerous
for a proprietary product--they involve distributing linkable object
files--but not terribly onerous for a non-GPL free software project.
One way of complying would be to make sure that the directory or page
you distribute the static binary from also contains the source code used
to create that binary, including the external dependencies.
> * subversion/*.c: We do not protect includes of svn_private_config.h as it is
> always available (even on Win32). You are also using the incorrect syntax (<>
> vs "")
This has been a long-standing point of disagreement between me and the
svn source code base. As I understand it, the difference between
#include "foo" and #include <foo> is that the former searches the source
code file's directory before the include path, and that's it. By
implication, the only files we should be including with "foo" are the
directory-private headers like wc.h. But we seem to include all of our
own headers with "foo".
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org