[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
gnun/server/gnun/doc: Makefile.am
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/Makefile.am (info_TEXINFOS): Add web-trans.texi.
(web_trans_TEXINFOS): New variable.
* NEWS: Update.
CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/trans-coord/gnun/server/gnun/ChangeLog?cvsroot=trans-coord&r1=1.131&r2=1.132
http://cvs.savannah.gnu.org/viewcvs/trans-coord/gnun/server/gnun/NEWS?cvsroot=trans-coord&r1=1.6&r2=1.7
http://cvs.savannah.gnu.org/viewcvs/trans-coord/gnun/server/gnun/doc/Makefile.am?cvsroot=trans-coord&r1=1.1&r2=1.2
http://cvs.savannah.gnu.org/viewcvs/trans-coord/gnun/server/gnun/doc/web-trans.texi?cvsroot=trans-coord&rev=1.1
Patches:
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/Makefile.am (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)
** GNUmakefile.team supports Subversion repositories.
@@ -18,6 +18,19 @@
use the latest version without the need to copy them manually every
time.
+** 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 http://gnu.org/server/standards/translations/ 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/Makefile.am
===================================================================
RCS file: /sources/trans-coord/trans-coord/gnun/server/gnun/doc/Makefile.am,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -b -r1.1 -r1.2
--- doc/Makefile.am 20 Jan 2009 21:31:33 -0000 1.1
+++ doc/Makefile.am 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 <http://www.gnu.org/licenses/>.
-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 web-trans.info
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
address@hidden %**end of header
+
address@hidden Please do not use features of Texinfo >> 4.11, which is the
version
address@hidden available in gNewSense. Thanks.
+
address@hidden
+
+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.
+
address@hidden
+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
address@hidden GNU Web Translators Manual
address@hidden Documentation for translators of www.gnu.org
address@hidden (last updated @value{lastupdate}, for GNUnited Nations version
@value{VERSION})
address@hidden by Yavor Doganov <@email{yavor@@gnu.org}>
address@hidden
address@hidden 0pt plus 1filll
address@hidden
address@hidden titlepage
+
address@hidden
+
address@hidden GNU organization
address@hidden
+* GNU Web Translators: (web-trans). Guidelines and procedures for
+www.gnu.org translators.
address@hidden direntry
+
address@hidden
address@hidden Top
address@hidden GNU Web Translators Manual
address@hidden
address@hidden ifnottex
+
address@hidden
+* 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 www.gnu.org 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{http://gnu.org} 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.
+
address@hidden
+* 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
address@hidden://www.gnu.org/@/server/@/standards/@/README.translations.html#TranslationsUnderway}.
+Chances are that there is already an established team. If there is no
+team listed for your language, this means that:
+
address@hidden
address@hidden
+There is no team established and there are no translations to this
+language.
+
address@hidden
+Some translations were submitted by occasional contributors, but no team
+has ever been formed.
+
address@hidden
+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{web-translators@@gnu.org}
+(@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
+being
address@hidden://savannah.gnu.org/@/projects/@/address@hidden
+Usually teams have mailing lists, either on Savannah or on some external
+site. Some teams have homepages,
address@hidden://gnu.org/@/server/@/standards/@/translations/@var{lang}}
+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{web-translators@@gnu.org}.
+
+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.
+
address@hidden
+* 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://www.gnu.org/@/software/@/gnun/}), 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 gnu.org are installed in
address@hidden format, and the @file{.html} is generated automatically.
+Here are the steps to produce and submit such a translation:
+
address@hidden
address@hidden
+Make a checkout of the CVS Web repository of the @samp{www} Savannah
+project. You can find generic instructions at
address@hidden://savannah.gnu.org/@/cvs/@/?group=www}. 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:
+
address@hidden
+cvs -z3 -d:pserver:anonymous@@cvs.savannah.gnu.org:/web/www co www/gnu
address@hidden example
+
+This command will fetch only the @file{/gnu} directory---in other words,
+all articles at @uref{http://gnu.org/gnu}.
+
address@hidden
+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}.
+
address@hidden
+When you are pleased with the translation, check that the PO file is
+valid and submit it to @email{web-translators@@gnu.org}, attached to
+your message. The web-translators will review (to the best of their
+ability) the translation and will install it in the repository.
+
address@hidden
+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/gnun.mk}, 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
+essay.
+
+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,
+OpenOffice.org (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{http://www.gnu.org/@/philosophy/@/free-sw.html}
+that would be:
+
address@hidden
+The Free Software Definition - GNU Project - Free Software Foundation (FSF)
+
+We maintain this free software address@hidden
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:
+
address@hidden
+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{web-translators@@gnu.org},
+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 gnu.org 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.
+
address@hidden
+* 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 gnu.org translation team for your
+language is a must, and you are the one for this job, follow these
+steps:
+
address@hidden
address@hidden
+If you do not have a Savannah account, register at
address@hidden://savannah.gnu.org/@/account/@/register.php}. Write access
+to the repository and project membership is handled via Savannah, so you
+would need an account in any case.
+
address@hidden
+Checkout a complete working copy of the CVS Web repository as described
+at @uref{https://savannah.gnu.org/@/cvs/@/?group=www}. 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.
+
address@hidden
+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/gnun.mk}. If it is not, the first thing to do is to
+translate and submit to @email{web-translators@@gnu.org} 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
address@hidden
+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}.
+
address@hidden
+The PO file header and initial comments should be completed as
+documented.
+
address@hidden
+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ü} and this is a character from the alphabet of your
+language, just write it as @samp{@"u} directly.
address@hidden itemize
+
address@hidden
+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:
+
address@hidden
+find -name address@hidden
address@hidden example
+
address@hidden
+Submit at least two translations of your own. We maintain a list with
+priority articles at
address@hidden://www.gnu.org/@/server/@/standards/@/translations/@/priorities.html},
+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
address@hidden@@gnu.org}.
+
address@hidden
+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.
+
address@hidden
+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.
+
address@hidden
+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{https://savannah.gnu.org/@/register/} 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
address@hidden@@gnu.org} to do so. Otherwise, the submission
+may appear in the task list of the Savannah Hackers for a fairly long
+time, which is troublesome.
+
address@hidden
+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
+www-commits
+
address@hidden
+trans-coord-discuss
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{trans-coord-discuss@@gnu.org} 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.
+
address@hidden
+* 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{http://gnu.org}
+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 gnu.org 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.
+
address@hidden
+* 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
+values.
+
+Thus, a possible straightforward way to manage these tasks is:
+
address@hidden
address@hidden
+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.
+
address@hidden
+When the translation is finished and ready for review, the translator
+changes the @samp{Status} to ``Ready For Test''.
+
address@hidden
+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.
+
address@hidden
+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 gnu.org 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
+details.
+
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
address@hidden@@gnu.org}.
+
+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{trans-coord-discuss@@gnu.org}.
+For general issues that affect more articles, or for severe problems,
+please write to @email{www-discuss@@gnu.org}.
+
+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{www-commits@@gnu.org}, 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/gnun.mk}),
+it would be nice to follow the GNU Coding Standards and describe the
+change precisely. For example, do not write:
+
address@hidden
+Added support for Nepali.
address@hidden example
+
+or
+
address@hidden
+Yay! First commit of the Panjabi homepage!
address@hidden example
+
+Instead, write the log as follows:
+
address@hidden
+(TEMPLATE_LINGUAS): Add `ne'.
address@hidden example
+
+and
+
address@hidden
+(HOME_LINGUAS): Add `pa'.
address@hidden example
+
+This makes it easier for others to search for a particular change in the
+history.
+
+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{www-commits@@gnu.org}. 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.
+
address@hidden
+* 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
address@hidden://www.gnu.org/@/server/@/standards/@/translations/@/@var{lang}};
+to add files to it first make a checkout, following the instructions at
address@hidden://savannah.gnu.org/@/cvs/@/address@hidden
+
+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
address@hidden://gnu.org/@/server/@/standards/README.webmastering.html#pollinking}
+and the FSF HTML Style Sheet
address@hidden://gnu.org/@/server/@/fsf-html-style-sheet.html}).
+
+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:
+
address@hidden
address@hidden
+Suggest readers to report bugs there.
+
address@hidden
+Use it for all kinds of internal team tasks.
+
address@hidden
+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{web-translators@@gnu.org}
+with her name and Savannah account. She has to be already a member of
address@hidden@var{lang}}.
+
+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
address@hidden@@gnu.org} 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:
+
address@hidden
address@hidden
+General information about the team's accomplishments during the past
+year, like:
+
address@hidden @minus
address@hidden
+A list of new translations.
+
address@hidden
+New members since the last report.
+
address@hidden
+Current active members.
+
address@hidden
+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
+
address@hidden
+Current problems (technical or social), conflicts, and ideas for sorting
+them out.
+
address@hidden
+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
+leaders.
+
+If there is no sensitive information in the report and you feel like
+sharing it, you can send it to @email{trans-coord-discuss@@gnu.org}
+(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{web-translators@@gnu.org}.
+
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
address@hidden@@gnu.org}. 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,
+hopefully.
+
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 gnu.org 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.
+
address@hidden
+* 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/address@hidden
+
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:
+
address@hidden
+<html xmlns="http://www.w3.org/@/1999/@/xhtml"; 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 gnu.org 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.
+
address@hidden
+# type: style
+msgid "@@import url('/style.css');"
+msgstr ""
+"@@import url('/style.css');\n"
+"@@import url('/style.bg.css');"
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
+gnu.org website. A typical language-specific
address@hidden@var{lang}.css} file looks like this:
+
address@hidden
+.inner @{ max-width: 65em; @}
+
address@hidden:url(/graphics/topbanner.bg.png) 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
+comment.
+
address@hidden
+* 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:
+
address@hidden
address@hidden
+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.}.
+
address@hidden
+Create a @address@hidden at the toplevel directory, if it
+doesn't exist already. Normally, you would need only one line in it,
+namely:
+
address@hidden
address@hidden:url(/graphics/address@hidden) no-repeat;@}
address@hidden example
+
address@hidden
+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{trans-coord-discuss@@gnu.org}, some people would
+be happy to help you. Failing that, write to
address@hidden@@gnu.org}.
+
address@hidden RTL
address@hidden Specific Issues Related to RTL
+
+Unfortunately, the @uref{http://gnu.org} 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:
+
address@hidden
address@hidden
+Set the attribute @code{dir="rtl"} in the @code{html} element at
address@hidden/address@hidden
+
address@hidden
+You @emph{must} have a custom CSS to override some of the pre-defined
+values. See @file{style.ar.css} 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
address@hidden@@gnu.org}; 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
address@hidden@@gnu.org} or @email{webmasters@@gnu.org}, precisely
+describing the problem.
+
address@hidden Priorities
address@hidden What To Translate
+
+The article
address@hidden://www.gnu.org/@/server/@/standards/@/translations/@/priorities.html}
+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
+road.
+
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{trans-coord-news@@gnu.org} 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
address@hidden@@gnu.org}---the goal of this list is
+precisely to discuss improvements of the translation process.
+
address@hidden
+* 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
address@hidden www-discuss@@gnu.org
+The basic discussion list of the @acronym{GNU} Webmasters. All team
+leaders are required to subscribe.
+
+This is a private mailing list.
+
address@hidden www-commits@@gnu.org
+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.
+
address@hidden trans-coord-discuss@@gnu.org
+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
+required.
+
+This is a private mailing list, although there is no absolute reason for
+that. It may become public in the future.
+
address@hidden trans-coord-news@@gnu.org
+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.
+
address@hidden trans-coord-devel@@gnu.org
+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{bug-gnun@@gnu.org} is an alias.
address@hidden table
+
address@hidden Savannah Projects
address@hidden Savannah Projects Membership
+
+Participants in the www.gnu.org 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{gnu.org} 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{web-translators@@gnu.org} are
+often redirected to the @samp{trans-coord} @samp{Bugs} tracker.
+
+The admins of this project are the @acronym{GNU} Web Translation
+Managers.
+
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
+
address@hidden
+FIXME: To be restored when indexing commands are added.
address@hidden Index
address@hidden Index
+
address@hidden cp
address@hidden ignore
+
address@hidden
+
+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"
+End:
| [Prev in Thread] |
Current Thread |
[Next in Thread] |
- trans-coord/gnun/server/gnun ChangeLog NEWS doc...,
Yavor Doganov <=