From: Bruno Haible Date: Wed, 23 Oct 2024 11:06:34 +0000 (+0200) Subject: doc: Revise "Translators" chapter. X-Git-Tag: v0.23~35 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=c042678d3e3175c3587237854011583f6847d5de;p=thirdparty%2Fgettext.git doc: Revise "Translators" chapter. * gettext-tools/doc/gettext.texi (Trans Intro 0, Trans Intro 1, Discussions, Organization, Information Flow): Remove sections. (Organization, Responsibilities): New sections. --- diff --git a/gettext-tools/doc/gettext.texi b/gettext-tools/doc/gettext.texi index fe7d71572..a76cd04c8 100644 --- a/gettext-tools/doc/gettext.texi +++ b/gettext-tools/doc/gettext.texi @@ -325,25 +325,11 @@ Temporary Notes for the Programmers Chapter The Translator's View -* Trans Intro 0:: Introduction 0 -* Trans Intro 1:: Introduction 1 -* Discussions:: Discussions * Organization:: Organization -* Information Flow:: Information Flow +* Responsibilities:: Responsibilities in the Translation Project * Translating plural forms:: How to fill in @code{msgstr[0]}, @code{msgstr[1]} * Prioritizing messages:: How to find which messages to translate first -Organization - -* Central Coordination:: Central Coordination -* National Teams:: National Teams -* Mailing Lists:: Mailing Lists - -National Teams - -* Sub-Cultures:: Sub-Cultures -* Organizational Ideas:: Organizational Ideas - The Maintainer's View * Flat and Non-Flat:: Flat or Non-Flat Directory Structures @@ -1256,7 +1242,7 @@ prompt, merely execute A locale name usually has the form @samp{@var{ll}_@var{CC}}. Here -@itemize +@itemize @bullet @item @samp{@var{ll}} is an @w{ISO 639} two-letter language code. For some languages, @@ -8017,440 +8003,131 @@ Solaris is not the only system having @code{gettext}. @node Translators @chapter The Translator's View -@c FIXME: Reorganize whole chapter. - @menu -* Trans Intro 0:: Introduction 0 -* Trans Intro 1:: Introduction 1 -* Discussions:: Discussions * Organization:: Organization -* Information Flow:: Information Flow +* Responsibilities:: Responsibilities in the Translation Project * Translating plural forms:: How to fill in @code{msgstr[0]}, @code{msgstr[1]} * Prioritizing messages:: How to find which messages to translate first @end menu -@node Trans Intro 0 -@section Introduction 0 - -@strong{ NOTE: } This documentation section is outdated and needs to be -revised. - -Free software is going international! The Translation Project is a way -to get maintainers, translators and users all together, so free software -will gradually become able to speak many native languages. - -The GNU @code{gettext} tool set contains @emph{everything} 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. - -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 @emph{work} at translating messages, -please send mail to your translating team. - -Each team has its own mailing list, courtesy of Linux -International. You may reach your translating team at the address -@file{@var{ll}@@li.org}, replacing @var{ll} by the two-letter @w{ISO 639} -code for your language. Language codes are @emph{not} the same as -country codes given in @w{ISO 3166}. The following translating teams -exist: - -@quotation -Chinese @code{zh}, Czech @code{cs}, Danish @code{da}, Dutch @code{nl}, -Esperanto @code{eo}, Finnish @code{fi}, French @code{fr}, Irish -@code{ga}, German @code{de}, Greek @code{el}, Italian @code{it}, -Japanese @code{ja}, Indonesian @code{in}, Norwegian @code{no}, Polish -@code{pl}, Portuguese @code{pt}, Russian @code{ru}, Spanish @code{es}, -Swedish @code{sv} and Turkish @code{tr}. -@end quotation - -@noindent -For example, you may reach the Chinese translating team by writing to -@file{zh@@li.org}. 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 @w{@file{sv-request@@li.org}}, -having this message body: - -@example -subscribe -@end example - -Keep in mind that team members should be interested in @emph{working} -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 @w{@file{coordinator@@translationproject.org}}; -you will then reach the coordinator for all translator teams. - -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 -@file{coordinator@@translationproject.org} indicating what language(s) -you can work on. - -@node Trans Intro 1 -@section Introduction 1 - -@strong{ NOTE: } This documentation section is outdated and needs to be -revised. - -This is now official, GNU is going international! Here is the -announcement submitted for the January 1995 GNU Bulletin: - -@quotation -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{coordinator@@translationproject.org} indicating what language(s) -you can work on. -@end quotation - -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 internationalization of free software. - -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 free software. This very document -is written in English. This will not change in the foreseeable future. - -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 free 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 -internationalization of free software is dedicated to succeed. - -For suggestion clarifications, additions or corrections to this -document, please e-mail to @file{coordinator@@translationproject.org}. - -@node Discussions -@section Discussions - -@strong{ NOTE: } This documentation section is outdated and needs to be -revised. - -Facing this internationalization effort, a few users expressed their -concerns. Some of these doubts are presented and discussed, here. - -@itemize @bullet -@item 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 @emph{into computers}, 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. - -@item 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. - -@item 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@dots{} - -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. - -@item Dependencies over the GPL or LGPL - -Some people wonder if using GNU @code{gettext} necessarily brings their -package under the protective wing of the GNU General Public License or -the GNU Lesser General Public License, when they do not want to make -their program free, or want other kinds of freedom. The simplest -answer is ``normally not''. - -The @code{gettext-runtime} part of GNU @code{gettext}, i.e.@: the -contents of @code{libintl}, is covered by the GNU Lesser General Public -License. The @code{gettext-tools} part of GNU @code{gettext}, i.e.@: the -rest of the GNU @code{gettext} package, is covered by the GNU General -Public License. - -The mere marking of localizable strings in a package, or conditional -inclusion of a few lines for initialization, is not really including -GPL'ed or LGPL'ed code. However, since the localization routines in -@code{libintl} are under the LGPL, the LGPL needs to be considered. -It gives the right to distribute the complete unmodified source of -@code{libintl} even with non-free programs. It also gives the right -to use @code{libintl} as a shared library, even for non-free programs. -But it gives the right to use @code{libintl} as a static library or -to incorporate @code{libintl} into another library only to free -software. - -@end itemize - @node Organization @section Organization -@strong{ NOTE: } This documentation section is outdated and needs to be -revised. - -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! - -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. - -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. - -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} becomes an official reality. The e-mail address -@file{coordinator@@translationproject.org} has been set up for receiving -offers from volunteers and general e-mail on these topics. This address -reaches the Translation Project coordinator. +For some software packages, each translator works on her own +and communicates directly with the developers of the package. +For some other software packages, on the other hand, +translators are organized +into @emph{translation projects} and @emph{translation teams}. -@menu -* Central Coordination:: Central Coordination -* National Teams:: National Teams -* Mailing Lists:: Mailing Lists -@end menu +A @emph{translation project} applies to a group of software packages +and shares procedures and methodologies regarding the translation. -@node Central Coordination -@subsection Central Coordination - -I also think GNU will need sooner than it thinks, that someone set up -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 @file{gnu.announce} a list of this national committee's -can be published. - -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. - -@node National Teams -@subsection National Teams - -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. - -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. - -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. - -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? - -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. - -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. - -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. +There are currently three major translation projects: -@menu -* Sub-Cultures:: Sub-Cultures -* Organizational Ideas:: Organizational Ideas -@end menu +@itemize @bullet +@item +The ``Translation Project'', which is used +by all kinds of Free Software packages, but in particular by GNU packages. +It has its home at @url{https://translationproject.org/}. -@node Sub-Cultures -@subsubsection Sub-Cultures +@item +The ``KDE Localization Project'', which is used by KDE packages. +It is at @url{https://l10n.kde.org/}. -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. +@item +The ``GNOME Localization Project'', which is used by GNOME packages. +It is at @url{https://l10n.gnome.org/}. +@end itemize -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 @emph{before} -GNU @code{gettext} become officially published. And I suspect that this -means soon! +A @emph{translation team} is a group of translators for a single language, +in the scope of a translation project. -@node Organizational Ideas -@subsubsection Organizational Ideas +@node Responsibilities +@section Responsibilities in the Translation Project -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: +The following rules and habits apply to the Translation Project. +The translator's responsibilities are: @itemize @bullet @item -Each group should have one FTP server (at least one master). +(Once only.) +She submits a translations disclaimer to the Free Software Foundation. + +A disclaimer is a legal document +that allows the software package to distribute her translation work. +It is not as strong as a copyright assignment. +Merely, it says that the signer +will never make use of the copyright on her translations: +will never forbid copying them, +and will never ask for some kind of compensation. +This guarantees that the FSF (and everyone else) +will always be allowed to freely distribute these translations. +The FSF wishes to have this guarantee in writing, to be on the safe side. + +There are two ways to submit the disclaimer: +@c In 2024, the wrote: +@c "I do like giving people options, so please include both." +Either online through +@url{https://crm.fsf.org/civicrm/profile/create?gid=91&reset=1,,this form} +on the FSF's web site, +or by printing, signing, and submitting +the file @file{disclaim-translations.txt} found in the GNU gettext distribution. + +@item +Agree with the other translators of the same team +who is ``in charge'' for the translations of a particular package. +@end itemize +The Translation Project has a coordinator. +He can be reached at @samp{coordinator@@translationproject.org}. +His responsibilities are: +@itemize @bullet @item -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). - +He maintains the web site @url{https://translationproject.org/}. @item -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). +When he receives a release or prerelease announcement +from one of the software package maintainers, +he extracts the POT file(s) +and sends notifications to all translation teams about it. +@end itemize +The responsibilities of the package maintainers are: +@itemize @bullet @item -A @dfn{core group} should judge about questionable changes (for now -this group consists solely by me but I ask some others occasionally; -this also seems to work). - +To incorporate the translations in the software package before a release. +@item +To forward bug reports about the translations +to the respective translation team. +A developer or maintainer should never apply a translation fix himself, +because that would cause conflicts with the translation team. @end itemize -@node Mailing Lists -@subsection Mailing Lists - -If we get any inquiries about GNU @code{gettext}, send them on to: - -@example -@file{coordinator@@translationproject.org} -@end example - -The @file{*-pretest} 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! - -Fran@,{c}ois, we have a mechanism in place here at -@file{gnu.ai.mit.edu} 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. - -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}. These lists have been @emph{very} dependable -so far@dots{} - -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. - -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 @emph{their} 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. - -@node Information Flow -@section Information Flow - -@strong{ NOTE: } This documentation section is outdated and needs to be -revised. - -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. - -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 @emph{as the maintainer}. -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. - -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 losing a lot of energy over it---same debates over again. - -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. - -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. +@c FIXME: Move to an FAQ. +@c +@c @item Dependencies over the GPL or LGPL +@c +@c Some people wonder if using GNU @code{gettext} necessarily brings their +@c package under the protective wing of the GNU General Public License or +@c the GNU Lesser General Public License, when they do not want to make +@c their program free, or want other kinds of freedom. The simplest +@c answer is ``normally not''. +@c +@c The @code{gettext-runtime} part of GNU @code{gettext}, i.e.@: the +@c contents of @code{libintl}, is covered by the GNU Lesser General Public +@c License. The @code{gettext-tools} part of GNU @code{gettext}, i.e.@: the +@c rest of the GNU @code{gettext} package, is covered by the GNU General +@c Public License. +@c +@c The mere marking of localizable strings in a package, or conditional +@c inclusion of a few lines for initialization, is not really including +@c GPL'ed or LGPL'ed code. However, since the localization routines in +@c @code{libintl} are under the LGPL, the LGPL needs to be considered. +@c It gives the right to distribute the complete unmodified source of +@c @code{libintl} even with non-free programs. It also gives the right +@c to use @code{libintl} as a shared library, even for non-free programs. +@c But it gives the right to use @code{libintl} as a static library or +@c to incorporate @code{libintl} into another library only to free +@c software. @node Translating plural forms @section Translating plural forms