[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wget
Subject:    Re: wget from hg repository and Solaris don't mix well --
From:       Micah Cowan <micah () cowan ! name>
Date:       2008-01-25 8:49:36
Message-ID: 4799A2A0.9000400 () cowan ! name
[Download RAW message or body]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Paul Townsend wrote:
>>> The Solaris `sed' doesn't flush the last data line if that line isn't
>>> terminated with a NEWLINE.  The problem surfaces in the "po" directory
>>> and the problem code is in the "Rules-quot" file where `msgfilter'
>>> passes some un-newline terminated data to a `sed' invocation (see my
>>> quick and dirty patch below).

<snip>

I wrote:
>> I was toying with the idea of eschewing en@quot in favor of a true,
>> hand-crafted en_US.po; this might allow me to use the proper diacritics
>> in Hrvoje's last name, for example; and to replace the (C) with a proper
>> copyright mark. But I haven't committed to doing this. And I kind of
>> like having LANGUAGE=en@boldquot; the right things grab my eye so much
>> better now. But then, I suppose it's a slippery slope from there to (as
>> I think at least one has suggested) colorizing Wget's output... :)

Rather than bothering with a hand-crafted en_US.po, I've modified the
sed rules used to generate the en@[bold]quot.po files (which use UTF-8),
to perform the relevant substitution for "NikÅ¡ić" and (C) ->  ©; and also
to include a few additional apostrophes in the replacements.

I also added rules to generate en_US.po from the en@quot.po, so that
these changes will be available to everyone using an en_US locale, and
not just the ones who think to set LANGUAGE=en@quot.

>> I'm not crazy about customizing gettext's Rules-quot (I've already had
>> to customize their Makefile.in.in, as it does some things I find rather
>> disagreeable); and even if I did, I'm not sure how to get around this
>> problem. I suppose one could rewrite the appropriate code with something
>> that invokes sed on the actual message file itself, rather than
>> individual strings... I'm really not sure what should be done about it. :\

Well, the bit about not customizing gettext's Rules-quot is already
blown away. And I'd certainly rather have done that than try to maintain
a manual en_US.po file.

Paul (sent privately):
> A possible partial solution would be to use the AC_PROG_SED autoconf
> macro to determine the sed to use.  According to the documentation, it
> prefers the GNU sed.  Also, the configure script should probably be
> expanded to check to see if any decided upon sed can output non-NEWLINE 
> terminated data and issue a warning/error if it can't.  (So much work
> for a relatively small problem (:@{).)

Yeah, it does sound like a lot of work to me. I'm not sure it's worth
it: I have all the .po files checked in, and as far as I know the only
time they'd be automatically updated is when doing make dist. Those few
people who have a reason to run make dist can set up their path for GNU
sed without too much trouble, I think.

That being said, I don't suppose I'd be opposed to a patch to that
effect, since I'm already making changes to Rules anyway.

- --
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHmaKg7M8hyUobTrERAiLnAJ9Ux7YGb7XZ8EfKsVtEWRqDFh+p4wCdHQ78
vLettgWgfhyoI5DIHwRBTGQ=
=3WND
-----END PGP SIGNATURE-----
[prev in list] [next in list] [prev in thread] [next in thread]