X-Git-Url: https://git.saurik.com/wxWidgets.git/blobdiff_plain/4f02408ec96dbb43a505aa2b4781ac943a32772c..bae2dc62af49b5a870bbabd9473a92921736a6f0:/docs/html/gettext/gettext_9.html diff --git a/docs/html/gettext/gettext_9.html b/docs/html/gettext/gettext_9.html new file mode 100644 index 0000000000..17c1200e8e --- /dev/null +++ b/docs/html/gettext/gettext_9.html @@ -0,0 +1,513 @@ +<HTML> +<HEAD> +<!-- This HTML file has been created by texi2html 1.54 + from gettext.texi on 25 January 1999 --> + +<TITLE>GNU gettext utilities - The Translator's View</TITLE> +<link href="gettext_10.html" rel=Next> +<link href="gettext_8.html" rel=Previous> +<link href="gettext_toc.html" rel=ToC> + +</HEAD> +<BODY> +<p>Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_8.html">previous</A>, <A HREF="gettext_10.html">next</A>, <A HREF="gettext_12.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>. +<P><HR><P> + + +<H1><A NAME="SEC56" HREF="gettext_toc.html#TOC56">The Translator's View</A></H1> + + + +<H2><A NAME="SEC57" HREF="gettext_toc.html#TOC57">Introduction 0</A></H2> + +<P> +GNU is going international! The Translation Project is a way +to get maintainers, translators and users all together, so GNU will +gradually become able to speak many native languages. + +</P> +<P> +The GNU <CODE>gettext</CODE> tool set contains <EM>everything</EM> maintainers +need for internationalizing their packages for messages. It also +contains quite useful tools for helping translators at localizing +messages to their native language, once a package has already been +internationalized. + +</P> +<P> +To achieve the Translation Project, we need many interested +people who like their own language and write it well, and who are also +able to synergize with other translators speaking the same language. +If you'd like to volunteer to <EM>work</EM> at translating messages, +please send mail to your translating team. + +</P> +<P> +Each team has its own mailing list, courtesy of Linux +International. You may reach your translating team at the address +<TT>`<VAR>ll</VAR>@li.org'</TT>, replacing <VAR>ll</VAR> by the two-letter ISO 639 +code for your language. Language codes are <EM>not</EM> the same as +country codes given in ISO 3166. The following translating teams +exist: + +</P> + +<BLOCKQUOTE> +<P> +Chinese <CODE>zh</CODE>, Czech <CODE>cs</CODE>, Danish <CODE>da</CODE>, Dutch <CODE>nl</CODE>, +Esperanto <CODE>eo</CODE>, Finnish <CODE>fi</CODE>, French <CODE>fr</CODE>, Irish +<CODE>ga</CODE>, German <CODE>de</CODE>, Greek <CODE>el</CODE>, Italian <CODE>it</CODE>, +Japanese <CODE>ja</CODE>, Indonesian <CODE>in</CODE>, Norwegian <CODE>no</CODE>, Polish +<CODE>pl</CODE>, Portuguese <CODE>pt</CODE>, Russian <CODE>ru</CODE>, Spanish <CODE>es</CODE>, +Swedish <CODE>sv</CODE> and Turkish <CODE>tr</CODE>. +</BLOCKQUOTE> + +<P> +For example, you may reach the Chinese translating team by writing to +<TT>`zh@li.org'</TT>. When you become a member of the translating team +for your own language, you may subscribe to its list. For example, +Swedish people can send a message to <TT>`sv-request@li.org'</TT>, +having this message body: + +</P> + +<PRE> +subscribe +</PRE> + +<P> +Keep in mind that team members should be interested in <EM>working</EM> +at translations, or at solving translational difficulties, rather than +merely lurking around. If your team does not exist yet and you want to +start one, please write to <TT>`gnu-translation@prep.ai.mit.edu'</TT>; +you will then reach the GNU coordinator for all translator teams. + +</P> +<P> +A handful of GNU packages have already been adapted and provided +with message translations for several languages. Translation +teams have begun to organize, using these packages as a starting +point. But there are many more packages and many languages for +which we have no volunteer translators. If you would like to +volunteer to work at translating messages, please send mail to +<TT>`gnu-translation@prep.ai.mit.edu'</TT> indicating what language(s) +you can work on. + +</P> + + +<H2><A NAME="SEC58" HREF="gettext_toc.html#TOC58">Introduction 1</A></H2> + +<P> +This is now official, GNU is going international! Here is the +announcement submitted for the January 1995 GNU Bulletin: + +</P> + +<BLOCKQUOTE> +<P> +A handful of GNU packages have already been adapted and provided +with message translations for several languages. Translation +teams have begun to organize, using these packages as a starting +point. But there are many more packages and many languages +for which we have no volunteer translators. If you'd like to +volunteer to work at translating messages, please send mail to +<SAMP>`gnu-translation@prep.ai.mit.edu'</SAMP> indicating what language(s) +you can work on. +</BLOCKQUOTE> + +<P> +This document should answer many questions for those who are curious +about the process or would like to contribute. Please at least skim +over it, hoping to cut down a little of the high volume of e-mail +generated by this collective effort towards GNU internationalization. + +</P> +<P> +Most free programming which is widely shared is done in English, and +currently, English is used as the main communicating language between +national communities collaborating to the GNU project. This very document +is written in English. This will not change in the foreseeable future. + +</P> +<P> +However, there is a strong appetite from national communities for +having more software able to write using national language and habits, +and there is an on-going effort to modify GNU software in such a way +that it becomes able to do so. The experiments driven so far raised +an enthusiastic response from pretesters, so we believe that GNU +internationalization is dedicated to succeed. + +</P> +<P> +For suggestion clarifications, additions or corrections to this +document, please e-mail to <TT>`gnu-translation@prep.ai.mit.edu'</TT>. + +</P> + + +<H2><A NAME="SEC59" HREF="gettext_toc.html#TOC59">Discussions</A></H2> + +<P> +Facing this internationalization effort, a few users expressed their +concerns. Some of these doubts are presented and discussed, here. + +</P> + +<UL> +<LI>Smaller groups + +Some languages are not spoken by a very large number of people, so people +speaking them sometimes consider that there may not be all that much +demand such versions of free software packages. Moreover, many people +being <EM>into computers</EM>, in some countries, generally seem to prefer +English versions of their software. + +On the other end, people might enjoy their own language a lot, and be +very motivated at providing to themselves the pleasure of having their +beloved free software speaking their mother tongue. They do themselves +a personal favor, and do not pay that much attention to the number of +people benefiting of their work. + +<LI>Misinterpretation + +Other users are shy to push forward their own language, seeing in this +some kind of misplaced propaganda. Someone thought there must be some +users of the language over the networks pestering other people with it. + +But any spoken language is worth localization, because there are +people behind the language for whom the language is important and +dear to their hearts. + +<LI>Odd translations + +The biggest problem is to find the right translations so that +everybody can understand the messages. Translations are usually a +little odd. Some people get used to English, to the extent they may +find translations into their own language "rather pushy, obnoxious +and sometimes even hilarious." As a French speaking man, I have +the experience of those instruction manuals for goods, so poorly +translated in French in Korea or Taiwan... + +The fact is that we sometimes have to create a kind of national +computer culture, and this is not easy without the collaboration of +many people liking their mother tongue. This is why translations are +better achieved by people knowing and loving their own language, and +ready to work together at improving the results they obtain. + +<LI>Dependencies over the GPL + +Some people wonder if using GNU <CODE>gettext</CODE> necessarily brings their package +under the protective wing of the GNU General Public License, when they +do not want to make their program free, or want other kinds of freedom. +The simplest answer is yes. + +The mere marking of localizable strings in a package, or conditional +inclusion of a few lines for initialization, is not really including +GPL'ed code. However, the localization routines themselves are under +the GPL and would bring the remainder of the package under the GPL +if they were distributed with it. So, I presume that, for those +for which this is a problem, it could be circumvented by letting to +the end installers the burden of assembling a package prepared for +localization, but not providing the localization routines themselves. + +</UL> + + + +<H2><A NAME="SEC60" HREF="gettext_toc.html#TOC60">Organization</A></H2> + +<P> +On a larger scale, the true solution would be to organize some kind of +fairly precise set up in which volunteers could participate. I gave +some thought to this idea lately, and realize there will be some +touchy points. I thought of writing to Richard Stallman to launch +such a project, but feel it might be good to shake out the ideas +between ourselves first. Most probably that Linux International has +some experience in the field already, or would like to orchestrate +the volunteer work, maybe. Food for thought, in any case! + +</P> +<P> +I guess we have to setup something early, somehow, that will help +many possible contributors of the same language to interlock and avoid +work duplication, and further be put in contact for solving together +problems particular to their tongue (in most languages, there are many +difficulties peculiar to translating technical English). My Swedish +contributor acknowledged these difficulties, and I'm well aware of +them for French. + +</P> +<P> +This is surely not a technical issue, but we should manage so the +effort of locale contributors be maximally useful, despite the national +team layer interface between contributors and maintainers. + +</P> +<P> +The Translation Project needs some setup for coordinating language +coordinators. Localizing evolving programs will surely +become a permanent and continuous activity in the free software community, +once well started. +The setup should be minimally completed and tested before GNU +<CODE>gettext</CODE> becomes an official reality. The e-mail address +<TT>`translation@iro.umontreal.ca'</TT> has been setup for receiving +offers from volunteers and general e-mail on these topics. This address +reaches the Translation Project coordinator. + +</P> + + + +<H3><A NAME="SEC61" HREF="gettext_toc.html#TOC61">Central Coordination</A></H3> + +<P> +I also think GNU will need sooner than it thinks, that someone setup +a way to organize and coordinate these groups. Some kind of group +of groups. My opinion is that it would be good that GNU delegates +this task to a small group of collaborating volunteers, shortly. +Perhaps in <TT>`gnu.announce'</TT> a list of this national committee's +can be published. + +</P> +<P> +My role as coordinator would simply be to refer to Ulrich any German +speaking volunteer interested to localization of free software packages, and +maybe helping national groups to initially organize, while maintaining +national registries for until national groups are ready to take over. +In fact, the coordinator should ease volunteers to get in contact with +one another for creating national teams, which should then select +one coordinator per language, or country (regionalized language). +If well done, the coordination should be useful without being an +overwhelming task, the time to put delegations in place. + +</P> + + +<H3><A NAME="SEC62" HREF="gettext_toc.html#TOC62">National Teams</A></H3> + +<P> +I suggest we look for volunteer coordinators/editors for individual +languages. These people will scan contributions of translation files +for various programs, for their own languages, and will ensure high +and uniform standards of diction. + +</P> +<P> +From my current experience with other people in these days, those who +provide localizations are very enthusiastic about the process, and are +more interested in the localization process than in the program they +localize, and want to do many programs, not just one. This seems +to confirm that having a coordinator/editor for each language is a +good idea. + +</P> +<P> +We need to choose someone who is good at writing clear and concise +prose in the language in question. That is hard--we can't check +it ourselves. So we need to ask a few people to judge each others' +writing and select the one who is best. + +</P> +<P> +I announce my prerelease to a few dozen people, and you would not +believe all the discussions it generated already. I shudder to think +what will happen when this will be launched, for true, officially, +world wide. Who am I to arbitrate between two Czekolsovak users +contradicting each other, for example? + +</P> +<P> +I assume that your German is not much better than my French so that +I would not be able to judge about these formulations. What I would +suggest is that for each language there is a group for people who +maintain the PO files and judge about changes. I suspect there will +be cultural differences between how such groups of people will behave. +Some will have relaxed ways, reach consensus easily, and have anyone +of the group relate to the maintainers, while others will fight to +death, organize heavy administrations up to national standards, and +use strict channels. + +</P> +<P> +The German team is putting out a good example. Right now, they are +maybe half a dozen people revising translations of each other and +discussing the linguistic issues. I do not even have all the names. +Ulrich Drepper is taking care of coordinating the German team. +He subscribed to all my pretest lists, so I do not even have to warn +him specifically of incoming releases. + +</P> +<P> +I'm sure, that is a good idea to get teams for each language working +on translations. That will make the translations better and more +consistent. + +</P> + + + +<H4><A NAME="SEC63" HREF="gettext_toc.html#TOC63">Sub-Cultures</A></H4> + +<P> +Taking French for example, there are a few sub-cultures around computers +which developed diverging vocabularies. Picking volunteers here and +there without addressing this problem in an organized way, soon in the +project, might produce a distasteful mix of internationalized programs, +and possibly trigger endless quarrels among those who really care. + +</P> +<P> +Keeping some kind of unity in the way French localization of +internationalized programs is achieved is a difficult (and delicate) job. +Knowing the latin character of French people (:-), if we take this +the wrong way, we could end up nowhere, or spoil a lot of energies. +Maybe we should begin to address this problem seriously <EM>before</EM> +GNU <CODE>gettext</CODE> become officially published. And I suspect that this +means soon! + +</P> + + +<H4><A NAME="SEC64" HREF="gettext_toc.html#TOC64">Organizational Ideas</A></H4> + +<P> +I expect the next big changes after the official release. Please note +that I use the German translation of the short GPL message. We need +to set a few good examples before the localization goes out for true +in the free software community. Here are a few points to discuss: + +</P> + +<UL> +<LI> + +Each group should have one FTP server (at least one master). + +<LI> + +The files on the server should reflect the latest version (of +course!) and it should also contain a RCS directory with the +corresponding archives (I don't have this now). + +<LI> + +There should also be a ChangeLog file (this is more useful than the +RCS archive but can be generated automatically from the later by +Emacs). + +<LI> + +A <STRONG>core group</STRONG> should judge about questionable changes (for now +this group consists solely by me but I ask some others occasionally; +this also seems to work). + +</UL> + + + +<H3><A NAME="SEC65" HREF="gettext_toc.html#TOC65">Mailing Lists</A></H3> + +<P> +If we get any inquiries about GNU <CODE>gettext</CODE>, send them on to: + +</P> + +<PRE> +<TT>`translation@iro.umontreal.ca'</TT> +</PRE> + +<P> +The <TT>`*-pretest'</TT> lists are quite useful to me, maybe the idea could +be generalized to many GNU, and non-GNU packages. But each maintainer +his/her way! + +</P> +<P> +Fran@,{c}ois, we have a mechanism in place here at +<TT>`gnu.ai.mit.edu'</TT> to track teams, support mailing lists for +them and log members. We have a slight preference that you use it. +If this is OK with you, I can get you clued in. + +</P> +<P> +Things are changing! A few years ago, when Daniel Fekete and I +asked for a mailing list for GNU localization, nested at the FSF, we +were politely invited to organize it anywhere else, and so did we. +For communicating with my pretesters, I later made a handful of +mailing lists located at iro.umontreal.ca and administrated by +<CODE>majordomo</CODE>. These lists have been <EM>very</EM> dependable +so far... + +</P> +<P> +I suspect that the German team will organize itself a mailing list +located in Germany, and so forth for other countries. But before they +organize for true, it could surely be useful to offer mailing lists +located at the FSF to each national team. So yes, please explain me +how I should proceed to create and handle them. + +</P> +<P> +We should create temporary mailing lists, one per country, to help +people organize. Temporary, because once regrouped and structured, it +would be fair the volunteers from country bring back <EM>their</EM> list +in there and manage it as they want. My feeling is that, in the long +run, each team should run its own list, from within their country. +There also should be some central list to which all teams could +subscribe as they see fit, as long as each team is represented in it. + +</P> + + +<H2><A NAME="SEC66" HREF="gettext_toc.html#TOC66">Information Flow</A></H2> + +<P> +There will surely be some discussion about this messages after the +packages are finally released. If people now send you some proposals +for better messages, how do you proceed? Jim, please note that +right now, as I put forward nearly a dozen of localizable programs, I +receive both the translations and the coordination concerns about them. + +</P> +<P> +If I put one of my things to pretest, Ulrich receives the announcement +and passes it on to the German team, who make last minute revisions. +Then he submits the translation files to me <EM>as the maintainer</EM>. +For free packages I do not maintain, I would not even hear about it. +This scheme could be made to work for the whole Translation Project, +I think. For security reasons, maybe Ulrich (national coordinators, +in fact) should update central registry kept at the Translation Project +(Jim, me, or Len's recruits) once in a while. + +</P> +<P> +In December/January, I was aggressively ready to internationalize +all of GNU, giving myself the duty of one small GNU package per week +or so, taking many weeks or months for bigger packages. But it does +not work this way. I first did all the things I'm responsible for. +I've nothing against some missionary work on other maintainers, but +I'm also loosing a lot of energy over it--same debates over again. + +</P> +<P> +And when the first localized packages are released we'll get a lot of +responses about ugly translations :-). Surely, and we need to have +beforehand a fairly good idea about how to handle the information +flow between the national teams and the package maintainers. + +</P> +<P> +Please start saving somewhere a quick history of each PO file. I know +for sure that the file format will change, allowing for comments. +It would be nice that each file has a kind of log, and references for +those who want to submit comments or gripes, or otherwise contribute. +I sent a proposal for a fast and flexible format, but it is not +receiving acceptance yet by the GNU deciders. I'll tell you when I +have more information about this. + +</P> +<P><HR><P> +<p>Go to the <A HREF="gettext_1.html">first</A>, <A HREF="gettext_8.html">previous</A>, <A HREF="gettext_10.html">next</A>, <A HREF="gettext_12.html">last</A> section, <A HREF="gettext_toc.html">table of contents</A>. +</BODY> +</HTML>