Date: Fri, 03 Apr 2009 12:59:46 -0400 From: Chuck Robey <chuckr@telenix.org> To: Alexander Leidinger <Alexander@Leidinger.net> Cc: FreeBSD Arch <arch@freebsd.org>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Marcel Moolenaar <xcllnt@mac.com>, Gordon Tetlow <gordon@tetlows.org> Subject: Re: On errno Message-ID: <49D64082.9060202@telenix.org> In-Reply-To: <20090402114916.170547o692pg252c@webmail.leidinger.net> References: <4915.1238655116@critter.freebsd.dk> <20090402114916.170547o692pg252c@webmail.leidinger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Alexander Leidinger wrote: > Quoting Poul-Henning Kamp <phk@phk.freebsd.dk> (from Thu, 02 Apr 2009 > 06:51:56 +0000): > >> In message <20090402084616.19846py8s75ogp44@webmail.leidinger.net>, >> Alexander Leidinger writes: >> >>> I agree with your general opinion about i18n and think that it is not >>> a matter of workforce, it's a matter of feasability. As soon as we >>> have the infrastructure, translations will show up "soonish". It's not >>> "if", it's "when". >> >> And once the novelty has worn off, we are left, as so many other >> operating systems, with at best 70% translation into each language. > > If I adapt your reasoning to our docs, we need to delete all our > translations and only keep the english one. Look at the subject: wasn't this (really clearly) a discussion of error strings, and not strings in general? Aren't there always error codes available in number form, so that any user could easily translate to their own language choice, even if it's unique, or even composed of bits and pieces of 5 different languages? Using numbers allows great flexibility, using strings just complicates things mightily. Some of the stuff I've read, about supplying error subcodes makes sense, but trying to extend this argument to *all* strings is outside the pale of the argument, isn't it? Besides, application translations is already being done pretty well, KDE is an example of that, and that's a long way from dealing with our kernel. > > If you are pissed off by the missing 30%, submit a patch or stick with > english. That's an adaption of what we tell to people when they complain > about missing stuff in unmaintained areas of src/ports. Alternatively we > can disconnect languages from the system if we think there's not enough > coverage. Above you also average the interest over all languages, an > generalization which doesn't hold, see below. > > You assume we need to ship with 100% coverage in all languages. For a > person which only uses 40% of one specific language, and this 40% are > covered by 100%, it does not matter. If those 40% are a major part to > allow to earn a person an income to feed childs and the relative other, > great. > > Note, people which set their LANG to something else already get only a > xx% translated system, e.g. KDE/GNOME are displaying a lot of stuff in > other languages, but stuff which is comming from FreeBSD itself is in > english, so we have the situation you describe already and users are > used to it (don't tell me this does not apply because we only program an > OS, it applies, as for an user it does not matter what we program, _he_ > is using a complete system consisting of an OS and other stuff, not only > the OS without anything else). They do their best, they enjoy their > native language where it is available and try to handle english when it > is not available. > > At some point I expect that we have some strong languages, and some not > so strong languages. Which ones are which and how many languages we > would have... I assume the trends regarding this for the handbook can > give a hint. > > Bye, > Alexander. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknWQIIACgkQz62J6PPcoOnW3ACdFdiokRdZZX4386RM3X9wdsuY SowAoJtuh6EgBc3qP8ADfduFm+cP3fCV =0ocL -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49D64082.9060202>