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
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,
@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 <copyright-clerk@fsf.org> 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
projects / thirdparty / gettext.git / commitdiff
