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

[PATCH] Don't strip Content-Type in .po files on Windows

From: Роман Донченко <dpb_at_corrigendum.ru>
Date: Mon, 06 Aug 2012 03:19:23 +0400

Greetings,

I submitted this patch a couple of years ago, but it didn't get much
attention. I still think it's relevant, so I'll try again.

[[[
On Windows, don't strip the Content-Type field from .po files during their
compilation.

GNU libintl, by default, converts the l10n strings into the locale
encoding, while Subversion requires UTF-8. This conversion can be
suppressed by calling bind_textdomain_codeset, but certain old versions of
libintl don't have that, so the Unix build system checks for the existence
of that function, and if it's not present, strips the Content-Type header
 from the .po files (which prevents encoding conversion, as well, but makes
msgfmt complain).

When building on Windows, this stripping is done unconditionally, but is
completely unnecessary:

- On Windows, we only support linking with svn-win32-libintl, which is
hacked to disable all encoding conversions.
- Even if someone links with with his own version of libintl, it's a safe
bet that it will be new enough to support bind_textdomain_codeset, so we
can just call that.

This patch removes Content-Type stripping on Windows, which gets rid of
msgfmt warnings, as well as simplifies the build system.

* build/generator/build_locale.ezt: Remove the strip-po-charset.py
invocation.

* build/generator/gen_win.py:
     (POFile.__init__): don't store the .spo file name.

* build/strip-po-charset.py: Delete.

* subversion/libsvn_subr/nls.c:
     (svn_nls_init): Move the bind_textdomain_codeset call out of the
#ifdef WIN32 block, so it's executed on Windows, as well.

* subversion/svn_private_config.hw: Indicate that bind_textdomain_codeset
is available if NLS is enabled.
]]]

Roman.

Received on 2012-08-06 01:25:40 CEST

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

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