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: 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
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: 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
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
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
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.
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.
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 new catalog is being integrated. So it's even more work for integrating catalogs.
