Re: gettext and charsets

2003-11-05 Thread Karl Eichwalder
Hrvoje Niksic [EMAIL PROTECTED] writes:

 Perhaps you could try posting to [EMAIL PROTECTED]?  Failing
 that, you might want to try at the address of the Free Translation
 Project and/or the Norwegian national team near you.

[EMAIL PROTECTED] is the preferred list for reporting gettext

Implementation issues can be discussed at
[EMAIL PROTECTED] (also read by Bruno Haible).

Re: some wget patches against beta3

2003-10-07 Thread Karl Eichwalder
Hrvoje Niksic [EMAIL PROTECTED] writes:

 As for the Polish translation, translations are normally handled
 through the Translation Project.  The TP robot is currently down, but
 I assume it will be back up soon, and then we'll submit the POT file
 and update the translations /en masse/.

It took a little bit longer than expected but now, the robot is up and
running again.  This morning (CET) I installed b3 for translation.

Re: wget 1.8.x bulgarian translation

2002-02-25 Thread Karl Eichwalder

Vesselin Markov [EMAIL PROTECTED] writes:

 I wrote a bulgarian localization of Wget 1.8.1 which 
 i hope you'll accept. I am sending


Thanks a lot -- but please consider to join the Bulgarian translation


At the moment, Yassen Roussev is listed to translate wget but I guess
will appreciate help!

For more info, please visit:

 Free Translation Project:

Linux frechet 2.4.16-4GB #1 Wed Dec 12 13:42:58 GMT 2001 i686 unknown
  8:52am  up 26 days, 22:14, 13 users,  load average: 1.41, 1.45, 2.33
Karl Eichwalder  home: [EMAIL PROTECTED]

Re: wget 1.8.1: po/el.po update

2002-02-20 Thread Karl Eichwalder


 I translated the few remaining messages in the greek po file.
 Here are the diffs.

Please, try to get in contact with the last translator (cf. the Cc:) to
avoid duplicate work.  Thanks a lot!

 Thanks for writing and maintaining such a great tool.

Linux frechet 2.4.16-4GB #1 Wed Dec 12 13:42:58 GMT 2001 i686 unknown
  3:34pm  up 21 days,  4:55, 13 users,  load average: 0.21, 0.22, 0.20
Karl Eichwalder  home: [EMAIL PROTECTED]

Re: Users and languages, was: Uncoupling translations from source

2001-12-10 Thread Karl Eichwalder


 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

Re: Uncoupling translations from source

2001-12-09 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 Why is unpacking two tar files instead of one a complication?

