On Tuesday 22 February 2005 00:10, Hrvoje Niksic wrote:
If wide chars were in that message, you could no longer print it with
printf, which means that a majority of gettext-using programs would be
utterly broken, Wget included. I imagine I would have gotten a bunch
of bug reports for that
Simone Piunno [EMAIL PROTECTED] writes:
On Tuesday 22 February 2005 00:10, Hrvoje Niksic wrote:
If wide chars were in that message, you could no longer print it with
printf, which means that a majority of gettext-using programs would be
utterly broken, Wget included. I imagine I would have
Mauro Tortonesi [EMAIL PROTECTED] writes:
On Sunday 20 February 2005 06:31 pm, Hrvoje Niksic wrote:
string_t.c uses the function iswblank, which doesn't seem to exist
on Solaris 8 I tried to compile it on. (Compilation is likely
broken on other non-Linux platforms as well for the same
Simone Piunno [EMAIL PROTECTED] writes:
I think by pushing this line of reasoning to the extreme you
shouldn't have added i18n through gettext, should you?
You are right, and I was indeed leery of adding support for gettext
until I was convinced that it would work well both on systems without
Hrvoje Niksic wrote:
2) Server messages printed by Wget in normal operation, such as the
200 Ok message. That one is printed just for the fun factor
anyway, we could as well print just the response code. However, I
don't see a problem with simply filtering out the non-ASCII's from
On Monday 21 February 2005 09:49 am, Draen Kaar wrote:
Hrvoje Niksic wrote:
2) Server messages printed by Wget in normal operation, such as the
200 Ok message. That one is printed just for the fun factor
anyway, we could as well print just the response code. However, I
don't
Mauro,
I tend to agree with Hrvoje. If you decide to open the
Pandora's box and implement iconv support, please, please,
provide an option, preferably default one, to configure or
use wget without iconv. FYI, there are languages which actively
use more than one coding. For example, I know 14
On Monday 21 February 2005 12:35 pm, Leonid wrote:
Mauro,
I tend to agree with Hrvoje. If you decide to open the
Pandora's box and implement iconv support, please, please,
provide an option, preferably default one, to configure or
use wget without iconv.
of course.
FYI, there are
Mauro Tortonesi [EMAIL PROTECTED] writes:
It is rather common that either the charset at the remote host or
the charset at the local host are set incorrectly.
this is not a problem. actually (apart from the case of a document
returned as an HTTP response) we cannot be sure that the charset
Mauro Tortonesi [EMAIL PROTECTED] writes:
the problem is not with HTTP response messages, but with HTTP
resources (which can be for example binary data or multibyte char
text - in this case you really want to escape unprintable data while
printing all the valid multibyte chars you can using
On Monday 21 February 2005 02:39 pm, you wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
the problem is not with HTTP response messages, but with HTTP
resources (which can be for example binary data or multibyte char
text - in this case you really want to escape unprintable data while
Mauro Tortonesi [EMAIL PROTECTED] writes:
but i suspect we wiil probably have to add foreign charset support
to wget one of these days. for example, suppose we are doing a
recursive HTTP retrieval and the HTML pages we retrieve are not
encoded in ASCII but in UTF16 (an encoding in which is
On Monday 21 February 2005 02:37 pm, you wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
It is rather common that either the charset at the remote host or
the charset at the local host are set incorrectly.
this is not a problem. actually (apart from the case of a document
returned as
On Monday 21 February 2005 03:57 pm, Hrvoje Niksic wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
but i suspect we wiil probably have to add foreign charset support
to wget one of these days. for example, suppose we are doing a
recursive HTTP retrieval and the HTML pages we retrieve are
Mauro Tortonesi [EMAIL PROTECTED] writes:
The only reason why that bug occurred was the broken hotfix that
escaped *all* non-ASCII content printed by Wget, instead of only that
actually read from the network. We don't need iconv to fix that, we
need correct quoting.
yes, you may be right.
On Monday 21 February 2005 04:23 pm, Hrvoje Niksic wrote:
Mauro Tortonesi [EMAIL PROTECTED] writes:
The only reason why that bug occurred was the broken hotfix that
escaped *all* non-ASCII content printed by Wget, instead of only that
actually read from the network. We don't need iconv to
Mauro Tortonesi [EMAIL PROTECTED] writes:
If that weren't safe, Wget would (along with many other programs) have
been broken a long time ago. In fact, if that were the case, I would
never have even accepted adding support for gettext in the first
place.
well, theoretically it could happen.
On Monday 21 February 2005 16:18, Hrvoje Niksic wrote:
Also, gettext doesn't change behavior of low-level
routines in a fundamental way -- it's just a way of getting different
strings. On the other hand, wide chars do introduce pretty invasive
changes to the way things work. The most basic
Simone Piunno [EMAIL PROTECTED] writes:
On Monday 21 February 2005 16:18, Hrvoje Niksic wrote:
Also, gettext doesn't change behavior of low-level routines in a
fundamental way -- it's just a way of getting different strings.
On the other hand, wide chars do introduce pretty invasive changes
string_t.c uses the function iswblank, which doesn't seem to exist on
Solaris 8 I tried to compile it on. (Compilation is likely broken on
other non-Linux platforms as well for the same reason.) Since nothing
seems to be using the routines from string_t, I solved the problem by
removing
On Sunday 20 February 2005 06:31 pm, Hrvoje Niksic wrote:
string_t.c uses the function iswblank, which doesn't seem to exist on
Solaris 8 I tried to compile it on. (Compilation is likely broken on
other non-Linux platforms as well for the same reason.) Since nothing
seems to be using the
21 matches
Mail list logo
