Re: gettext and charsets
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 bugs. Implementation issues can be discussed at [EMAIL PROTECTED] (also read by Bruno Haible).
Re: some wget patches against beta3
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
Vesselin Markov [EMAIL PROTECTED] writes: I wrote a bulgarian localization of Wget 1.8.1 which i hope you'll accept. I am sending wget-1.8.1-BG/po/bg.po wget-1.8.1-BG/po/bg.gmo wget/share/locale/bg/LC_MESSAGES/wget.mo Thanks a lot -- but please consider to join the Bulgarian translation team: [EMAIL PROTECTED] At the moment, Yassen Roussev is listed to translate wget but I guess will appreciate help! For more info, please visit: Free Translation Project: http://www.iro.umontreal.ca/contrib/po/HTML/ -- 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 work: [EMAIL PROTECTED] Karl Eichwalder home: [EMAIL PROTECTED]
Re: wget 1.8.1: po/el.po update
[EMAIL PROTECTED] writes: 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 work: [EMAIL PROTECTED] Karl Eichwalder home: [EMAIL PROTECTED]
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/
Re: Uncoupling translations from source
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 that. 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): | http://www.suse.de/~ke/ | ,__o Free Translation Project:|_-\_, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)
Re: English vs Locale
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.: http://www.iro.umontreal.ca/contrib/po/HTML/domain-wget.html 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 work: [EMAIL PROTECTED] Karl Eichwalder home: [EMAIL PROTECTED]
Re: wget/src/ftp-ls.c: tiny typo
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 translations, 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 [EMAIL PROTECTED] 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: http://www.iro.umontreal.ca/contrib/po/HTML/maintainers.html -- work : [EMAIL PROTECTED] | ,__o : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
Re: wget/src/ftp-ls.c: tiny typo
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 : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
Re: wget/src/ftp-ls.c: tiny typo
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 translations): 1.7 The normal forthcoming release. Then 1.7.0.1 Only translations added or 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 1.7.1.1 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 www.iro.umontreal.ca 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 ideas. 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 : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
Re: wget/src/ftp-ls.c: tiny typo
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 : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
wget/src/ftp-ls.c: tiny typo
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); default: 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 : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)
translations 1.7? (Re: Question)
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 (http://www.iro.umontreal.ca/contrib/po/HTML/). Of course, I can wait if you think it's too early. Karl
Re: wget.pot and translations
Hrvoje Niksic [EMAIL PROTECTED] writes: Since the other methods have obviously failed, here is the pot file: http://jagor.srce.hr/~hniksic/wget/wget.pot 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 projects). 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 lot!). All the best, Karl -- 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 work: [EMAIL PROTECTED] Karl Eichwalder home: [EMAIL PROTECTED]
Re: Support for DESTDIR while installing
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 : http://www.suse.de/~ke/ | _-\_, home : [EMAIL PROTECTED] |(*)/'(*)