At the moment, it just wont work (gettext limitation); nevertheless we
are thinking about the possibility to offer separate translation update
packages.  For it's still essential to ship most recent translations
with every regular package release.

 (And that's provided you want translations in the first place; many
 people don't.)

These people are experts.  They can go directly to the CVS and download
what they need.  Please note, according to my experiences Americans
can stand the translations coming with tar.gz files; only advanced
European users (so called experts) don't like them.

 There are packages that are much more complicated to install than

The difference is translation are not essential -- thus people will
tend to ignore them if additional efforts are involved.  This might
change in the future but for now that's the truth.

[EMAIL PROTECTED] (work) / [EMAIL PROTECTED] (home):  |  |  ,__o
Free Translation Project:|_-\_, |   (*)/'(*)

Re: Uncoupling translations from source

2001-12-09 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 How can gettext know how many tar files were involved in creating a
 source tree?

Use gettext default files (.am, .in, .m4) you must edit some files
( or po/LINGUAS) and run automake/autoconf to make the new
languages available.

 Why is it essential?  I can see how it could be useful, but why

We (= people involved in the GNU project) think without localization
software is of limited use for the majority of (new) users worldwide.
As documentation is essential so are translations.

 Not necessarily.  Some of them only speak English (see Americans
 from before), but some simply never use translations.

Yes, but I never encoutered an American who felt annoyed by shipping
the translation overhead with regular .tar.gz files.  I'm sure we'll
work out an improved way to distribute translations when more an more
translations will become available -- but for now it's better not to
change the default way to ship them.

 For example, I never use translated programs, although I approve of
 and take part in the translation effort.

I know and I appreciate your POV and your efforts a lot.  All your
proposals are not lost (I've saved them for the future).

 Those people who do want translations will invest the (tiny)
 additional effort and will get them.

I think different :)  At least it will take some time to adjust all
involved pieces: gettext, the robot, every single software package,
translators, maintainers, distributors, etc.  Yes, it's possible to do
-- but it just will take time.

[EMAIL PROTECTED] (work) / [EMAIL PROTECTED] (home):  |  |  ,__o
Free Translation Project:|_-\_, |   (*)/'(*)

Re: English vs Locale

2001-10-29 Thread Karl Eichwalder

Marc St-Jacques [EMAIL PROTECTED] writes:

 When I type 'wget --help', only one tenth of it's output is in my locale's 
 language, in this case, French.
 Now this is a package that came with Mandrake 8.1.  Is it an overall problem 
 with wget or is Mandrake at fault here ?

The official release 1.7 lacks several translations.  By now, it's
complete; cf.:

I'd like to see a new release (1.7.1) with all translations updated.

Linux frechet 2.4.10-4GB #1 Mon Oct 15 17:27:24 GMT 2001 i686 unknown
 11:14am  up 3 days, 22:55,  6 users,  load average: 0.31, 0.12, 0.08
Karl Eichwalder  home: [EMAIL PROTECTED]

Re: translating into hungarian

2001-10-01 Thread Karl Eichwalder

Szasz Pal [EMAIL PROTECTED] writes:

 I like very mutch the wget porhram, and i obsereved, that it's not yet 
 translated into hungarian.
 I could try to translate it. Are you interested in it?

Great!  Please, consider to join the Translation Project:

Special translator info is available as:

 I'm not on the list, so please answer to to the following address:

It's the best to use the Reply-To: header for this purpose.

Linux frechet 2.4.7-4GB #1 Tue Jul 24 15:07:28 GMT 2001 i686 unknown
  9:59am  up 12 days, 22:14,  7 users,  load average: 0.14, 0.24, 0.12
Karl Eichwalder  home: [EMAIL PROTECTED]

Re: wget/src/ftp-ls.c: tiny typo

2001-06-04 Thread Karl Eichwalder

R.I.P. Deaddog [EMAIL PROTECTED] writes:

 For separating translation as another tarball, there's another risk of
 people putting different versions of source and translation together,
 not to mention the additional time needed for packaging.

Yes, this disaster happens for manpages all the time ;-(

 But of course it's up to developers to decide which method costs less
 and which costs more.

Yes.  Using the TP and its defaults isn't mandatory.  Of course it helps
to reduce the organizational(?) overhead if you try to use the TP setup.

Hrvoje Niksic [EMAIL PROTECTED] writes:

 I didn't mean that the translators were lazy or anything like that.
 By too late I meant that `wget.pot' in the current tree is already
 different from `wget-1.7-pre1.pot'!

That's life and translators are used to it.  From pre-release to
pre-release the message will stabilize.  Whenever there are message
string related changes we can install a new .pot file; just announce it
to us ([EMAIL PROTECTED]).  For the moment we still have to
approve such a request; it's on the improvement list to let install
maintainers new versions on their own.

Even if a language file isn't 100% complete a translation is useful.

 Another unfortunate misunderstanding: your asking for the POT file was
 perfectly fine, and I am grateful that you did.

Thanks :)

 The problem on my side is that I don't know what to do with 1.6

Hard to tell.  Put them into the wget CVS please.  And if you think it's
useful, release them together with wget 1.6 as wget-1.6.1 (like some
GNOMErs do; KDE people do the same AFAIK).

 just like I don't know what to do with 1.7-pre1 translations which are
 already out of date.

Add them to the CVS, please, and distribute them together with the next
wget release..

  Next time I'll wait whether you'll send an request to
 I didn't even know about that address.  I'll have to, once again, read
 up on the exact TP procedures.

Good idea.  You can start here:

work : [EMAIL PROTECTED]  |   ,__o
 : | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)

Re: wget/src/ftp-ls.c: tiny typo

