[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

trans-coord/gnun/server/gnun ChangeLog NEWS doc...

From: Yavor Doganov
Subject: trans-coord/gnun/server/gnun ChangeLog NEWS doc...
Date: Fri, 13 Feb 2009 00:22:22 +0000

CVSROOT:        /sources/trans-coord
Module name:    trans-coord
Changes by:     Yavor Doganov <yavor>   09/02/13 00:22:21

Modified files:
        gnun/server/gnun: ChangeLog NEWS 
Added files:
        gnun/server/gnun/doc: web-trans.texi 

Log message:
        New manual; a general guide for web-translators.
        * doc/web-trans.texi: New file.
        * doc/ (info_TEXINFOS): Add web-trans.texi.
        (web_trans_TEXINFOS): New variable.
        * NEWS: Update.


Index: ChangeLog
RCS file: /sources/trans-coord/trans-coord/gnun/server/gnun/ChangeLog,v
retrieving revision 1.131
retrieving revision 1.132
diff -u -b -r1.131 -r1.132
--- ChangeLog   8 Feb 2009 15:53:21 -0000       1.131
+++ ChangeLog   13 Feb 2009 00:22:20 -0000      1.132
@@ -1,3 +1,10 @@
+2009-02-13  Yavor Doganov  <address@hidden>
+       * doc/web-trans.texi: New file.
+       * doc/ (info_TEXINFOS): Add web-trans.texi.
+       (web_trans_TEXINFOS): New variable.
+       * NEWS: Update.
 2009-02-08  Yavor Doganov  <address@hidden>
        * NEWS: Document the 2009-02-06 parallel build fix.

Index: NEWS
RCS file: /sources/trans-coord/trans-coord/gnun/server/gnun/NEWS,v
retrieving revision 1.6
retrieving revision 1.7
diff -u -b -r1.6 -r1.7
--- NEWS        8 Feb 2009 16:00:53 -0000       1.6
+++ NEWS        13 Feb 2009 00:22:21 -0000      1.7
@@ -1,6 +1,6 @@
 GNUnited Nations NEWS - User visible changes.
-* Changes in GNUnited Nations 0.2 (2009-02-??)
+* Changes in GNUnited Nations 0.2 (2009-02-13)
 ** supports Subversion repositories.
@@ -18,6 +18,19 @@
    use the latest version without the need to copy them manually every
+** New web-translators manual.
+   The new manual (web-trans.texi) describes the whole (revamped)
+   translation process and is the canonical documentation for
+   web-translators at all levels (managers, team leaders, team
+   members, volunteers).  It is still incomplete and is designed never
+   to be completed: the translation process should evolve, and its
+   documentation ought to follow accordingly.
+   The files at will be
+   removed soon; they are obsolete since quite some time.  The
+   standard entry point for new volunteers README.translations.html
+   will also be revised.
 ** Bugs fixed in 0.2.
 *** Parallel (-jN) build fix.

Index: doc/
RCS file: /sources/trans-coord/trans-coord/gnun/server/gnun/doc/,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -b -r1.1 -r1.2
--- doc/     20 Jan 2009 21:31:33 -0000      1.1
+++ doc/     13 Feb 2009 00:22:21 -0000      1.2
@@ -15,5 +15,6 @@
 # You should have received a copy of the GNU General Public License
 # along with GNUnited Nations.  If not, see <>.
-info_TEXINFOS = gnun.texi
+info_TEXINFOS = gnun.texi web-trans.texi
 gnun_TEXINFOS = fdl.texi
+web_trans_TEXINFOS = fdl.texi

Index: doc/web-trans.texi
RCS file: doc/web-trans.texi
diff -N doc/web-trans.texi
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ doc/web-trans.texi  13 Feb 2009 00:22:21 -0000      1.1
@@ -0,0 +1,1548 @@
+\input texinfo
address@hidden %**start of header
address@hidden version1.texi
address@hidden GNU Web Translators Manual
address@hidden FIXME: Would be nice to have it in the format `%:b %:d, %:y', but
address@hidden in English.
address@hidden lastupdate 13.02.2009
address@hidden %**end of header
address@hidden Please do not use features of Texinfo >> 4.11, which is the 
address@hidden available in gNewSense.  Thanks.
+This manual is a guide for the @acronym{GNU} Web address@hidden
+Last updated on @value{lastupdate}, for @acronym{GNU}nited Nations
+version @value{VERSION}.
address@hidden 1
+Copyright @copyright{} 2009 Free Software Foundation, Inc.
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the @acronym{GNU} Free Documentation License,
+Version 1.3 or any later version published by the Free Software
+Foundation; with no Invariant Sections, no Front-Cover Texts, and no
+Back-Cover Texts.  A copy of the license is included in the section
+entitled address@hidden Free Documentation License.''
address@hidden quotation
address@hidden copying
address@hidden GNU Web Translators Manual
address@hidden Documentation for translators of
address@hidden (last updated @value{lastupdate}, for GNUnited Nations version 
address@hidden by Yavor Doganov <@email{}>
address@hidden 0pt plus 1filll
address@hidden titlepage
address@hidden GNU organization
+* GNU Web Translators: (web-trans).  Guidelines and procedures for translators.
address@hidden direntry
address@hidden Top
address@hidden GNU Web Translators Manual
address@hidden ifnottex
+* Introduction::         Begin of the journey.
+* Members::              Information for translation team members.
+* Leaders::              Guidelines and procedures for team leaders.
+* Translation Managers:: Responsibilities of the GNU Web Translation
+                           co-ordinators.
+* Translation Tips::     Explanation of some non-obvious things.
+* Summary::              Overview.
address@hidden * Index::
+* Copying This Manual::  The GNU Free Documentation License.
address@hidden menu
address@hidden Introduction
address@hidden Introduction
+This manual is an attempt to describe in detail the process of
+translating articles---how to join a team, or start a new
+one, the responsibilities of the team members and leaders, as well as
+some peculiarities of the @acronym{GNU} Project's website when it comes
+to localization.
+The @acronym{GNU} website contains hundreds of documents, most of them
+philosophical articles (essays) and technical documents which need to be
+translated to make them available to a broader audience.  This is
+especially important for the philosophy-related materials, as many
+people do not speak English and even those that do usually prefer to
+read such articles in their native language.  Dealing with the task of
+translating a website this large is a hard job, and too often people
+volunteering as translators get frustrated or lose interest in keeping
+up with that work.  Reading this manual, and the related @acronym{GNUN}
+manual (@pxref{Top, , GNUnited Nations, gnun, The GNUnited Nations
+Manual}), is just the tip of the iceberg.  This is not meant to
+discourage any potential volunteer; rather, we prefer to be honest and
+to give preliminary estimation of the work/responsibility involved---if
+you feel you are not in a position to help you may move on to a smaller
+project before going through all procedures.
+It is important to realize that being a @acronym{GNU} Web Translator is
+a hard job at all levels, but your help is much appreciated and is
+invaluable contribution to the society.  While there are many people who
+contribute to our community by writing free software (and their number
+is constantly increasing), the ones actively engaged in teaching others
+to appreciate and defend their freedom are only a few.  Consequently and
+rather unfortunately, there are not so many volunteers willing to
+maintain on the long term translations of the various essays that
+describe the fundamental values of the free software movement.
+Translators of the @uref{} website are organized in
+language teams.  Each team has one or more co-ordinators, who are
+responsible for the respective team.  The co-ordinators participate in
+the Savannah @samp{trans-coord} organizational project, which is managed
+by the @acronym{GNU} Web Translation Managers.  The manual is organized
+in chapters that follow the organizational structure of the whole
+translation project.
+If you wish to join a translation team or contribute a translation or
+two, @pxref{Members}.  If your intention is to form a translation
+team, @pxref{Leaders}.  The chapter about the @samp{trans-coord}
+administrators (a.k.a. @address@hidden Translation Managers})
+describes all the responsibilities and procedures involved in performing
+this duty.  @xref{Translation Managers}.
address@hidden Members
address@hidden Team Members
+Being a team member means to co-operate with a group of other people,
+working under the co-ordinatorship of the appointed team leader.
+Usually, this involves translating articles and reviewing/proof-reading
+other people's translations, participating in discussions about
+terminology issues, and sometimes performing clean-up tasks.
+* Joining::             How to join a translation team.
+* Submitting::          Submitting a translation when there is no team.
+* Leaving A Team::      Leave when you have to.
address@hidden menu
address@hidden Joining
address@hidden Joining A Team
+To join a team, please first look at the existing teams at
+Chances are that there is already an established team.  If there is no
+team listed for your language, this means that:
+There is no team established and there are no translations to this
+Some translations were submitted by occasional contributors, but no team
+has ever been formed.
+The page is not updated to reflect the current situation (this shouldn't
+happen, but it's a possibility anyway).
address@hidden itemize
+If the team is marked as @dfn{orphaned}, there is no problem: you can
+still submit your translation to @email{}
+(@pxref{Submitting}).  In case you want to establish a new translation
+team or become a co-ordinator of an existing one, please refer to the
+next chapter, @pxref{Leaders}.
+Contacting the team is best done via Savannah---each translation team
+has its own project, named @address@hidden, with the project page
+Usually teams have mailing lists, either on Savannah or on some external
+site.  Some teams have homepages,
+with additional contact details and procedures for team members.
+You could also write directly to the team leader via the Savannah
+interface---that way you request will be recorded by Savannah and can be
+tracked or completed when the membership is approved.
+The actual process of submitting translations for review varies from
+team to team, as teams have certain liberties to organize themselves as
+they see fit.  Thus, this manual does not make any attempt to cover that
+aspect---please refer to the team-specific documentation (if any) or ask
+the co-ordinator.
+Certainly, it is not mandatory to be an active team member to contribute
+a translation or two.  If you feel that you don't have the time to
+participate actively, that is fine; you can still send your translation
+to the team.  No contributions should be rejected.
+If you do not hear from the team within a reasonable time frame (say,
+two weeks), please write to @email{}.
+For general information about the translation process,
address@hidden Tips}.
address@hidden Submitting
address@hidden How To Submit a Translation
+Everyone can still submit translations even if there is no translation
+team formed.  There are two ways to do that---following the existing
+procedures, which is the preferred way, and sending it as plain text,
+which means more work for a limited group of volunteers (the Translation
+Managers) to convert the translation in @file{.po} format.
+* Submitting as PO::
+* Submitting as Plain Text::
address@hidden menu
address@hidden Submitting as PO
address@hidden How To Submit a Translation in PO Format
+All address@hidden really, but the goal is to maintain
+all of them.} are maintained via @acronym{GNUN} (see
address@hidden://}), which significantly eases
+maintenance and avoids the unpleasant situation where a translation is
+lagging behind the original.  @xref{Advantages, , , gnun, The GNUnited
+Nations Manual}.
+As of September 2008 all new translations at are installed in
address@hidden format, and the @file{.html} is generated automatically.
+Here are the steps to produce and submit such a translation:
+Make a checkout of the CVS Web repository of the @samp{www} Savannah
+project.  You can find generic instructions at
address@hidden://}.  All updates to the
+website are done as commits in the repository, so you would need an
+up-to-date working copy.  Anonymous access works under any
+circumstances, i.e. it is not mandatory to have a registered account at
+Savannah to use it.  You can also check out only a specific directory,
+for example:
+cvs -z3 co www/gnu
address@hidden example
+This command will fetch only the @file{/gnu} directory---in other words,
+all articles at @uref{}.
+Assuming you already know the article you want to translate, you have to
+create an empty @address@hidden@var{lang}.po} file and then
+translate all messages with a PO editor.  @xref{New Translation, , ,
+gnun, The GNUnited Nations Manual}.  For an almost complete list of PO
+editors, @pxref{PO Files, , , gnun, The GNUnited Nations Manual}.
+When you are pleased with the translation, check that the PO file is
+valid and submit it to @email{}, attached to
+your message.  The web-translators will review (to the best of their
+ability) the translation and will install it in the repository.
+In order @acronym{GNUN} to be able to generate (and subsequently update)
+a gettextized translation, the language should have the server templates
+available as PO files.  These templates are short, and translating them
+shouldn't take much time.  If the language code is present in the
address@hidden variable at @file{server/gnun/}, then you
+don't have to do anything.  If not, the required files are
address@hidden/po/address@hidden and
address@hidden/po/address@hidden can translate and
+submit them in the usual way, together with the translation of the
+If you don't want to translate the templates for whatever reason---do
+not worry, the web-translators will install empty templates (which means
+the English strings will be used).
address@hidden itemize
+It is quite possible that there will be errors or typos, so once you are
+informed that the translation is online, check it carefully and if
+necessary, resubmit the PO file with corrections.  Do not forget to run
address@hidden update} first and edit the updated @file{.po} file from the
+repository---most probably the Translation Managers have already made
+some modifications to it, usually to fix validation errors and to
+complete the PO file header.
address@hidden Submitting as Plain Text
address@hidden How To Submit a Translation as Plain Text
+If you feel the procedure described in the previous section is too
+burdensome and unfeasible for you to follow, you can still submit a
+translation in plain text.  It will be manually converted to PO file by
+the @acronym{GNU} Web Translation Managers, which can be tricky
+sometimes, and naturally, means more work for them and slower processing
+of your request.
+You should @emph{never} translate the HTML markup---i.e. @emph{do not}
+use the ``View Source'' functionality of your browser to translate the
+raw HTML.  Most of it is irrelevant, and automatically inherited from
+the markup of the original article.  Simply save your translation in a
+plain text file (@file{.txt}), preferably in UTF-8 encoding.  You can
+use any decent text editor for that---Emacs, Vim, gEdit, Kate, (the file should be saved as @file{.txt}, not
address@hidden), etc.
+Translate the title, the blue heading (if it differs slightly from the
+title) and the body of the article upto the link @samp{back to top}.
+For example, for @uref{}
+that would be:
+The Free Software Definition - GNU Project - Free Software Foundation (FSF)
+We maintain this free software address@hidden
address@hidden you would like to review the complete list of changes, you can
+do so on our cvsweb interface.
address@hidden example
+Since web-translators do not speak all languages, it is essential to
+mark somehow any inner markup, because very often it is hard to figure
+out what translated text should be enclosed inside @code{<em>} or
address@hidden<a>} elements, to name a few.  The easiest way to do this is just
+to use the corresponding HTML markup, although anything else is
+suitable.  For example, here is how to indicate that the link ``History
+section'' at the first paragraph of the same article should correspond
+to ``secci@'on historial'' in the translation:
+Si quisiera revisar los cambios que hemos hecho, por favor vea la
address@hidden@'on address@hidden m@'as abajo para m@'as informaci@'on.
address@hidden example
+It is not necessary to include the value of the @code{href} attribute,
+as it is already known.
+If you wish your name to appear in the footer as a translator of the
+article, please also provide a translation of @samp{Translation:
address@hidden name in your native language}} or @samp{Translated by:
address@hidden name in your native language}}, as you prefer.  Please also
+state if you wish your email address to be published (some readers
+prefer to send suggestions directly to the translator, but we certainly
+do not require that translators must publish their address).
+Finally, send the translation to @email{},
+either inline or as an attachment to your message.  Once online, please
+check for any errors or omissions that may have resulted from the
+conversion process, and report them back.
address@hidden Leaving A Team
address@hidden Leaving A Team
+When you realize that you don't have time or can't devote sufficient
+resources to perform the tasks anymore, it is prudent to inform the
+translation team co-ordinator and possibly all the rest of the
+team-mates.  The team leader should always have a rough estimation about
+the available translators, even though there are no reliable means to
+establish that.  Your announcement that you are stepping down
+(temporarily or permanently) may help her in this regard.
address@hidden Leaders
address@hidden Team Co-ordinators
+A translation team leader is the person who is ultimately
+responsible for organizing and managing the team, including, but not
+limited to, having the final say on contributed translations and
+exercising levels of control as she sees fit.
+A prospective team co-ordinator should have perfect understanding of the
+GNU Philosophy and the various issues the free software movement set out
+to solve.  Energy and time are always needed, as well as certain
+communication skills.
+However, a team leader is not a dictator (for life); every action and/or
+decision taken should have its justification and should stem from the
+goals of the project at large.  Inefficient or inoperative leaders are
+replaced, if necessary.
+* New Team::            Procedures to establish a new team.
+* Managing::            General guidelines how to manage a team.
+* Reports::             Reporting team status and activity.
+* Stepping Down::       Orphaning the team and finding a replacement.
address@hidden menu
address@hidden New Team
address@hidden How To Form A New Team
+Establishing a new team is not hard, but a certain procedure ought to be
+followed.  The most important thing to realize is that this is somewhat
+a long-term engagement that requires a lot of spare time, communication
+and technical skills, and devotion.  The only ``bonus'' team leaders
+have is more work and more responsibilities.
+You should read most of the philosophy-related articles and @emph{all}
+the documentation related to the translation process before you decide
+to form a new team, or take over an orphaned team.  Once you have the
+internal feeling that having a translation team for your
+language is a must, and you are the one for this job, follow these
+If you do not have a Savannah account, register at
address@hidden://}.  Write access
+to the repository and project membership is handled via Savannah, so you
+would need an account in any case.
+Checkout a complete working copy of the CVS Web repository as described
+at @uref{}.  If you still
+don't have a Savannah account or if you have registered one, but are not
+yet member of any Savannah project, refer to the instructions under
+``Anonymous CVS Access''.  If you are already a member of (any) Savannah
+project, you can proceed with ``Project Member CVS Access via SSH'',
+although you will still lack permission to commit (later, when it is
+granted, you can use the same working copy).
+Examine the layout and structure of the repository.  Basically, it is
+mapped to the URL locations, more or less.  Take a look at the most
+important materials to translate under @file{/philosophy}, @file{/gnu},
address@hidden/copyleft} and @file{/licenses} directories just to get a
+rough estimate about the amount of work involved.  If you are still not
+scared and determined to go on further, excellent.
+As you have probably observed, every directory that contains
+translatable articles has a @file{/po} sub-directory, which is where the
+new canonical source format of the translations is stored.
+Assuming you have already read the @acronym{GNUN} manual entirely (as
+recommended in the beginning of this section), check if your language
+code is present in the variable @code{TEMPLATE_LINGUAS} at
address@hidden/gnun/}.  If it is not, the first thing to do is to
+translate and submit to @email{} the files
address@hidden/po/address@hidden and
address@hidden/po/address@hidden, together with your first
+message stating that you would like to establish a new team.  @xref{New
+Translation, , , gnun, The GNUnited Nations Manual}.
address@hidden @minus
+The language code (@var{lang}) should be the ISO 639-1 code of the
+language, for example @samp{hy} for Armenian or @samp{el} for Greek.  If
+there is no such code, use the ISO 639-2 one---e.g. @samp{mai} for
+Maithili.  If the language is a variant such as Brazilian Portuguese or
+Simplified Chinese, use small caps and a address@hidden and
address@hidden instead of @samp{pt_BR} and @samp{zh_CN}.
+The PO file header and initial comments should be completed as
+Do not use HTML entities for non-ASCII characters as in the English
+original.  They are harder to type and read.  So, if there is
address@hidden&uuml;} and this is a character from the alphabet of your
+language, just write it as @samp{@"u} directly.
address@hidden itemize
+Any prospective team leader should submit a few translations first.
+This is a process of pointing errors and omissions (which are expected
+and natural); it's an important thing to do as the leader is going to
+carry out these checks on her own, once the team is approved.  If there
+are existing translations that are not yet in PO format, the best thing
+to do is to migrate one or two.  You can use @command{find} to find out
+what's already in the repository, for example:
+find -name address@hidden
address@hidden example
+Submit at least two translations of your own.  We maintain a list with
+priority articles at
+although it is probably hard to start with one of them.  Choose whatever
+you wish, provided it is an essay and not an auxiliary page.  Avoid
+translating the homepage or @file{whatsnew.html}---they are moving
+targets and keeping up would be only a distraction for both parties in
+the process.  As usual, send the completed translation to}.
+The Translation Managers will review your translations, and eventually
+comment on them (mostly technical details if there is no one among them
+speaking your language).  Depending on the case, it might be required to
+submit a corrected file.  In any event, please take into account the
+remarks in future work.
+Once the Translation Managers determine that you are doing well and
+about to complete the process, they will send you the standard
+questionnaire for new team leaders.  It is relevantly short and it
+shouldn't take more than 10-30 minutes to complete.  This questionnaire
+is important, as we consider it crucial any translation team
+co-ordinator to have a good understanding of the philosophy of the free
+software movement.  It is not unusual energetic people who complete all
+technical steps without trouble to fail here.
+If all goes well, you will receive a response inviting you to apply for
+a new translation project at Savannah.  The project name should be
address@hidden@var{lang}} where @var{lang} is, unsurprisingly, the language
+code.  If such a project already exists, this step will be skipped and
+you'll be made an administrator of the project.  To register the
+project, go to @uref{} and make sure
+you fill in the required fields.  The ``Group type'' should be
address@hidden translation team}, and ``Project
+license''address@hidden Only}.
address@hidden attention:} This step is a formality.  You should proceed
+with the project registration only when you have been asked by} to do so.  Otherwise, the submission
+may appear in the task list of the Savannah Hackers for a fairly long
+time, which is troublesome.
+When the project is approved, the team information will be added to the
+list at @file{README.translations.html}, you will become a member of the
address@hidden project (thus granting you CVS write access to the whole
+repository---so be careful) and the @samp{trans-coord} project.  You'll
+also be subscribed to the following mailing lists:
address@hidden @minus
address@hidden itemize
+You'll have to request subscription to @samp{www-discuss}
+yourself---this list is managed by the @acronym{GNU} Webmasters, but all
+team leaders are required to subscribe in order to receive important
+site-wide announcements.
address@hidden enumerate
+The whole process should not take more than two weeks or maximum a
+month---if this period turns out to be longer, it is an indication that
+you do not have the required time and resources for this job, or
+web-translators are badly lagging behind and do not process the requests
+with the expected pace.
+Applications for new teams are sometimes processed in
address@hidden general, we try to avoid this and direct all new
+volunteers to the person who is already carrying out the process---this
+is also a verification if she can cooperate easily with others.}---the
+most suitable candidate is chosen in this case.  This is, undoubtedly,
+based on a subjective judgment made by the Translation Managers, and
+many factors are important.
+The procedure for taking over an orphaned team is the same.  Once
+completed, you will be made an admin of the respective
address@hidden@var{lang}} Savannah project, or if it doesn't exist, invited
+to apply for registration.  Do not automatically remove old members just
+because you are starting ``afresh''---some of them might want to
+continue to contribute.  Contact them privately, explaining that you're
+the new appointed team co-ordinator, and ask them if they would be
+willing to continue their involvement in the team.
address@hidden Managing
address@hidden The Gentle Art of Managing A Translation Team
+It is not our ambition to describe all activities involved in managing a
+team---it's very likely that you will encounter new problems, take care
+of tasks nobody else is aware of, or invent new techniques and
+approaches in your quest to keep things running.  Managing a team is a
+hard task on all counts: communication with others, recruiting
+volunteers (and keeping them as long as possible), defending certain
+decisions, leading discussions about terminology issues, handling
+personal conflicts within the team, technical skills when
+reviewing/merging/syncing translations, etc.  The list goes on and on.
+This manual can only summarize some of the most common issues and
address@hidden ways to deal with them.  It is up to the team leader to
+establish the precise team procedures and practices.
+The @email{} mailing list was specifically
+created to discuss issues that leaders encounter while managing the
+teams, and for general organizational work.  Feel free to discuss
+anything related to the translation process there.
+* Review::              The importance of peer review.
+* Commits::             What to modify, and how.
+* Savannah::            Using Savannah resources.
+* Co-leaders::          Promoting co-leaders, when necessary.
address@hidden menu
address@hidden Review
address@hidden Peer Review
+First and foremost, find at least one person for peer review.  You will
+review her translations, and she will review yours (at least in the
+beginning).  Being a team leader does not mean that you cannot make
+mistakes; everyone does.  The mutual review (especially if done by a
+larger group) is crucial for the quality of the translation process.
+Too many errors are just missed (especially if they are obvious) when
+the translator does a final review of her own translation.
+It is good to establish a practice: Do not commit officially (i.e. in
address@hidden, which will appear online at @uref{}
+immediately) a translation that is not yet reviewed by someone else who
+is not the translator.  Always perform a final review yourself even if
+the translation has been checked by another member of the team.  In
+other words, every translation installed at should pass through
+your hands (read: eyes).
+One common technique for performing such reviews is to use a mailing
+list---the translator sends the new translation and participants comment
+on specific parts, quoting them appropriately.  The benefit of this
+approach is that it is straightforward, but the drawback is that there
+is no automatic ``record'' about the conclusion of the specific
+discussion (or sub-thread) and sometimes such discussions easily
+digress, making it even harder to come up with a solution.
+Another way is to use Savannah's built-in trackers (the @samp{Tasks} and
address@hidden trackers, specifically).  This is further explained in the
+next section, @pxref{Tracking Tasks}.  One way or another, you should
+create some kind of review process.
+* Tracking Tasks::              Using Savannah to track tasks and bugs.
+* Unreviewed Translations::     What to do with translations that are
+                                  not reviewed.
address@hidden menu
address@hidden Tracking Tasks
address@hidden How To Track Tasks and Bugs Using Savannah
+The team leader has to make sure that prospective translations are
+reviewed, that they do not contain obvious errors and/or confusing
+expressions and that they match the spirit and intention of the original
+essay.  However, many teams tend to suffer from a specific problem: team
+members rely on the leader to make these extensive reviews. That is
+fine, as far as it goes, and the leader should always review
+translations before installing them in the repository---but it is nearly
+impossible (especially for a large team) to rely on a single person for
+such tasks.  Team co-ordinators often do not manage to make such reviews
+in time, resulting in frustration among the team members and generally
+slowing the translation process.
+A solution to this specific problem is to distribute the load among more
+people.  For example: Member D makes a translation of @file{foo.html}
+and uploads @address@hidden in the translation project's
+repository at Savannah, marking the relevant task as ``Ready for Test''
+(of course, the equivalent is sending a message with the attached
+translation to the team's mailing list, or similar).  Then Member A, B
+and C (or only A and B if C is currently busy) review it independently
+and post comments/suggestions/errors in the bug tracker.  Discussion
+goes on between them and D, problems are rectified and finally the
+leader (who may happen to be one of A, B, C, D) makes a final review.
+It is easier to make the final review when most of the issues are
+already fixed in previous revisions.  Finally, the translation is
+published.  The result is better quality of the translation (since more
+people looked at it) and the whole burden does not fall solely on the
+shoulders of the leader.  You can also set up an internal formal rule:
+If a member makes a translation, he has to review another one (or two)
+as well.
+Some translations can take a fairly long time---the typical example is a
+complicated essay or a transcript of a speech.  It is best to avoid
+duplicate work by indicating, or better---recording, that someone is
+working on this specific article.  The @samp{Tasks} tracker is suitable
+for this purpose.
+It is prudent to discuss the most convenient naming scheme and practice
+among team members, and publish the convention and/or rules at the
+team's homepage.  Note that you can create @dfn{Custom Fields} in the
+trackers, and resolved bugs can be searched based on these custom
+Thus, a possible straightforward way to manage these tasks is:
+If someone starts working on a new translation, she creates a new task
+with a @samp{Subject} indicating the article, for example simply
address@hidden/bsd.html} and assigns it to herself.
+When the translation is finished and ready for review, the translator
+changes the @samp{Status} to ``Ready For Test''.
+Other members review it, and open bugs relevant to one specific problem.
+It is usually better not to conflate two different issues together---it
+makes them harder to discuss, and hard to track them by severity.  Some
+are grammatical errors, some are fundamental ones that change the whole
+meaning, some are simply suggestions for improvement.  It helps if the
+project admin creates new Category fields for every article, for
+instance @samp{gnu/address@hidden,
address@hidden/address@hidden would enable
+functionality like ``Show me all bugs ever reported against this
+translation'', which is useful.
+Once the bugs (or at least the important bugs) are fixed, the team
+leader can make the final review and install the translation in the
+official repository, marking the task as @samp{Done}.  Bugs that are not
+resolved should remain opened, naturally.
address@hidden itemize
+Of course, teams can choose to manage these things using external
+resources and eventually other bug (or issue) tracking systems.
+Whatever you decide, please make sure that bugs can be reported using
+free software only, and that the software providing that service is
+free.  It makes an extremely bad impression if a reader has to report a
+problem about a translation via non-free hosting platforms like
+SourceForge or Launchpad.
+If you use a certain facility (i.e. a bug tracking system) to manage
+bugs in translations, it is best to take advantage of
address@hidden@var{lang}.html} and advertise it on every page.
address@hidden, , , gnun, The GNUnited Nations Manual}, for
address@hidden Unreviewed Translations
address@hidden How To Proceed With Unreviewed Translations
+Sometimes a translation (typically your own) is not reviewed by anyone
+else for a fairly long time.  This is unfortunate, but there is no
+reason to keep it in draft state forever.  If nobody reviewed it for a
+substantially long period (like 3 or 4 months), commit it as it is.
+Readers may report bugs as well (and they do!).
+It is important to record somehow that this published translation still
+lacks appropriate review.  If the suggestion in the previous section is
+implemented, it would mean leaving the relevant task @samp{Open} and
address@hidden For Test} despite the translation being officially online.
+You may also add a comment to the PO file.
address@hidden Commits
address@hidden CVS Commits And Best Practices
+As all team leaders have write access to the CVS repository of the
address@hidden project, this technically means that they are able to modify
+every single file in it, and also those of the Web CVS repositories of
+other projects at Savannah.  This vote of confidence should never be
+abused---the only files team co-ordinators should add/update are those
+relevant to their translation work.  It is OK to fix an obvious typo in
+an original article; for anything else please report to}.
+If you wish to volunteer as webmaster and help with generic webmaster
+work and RT tickets, that is perfectly fine---please follow the
+established (by the @acronym{GNU} Webmasters) procedure.  If you are
+approved, you can modify such pages wearing your ``webmaster's hat''.
+If a particular page has issues with the markup which create problems
+for your language, please inform @email{}.
+For general issues that affect more articles, or for severe problems,
+please write to @email{}.
+It is recommended to read the entire CVS manual at least once, for a
+basic understanding of how this VCS works.  @xref{Top, Concurrent
+Versions System, , cvs, Version Management with CVS}.  It is not
+necessary to become an expert---the @samp{www} project does not use
+complex features like tags, vendor branches, merging, etc. as they are
+not very useful for a live website.
+However, you'd probably have to learn how to use CVS for effective
+work---to extract information from the history, review diffs and
+specific changes, synchronize with the working repository of the team
+(if any), adding/removing files, etc.
+If you make changes that affect more than one file but the change is
+coherent, please do it as a single commit.  This will generate only one
+message to @email{}, which is better than 5 messages
+for 5 files about semantically the same change.  Always write commit
+logs in address@hidden advice is applicable for the @samp{www}
+repository only---feel free to write logs in your native language when
+committing in your project's Sources repository.}, providing a short
+description of the change.  If you modify a file that is not an article
+but a script or part of software (such as @file{server/gnun/}),
+it would be nice to follow the GNU Coding Standards and describe the
+change precisely.  For example, do not write:
+Added support for Nepali.
address@hidden example
+Yay!  First commit of the Panjabi homepage!
address@hidden example
+Instead, write the log as follows:
address@hidden example
+(HOME_LINGUAS): Add `pa'.
address@hidden example
+This makes it easier for others to search for a particular change in the
+If you add a binary file (for example, @file{.png}), do it with
address@hidden commit -kb @var{file}}.  This turns off keyword substitution,
+which prevents RCS keywords like @address@hidden to get expanded,
+subsequently corrupting the file.  @xref{Substitution Modes, , , cvs,
+Version Management with CVS}.  More importantly, using @option{-kb}
+prevents corruption of the binary when people using CVS clients under
+Windoze checkout, modify the file, and then commit it with messed EOLs.
+(Unfortunately there are still committers using non-free operating
+systems---we cannot dictate what OS people use, but we can at least try
+to prevent damage.)
+Although not absolutely compulsory, it is recommended that every team
+leader subscribes to @email{}.  It is useful to
+examine the diffs of your own messages, if you miss something while
+inspecting the diff before the commit.  In any case, a team leader
+should be subscribed to that list to avoid his own commit messages to be
+moderated.  If you absolutely do not desire receiving all traffic, just
+disable mail delivery in Mailman's user interface.
address@hidden Savannah
address@hidden Taking Advantage of Savannah
+Every translation team should have a project in Savannah.  There are
+some teams that use their own resources outside from Savannah; although
+there's no obligation to use Savannah for team work, the need for a
+Savannah project for each language is obvious: it's a standard way to
+find information for translation teams and their contacts.
+Using external hosting facilities is sometimes justified---for example,
+some languages have a single mailing list for all free software-related
+translations, where all translators co-operate.  Others have already
+established repositories and/or bug tracking systems where usual
+contributors already have access.  Some team members prefer to work
+within the established infrastructure of a broad translation team (for
+whatever reason), and this is entirely acceptable.  However, it is
+important to remember that regardless of the technical resources which a
+team decides to use, the responsibility of the team co-ordinator remains
+the same.
+Those teams that are using Savannah have a broad variety of tools at
+hand: team membership management, documents, trackers (bugs, tasks and
+support), alerts, CVS (and any other VCS that Savannah supports), home
+pages, mailing lists, etc.  How each team uses these resources is up to
+the team itself, but it often turns out to choose Savannah for nearly
+all of the team activities, as it requires almost zero work; the
+Savannah Hackers are happy to support us.
+Whatever you (in your capacity as a team leader) decide, please do it
+with caution: some organizational decisions may become ineffective as
+time goes by, and some may not scale well when the team grows.  If the
+team is young and has a couple of members, it is better to refrain from
+such decision and discuss them with all the members when their number
+grows.  Two or three people do not need a rocket platform or complex
+wizardry to do their work.
+The next sections contain suggestions about how a team can use the
+facilities provided by Savannah.  It is not mandatory to follow them,
+they are just suggestions.
+* Savannah Members::
+* Savannah Homepage::
+* Savannah Support::
+* Savannah Tasks::
+* Savannah Bugs::
+* Savannah Patch::
+* Savannah News::
+* Savannah Mailing Lists::
+* Savannah VCS::
address@hidden menu
address@hidden Savannah Members
address@hidden Managing Members
+You should add active translators as members of the translation team,
+and remove them when they leave.  Team members should have access to all
+of the project's resources, and tracking their number is one of the ways
+for web-translators to determine the status of the team.
+It is OK if a particular contributor wants to translate an article or
+two and does not want to be engaged with the team on a long-term basis.
+In such situations, there is no need to add her as a member.
+It is a good idea to mark inactive members, for example if there is no
+interaction (bug reports, new translations, updates to existing
+translations, proof-reading) for at least six months.  You can do that
+by unmarking the @samp{On Duty} checkbox for the respective project
+member under @samp{Set Permissions}.  Inactive members have absolutely
+the same rights as active ones---the only exception is that they don't
+count for the total number of members, and they appear separately on
address@hidden Members}.
address@hidden Savannah Homepage
address@hidden Homepage of The Team
+Every Savannah project has a Web repository, which is, for technical and
+historical reasons, only CVS.  By default it is mapped to
+to add files to it first make a checkout, following the instructions at
+It is recommended to describe all team-specific procedures, if there are
+any.  That way, you can point potential team members to the
+corresponding page containing these instructions, instead of repeatedly
+explaining every volunteer separately.
+All team-specific pages should follow the usual linking criteria (see
+and the FSF HTML Style Sheet
+For historical reasons, team-specific materials were available in the
address@hidden repository, under ad-hoc locations as @file{/spanish},
address@hidden/wwwsr}, etc.  These locations are deprecated, and the contents
+will be moved without warning to @file{/graveyard} in the
address@hidden @emph{Sources} repository, following the original
address@hidden layout (that is, if there were any sub-directories, they will
+be retained).
address@hidden Savannah Support
address@hidden Support Tracker
+This tracker is supposed to be related to things about the @emph{project
+management} itself, i.e. project members may report here missing
+functionality and/or features that requires the project admin(s)'s
+action.  Do not use it for anything else as it quickly becomes
+confusing.  It is OK to disable it if the team is small.
address@hidden Savannah Tasks
address@hidden Tasks Tracker
+This is a way to manage all sorts of tasks.  They appear in the personal
+Savannah page of the assignee, so it is difficult to miss them out.  It
+is possible to use this tracker to ``announce'' to the team members that
+a specific article should be translated.  The one who volunteers may
+assign the task to herself.
+Teams may use this tracker to avoid duplicate work, by declaring that
+they intend to work on a specific translation.
+Feel free to organize the @samp{Tasks} management as you see fit.
address@hidden Savannah Bugs
address@hidden Bugs Tracker
+The @samp{Bugs} tracker is designed for tracking bugs.  You can use for
+several purposes:
+Suggest readers to report bugs there.
+Use it for all kinds of internal team tasks.
+Forward bugs reported against @var{lang} translations in the
address@hidden project and assign them to the specific maintainer
+(who is supposed to be a @address@hidden project member), if you
+have such policy.
address@hidden itemize
address@hidden Savannah Patch
address@hidden Patch Tracker
+This tracker doesn't make much sense for translation projects, as the
+original on which the translation is based is volatile and the
+translation @dfn{patch} is 100% guaranteed not to apply cleanly very
+soon after it is submitted.  Even ignoring this detail, this specific
+feature is slowly marching towards complete deprecation, as there are
+much better ways to submit patches nowadays.
+You should disable this feature, as it causes only confusion.
address@hidden Savannah News
address@hidden News Tracker
+That is a way to inform newcomers and interested people (who visit the
+project page from time to time, or subscribe to the @samp{News} RSS
+feed) about a major change or event within the project.
+You can also setup news entries to be sent to a mailing list (that's
+possible for the other trackers as well).
+The purpose of this feature is informational---if members need to know
+about an important change (in practices, procedures, etc.), it is
+perfectly OK to announce it here.  Some teams use it to announce new
+translations, which is also fine.
address@hidden Savannah Mailing Lists
address@hidden Managing Mailing Lists
+You can create new mailing lists via the Savannah interface.  However,
+this should be done after some thought.  If the project membership is
+low (<= 10 members), there is no need to create more than one mailing
+list.  If there is a general translation list common for all translators
+of the language (i.e. GNOME, GNUstep, KDE, and free software in
+general), there is no reason at all to create a list at Savannah.
+You can redirect all messages generated by the trackers to any list
+(including those that are not on GNU servers).
address@hidden Savannah VCS
address@hidden Version Control Systems
+An easy way to keep up with changes in the original articles and to
+manage continuous contributions is to keep all translations in the
+translation project's Sources repository.  That way, it is easy to edit
+draft translations and install them in @samp{www} only when they're
+ready.  It is also convenient to update the translation (merge any
+changes from the original) while it is still under review.
address@hidden Files and Team, , , gnun, The GNUnited Nations Manual}, for
+more information.
address@hidden:} A choice of a particular VCS is a sensitive
+matter---some modern ones provide compelling features, but they also
+bump the barrier for participation higher.  The VCS is supposed to ease
+collaborative maintenance---if it eases only you, project members just
+won't use so that won't be a net win.
address@hidden Co-leaders
address@hidden Promoting Members As Co-leaders
+When the team grows large and it becomes hard for a single person to
+manage, there is no problem to add another (or even another two) people
+to help.  Note that a subsequently appointed team co-ordinator is not
+simply a @dfn{committer} with write access to the @samp{www} repository;
+she has full responsibilities just like a single leader, although the
+latter still remains the primary contact for the team.
+If you'd like another person to act as a co-leader and help you with the
+management tasks, send a message to @email{}
+with her name and Savannah account.  She has to be already a member of
+The procedure for co-leaders is a simplified version of the one for a
+new team or taking over an existing team.  @xref{New Team}.
+To remove co-ordinators, please write to} with details and rationale for the
+removal.  Do not edit @file{README.translations.html} yourself; this is
+a final formality step to be performed by the Translation Managers.
address@hidden Reports
address@hidden Reporting Team Status
+Team leaders must send an annual report about the status of the team.  A
+good report should include:
+General information about the team's accomplishments during the past
+year, like:
address@hidden @minus
+A list of new translations.
+New members since the last report.
+Current active members.
+Solved problems and other issues, if any.  (Usual bug reports and other
+improvements/fixes to the existing translations do not count as
address@hidden in this sense.)
address@hidden itemize
+Current problems (technical or social), conflicts, and ideas for sorting
+them out.
+Anything else you consider important or worth mentioning.
address@hidden itemize
+The best time to send a report is near the end of the year, for example
+November.  In any case, please do not send it later than December 15th,
+as the Translation Manager has to prepare a general report to the FSF,
+and it is better if it takes into account the reports of the team
+If there is no sensitive information in the report and you feel like
+sharing it, you can send it to @email{}
+(which is still a private mailing list).  That way, other list readers
+may help with suggestions how to solve a particular issue.  Informing
+each other about the progress improves the community spirit.
+If you do not wish to share some information that is in the report,
+please send it to @email{}.
address@hidden Stepping Down
address@hidden How To Retire Painlessly
+When you feel you don't have the energy to manage the team successfully,
+or perhaps you start losing motivation, please inform}.  It would be substantially easier if
+you try to find a replacement or recommend a specific person---we will
+try to find someone in any case, but your judgment is important and it
+will be considered with priority.
+An excellent way to step down is to do it with a ``plan''---suggest the
+person you consider capable of doing the job as co-leader
+(@pxref{Co-leaders}) and retire completely when she is absolutely ready
+to proceed without your further help and advice.
address@hidden Translation Managers
address@hidden @samp{trans-coord} Admins
+This chapter is not yet written.  The current admins know what to do,
address@hidden Translation Tips
address@hidden Details About The Translation Process
+The purpose of this chapter is to summarize some odd and not so obvious
+details about specific parts of the website.  Most of them
+become well known as time goes by; however, practice shows that it is
+difficult to figure them out at once.
+Some limitations and oddities are just historical remnants from old
+habits and previous incarnations of old (inefficient) translation and
+webmastering processes.  Others are outright deficiencies
+(i.e. ``bugs''), but no one has stepped in to correct them so far.
+* Migrating::           How to migrate to the new style.
+* SSI::                 Overview of SSI #include directives.
+* CSS::                 General advice how to use CSS.
+* Priorities::          What to translate as a priority.
+* Capitalization::      To CAPITALIZE or not?
+* Terminology::         Dealing with terminology issues.
address@hidden menu
address@hidden Migrating
address@hidden Migration To The New Style
+Migration to the new style should be straightforward, and this is one of
+the problems @acronym{GNUN} set out to solve.  If you have to migrate
+old-style translations, @pxref{Migrating, , , gnun, The GNUnited Nations
+Manual}.  If the old translation is HTML 2.0 (or 3.2), you still have to
+take care about the inner markup.  Overall, it is substantially easier
+than doing all of it manually.
+Subsequent migrations to newer (X)HTML standards and newer look and feel
+of the website are supposed to happen semi-automatically, although this
+manual will be updated as needed.
address@hidden SSI
address@hidden Summary of SSI @code{#include}s
+The GNU Project's website uses @acronym{SSI} (Server Side Includes) to
+manage some common parts that are the same in many of the articles.
+With the help of @acronym{GNUN} their handling should be behind the
+scenes, but for some of them manual intervention is needed.  Here is a
+(possibly incomplete) list of the @code{#include}'s used:
address@hidden @file
address@hidden server/banner.html
+This is the file containing the menus, the FSF widget, and any visible
+announcements made from time to time.  If a string gets ``fuzzy'' or
+``new'' here, it will appear in English in all translations, until
address@hidden/po/address@hidden is updated.  Note that some
+validation errors originate from an error in
address@hidden server/footer-text.html
+This is a very short file currently containing the ``back to top'' link.
+Also translatable via @acronym{GNUN}.
address@hidden server/header.html
+The declaration that is included in literally every file.  It is
+maintained manually, as it does not make much sense to put it under
address@hidden's control (there are no translatable strings).  Remember
+to specify the proper @code{xml:lang} and @code{lang} attributes, and
+for RTL languages, the @code{dir} attribute.  For example, the file
address@hidden should contain this line:
+<html xmlns=""; xml:lang="ar" lang="ar"
+      dir="rtl">
address@hidden example
address@hidden server/footer.html
+This is a very short and simple file (at least at the time of writing),
+containing another @code{#include} directive.  It is maintained
+manually, so just add @var{lang} to the filename, in order the localized
address@hidden@var{lang}.html} to be included.
address@hidden translations.include
+The list of translations for the homepage (and only the homepage).  It
+is maintained manually; in order the link to a translation to appear on
+all of the homepages, it has to be present here.
address@hidden gnusflashes.include
+A portion of the most recent 3 news items from
address@hidden/whatsnew.html}, generated automatically.  If your language
+does not have @file{server/po/address@hidden, this file will be
+used.  Otherwise, if there is an existing localized homepage and you
+commit @address@hidden, the homepage will be rebuilt to
+include the translated @address@hidden
address@hidden server/whatsnew.include
+Generated automatically, this file is included from
address@hidden/whatsnew.html}.  Translations are built automatically, and
+the localized @file{gnusflashes.include} is derived from it.
address@hidden licenses/gpl-3.0-body.html
address@hidden licenses/fdl-1.3-body.html
address@hidden @dots{}
+Some of the licenses have the text of the license itself separated in
+another file.  This serves two purposes: 1) to provide a ``standalone''
+HTML version of the license without the style; 2) to prevent
+strings sneaking in the @file{.pot} files, as licenses have only
+unofficial translations, hosted elsewhere.  Nothing special should be
+done about these SSI directives; the files generated by @acronym{GNUN}
+include them verbatim as they should not be translated.
address@hidden server/sidebar*.html
+These files are deprecated---they are remnants from an older design that
+lived shortly in the middle between the old classic design and the
+current one.  If all translations are successfully migrated and none of
+them includes such files, you should delete them.  You can use
address@hidden to check this.
address@hidden table
+The files @file{header.html}, @file{banner.html}, @file{footer.html} and
address@hidden in the @file{server} sub-directory are what
+webmasters call ``the server templates''.  These files are included in
+almost every article, translated or not.  They are somewhat important,
+as an error made in translating them propagates everywhere.  The server
+templates, the homepages, and whatsnew (a.k.a. ``GNU News'') are being
+rebuilt by @acronym{GNUN} whenever there is a change in the original
+English files; the @code{GRACE} variable has no effect for them.
address@hidden Variables, , , gnun, The GNUnited Nations Manual}.
address@hidden CSS
address@hidden How To Use Custom CSS
+The file @file{style.css} gets included in almost all the English
+articles.  It includes two other files, which form the actual CSS style
+used.  However, this style is seldom right for translations---many
+languages have much longer expressions, and that is natural.  To include
+your own CSS, create a file @address@hidden and add it
address@hidden the original @file{style.css} in your
address@hidden/po/address@hidden, i.e.
+# type: style
+msgid "@@import url('/style.css');"
+msgstr ""
+"@@import url('/style.css');\n"
+"@@import url('/');"
address@hidden example
+Override only what is necessary and looks broken in your language; do
+not invent your own style.  This is important for the consistency of the website.  A typical language-specific
address@hidden@var{lang}.css} file looks like this:
+.inner @{ max-width: 65em; @}
address@hidden:url(/graphics/ no-repeat;@}
+#fssbox @{font-size: 50%;@}
address@hidden example
+This widens the menu and the area where the articles are displayed
+(because the menu entries are @emph{much} longer than the English
+equivalents when translated), includes a localized logo, and makes the
+font size for the FSF widget twice smaller (because in this language,
+the translations are almost twice longer and displayed truncated, which
+is undesirable).
+When creating your own @address@hidden, don't forget to
+include the license notice from the @file{style.css}, with a short
+* topbanner::           How to localize the topbanner image.
+* RTL::                 Special notes about RTL languages.
address@hidden menu
address@hidden topbanner
address@hidden Localizing The @file{topbanner} Image
+If you'd like the nice gnu image to be localized (i.e. ``GNU Operating
+System'' to appear in your native language, here are the steps:
+Copy @file{graphics/topbanner.svg} as
address@hidden/address@hidden where @var{lang} is the
+language code, as usual.  Edit the file with Inkscape or with a plain
+text editor such as GNU Emacs, translating ``GNU Operating System''.
+Then with Inkscape, save the file as
address@hidden/address@hidden (File -> Export address@hidden).
+Then open the PNG image with the GIMP and flatten it (Image -> Flatten
+Image).  Don't forget to save and @code{cvs add} the address@hidden
+advice applies to all new files, of course.}.
+Create a @address@hidden at the toplevel directory, if it
+doesn't exist already.  Normally, you would need only one line in it,
address@hidden:url(/graphics/address@hidden) no-repeat;@}
address@hidden example
+If not done already for other reasons, update
address@hidden@var{lang}.po} to include the language specific
address@hidden@var{lang}.css}.  @xref{CSS}.
address@hidden enumerate
+If you feel uncomfortable manipulating images---don't despair!  Send a
+plea for help to @email{}, some people would
+be happy to help you.  Failing that, write to}.
address@hidden RTL
address@hidden Specific Issues Related to RTL
+Unfortunately, the @uref{} website does not have excellent
+support for RTL (right-to-left) languages, although best efforts are
+made.  If your language is in this category, make sure to:
+Set the attribute @code{dir="rtl"} in the @code{html} element at
+You @emph{must} have a custom CSS to override some of the pre-defined
+values.  See @file{} and @file{style.fa.css} to understand
+how these two languages solve some of the problems.  @xref{CSS}.
address@hidden itemize
address@hidden:} Some articles contain their own @code{<style>}
+redefinitions, or style attributes in the form @code{<p
+style="@dots{}">}.  In such situations, it is quite possible that the
+general language-specific CSS does not help, and the translation of this
+specific article does not look correct.  Please write to}; if you have a working solution
+that works for both cases---so much the better.  For general issues that
+affect your language and require a general solution, write to} or @email{}, precisely
+describing the problem.
address@hidden Priorities
address@hidden What To Translate
+The article
+lists the most important essays to translate.  In general, articles in
+the directories @file{philosophy}, @file{gnu}, @file{copyleft} and
address@hidden are important.  The others may be deferred for a time
+when a team completes most of the important translations, or they can be
+translated as a ``rest''--in translators' parlance this means doing
+something in between which is typically easier to handle.
address@hidden not} translate articles under these directories:
address@hidden @file
address@hidden software/@var{pkg}/
+These pages are maintained by the respective @var{pkg} maintainers.
address@hidden does not support them for the time being, as they reside
+in separate repositories.  The procedures for contributing translations
+of such articles are not yet settled.
address@hidden brave-gnu-world
+The Brave GNU World initiative has been abandoned long time ago, and
+it's in a separate repository---thus not supported by the automatic
address@hidden build job.
address@hidden home.shtml
+There is not problem to translate this page, but don't make the mistake
+to pick it up as your first translation.  It is modified often,
+sometimes intensively, and only active team members should take that
address@hidden server/whatsnew.html
+This is ``What's New'', also known as ``GNU's Flashes'', also known as
+``GNU News''.  Translate it only if the team has sufficient manpower to
+catch up---new entries appear immediately on the homepages.  You might
+want to subscribe to @email{} in case you
+maintain localized @samp{gnunews}.
address@hidden table
address@hidden Capitalization
address@hidden When To CAPITALIZE
+The English language has strict rules for capitalization of titles,
+chapters, acronym expansions and the like.  They do not make sense for
+many other languages, but unfortunately, many translators
address@hidden duplicate} the capitalization in their translation.
+Examples for common (and correct) English capitalization is the title of
+the article ``Why Software Should Be Free'' or ``Free Software
+Foundation'' (FSF).  However, in languages that do not have such grammar
+rules it is wrong to write ``Dlaczego Oprogramowanie Powinno By@'c
+Wolne'' (Polish) or ``Fondation Pour Le Logiciel Libre'' (French).
+Another prominent and widely spread mistake is to write your own
+language with a capital letter in the @code{translations-list} when
+languages are written beginning with a small letter according to your
+own rules.  In other words, it is right to write @samp{English} or
address@hidden (because in English and German languages are
+capitalized), but not @samp{Fran@,{c}ais} or @address@hidden
+them as @samp{fran@,{c}ais} or @address@hidden, respectively.
address@hidden Terminology
address@hidden Language-specific Terminology
+This is a very important topic, not yet covered by this manual.
address@hidden Summary
address@hidden Overview Of The Translation Process
+In general, it is expected that all participants in the translation
+process apply common sense for all of the decisions (important or not)
+they are going to take in their capacity as a manager, team leader, or
+contributing member.  Certainly, many decisions are not easy, and
+require some thought.
+This manual is a work in progress---it is not set in stone, and it will
+never be finished---the ultimate goal is to constantly improve the
+translation process, and as a consequence, the documentation.  Every
+participant in the process should be free to suggest modifications to
+the current procedures and suggestions how to improve the current state
+of affairs.  Ideally, they should be accompanied with patches to the
+Texinfo source, but that's not mandatory.  In any event, please write to}---the goal of this list is
+precisely to discuss improvements of  the translation process.
+* Mailing Lists::      Summary of mailing lists.
+* Savannah Projects::  Projects' membership.
address@hidden menu
address@hidden Mailing Lists
address@hidden Related Mailing Lists
+Here is a short summary of the mailing lists relevant to the translation
+process, and a brief description about how they relate to the various
+participants in the process.
address@hidden @email
+The basic discussion list of the @acronym{GNU} Webmasters.  All team
+leaders are required to subscribe.
+This is a private mailing list.
+Commits to the @samp{www} repository are sent here.  All Translation
+Managers are required to subscribe.  It is strongly recommended that
+team leaders subscribe---in any case they should, and mail delivery can
+be disabled personally.
+This is a public mailing list, so everyone can subscribe and review the
+archives.  The @samp{www} CVS repository is also public.
+The main discussion list for the @acronym{GNU} Web Translators.  Team
+leaders must subscribe, as errors from @acronym{GNUN} are mailed here.
+Team members are welcome to join as well, provided they are already
+members of @address@hidden If they want to subscribe with a
+different email address, a verification from the team leader is
+This is a private mailing list, although there is no absolute reason for
+that.  It may become public in the future.
+This is a list for notifications about gnunews and @acronym{GNU}nited
+Nations releases.  It is not mandatory to subscribe to it, although the
+traffic is very low.  If you want to track only @acronym{GNUN} release
+announcements, subscribe to the @samp{gnun} keyword via Mailman's user
+interface.  In the near future, there will be automatic announcements
+for newly available English articles and translations.
+This is a public mailing list.
+All development of @acronym{GNUN} happens here.  Most of the traffic is
+build logs from the various @acronym{GNUN} automatic builds, so it is
+not a very pleasant thing to be subscribed, especially if you are not
+interested in its internals.  However, everyone can use the web archives
+to check the log why a particular article was not built at expected.
+This is a public list, and @email{} is an alias.
address@hidden table
address@hidden Savannah Projects
address@hidden Savannah Projects Membership
+Participants in the translations process normally have to be
+members of the following Savannah projects, depending on the case:
address@hidden @samp
address@hidden www
+The main project which hosts the @samp{} Web repository.
+Administrators are the Chief Webmaster, entrusted webmasters and the
+Translation Manager (in order to approve leader's applications).  All
+team leaders (and co-leaders) should be members of this project.
+Note that this project has no direct relationship with translators,
+although anything happening in @samp{www} directly affects them.  The
address@hidden project is managed separately and has a different (entirely
+unrelated) process for approving contributors.
address@hidden trans-coord
+An organizational project especially created for coordination and
+improvement of the translation process.  All team leaders are required
+to be members, as bugs reported to @email{} are
+often redirected to the @samp{trans-coord} @samp{Bugs} tracker.
+The admins of this project are the @acronym{GNU} Web Translation
address@hidden address@hidden
+All translation team leaders of the language @var{lang} should be
+members of the project @address@hidden  The admins of the project
+are the team leader and the co-leaders, if any.
address@hidden table
address@hidden Copying This Manual
address@hidden GNU Free Documentation License
address@hidden fdl.texi
+FIXME: To be restored when indexing commands are added.
address@hidden Index
address@hidden Index
address@hidden cp
address@hidden ignore
+Local Variables:
+eval: (add-hook 'write-file-hooks 'time-stamp)
+time-stamp-start: "@set lastupdate "
+time-stamp-end: "$"
+time-stamp-format: "%02d.%02m.%:y"
+compile-command: "texi2pdf -c web-trans.texi"
+ispell-local-dictionary: "american"

reply via email to

[Prev in Thread] Current Thread [Next in Thread]