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: 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/
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: 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
Re: Uncoupling translations from source
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 (configure.in 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 > essential? 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): | http://www.suse.de/~ke/ | ,__o Free Translation Project:|_-\_<, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)
Re: Uncoupling translations from source
[EMAIL PROTECTED] writes: > Maybe you wanted to say that many Europeans > speak English so well, that they do not need translations? No, these users are liberal (according to my experiences); they don't feel offended when translations are bundled with regular source files. -- [EMAIL PROTECTED] (work) / [EMAIL PROTECTED] (home): | http://www.suse.de/~ke/ | ,__o Free Translation Project:|_-\_<, http://www.iro.umontreal.ca/contrib/po/HTML/ | (*)/'(*)
Re: Uncoupling translations from source
Hi listers! Karl wrote: > 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. I do not want to start a flame war or anything, but am I the only European who feels discriminated against by that sentence? If that was not your intention (what I think, as you are also European), then what did you want to express? Maybe you wanted to say that many Europeans speak English so well, that they do not need translations? Regards Jens -- GMX - Die Kommunikationsplattform im Internet. http://www.gmx.net
Re: Uncoupling translations from source
Karl Eichwalder <[EMAIL PROTECTED]> writes: > 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); Can you elaborate on this? How can gettext know how many tar files were involved in creating a source tree? > 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. Why is it essential? I can see how it could be useful, but why essential? >> (And that's provided you want translations in the first place; many >> people don't.) > > These people are experts. Not necessarily. Some of them only speak English (see "Americans" from before), but some simply never use translations. For example, I never use translated programs, although I approve of and take part in the translation effort. > 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. I think there has been a slight misunderstanding here. I'm not doing this to reduce the download size, or to appease people who dislike translations. The primary reason is to make sure that you always get the freshest translations along with the source, or no translations at all. The "savings" for the people who dislike translations are just a nice side-effect, nothing more. >> 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. But I consider that a feature. Those people who do want translations will invest the (tiny) additional effort and will get them.
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: Uncoupling translations from source
"Martin v. Loewis" <[EMAIL PROTECTED]> writes: >> > If they were, anybody with write access could integrate them >> >> But not after the release, because after the release the strings >> already change. > > Are you saying you will not integrate catalogs that you receive after > the release into the CVS? No, that's not what I'm saying, although I can now see how it could have sounded that way. I'm saying that after the release it's already late for *those* catalogs to fix a "missing catalog" problem with the release. > Please reconsider; translations are still useful even if some > strings change. I know that. >> > There will be always a next release. >> >> Not with the same messages. And *that* is the problem my proposal >> solves. > > It doesn't really solve it: It complicates the installation > procedure for anybody using your package. Why is unpacking two tar files instead of one a complication? (And that's provided you want translations in the first place; many people don't.) There are packages that are much more complicated to install than that.
Re: Uncoupling translations from source
> > If they were, anybody with write access could integrate them > > But not after the release, because after the release the strings > already change. Are you saying you will not integrate catalogs that you receive after the release into the CVS? Please reconsider; translations are still useful even if some strings change. > > There will be always a next release. > > Not with the same messages. And *that* is the problem my proposal > solves. It doesn't really solve it: It complicates the installation procedure for anybody using your package. I can see now what you are trying to achieve, and perhaps it solves the problem that you have (that translation must be completely up-to-date); I think this procedure will cause new problems. We probably can't get much further with this than, so as I said before: Do whatever you feel is good for you and your users. Kind regards, Martin
Re: Uncoupling translations from source
"Martin v. Loewis" <[EMAIL PROTECTED]> writes: > Many of them. For example, bash has been translated a long time ago, > into different languages (before 2.0 was approaching). However, the > current bash still ships without any translations, since none of the > distributors has invested enough time to integrate the various > pieces (which consist of a patch to the bash sources, and the actual > files from the TP). This sounds very different from what I intend to do: I will personally make sure that the translations are usable by just unpacking the two tar files. No patching needed; no unsafety incurred. Note that I *like* the translations and don't want them to go away. I simply think they should be *distributed* at their own schedule, which is different from one of the release. > Are you saying that translations are not maintained in the CVS? I'm not. > If they were, anybody with write access could integrate them But not after the release, because after the release the strings already change. >> > Furthermore, if this turns out to be an unacceptable burden: >> > Couldn't the process of integrating translations be automated? >> >> Not after the release. > > There will be always a next release. Not with the same messages. And *that* is the problem my proposal solves. >> > Translators can (and do) take all the time they need. >> >> Not after the release. > > I don't understand. When you make a release, won't you start working > on the next version. And can't you integrate the translations you > have then? See above. >> Those translations end up never being integrated into the source, >> and the fear you expressed in your first paragraph in fact comes to >> pass: the user never see the new translations. > > Again, I don't understand. If you can't integrate the new > translations, just integrate the old ones (which you got late for > the previous release). More of the same misunderstanding. Again, please see above. >> Of course. That's exactly why I proposed the uncoupling: to have >> even less reason to tie the schedules simply because you can "plug" >> a new version of the translations any time you want, before or >> after compiling. > > Well, I'm not going to argue with you of how you package your > software. I'm just saying that I cannot see the reason for doing so. And I'm hoping to explain the reasons. Obviously I'm not getting across very well. :-( >> My change guarantees that any language whose translators care about >> translating Wget will get its translation along with everyone >> else's, only later. > > But they can do that today: Everybody can download the translations > immediately after they are released by the translator - no need to > wait for you to package them in a tar file. Yes, but not from the same place they've downloaded Wget from. And not in a convenient bundle, like they get from the Wget sources. I'm trying to make downloading the most recent translations just as easy as downloading the ones that came with the release. > Again, I think the risk of no translation being distributed at all > is high enough not to pursue this idea. If you think translators > should see the updated catalogs on the wget download area, I'd > recommend to produce wget-1.8.1, etc. Wget 1.8.1 is likely to exist, but with new messages. Issuing new Wget releases for the sake of translation is the burden I mentioned before. I would like not to have to do that, but to have someone just upload the latest translations of Wget 1.8 to the GNU site.
Re: Uncoupling translations from source
> > Please reconsider this change. I believe it will result in no > > translation being distributed at all to users for some distributors, > > since they will fail to integrate the translations. > > Is there a precedence for this? And even when distributions make > mistakes, they seem to be willing to correct them. Many of them. For example, bash has been translated a long time ago, into different languages (before 2.0 was approaching). However, the current bash still ships without any translations, since none of the distributors has invested enough time to integrate the various pieces (which consist of a patch to the bash sources, and the actual files from the TP). There is a number of other packages which don't use our translations; in no case, any distributor I know has actually worked on integrating them into the distribution. > > Can't that be handled by a volunteer as well, with the current > > procedures > > No, because currently the translations are integrated with the > release, so new translations require a new release. Issuing a new > release can only be done by the maintainer (or a release coordinator), > not by a translation volunteer. Are you saying that translations are not maintained in the CVS? If they were, anybody with write access could integrate them, and the release coordinator would just pick them up. I cannot see why the release coordinator would actively need to integrate the translations. > > Furthermore, if this turns out to be an unacceptable burden: > > Couldn't the process of integrating translations be automated? > > Not after the release. There will be always a next release. > >> * Give the translators more time to translate the packages, while > >> allowing the faster ones to react immediately. For example, the > >> first version of the translations tarball can be issued one week > >> after the release, the second version a week after that, and then as > >> a new translation arrives. > > > > Translators can (and do) take all the time they need. > > Not after the release. I don't understand. When you make a release, won't you start working on the next version. And can't you integrate the translations you have then? > Those translations end up never being integrated into the source, > and the fear you expressed in your first paragraph in fact comes to > pass: the user never see the new translations. Again, I don't understand. If you can't integrate the new translations, just integrate the old ones (which you got late for the previous release). > > There is absolutely no reason to tie the schedules: > > Of course. That's exactly why I proposed the uncoupling: to have even > less reason to tie the schedules simply because you can "plug" a new > version of the translations any time you want, before or after > compiling. Well, I'm not going to argue with you of how you package your software. I'm just saying that I cannot see the reason for doing so. > > Just integrate all catalogs that you receive by the time of a > > release. Whoever is late, is late - there will be always a next > > release, which will include the late translations. > > The next release will have new strings, which will again not be > translated by everyone. Our experience is that many strings will stay as they are. Some will change, but for packages doing minor releases, the next minor releases will have so few string changes that most users won't notice. > Your method *guarantees* that many translations will be behind. If you distribute pre-releases to translators, some translations will be behind very very little. > My change guarantees that any language whose translators care about > translating Wget will get its translation along with everyone > else's, only later. But they can do that today: Everybody can download the translations immediately after they are released by the translator - no need to wait for you to package them in a tar file. So I cannot see any improvement over the current state. > There is a lot wrong with them being outdated *after* the release, > and *after* the updated translations come in. That's where > wget-1.8-translations-2.tar.gz would come in. And -3, and -4, and so > on. Again, I think the risk of no translation being distributed at all is high enough not to pursue this idea. If you think translators should see the updated catalogs on the wget download area, I'd recommend to produce wget-1.8.1, etc. > True, but last time I checked, the TP doesn't offer the translations > in the form of an easily downloadable `.tar.gz' file. I would like > such a file, so that it can be either "plugged" into an unpacked > release directory, or installed to the running system, possibly using > a script. I'd be willing to provide such a file. Just let me know what directory and file structure you'd like to see in it. > > There is a relatively reliable way to catch such errors: You merge > > each translations with the official PO template of the rel
Re: Uncoupling translations from source
"Martin v. Loewis" <[EMAIL PROTECTED]> writes: > Please reconsider this change. I believe it will result in no > translation being distributed at all to users for some distributors, > since they will fail to integrate the translations. Is there a precedence for this? And even when distributions make mistakes, they seem to be willing to correct them. >> * Relieve the maintainer of the burden of handling the translations. >> It will be possible for the translations to be handled by a >> volunteer, or by the Translation Project, if it so chooses. Or a >> new translation tarball could even be created by having a script >> wget the available files from the TP and create the distribution >> automatically. > > Can't that be handled by a volunteer as well, with the current > procedures No, because currently the translations are integrated with the release, so new translations require a new release. Issuing a new release can only be done by the maintainer (or a release coordinator), not by a translation volunteer. > Also, if you are going to produce an additional package: Doesn't > this add *more* work. Not if the additional package is created automatically, and especially not if it's handled by someone else. > Furthermore, if this turns out to be an unacceptable burden: > Couldn't the process of integrating translations be automated? Not after the release. >> * Give the translators more time to translate the packages, while >> allowing the faster ones to react immediately. For example, the >> first version of the translations tarball can be issued one week >> after the release, the second version a week after that, and then as >> a new translation arrives. > > Translators can (and do) take all the time they need. Not after the release. Those translations end up never being integrated into the source, and the fear you expressed in your first paragraph in fact comes to pass: the user never see the new translations. > There is absolutely no reason to tie the schedules: Of course. That's exactly why I proposed the uncoupling: to have even less reason to tie the schedules simply because you can "plug" a new version of the translations any time you want, before or after compiling. > Just integrate all catalogs that you receive by the time of a > release. Whoever is late, is late - there will be always a next > release, which will include the late translations. The next release will have new strings, which will again not be translated by everyone. Your method *guarantees* that many translations will be behind. My change guarantees that any language whose translators care about translating Wget will get its translation along with everyone else's, only later. >> * Remove the need for a "string freeze", > > Ignore the concept of "string freeze" if it doesn't work for > you. There is nothing wrong with translations being outdated at the > time of the release. There is a lot wrong with them being outdated *after* the release, and *after* the updated translations come in. That's where wget-1.8-translations-2.tar.gz would come in. And -3, and -4, and so on. > If you think you need to provide your users with updated catalogs, > you can *still* consider to provide the tar file of catalogs, or you > could roll out another release, just to include the updated > translations. That sounds like an interesting proposal. Still, to me it sounds even better in that case to go ahead and completely separate the two distributions. I would like to see what other people think about it. > That's an important point. Users looking for updated translations can > already do that very easily: They just need to go to the TP wget > page. True, but last time I checked, the TP doesn't offer the translations in the form of an easily downloadable `.tar.gz' file. I would like such a file, so that it can be either "plugged" into an unpacked release directory, or installed to the running system, possibly using a script. >> * Allow the users who don't need or want I18N (sometimes referred to >> as "Americans") to download Wget without getting the translations at >> all. If they change their minds, they can still get the >> translations later, and install them. > > Is that really an issue? It's not an "issue", but it's what I consider a nice side-effect. > As for the security issue: We recently found that there is a chance > that the printf strings are not correctly reflected in the > translations. msgfmt is supposed to catch this, provided there is a > c-format comment on the message. If that gets lost, wget may crash > in a translated version if such a buggy catalog is used. OK. > There is a relatively reliable way to catch such errors: You merge > each translations with the official PO template of the release, and > then only msgfmt the merge results. If c-format is used properly > everywhere in the template, the problem will be detected. That > requires that msgfmt is invoked each time a
Re: Uncoupling translations from source
Hi, In my opiníon, this is a very good idea. I am a german, but I don't like to be not asked to install other languages than english, since the translations are sometimes not too good. greets -jan
Re: Uncoupling translations from source
Hi Hrvoje and everyone on the list, I think that sounds like a good idea. In fact, I thought so when this topic came up for the first time a few days ago. However, I might not be typical, as I really do not care about a translation as long as English remains wget's first language. (And no, I am not "American" ;) ) What I care about are added features and killed bugs, so my preference is clear: More development time by separating. So, that's my opinion, looking forward to read others'. CU Jens http://www.jensroesner.de/wgetgui/
Re: Uncoupling translations from source
> I'm seriously considering a change in how Wget translations are > distributed: I want to uncouple translations from the source. First > I'll explain what I have in mind, and then I'll give my reasons. I > would like to hear whether you think this is a good idea, and why. Please reconsider this change. I believe it will result in no translation being distributed at all to users for some distributors, since they will fail to integrate the translations. Also, there are security implications that need consideration. > * Relieve the maintainer of the burden of handling the translations. > It will be possible for the translations to be handled by a > volunteer, or by the Translation Project, if it so chooses. Or a > new translation tarball could even be created by having a script > wget the available files from the TP and create the distribution > automatically. Can't that be handled by a volunteer as well, with the current procedures (assuming you find one)? I don't know how wget is maintained, but I hope it would be possible to provide CVS write access to that volunteer. Also, if you are going to produce an additional package: Doesn't this add *more* work. Furthermore, if this turns out to be an unacceptable burden: Couldn't the process of integrating translations be automated? > * Give the translators more time to translate the packages, while > allowing the faster ones to react immediately. For example, the > first version of the translations tarball can be issued one week > after the release, the second version a week after that, and then as > a new translation arrives. Translators can (and do) take all the time they need. There is absolutely no reason to tie the schedules: Just integrate all catalogs that you receive by the time of a release. Whoever is late, is late - there will be always a next release, which will include the late translations. > * Remove the need for a "string freeze", Ignore the concept of "string freeze" if it doesn't work for you. There is nothing wrong with translations being outdated at the time of the release. If you think you need to provide your users with updated catalogs, you can *still* consider to provide the tar file of catalogs, or you could roll out another release, just to include the updated translations. Again, there is absolutely no need to do that, if you don't want. > * Allow the users a simple way to update the translations on a running > system. That's an important point. Users looking for updated translations can already do that very easily: They just need to go to the TP wget page. Since they know that this is the place where to get updated translations immediately, they will do so if they are interested in the most recent catalogs - they will typically want to update more than one catalog. > * Allow the users who don't need or want I18N (sometimes referred to > as "Americans") to download Wget without getting the translations at > all. If they change their minds, they can still get the > translations later, and install them. Is that really an issue? As for the security issue: We recently found that there is a chance that the printf strings are not correctly reflected in the translations. msgfmt is supposed to catch this, provided there is a c-format comment on the message. If that gets lost, wget may crash in a translated version if such a buggy catalog is used. There is a relatively reliable way to catch such errors: You merge each translations with the official PO template of the release, and then only msgfmt the merge results. If c-format is used properly everywhere in the template, the problem will be detected. That requires that msgfmt is invoked each time a new catalog is being integrated. Regards, Martin
Uncoupling translations from source
I'm seriously considering a change in how Wget translations are distributed: I want to uncouple translations from the source. First I'll explain what I have in mind, and then I'll give my reasons. I would like to hear whether you think this is a good idea, and why. What: Uncouple the translations from the source in such a way that the *.po and the related *.gmo files are no longer distributed in the `wget-VERSION.tar.gz' archive. The po/ subdirectory of `wget-VERSION.tar.gz' will still contain the Makefiles and the infrastructure for NLS, including the `wget.pot' file -- in other words, everything except the actual translations. The translations will be shipped in a separate archive named `wget-VERSION-translations-N.tar.gz', in the same directory with the source archive. VERSION is the release of Wget, and N is the version of the translations distribution that corresponds to that Wget release, beginning with one and incremented with each new version of the translations tarball. The translations will only contain the `po/' directory and will unpack to `wget-VERSION/po/'. It will also contain MO files compiled with GNU gettext. In other words, unpacking both tarballs in the same location will produce the result equivalent to what you get after unpacking the current `wget-VERSION.tar.gz'. Why: * Relieve the maintainer of the burden of handling the translations. It will be possible for the translations to be handled by a volunteer, or by the Translation Project, if it so chooses. Or a new translation tarball could even be created by having a script wget the available files from the TP and create the distribution automatically. * Give the translators more time to translate the packages, while allowing the faster ones to react immediately. For example, the first version of the translations tarball can be issued one week after the release, the second version a week after that, and then as a new translation arrives. This means that the first version of the translation tarball will already contain the input from the faster translators. But unlike the traditional model, this will not leave users of languages with slower translators empty-handed; they simply need to wait for a week or two until their translation appears in the tarball. * Remove the need for a "string freeze", which can cause problems when very important messages need to be changed, and *still* don't guarantee that all the translators will have enough time to translate the package. * Allow the users a simple way to update the translations on a running system. * Allow the users who don't need or want I18N (sometimes referred to as "Americans") to download Wget without getting the translations at all. If they change their minds, they can still get the translations later, and install them. Q: I don't agree with this. Is your decision final, or will you take counter arguments into account? My decision is not final, and I would definitely like to encourage a discussion. Getting feedback about this from Wget users is one reason for sending this message. Q: Why change what has always worked? Because I am dissatisfied with how it has worked. Integrating PO files into the source tree detracts time that could be spent on development or answering bug reports. Some people find this loss negligible or acceptable, but I think differently. Besides, see the points above; each of them addresses an issue raised by users and developers over time. Q: But everyone else does it differently... Most of them do. But then again, the best way to effect a change is to lead the way. Q: But won't this make the translations harder to come by, and hence hurt the Translation Project? I don't think it will make a shred of difference. There are people who care about translations. There are people who don't. The latter will not download the translations, and will be none the worse for it. The former will either download the translation, or notice them missing and *then* download them from the same place they downloaded Wget from.