2001-06-04 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 But...  The Wget 1.6 branch exists, and contains minor bugfixes,
 including changed strings.  (I gave up on 1.6.1 because of the
 imminent 1.7 release.)

Reasonable.  Then there's no need to care about still incoming
translations for 1.6.

 If I were to release 1.6.1 with the 1.6 translations, they would once
 again be incorrect.

You could ask [EMAIL PROTECTED] to ask the translations team
to have a look at the 1.6.1 message files.

work : [EMAIL PROTECTED]  |   ,__o
 : | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)

Re: wget/src/ftp-ls.c: tiny typo

2001-06-03 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 The strategy of re-releasing the whole package shares many of the
 flaws with the strings freeze strategy.  Specifically, I would be
 tempted to include bug fixes and string changes into such a
 re-released package.

Would be okay with me.  Just increase the version number (reserve the
first 3 numbers for programming realated issue and the 4th number for

1.7 The normal forthcoming release.

Then Only translations added


1.7.1   Release with bug fixes (and with new translations)

If it was needed to release 1.7.1 and further translations will arrive,
release That's the bug fix release with new translations.

 Unbundling translations has the additional benefit that people who
 don't care about translations (*gasp*) never need to deal with them.

We'll go this way sooner or later; IMO, the time doesn't have come.

 I really cannot understand how an additional TAR file would be an
 irritation to *everyone*.  The programmers, the translators, and the
 users would never even notice it!

Might be part of the problem.  programmers just get familiar with how
it works; maybe, they are not fond of the idea to maintain additional
tar files.  At the moment it's guaranteed it just works (widely
supported by automake, autoconf and gettext plus the robot).

 Compare that to the current situation where all of Wget's translations
 except the Croatian one are *guaranteed* to be incomplete!

Not necessarily.  Interested parties can have a look at and fetch updated files.

 Francois Pinard has dismissed my idea out of hand.  Sometimes I get
 the feeling that the Translation Project is extremely closed to new

No, not at all.  But it's a lot of work to arrange all the
infrastructure for all the i18n/l10n business.  At the moment we (Martin
v. Löwis and me, with background support by François) are trying to get
the whole project fly again: we've to test gettext, support the teams,
support new translators who want to establish a new team, sort out
copyright issues, add new software packages, keeping track of changing
email addresses and web and FTP references, update/fix the robot
software.  Then we'll have to update the texts of François' website and
we've to work out a scheme to hand out more work to the so called team
leaders (that's a big permission/security problem).

If this is done we can start to change the workflow.  Of course, we can
start now to collect all ideas and to assign priorities.

 Several years ago when I decided to not bundle gettext with Wget, it
 was considered almost unthinkable.  Today it is becoming an
 established practice.

;)  For Linux this might work...

 Sometimes I wish the TP people would listen to suggestions with a more
 attentive ear.

Be assured, we do.  Of course, François also did listen.  Actually, he
collected and sorted all the different mails (proposals, support
requests, etc.); all things are in a pretty good condition as handed out
by François.  Now we're trying to cut down the backlog.  I'm sure this
will not take too long.

I guess I can start to think seriously about improvement proposals the
next month.  This doesn't mean the improvement will come true 2 months
later ;)

Hope this helps for the moment.

work : [EMAIL PROTECTED]  |   ,__o
 : | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)

Re: wget/src/ftp-ls.c: tiny typo

2001-06-03 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 Maybe a more in-depth investigation is needed?  I really don't see a
 single reason why the ls/sed trick Wget employs shouldn't work for any
 other Autoconf-based tool.

Using wildcards is inherently dangerous.  I think all source files and
all installable files ought to be listed explicitly.

work : [EMAIL PROTECTED]  |   ,__o
 : | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)

wget/src/ftp-ls.c: tiny typo

2001-06-02 Thread Karl Eichwalder

2001-06-03  Karl Eichwalder  [EMAIL PROTECTED]

* ftp-ls.c (ftp_parse_ls): Fix typo.

