Re: Uncoupling translations from source
Maybe you wanted to say that many Europeans speak English so well, that they do not need translations? It is my observation as well: Some users are hostile towards the notion of translated software. Those are typically not native English speakers, but people who found, at one time or the other, reason to complain about translations. They do so for all operating systems, making fun of erroneous translations (such as the infamous Pfeife zerbrochen of SINIX, or translations that an MS employee came up with). Unfortunately (I think), those people then come to the conclusion that translations, in general, suck, where I feel that the right conclusion should have been that translations, like all other parts of software, may have bugs that need to be reported and fixed. Those people ignore that many other people have less problems using computers if the computers complain in their native tongue. Unfortunately, again, the group complaining about translations is often more vocal about it. I don't know whether this is a European phenomenon only, or whether people in other continents develop the same dislike towards their own language when interacting with computers. Most certainly, native English speakers are neutral towards translations, since they don't need them and can't comment on their quality and usefulness. Kind regards, Martin
Users and languages, was: Uncoupling translations from source
Hi Martin and the others, if you feel that this is too off-topic, yell Stop! Maybe you wanted to say that many Europeans speak English so well, that they do not need translations? It is my observation as well: Some users are hostile towards the notion of translated software. Well, I have a local language Netscape, ThumbsPlus, WinCommander accompanied by many English language programs like PSP. And most of the people I know are the same. Maybe (also) a Windows/Unix difference? Those are typically not native English speakers, Of course not, as these have -most of the time- a program in their language. but people who found, at one time or the other, reason to complain about translations. They do so for all operating systems, making fun of erroneous translations (such as the infamous Pfeife zerbrochen of SINIX, or translations that an MS employee came up with). IMO, a bad translation is only useful, if I speak the original language even worse. I'd rather stick to a precise Oxford English than a German Kauderwelsch created by BabelFish (TM). Unfortunately (I think), those people then come to the conclusion that translations, in general, suck, where I feel that the right conclusion should have been that translations, like all other parts of software, may have bugs that need to be reported and fixed. Agreed, these bugs need reporting, !and! fixing. However, IMO, the time spent for fixing translations is better used for fixing bugs concerning the program and adding new features. Of course I would talk differently if there was a really cool program in Kisuaheli. So I am aware of the weaknesses in my argumentation. Those people ignore that many other people have less problems using computers if the computers complain in their native tongue. Unfortunately, again, the group complaining about translations is often more vocal about it. As long as I have the choice, I will certainly not complain. And if a translation makes working easier for other people, they should have the possibility to do so. My point is, that _I_ find it easier to use a manual/prog in good English than in bad German. (And, to admit it, I rarely take the time to report translation bugs...) I don't know whether this is a European phenomenon only, or whether people in other continents develop the same dislike towards their own language when interacting with computers. I can really not relate to this very much. Germany for exapmple is one of very few countries, where movies get translated, not with subtitles, but with lip-syncing. So why the supposedly different attitude when computers are involved? The only reason I can think of is that they think the same way as me: Better download the good English version and not the localized package with content I do not know the quality of. Most certainly, native English speakers are neutral towards translations, since they don't need them and can't comment on their quality and usefulness. Well, only because most programs are available in English, that does not mean that native English speakers do not need translations... ; CU Jens -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
RE: wget 1.8beta - handling of non-ascii characters in URL
Mac Os X could have some special characters. Future OSs could have some special characters. A BeOs port could appear. If wget is going down that road (would be really nice) I'm wondering if it would be better having a/several internal defaults (general unix and windows at least) AND some way to specifiy a different table in .wgetrc - this would end the hassle for everybody who's changing the default currently because he's mirroring something and doesn't want ~ to be encoded, or because wget is mirroring on unix but exporting to windows with samba, or has just some special needs. Heiko -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY -Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]] Sent: Friday, December 07, 2001 4:24 PM To: Wget List Subject: Re: wget 1.8beta - handling of non-ascii characters in URL Andre Majorel [EMAIL PROTECTED] writes: Which of course is another can of worms because it's heavily platform dependant. Apparently FAT and VFAT do not have the same set of forbidden characters. Then maybe such processing will be in a totally independent table and function, so that it can be implemented differently for different file systems. In reality, we will hopefully only need to differentiate between Unix-like and Windows-like file systems.
Re: Users and languages, was: Uncoupling translations from source
[EMAIL PROTECTED] writes: IMO, a bad translation is only useful, if I speak the original language even worse. I'd rather stick to a precise Oxford English than a German Kauderwelsch created by BabelFish (TM). Just try to translate a middle size program (2-500 message) and you'll see how un-precise original messages are ;-) It takes more of my time to report and discuss inconsistencies than to translate the strings. My point is, that _I_ find it easier to use a manual/prog in good English than in bad German. (And, to admit it, I rarely take the time to report translation bugs...) Additional note, you're not allowed to install programs for your users in some countries when there's no native language support. -- Free Translation Project: Karl Eichwalder http://www.iro.umontreal.ca/contrib/po/HTML/
WNP for cvs sources of Dec 9, 2001
hi! here is latest wget-new-percentage patch: http://www.biscom.net/~cade/away/wget-new-percentage/wget-new-percentage-cvs-20011209.tar.gz any feedback is welcome, thanx! P! Vladi. -- Vladi Belperchinov-Shabanski [EMAIL PROTECTED] [EMAIL PROTECTED] Personal home page at http://www.biscom.net/~cade DataMax Ltd. http://www.datamax.bg Too many hopes and dreams won't see the light... smime.p7s Description: S/MIME Cryptographic Signature
Re: Uncoupling translations from source
On 10/12/2001 08:10:12 Martin v. Loewis wrote: Maybe you wanted to say that many Europeans speak English so well, that they do not need translations? It is my observation as well: Some users are hostile towards the notion of translated software. Those are typically not native English speakers, but people who found, at one time or the other, reason to complain about translations. They do so for all operating systems, making fun of erroneous translations (such as the infamous Pfeife zerbrochen of SINIX, or translations that an MS employee came up with). From an ancient DR-DOS (version 3.something) Nicht breit __reading__ laufwerk A: This was clearly an oversight (the message was probably pasted together from various places). My native language is Hungarian, and I don't remember using ANY software in Hungarian (with the possible exception of Recognita, which is written by hungarians). For the few I tried, I found the hungarian translation incredibly awkward (this is exacerbated by the fact that Hungarian is neither germanic nor latinic), even if not at the level of all your base are belong to us :-) It was easier to use the english version (this was all commercial software). Complaining about the *presence* of translation is silly, IMO. Presumably gettext has a way to decide what language to use (LANG environment variable, or suchlike; LANG=en_gb should do). Decoupling translations is a good idea, if the logistics can be sorted out. Csaba -- Csaba Ráduly, Software Engineer Sophos Anti-Virus email: [EMAIL PROTECTED]http://www.sophos.com US Support: +1 888 SOPHOS 9 UK Support: +44 1235 559933
RE: Wget 1.8 is released
windows binary at http://space.tin.it/computer/hherold Heiko -- -- PREVINET S.p.A.[EMAIL PROTECTED] -- Via Ferretto, 1ph x39-041-5907073 -- I-31021 Mogliano V.to (TV) fax x39-041-5907087 -- ITALY -Original Message- From: Hrvoje Niksic [mailto:[EMAIL PROTECTED]] Sent: Monday, December 10, 2001 9:43 AM To: Wget List Subject: Re: Wget 1.8 is released The new version has appeared on the GNU site: ftp://ftp.gnu.org/pub/gnu/wget/wget-1.8.tar.gz
[±¤°í]°¡Àå Àú·ÅÇÑ Ç×°ø±ÇÀº Ç×°ø±Ç°æ¸Å¿¡¼..
Title: ¡Ø ÀÌ ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡¼ ÀÓÀÇ·Î »ÌÀº °ÍÀÌ¿À´Ï,À̸ÞÀÏ ÀÌ¿Ü´Â ¾î¶°ÇÑ °³ÀÎÀÚ·áµµ ¾ËÁö ¸ø ¡Ø ÀÌ ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡¼ ÀÓÀÇ·Î »ÌÀº °ÍÀÌ¿À´Ï,À̸ÞÀÏ ÀÌ¿Ü´Â ¾î¶°ÇÑ °³ÀÎÀÚ·áµµ ¾ËÁö ¸øÇÕ´Ï´Ù.ÀÓÀÇÀûÀ¸·Î ó¸®ÇÑ ¸ÞÀÏ¿¡ ´ëÇؼ´Â ¼ö½Å°ÅºÎÇÏ¿© ÁÖ½Ã¸é ¸ÞÀÏÀ» ¹ß¼ÛÇÏÁö ¾Êµµ·ÏÇÏ°Ú½À´Ï´Ù. ¢Ñ ¼ö½Å°ÅºÎ
[±¤°í]°¡Àå Àú·ÅÇÑ Ç×°ø±ÇÀº Ç×°ø±Ç°æ¸Å¿¡¼..
Title: ¡Ø ÀÌ ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡¼ ÀÓÀÇ·Î »ÌÀº °ÍÀÌ¿À´Ï,À̸ÞÀÏ ÀÌ¿Ü´Â ¾î¶°ÇÑ °³ÀÎÀÚ·áµµ ¾ËÁö ¸ø ¡Ø ÀÌ ¸ÞÀÏÀº °Ô½ÃÆÇ¿¡¼ ÀÓÀÇ·Î »ÌÀº °ÍÀÌ¿À´Ï,À̸ÞÀÏ ÀÌ¿Ü´Â ¾î¶°ÇÑ °³ÀÎÀÚ·áµµ ¾ËÁö ¸øÇÕ´Ï´Ù.ÀÓÀÇÀûÀ¸·Î ó¸®ÇÑ ¸ÞÀÏ¿¡ ´ëÇؼ´Â ¼ö½Å°ÅºÎÇÏ¿© ÁÖ½Ã¸é ¸ÞÀÏÀ» ¹ß¼ÛÇÏÁö ¾Êµµ·ÏÇÏ°Ú½À´Ï´Ù. ¢Ñ ¼ö½Å°ÅºÎ
patch: fix percentage 100 for continued downloads
hi all, I'm currently not on the list so please CC to me. have you ever seen something like this? Length: 653,854 [-159,202 to go] (unauthoritative) [ skipping 750K ] 750K ,, ,, ,, ,, ..125% @ 3.48 KB/s I have a very unreliable internet connection and therefore I use wget a lot, but it also means I get a lot of these high percentages reported. It only happens when the length is unauthoritative. So I propose this patch to fix this so wget always reports the right progress! It works for me, I never get percentages 100% anymore! -- cut here -- diff -urN wget-1.7.1/src/ftp.c wget-1.7.1-correctpercentage/src/ftp.c --- wget-1.7.1/src/ftp.cFri Nov 16 20:38:03 2001 +++ wget-1.7.1-correctpercentage/src/ftp.c Mon Dec 10 20:44:54 2001 @@ -868,6 +868,8 @@ if (restval) logprintf (LOG_VERBOSE, _( [%s to go]), legible (expected_bytes - restval)); + /* set expected_bytes to correct value */ + expected_bytes += restval; logputs (LOG_VERBOSE, _( (unauthoritative)\n)); } timer = wtimer_new (); -- until here -- rvd
Re: Wget-1.8 Failed Compiliation
war [EMAIL PROTECTED] writes: gcc -I. -I. -I/app/openssl-0.9.6b/include -DHAVE_CONFIG_H -DSYSTEM_WGETRC=\/app/wget-1.8/etc/wgetrc\ -DLOCALEDIR=\/app/wget-1.8/share/locale\ -O2 -Wall -Wno-implicit -c gen-md5.c In file included from gen-md5.c:31: /usr/include/md5.h:27: Could you send the output of `configure' and the contents of the resulting `config.h' file? Thanks.
Re: Compiling Wget 1.8: md5.h
Erik Sigra [EMAIL PROTECTED] writes: I have compiled the previous versions of Wget without any problem. But version 1.8 introduced a problem; it can't find md5.h when compiling gen-md5.c. I have the file md5.h in /usr/local/ssl/include/openssl but the Wget compilation seems to look in /usr/local/ssl/include. You need to tell me more details, beginning with what system you are compiling on. Configure output and the resulting `config.h' file would be the next thing I need. The problem is that many systems have more than one MD5 library, and more than one `md5.h' include file. It is possible that MD5 has been misdetected by Wget on your system.
unsubscribe
[EMAIL PROTECTED] Please unsubscribe me...
bug in wget rate limit feature
Hi, Today I downloaded the new wget release (1.8) (I'm a huge fan of the util btw ;p ) and have been trying out the rate-limit feature. When I run: wget --limit-rate=20k http://www.planetmirror.com/pub/debian-cd/2.1_r4/i386/binary-i386-1.iso I get a core dump with the following output --10:16:54-- http://www.planetmirror.com/pub/debian-cd/2.1_r4/i386/binary-i386-1.iso = `binary-i386-1.iso.1' Resolving twist... done. Connecting to twist[167.123.1.1]:8080... connected. Proxy request sent, awaiting response... 200 OK Length: 639,348,736 [application/octet-stream] 0% [ ] 64,30619.26K/s ETA 9:00:08 assertion p - bp-buffer = bp-width failed: file progress.c, line 673 Abort (core dumped) twist is our web proxy (running squid) The funny thing is I can snarf the whole intranet using the -m and rate limit options with no bugs at all. A huge iso though just makes it fall over. I'm running FreeBSD 4.1 (which until it hits ports may be a problem). I can't test a non-proxied linux pc from here to see if the same thing happens when grabbing an iso. keep up the good work with wget!
Re: bug in wget rate limit feature
[EMAIL PROTECTED] writes: Today I downloaded the new wget release (1.8) (I'm a huge fan of the util btw ;p ) and have been trying out the rate-limit feature. [...] assertion p - bp-buffer = bp-width failed: file progress.c, line 673 Thanks for the report. The bug shows with downloads whose ETA is 10 or more hours, and is trivially fixed by this patch, already applied to the CVS: Index: progress.c === RCS file: /pack/anoncvs/wget/src/progress.c,v retrieving revision 1.21 retrieving revision 1.22 diff -u -r1.21 -r1.22 --- progress.c 2001/12/09 01:24:40 1.21 +++ progress.c 2001/12/09 04:51:40 1.22 @@ -647,7 +647,7 @@ /* Hours not printed: pad with three spaces (two digits and colon). */ APPEND_LITERAL ( ); - else if (eta_hrs = 10) + else if (eta_hrs 10) /* Hours printed with one digit: pad with one space. */ *p++ = ' '; else
Seg fault in GNU Wget 1.7.1
Hi,
I found a way to make GNU Wget 1.7.1 (wget) crash with a segmentation
fault. Here are the details:
With my particular setup, wget crashes with an argument of 78 characters
or more. This can easily be replicated (on my machine) as such:
I. 78 'x's, could also use `perl -e print 'x' x 78;` if Perl is installed.
$ wget -d
xx
DEBUG output created by Wget 1.7.1 on linux-gnu.
parseurl
(xx) -
host xx -
opath - dir - file - ndir
newpath: /
Segmentation fault
II. Using 77 or fewer characters ('x's), wget works correctly:
$ wget -d
x
DEBUG output created by Wget 1.7.1 on linux-gnu.
parseurl
(x) -
host x -
opath - dir - file - ndir
newpath: /
--19:15:38--
http://x/
= `index.html'
Connecting to
x:80...
x: Host
not found.
Using ddd and gdb I narrowed it down to the following stack trace:
src/http.c:1504 http_loop() - src/log.c:388 logprintf() - \
src/log.c:295 logvprintf() - glibc6 vfprintf() - glibc6 strlen()
Here's the actual 'where' output from gdb:
#0 0xfdf1504 in strlen () at soinit.c:59
#1 0xfdd5834 in vfprintf () at vfprintf.c:1565
#2 0xfde50d0 in _IO_vsnprintf (string=0x10042948 --i \017èi , 'x' repeats 70
times, maxlen=129, format=0x10027cd8 --%s-- %s\n %s = `%s'\n, args=0x7478)
at vsnprintf.c:129
#3 0x10018558 in logvprintf ()
#4 0x100186c4 in logprintf ()
#5 0x1001442c in http_loop ()
#6 0x1001e740 in retrieve_url ()
#7 0x1001a054 in main ()
#8 0xfdb2754 in __libc_start_main () at ../sysdeps/powerpc/elf/libc-start.c:106
#9 0x0 in ?? ()
I tried to replicate the bug on a Debian (testing) GNU/Linux for x86
(486) without success. The glibc6 version (2.2.4) seems to be OK.
So it appears that the bug is probably actually in my version of glibc6
(2.1.3). I'm running Debian (stable) GNU/Linux for PowerPC (PPC).
Incidentally, using the -nv (no verbose) or -q (quiet) wget options seem
to workaround this bug:
(78 'x's)
$ wget -nv
xx
xx: Host
not found.
$ wget -q
xx
I don't know if there's much you can do about this bug but I thought I
would let you know the details in case you hear from others about it.
Once Debian releases version 3.0 (the next stable release), I'll
upgrade, recompile wget and hopefully this problem will be fixed.
Please let me know if you need any more detail or want me to beta test
any changes.
Thanks,
Matt
--
Matt Christian [EMAIL PROTECTED] Learn to love and love to learn.
http://www.visi.com/~mattc/ 0111 ftp://ftp.visi.com/users/mattc/
5468652073656372657420697320131b331b2e1b311b341b311b351b39110d0a
Re: Wget-1.8 Failed Compiliation
war [EMAIL PROTECTED] writes: This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. This configure run looks totally hosed. The line we're looking for is the one that attempts to detect MD5Update in libmd5: configure:7251: checking for MD5Update in -lmd5 No output? And then, later: checking for MD5Update in -lmd5... (cached) yes Cached to yes? What's this about? How exactly are you running `configure'? This test makes Wget think that it detected Solaris MD5 library: /* Define if we're using Solaris libmd5. */ #define HAVE_SOLARIS_MD5 1