--- wget/src/ftp-ls.c.~1.18.~   Sun Jun  3 07:32:03 2001
+++ wget/src/ftp-ls.c   Sun Jun  3 07:33:39 2001
@@ -785,7 +785,7 @@
   return ftp_parse_unix_ls (file, TRUE);
   logprintf (LOG_NOTQUIET, _(\
-Usupported listing type, trying Unix listing parser.\n));
+Unsupported listing type, trying Unix listing parser.\n));
   return ftp_parse_unix_ls (file, FALSE);

Diff finished at Sun Jun  3 07:34:43

work : [EMAIL PROTECTED]  |   ,__o
 : | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)

translations 1.7? (Re: Question)

2001-05-30 Thread Karl Eichwalder

On 30 May 2001, Hrvoje Niksic wrote:

 Yes, but you need the version 1.7, which is about to be released.

If a pre-release is available I'd like to install the .pot file of this
pre-release package on the Translation Robot site

Of course, I can wait if you think it's too early.


Re: wget.pot and translations

2001-05-08 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 Since the other methods have obviously failed, here is the pot file:

I'm very sorry about all the trouble you all have had with the
Translation Robot.  Now I've learnt from François how to feed this
nice system (at least, it looks as if I'm able to update existing

I just run wget-1.6 through the robot (mainly for real live testing).
Now it should be possible to submit .pot files as usual (human
intervention by me (or Martin v. Löwis) is still needed to put those
files in place -- we'll try our best).  Martin will mainly take care
about the technical details; I'll try to do the paper work, files
processing and the like.

Thanks again to François Pinard for implementing and establishing this
great system (he's still acting in the background; this will help a

All the best,

Linux Frechet 2.2.18 #1 Fri Jan 19 22:10:35 GMT 2001 i686 unknown
  7:54pm  up 5 days,  2:27, 11 users,  load average: 0.04, 0.03, 0.00
Karl Eichwalder  home: [EMAIL PROTECTED]

Re: Support for DESTDIR while installing

2001-01-20 Thread Karl Eichwalder

Hrvoje Niksic [EMAIL PROTECTED] writes:

 Only if you haven't run `make' before.  With Wget, it's perfectly safe
 to say:
 $ make   # assumes regular prefix
 ... build finishes ...
 $ make install prefix=/something/different   # same as DESTDIR=...

Okay, but it isn't userfriendly to ask the user to use different values
for the same variable at different stages of the configuration,
compilation and installation precess.

Yes, I admit wget fulfills the Coding Standards as written; but I see
possibilities to improve it even more.

work : [EMAIL PROTECTED]  |   ,__o
 : | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)

Re: Support for DESTDIR while installing

2001-01-20 Thread Karl Eichwalder

Russ Allbery [EMAIL PROTECTED] writes:

 Karl Eichwalder [EMAIL PROTECTED] writes:
  Hrvoje Niksic [EMAIL PROTECTED] writes:

  $ make   # assumes regular prefix
  ... build finishes ...
  $ make install prefix=/something/different   # same as DESTDIR=...

  Okay, but it isn't userfriendly to ask the user to use different values
  for the same variable at different stages of the configuration,
  compilation and installation precess.

 No, every package *should* support the above sequence.

Yes.  Look at Tom's mail; he confirms it's easy to support the prefix
and the DESTDIR way at the same time ;)  The hard part is to get the
prefix way right.

 It's pretty much the standard way of doing this, and tons of package
 management software in the class stow uses this or something like it
 (I don't know if stow in particular does, but I know that a lot of
 stow-like things do).

Yes, the nice thing with DESTDIR is you only have to say:

./configure --prefix=/gnu/usr --sysconfdir=/gnu/etc
make DESTDIR=/var/tmp/package-root install

And without DESTDIR support you would have to repeat
"/var/tmp/package-root" for every directory:

./configure --prefix=/gnu/usr --sysconfdir=/gnu/etc
make prefix=/var/tmp/package-root/gnu/usr \
 sysconfdir=/var/tmp/package-root/gnu/etc \

and you've to hope the rules are carefully arranged and will not touch
files during the install step again (in this regard wget is a perfect
package, too!).

work : [EMAIL PROTECTED]  |   ,__o
 : | _-\_,
home : [EMAIL PROTECTED] |(*)/'(*)