trans-coord-devel
[Top][All Lists]
Advanced

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

trans-coord/gnun/prep/gnun ChangeLog TODO fdl.t...


From: Yavor Doganov
Subject: trans-coord/gnun/prep/gnun ChangeLog TODO fdl.t...
Date: Sat, 09 Feb 2008 17:06:53 +0000

CVSROOT:        /cvsroot/trans-coord
Module name:    trans-coord
Changes by:     Yavor Doganov <yavor>   08/02/09 17:06:53

Modified files:
        gnun/prep/gnun : ChangeLog TODO 
Added files:
        gnun/prep/gnun : fdl.texi gnun.texi 

Log message:
        That's no skeleton, it's a space station!
        * gnun.texi: New file; basic skeleton of the documentaiton.
        * fdl.texi: Import from the canonical location.

CVSWeb URLs:
http://cvs.savannah.gnu.org/viewcvs/trans-coord/gnun/prep/gnun/ChangeLog?cvsroot=trans-coord&r1=1.39&r2=1.40
http://cvs.savannah.gnu.org/viewcvs/trans-coord/gnun/prep/gnun/TODO?cvsroot=trans-coord&r1=1.11&r2=1.12
http://cvs.savannah.gnu.org/viewcvs/trans-coord/gnun/prep/gnun/fdl.texi?cvsroot=trans-coord&rev=1.1
http://cvs.savannah.gnu.org/viewcvs/trans-coord/gnun/prep/gnun/gnun.texi?cvsroot=trans-coord&rev=1.1

Patches:
Index: ChangeLog
===================================================================
RCS file: /cvsroot/trans-coord/trans-coord/gnun/prep/gnun/ChangeLog,v
retrieving revision 1.39
retrieving revision 1.40
diff -u -b -r1.39 -r1.40
--- ChangeLog   8 Feb 2008 17:59:17 -0000       1.39
+++ ChangeLog   9 Feb 2008 17:06:52 -0000       1.40
@@ -1,3 +1,8 @@
+2008-02-09  Yavor Doganov  <address@hidden>
+
+       * gnun.texi: New file; basic skeleton of the documentaiton.
+       * fdl.texi: Import from the canonical location.
+       
 2008-02-08  Yavor Doganov  <address@hidden>
 
        * GNUmakefile (generate-pot): Indent and use a workaround for

Index: TODO
===================================================================
RCS file: /cvsroot/trans-coord/trans-coord/gnun/prep/gnun/TODO,v
retrieving revision 1.11
retrieving revision 1.12
diff -u -b -r1.11 -r1.12
--- TODO        8 Feb 2008 17:59:17 -0000       1.11
+++ TODO        9 Feb 2008 17:06:53 -0000       1.12
@@ -2,8 +2,6 @@
 
 * Present bugs
 
-** Missing documentation.
-
 ** home.shtml: Make checks whether the HTML is decently generated.
 
 ** Po4a wraps the <script> of the FSF widget at /server/banner.html,
@@ -20,6 +18,8 @@
 
 * General (when bugs are fixed)
 
+** The documentation is not complete, and should be improved.
+
 ** Experiment with msgmerge's `--previous' option and make it the
    default, if feasible.  Requires gettext >= 0.16.
 

Index: fdl.texi
===================================================================
RCS file: fdl.texi
diff -N fdl.texi
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ fdl.texi    9 Feb 2008 17:06:53 -0000       1.1
@@ -0,0 +1,451 @@
address@hidden The GNU Free Documentation License.
address@hidden Version 1.2, November 2002
+
address@hidden This file is intended to be included within another document,
address@hidden hence no sectioning command or @node.
+
address@hidden
+Copyright @copyright{} 2000,2001,2002 Free Software Foundation, Inc.
+51 Franklin St, Fifth Floor, Boston, MA  02110-1301, USA
+
+Everyone is permitted to copy and distribute verbatim copies
+of this license document, but changing it is not allowed.
address@hidden display
+
address@hidden 0
address@hidden
+PREAMBLE
+
+The purpose of this License is to make a manual, textbook, or other
+functional and useful document @dfn{free} in the sense of freedom: to
+assure everyone the effective freedom to copy and redistribute it,
+with or without modifying it, either commercially or noncommercially.
+Secondarily, this License preserves for the author and publisher a way
+to get credit for their work, while not being considered responsible
+for modifications made by others.
+
+This License is a kind of ``copyleft'', which means that derivative
+works of the document must themselves be free in the same sense.  It
+complements the GNU General Public License, which is a copyleft
+license designed for free software.
+
+We have designed this License in order to use it for manuals for free
+software, because free software needs free documentation: a free
+program should come with manuals providing the same freedoms that the
+software does.  But this License is not limited to software manuals;
+it can be used for any textual work, regardless of subject matter or
+whether it is published as a printed book.  We recommend this License
+principally for works whose purpose is instruction or reference.
+
address@hidden
+APPLICABILITY AND DEFINITIONS
+
+This License applies to any manual or other work, in any medium, that
+contains a notice placed by the copyright holder saying it can be
+distributed under the terms of this License.  Such a notice grants a
+world-wide, royalty-free license, unlimited in duration, to use that
+work under the conditions stated herein.  The ``Document'', below,
+refers to any such manual or work.  Any member of the public is a
+licensee, and is addressed as ``you''.  You accept the license if you
+copy, modify or distribute the work in a way requiring permission
+under copyright law.
+
+A ``Modified Version'' of the Document means any work containing the
+Document or a portion of it, either copied verbatim, or with
+modifications and/or translated into another language.
+
+A ``Secondary Section'' is a named appendix or a front-matter section
+of the Document that deals exclusively with the relationship of the
+publishers or authors of the Document to the Document's overall
+subject (or to related matters) and contains nothing that could fall
+directly within that overall subject.  (Thus, if the Document is in
+part a textbook of mathematics, a Secondary Section may not explain
+any mathematics.)  The relationship could be a matter of historical
+connection with the subject or with related matters, or of legal,
+commercial, philosophical, ethical or political position regarding
+them.
+
+The ``Invariant Sections'' are certain Secondary Sections whose titles
+are designated, as being those of Invariant Sections, in the notice
+that says that the Document is released under this License.  If a
+section does not fit the above definition of Secondary then it is not
+allowed to be designated as Invariant.  The Document may contain zero
+Invariant Sections.  If the Document does not identify any Invariant
+Sections then there are none.
+
+The ``Cover Texts'' are certain short passages of text that are listed,
+as Front-Cover Texts or Back-Cover Texts, in the notice that says that
+the Document is released under this License.  A Front-Cover Text may
+be at most 5 words, and a Back-Cover Text may be at most 25 words.
+
+A ``Transparent'' copy of the Document means a machine-readable copy,
+represented in a format whose specification is available to the
+general public, that is suitable for revising the document
+straightforwardly with generic text editors or (for images composed of
+pixels) generic paint programs or (for drawings) some widely available
+drawing editor, and that is suitable for input to text formatters or
+for automatic translation to a variety of formats suitable for input
+to text formatters.  A copy made in an otherwise Transparent file
+format whose markup, or absence of markup, has been arranged to thwart
+or discourage subsequent modification by readers is not Transparent.
+An image format is not Transparent if used for any substantial amount
+of text.  A copy that is not ``Transparent'' is called ``Opaque''.
+
+Examples of suitable formats for Transparent copies include plain
address@hidden without markup, Texinfo input format, address@hidden input
+format, @acronym{SGML} or @acronym{XML} using a publicly available
address@hidden, and standard-conforming simple @acronym{HTML},
+PostScript or @acronym{PDF} designed for human modification.  Examples
+of transparent image formats include @acronym{PNG}, @acronym{XCF} and
address@hidden  Opaque formats include proprietary formats that can be
+read and edited only by proprietary word processors, @acronym{SGML} or
address@hidden for which the @acronym{DTD} and/or processing tools are
+not generally available, and the machine-generated @acronym{HTML},
+PostScript or @acronym{PDF} produced by some word processors for
+output purposes only.
+
+The ``Title Page'' means, for a printed book, the title page itself,
+plus such following pages as are needed to hold, legibly, the material
+this License requires to appear in the title page.  For works in
+formats which do not have any title page as such, ``Title Page'' means
+the text near the most prominent appearance of the work's title,
+preceding the beginning of the body of the text.
+
+A section ``Entitled XYZ'' means a named subunit of the Document whose
+title either is precisely XYZ or contains XYZ in parentheses following
+text that translates XYZ in another language.  (Here XYZ stands for a
+specific section name mentioned below, such as ``Acknowledgements'',
+``Dedications'', ``Endorsements'', or ``History''.)  To ``Preserve the Title''
+of such a section when you modify the Document means that it remains a
+section ``Entitled XYZ'' according to this definition.
+
+The Document may include Warranty Disclaimers next to the notice which
+states that this License applies to the Document.  These Warranty
+Disclaimers are considered to be included by reference in this
+License, but only as regards disclaiming warranties: any other
+implication that these Warranty Disclaimers may have is void and has
+no effect on the meaning of this License.
+
address@hidden
+VERBATIM COPYING
+
+You may copy and distribute the Document in any medium, either
+commercially or noncommercially, provided that this License, the
+copyright notices, and the license notice saying this License applies
+to the Document are reproduced in all copies, and that you add no other
+conditions whatsoever to those of this License.  You may not use
+technical measures to obstruct or control the reading or further
+copying of the copies you make or distribute.  However, you may accept
+compensation in exchange for copies.  If you distribute a large enough
+number of copies you must also follow the conditions in section 3.
+
+You may also lend copies, under the same conditions stated above, and
+you may publicly display copies.
+
address@hidden
+COPYING IN QUANTITY
+
+If you publish printed copies (or copies in media that commonly have
+printed covers) of the Document, numbering more than 100, and the
+Document's license notice requires Cover Texts, you must enclose the
+copies in covers that carry, clearly and legibly, all these Cover
+Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on
+the back cover.  Both covers must also clearly and legibly identify
+you as the publisher of these copies.  The front cover must present
+the full title with all words of the title equally prominent and
+visible.  You may add other material on the covers in addition.
+Copying with changes limited to the covers, as long as they preserve
+the title of the Document and satisfy these conditions, can be treated
+as verbatim copying in other respects.
+
+If the required texts for either cover are too voluminous to fit
+legibly, you should put the first ones listed (as many as fit
+reasonably) on the actual cover, and continue the rest onto adjacent
+pages.
+
+If you publish or distribute Opaque copies of the Document numbering
+more than 100, you must either include a machine-readable Transparent
+copy along with each Opaque copy, or state in or with each Opaque copy
+a computer-network location from which the general network-using
+public has access to download using public-standard network protocols
+a complete Transparent copy of the Document, free of added material.
+If you use the latter option, you must take reasonably prudent steps,
+when you begin distribution of Opaque copies in quantity, to ensure
+that this Transparent copy will remain thus accessible at the stated
+location until at least one year after the last time you distribute an
+Opaque copy (directly or through your agents or retailers) of that
+edition to the public.
+
+It is requested, but not required, that you contact the authors of the
+Document well before redistributing any large number of copies, to give
+them a chance to provide you with an updated version of the Document.
+
address@hidden
+MODIFICATIONS
+
+You may copy and distribute a Modified Version of the Document under
+the conditions of sections 2 and 3 above, provided that you release
+the Modified Version under precisely this License, with the Modified
+Version filling the role of the Document, thus licensing distribution
+and modification of the Modified Version to whoever possesses a copy
+of it.  In addition, you must do these things in the Modified Version:
+
address@hidden A
address@hidden
+Use in the Title Page (and on the covers, if any) a title distinct
+from that of the Document, and from those of previous versions
+(which should, if there were any, be listed in the History section
+of the Document).  You may use the same title as a previous version
+if the original publisher of that version gives permission.
+
address@hidden
+List on the Title Page, as authors, one or more persons or entities
+responsible for authorship of the modifications in the Modified
+Version, together with at least five of the principal authors of the
+Document (all of its principal authors, if it has fewer than five),
+unless they release you from this requirement.
+
address@hidden
+State on the Title page the name of the publisher of the
+Modified Version, as the publisher.
+
address@hidden
+Preserve all the copyright notices of the Document.
+
address@hidden
+Add an appropriate copyright notice for your modifications
+adjacent to the other copyright notices.
+
address@hidden
+Include, immediately after the copyright notices, a license notice
+giving the public permission to use the Modified Version under the
+terms of this License, in the form shown in the Addendum below.
+
address@hidden
+Preserve in that license notice the full lists of Invariant Sections
+and required Cover Texts given in the Document's license notice.
+
address@hidden
+Include an unaltered copy of this License.
+
address@hidden
+Preserve the section Entitled ``History'', Preserve its Title, and add
+to it an item stating at least the title, year, new authors, and
+publisher of the Modified Version as given on the Title Page.  If
+there is no section Entitled ``History'' in the Document, create one
+stating the title, year, authors, and publisher of the Document as
+given on its Title Page, then add an item describing the Modified
+Version as stated in the previous sentence.
+
address@hidden
+Preserve the network location, if any, given in the Document for
+public access to a Transparent copy of the Document, and likewise
+the network locations given in the Document for previous versions
+it was based on.  These may be placed in the ``History'' section.
+You may omit a network location for a work that was published at
+least four years before the Document itself, or if the original
+publisher of the version it refers to gives permission.
+
address@hidden
+For any section Entitled ``Acknowledgements'' or ``Dedications'', Preserve
+the Title of the section, and preserve in the section all the
+substance and tone of each of the contributor acknowledgements and/or
+dedications given therein.
+
address@hidden
+Preserve all the Invariant Sections of the Document,
+unaltered in their text and in their titles.  Section numbers
+or the equivalent are not considered part of the section titles.
+
address@hidden
+Delete any section Entitled ``Endorsements''.  Such a section
+may not be included in the Modified Version.
+
address@hidden
+Do not retitle any existing section to be Entitled ``Endorsements'' or
+to conflict in title with any Invariant Section.
+
address@hidden
+Preserve any Warranty Disclaimers.
address@hidden enumerate
+
+If the Modified Version includes new front-matter sections or
+appendices that qualify as Secondary Sections and contain no material
+copied from the Document, you may at your option designate some or all
+of these sections as invariant.  To do this, add their titles to the
+list of Invariant Sections in the Modified Version's license notice.
+These titles must be distinct from any other section titles.
+
+You may add a section Entitled ``Endorsements'', provided it contains
+nothing but endorsements of your Modified Version by various
+parties---for example, statements of peer review or that the text has
+been approved by an organization as the authoritative definition of a
+standard.
+
+You may add a passage of up to five words as a Front-Cover Text, and a
+passage of up to 25 words as a Back-Cover Text, to the end of the list
+of Cover Texts in the Modified Version.  Only one passage of
+Front-Cover Text and one of Back-Cover Text may be added by (or
+through arrangements made by) any one entity.  If the Document already
+includes a cover text for the same cover, previously added by you or
+by arrangement made by the same entity you are acting on behalf of,
+you may not add another; but you may replace the old one, on explicit
+permission from the previous publisher that added the old one.
+
+The author(s) and publisher(s) of the Document do not by this License
+give permission to use their names for publicity for or to assert or
+imply endorsement of any Modified Version.
+
address@hidden
+COMBINING DOCUMENTS
+
+You may combine the Document with other documents released under this
+License, under the terms defined in section 4 above for modified
+versions, provided that you include in the combination all of the
+Invariant Sections of all of the original documents, unmodified, and
+list them all as Invariant Sections of your combined work in its
+license notice, and that you preserve all their Warranty Disclaimers.
+
+The combined work need only contain one copy of this License, and
+multiple identical Invariant Sections may be replaced with a single
+copy.  If there are multiple Invariant Sections with the same name but
+different contents, make the title of each such section unique by
+adding at the end of it, in parentheses, the name of the original
+author or publisher of that section if known, or else a unique number.
+Make the same adjustment to the section titles in the list of
+Invariant Sections in the license notice of the combined work.
+
+In the combination, you must combine any sections Entitled ``History''
+in the various original documents, forming one section Entitled
+``History''; likewise combine any sections Entitled ``Acknowledgements'',
+and any sections Entitled ``Dedications''.  You must delete all
+sections Entitled ``Endorsements.''
+
address@hidden
+COLLECTIONS OF DOCUMENTS
+
+You may make a collection consisting of the Document and other documents
+released under this License, and replace the individual copies of this
+License in the various documents with a single copy that is included in
+the collection, provided that you follow the rules of this License for
+verbatim copying of each of the documents in all other respects.
+
+You may extract a single document from such a collection, and distribute
+it individually under this License, provided you insert a copy of this
+License into the extracted document, and follow this License in all
+other respects regarding verbatim copying of that document.
+
address@hidden
+AGGREGATION WITH INDEPENDENT WORKS
+
+A compilation of the Document or its derivatives with other separate
+and independent documents or works, in or on a volume of a storage or
+distribution medium, is called an ``aggregate'' if the copyright
+resulting from the compilation is not used to limit the legal rights
+of the compilation's users beyond what the individual works permit.
+When the Document is included in an aggregate, this License does not
+apply to the other works in the aggregate which are not themselves
+derivative works of the Document.
+
+If the Cover Text requirement of section 3 is applicable to these
+copies of the Document, then if the Document is less than one half of
+the entire aggregate, the Document's Cover Texts may be placed on
+covers that bracket the Document within the aggregate, or the
+electronic equivalent of covers if the Document is in electronic form.
+Otherwise they must appear on printed covers that bracket the whole
+aggregate.
+
address@hidden
+TRANSLATION
+
+Translation is considered a kind of modification, so you may
+distribute translations of the Document under the terms of section 4.
+Replacing Invariant Sections with translations requires special
+permission from their copyright holders, but you may include
+translations of some or all Invariant Sections in addition to the
+original versions of these Invariant Sections.  You may include a
+translation of this License, and all the license notices in the
+Document, and any Warranty Disclaimers, provided that you also include
+the original English version of this License and the original versions
+of those notices and disclaimers.  In case of a disagreement between
+the translation and the original version of this License or a notice
+or disclaimer, the original version will prevail.
+
+If a section in the Document is Entitled ``Acknowledgements'',
+``Dedications'', or ``History'', the requirement (section 4) to Preserve
+its Title (section 1) will typically require changing the actual
+title.
+
address@hidden
+TERMINATION
+
+You may not copy, modify, sublicense, or distribute the Document except
+as expressly provided for under this License.  Any other attempt to
+copy, modify, sublicense or distribute the Document is void, and will
+automatically terminate your rights under this License.  However,
+parties who have received copies, or rights, from you under this
+License will not have their licenses terminated so long as such
+parties remain in full compliance.
+
address@hidden
+FUTURE REVISIONS OF THIS LICENSE
+
+The Free Software Foundation may publish new, revised versions
+of the GNU Free Documentation License from time to time.  Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.  See
address@hidden://www.gnu.org/copyleft/}.
+
+Each version of the License is given a distinguishing version number.
+If the Document specifies that a particular numbered version of this
+License ``or any later version'' applies to it, you have the option of
+following the terms and conditions either of that specified version or
+of any later version that has been published (not as a draft) by the
+Free Software Foundation.  If the Document does not specify a version
+number of this License, you may choose any version ever published (not
+as a draft) by the Free Software Foundation.
address@hidden enumerate
+
address@hidden
address@hidden ADDENDUM: How to use this License for your documents
+
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and
+license notices just after the title page:
+
address@hidden
address@hidden
+  Copyright (C)  @var{year}  @var{your name}.
+  Permission is granted to copy, distribute and/or modify this document
+  under the terms of the GNU Free Documentation License, Version 1.2
+  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 ``GNU
+  Free Documentation License''.
address@hidden group
address@hidden smallexample
+
+If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
+replace the address@hidden'' line with this:
+
address@hidden
address@hidden
+    with the Invariant Sections being @var{list their titles}, with
+    the Front-Cover Texts being @var{list}, and with the Back-Cover Texts
+    being @var{list}.
address@hidden group
address@hidden smallexample
+
+If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+
+If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of
+free software license, such as the GNU General Public License,
+to permit their use in free software.
+
address@hidden Local Variables:
address@hidden ispell-local-pdict: "ispell-dict"
address@hidden End:
+

Index: gnun.texi
===================================================================
RCS file: gnun.texi
diff -N gnun.texi
--- /dev/null   1 Jan 1970 00:00:00 -0000
+++ gnun.texi   9 Feb 2008 17:06:53 -0000       1.1
@@ -0,0 +1,840 @@
+\input texinfo
address@hidden %**start of header
address@hidden gnun.info
address@hidden GNUnited Nations Manual
address@hidden FIXME: Would be nice to have it in the format `%:b %:d, %:y', but
address@hidden in English.
address@hidden lastupdate 09.02.2008
address@hidden %**end of header
+
address@hidden Please do not use features of Texinfo >> 4.8, which is the 
version
address@hidden available in gNewSense.  Thanks.
+
address@hidden FIXME: Add more xrefs, where appropriate.
address@hidden FIXME: Add indexing commands.
+
address@hidden
+
+This manual is for @acronym{GNU}nited Nations, a suite for maintaining
+translations of www.gnu.org essays and other address@hidden
+Last updated on @value{lastupdate}.
address@hidden 1
+Copyright @copyright{} 2008 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.2 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 GNUnited Nations Manual
address@hidden Software for maintaining www.gnu.org translations
address@hidden (last updated @value{lastupdate})
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 Localization
address@hidden
+* GNUnited Nations: (gnun).     Maintaining gnu.org translations.
address@hidden direntry
+
address@hidden
address@hidden Top
address@hidden GNUnited Nations
address@hidden
address@hidden ifnottex
+
address@hidden
+* Introduction::        Overview of GNUnited Nations.
+* Usage::               Basic usage, invocation and tips.
+* Internals::           Dive into @acronym{GNUN}.
+* Index::
+* Copying This Manual:: The GNU Free Documentation License.
address@hidden menu
+
address@hidden Introduction
address@hidden Introduction to @acronym{GNU}nited Nations
+
address@hidden Nations (abbreviated @acronym{GNUN}) is a
+collection of makefiles and scripts that are supposed to make the life
+of @url{http://gnu.org} translators easier.  Although it is
+specifically developed for the @acronym{GNU} Project's website, it
+could be customized, at least in theory, to fit the needs of other
+internationalized sites.  @acronym{GNUN} is in early stage of
+development, but if it proves useful, and if there is sufficient
+interest (and time), it is possible to develop a robust configuration
+interface that would be appropriate for general usage.
+
+It is vitally important to understand that @acronym{GNUN} is
address@hidden a silver bullet that solves all problems.  If we have to be
+honest, deploying @acronym{GNUN} in fact even does create some
+(@pxref{Disadvantages}).
+
address@hidden Nations is free software, available under the
address@hidden General Public License.
+
+This manual is organized in way that is suitable both for translators
+and @acronym{GNU} Web Translation managers (plus eventually interested
address@hidden Webmasters, if any).  It may also serve as an
+introductory material and reference for new @acronym{GNUN} developers
+and contributors.  Hopefully, it might be useful to people who
+customize and adopt the software for a third party site or for their
+own needs.  Feel free to skip sections or entire chapters if they are
+irrelevant for your intended usage.
+
+This manual is free documentation, and you can modify and redistribute
+it under the terms of the @acronym{GNU} Free Documentation License.
address@hidden This Manual, ,GNU Free Documentation License}.
+
address@hidden
+* Overview::            What is @acronym{GNUN} and why is necessary?
+* Concepts::            Basic concepts and goals.
+* Advantages::          The goodness @acronym{GNUN} brings.
+* Disadvantages::       Staying on firm ground.
address@hidden menu
+
address@hidden Overview
address@hidden Why @acronym{GNUN} is Being Developed
+
+The @acronym{GNU} Project's website, @uref{http://www.gnu.org}, has
+become considerably large over the years.  Maintaining it requires
+significant effort, and sometimes a new web standard is developed
+faster than the time required to migrate all articles to the next
+widely adopted one.
+
+When it comes to internalization, the problems are so many that it is
+hard to enumerate them.  It has become apparent that maintaining
+translations up-to-date is a major undertaking, involving tedious
+skimming through commit logs, reviewing diffs and other medieval
+techniques to catch up.  Some translation teams have developed their
+own sets of scripts, but so far there has been no universal solution.
+
+This unpleasant situation, combined with rapid and incompatible
+design changes, have lead some teams to neglect the important work of
+keeping their translation in line with the changing original
+articles.  As a consequence, the @acronym{GNU} Project is facing the
+problem of maintaining them in suboptimal ways, in order to keep the
+information updated.
+
+The reasons for developing @acronym{GNU}nited Nations are very similar
+to those that lead to the inception of @acronym{GNU} gettext, or
address@hidden Documentation Utilities (@code{gnome-doc-utils}) some
+years later.
+
address@hidden Concepts
address@hidden What @acronym{GNU}nited Nations is and Should be
+
+The basic goal behind @acronym{GNUN} is to transform the original
+English articles to ``PO templates'', suitable for manipulation with
+the various `gettext' utilities.  @xref{Top, , Introduction, gettext,
+GNU gettext tools}, for a basic overview.  The translations are kept
+as PO files, based on the PO templates (`PO' for short), and being
+transformed in HTML format with another collection of tools, Po4a
+(@uref{http://po4a.alioth.debian.org}).
+
+If the original article changes, the POT is automatically rebuilt, as
+well as all translations that already have a PO file installed.  Thus,
+if something changes in the English article, the relevant element in
+the translations will be substituted with the English text, until the
+translation teams update them.
+
+The POT for every article under @acronym{GNUN}'s control is kept in
+the `www' repository under a special directory @file{po/}, which is a
+sub-directory of the relevant directory in the `www' tree.  So, for
address@hidden://www.gnu.org/philosophy/free-sw.html} that is
address@hidden/po/}.  Except @file{free-sw.pot}, this directory
+holds the canonical source of every translation, like
address@hidden, @file{free-sw.ca.po}, etc.
+
+Several additional features are implemented, like automatic update of
+the list of the available translations.  For example, if a new
+translation is added and the list of translations in
address@hidden is updated, all translated @file{free-sw.xx.html}
+will be regenerated.  This saves a lot of tedious, repetitive work.
+There is a basic infrastructure to ``inject'' general information
+about a translation team---like a note how to contact the team, or how
+to report a bug/suggestion for improvement.  Translators' credits are
+also handled, as well as translators' notes, if any.
+
address@hidden can be extended, and new features will certainly be
+added.  The @file{TODO} file currently lists some of them, but new
+ideas pop up quite often.  The plan is to make a solid foundation and
+develop front-ends---a web front-end, possibly based on Pootle, a
+statistics facility, probably a wiki compiler, and more.
+
address@hidden Advantages
address@hidden Major Advantages of @acronym{GNUN}
+
+Here is a simple list of situations where we hope this suite would
+prove to be useful.
+
address@hidden
address@hidden
+Automatic rebuild of all translations when the original article
+changes.  This is the most important feature, as it prevents
+accumulation of seriously outdated translations.
+
address@hidden
+Global update of the whole site.  Apply the previous point to the web
+server templates (under @file{server/} in the `www' repository).  A
+single change to such a file will affect literally @emph{all}
+articles, translated or not.
+
address@hidden
+Urgent notices.  Sometimes an ``urgent'' notice is added by the
+webmasters, which should appear on all pages.  Typically this is about
+an event where urgent action is needed, although often it is only
+relevant to a single country or even a particular city.  Such a notice
+will propagate to all pages, and translators may choose whether to
+translate it or not.  For example, the Urdu translation team may
+conclude that there are only a few Urdu immigrants in Massachusetts,
+to participate in an event that will happen in Boston, so translating
+the ``urgent'' notice may not be very ``urgent'' for Urdu.  When the
+notice is removed, often in a week or two, it will disappear without
+translators' intervention, whether they translated it or not.
+
address@hidden
+Simplification of the translation process---lots of errors and typos
+come from the fact that translators basically have to duplicate the
+whole HTML markup of the original.  The PO files eliminate most of the
+basic markup, which is where most of the validation errors come from.
+
address@hidden
+Markup consistency site-wide---it would be substantially easier to
+update the site to a future standard, because translations will
+naturally follow the changes in the original articles.
+
address@hidden
+Easy updates by translators.  Modified paragraphs, links, etc. will
+appear as ``fuzzy'' strings in the PO files, newly added ones will
+appear as ``untranslated'', and deleted will appear as ``obsolete''.
+It is substantially easier to update a PO file, where a keystroke
+takes you to the part that need updating, whatever it may be.
+
address@hidden
+Reporting and statistics.  Since the basis is standard PO files, which
+are the canonical source of the translations, it is easy to manipulate
+them and extract useful information.
address@hidden itemize
+
address@hidden Disadvantages
address@hidden Known Bugs and Limitations
+
+As it happens in real life, we don't wear pink glasses and are aware
+of certain limitations and annoyances of this semi-automatic system.
+
address@hidden
address@hidden
+Often it is hard to figure out where precisely a change was made.  A
+change in one single word in a long paragraph of the HTML article will
+lead to the whole of it being marked as ``fuzzy'' in the PO files.  So
+don't unsubscribe from @email{www-commits@@gnu.org} yet, and be
+prepared to check the CVS history of the original article.
+
address@hidden
+We plan to invoke a build once a day, because doing it more often will
+potentially generate more messages to the mailing list in the form of
+commit notifications.  This has its drawback, since translators will
+have to wait for a day until their PO files are updated, and another
+day for the @file{.xx.html} articles to get generated, after they
+commit the updated POs.
+
address@hidden
+Currently there is no way a translation team can take advantage of
address@hidden while following their own translation process, because
+the suite is tied to the official repository.  We hope that we will
+resolve this problem soon.
address@hidden itemize
+
address@hidden Usage
address@hidden General Usage
+
address@hidden
+If anything may go wrong, it will definitely go wrong.
+---Murphy's Law
+
+Murphy is an optimist.
+---O'Rielly's Law
address@hidden flushright
address@hidden 1
+
address@hidden currently consists of a few makefiles, scripts and
+optional @file{generic.xx.html} files, intended to contain
+article-independent but team-specific information.  They are designed
+to reside in the @file{prep/gnun/} directory, but this may change.  In
+all examples in this manual, ``invoking'' means executing on the
+command line @command{make -C prep/gnun/ address@hidden
address@hidden@var{value} @dots{}]} while the working directory is
+the root in the `www' web repository.  For the purpose of brevity, we
+will refer to the above command as simply @command{make}, which is
+equivalent to @command{cd prep/gnun ; make}.  It is desirable never to
+invoke @command{make} with the @option{-k} (@option{--keep-going})
+option, because an eventual error in only one make recipe might create
+a mess in many articles, both original and translated.  Do this with
+caution, and generally only when debugging in a safe environment.
+
+The build process is intended to be invoked by a cron job, although
+manual intervention to a certain degree is possible.
+
address@hidden
+* Invoking GNUN::       How to trigger a (re)build.
+* Main Variables::      Specifying what to build.
+* PO Files::            The gentle art of editing PO files.
address@hidden menu
+
address@hidden Invoking GNUN
address@hidden Invoking GNUN
+
+The central part of @acronym{GNU}nited Nations is a makefile; actually
+a @file{GNUmakefile} since it heavily relies on features and
+extensions available in @acronym{GNU} Make.  Thus, invoking a build
+consists of typing @command{make} on the command line, or within cron.
+If you are deploying the software on a non-GNU machine, probably
address@hidden Make is installed and available as @command{gmake}.  If
+not, you should seriously consider installing it, since as far as we
+know, the build will fail otherwise.  See
address@hidden://www.gnu.org/software/make} for information how to
+download and install @acronym{GNU} Make.
+
+If you don't specify a target, @command{make} by default builds the
+target @code{all}, which in this case is to rebuild all translations
+that are not up-to-date.  However, there are special targets that do
+not depend on the standard @code{all} target, which can be built by
address@hidden @var{target}}.  Some of the variables in the next
+section apply to them, and some do not.
+
address@hidden
+* Runtime Variables::   Variables to control the build process.
+* Special Targets::     Targets that are not built by default.
address@hidden menu
+
address@hidden Runtime Variables
address@hidden Variables to Control the Build Process
+
+The build process has several modes of operation, and they all relate
+to the handling of files that are to be added to the repository or
+performing certain sanity checks at build time.  The variables are
+specified on the command line, after @command{make}, in the form
address@hidden, e.g. @command{make VCS=yes}.  In the future,
+additional features will be implemented in a similar fashion.
+
address@hidden @samp
address@hidden VCS=no
address@hidden @dots{}
+Do not add any files to the repository.  This is the default.  You may
+as well omit to define @code{VCS} entirely; there is no special code
+that expects assigning the value `no'.
+
address@hidden VCS=yes
+Automatically add any new files in the repository.  These are any POT
+files, if they are generated for the first time, and the translated
+articles (@file{.xx.html}) in HTML format.  In addition, if there is
+no @file{prep/gnun/generic.xx.html} file for the specific language an
+article is being generated, an empty file will be added.  Finally, any
+missing PO and their HTML counterparts of the server templates will be
+added, computed on the basis of the @code{template_files} variable.
+
address@hidden VCS=always
+Because @acronym{GNU} Make considers the targets up-to-date after a
+successful build, if it was performed with no VCS interaction, the
+important newly created files will not be added (and committed when
+you do @command{cvs commit}) in the repository.  Assigning this value
+enables additional check and forcefully adds all files.  Use it
+sparingly, since it is very slow and generally less reliable.
+
address@hidden VALIDATE=no
address@hidden @dots{}
+Does not perform validation of the HTML articles and PO files.  This
+is the default, and not defining this variable has the same effect.
+
address@hidden VALIDATE=yes
+Validates all original articles before generating the POTs, to ensure
+that the ultimate source is valid XHMTL.  Also, validates all
+generated translations in HTML format and all PO files.  It is highly
+recommended to run the build this way, even if it is a bit tedious to
+fix the errors that are reported as a result of enforcing validation.
address@hidden table
+
+Note that @code{VCS=yes,always} is a valid combination: because POT
+files of the server templates are not handled by @code{always},
+running the build this way will commit any newly added files as
+specified in @code{TEMPLATE_LINGUAS} and will perform additional check
+at the end, @code{cvs add}-ing all necessary files.
+
address@hidden Special Targets
address@hidden Targets Specified on the Command Line
+
+Some targets are not built by default, because they are only useful
+under certain circumstances.  Think of them like semi-automated
+commands or canned command sequences that are more complicated, and
+more importantly, whose arguments are variables computed at the time
address@hidden reads the makefiles---the filesets they affect are
+specific and already defined, one way or another.
+
address@hidden
+* sync::
+* clean::
+* distclean::
address@hidden menu
+
address@hidden sync
address@hidden The @code{sync} target
+
+The @code{sync} target has a simple task: synchronize the
address@hidden English} articles from a canonical repository, like
+`www'.  It is very important that such synchronization happens,
+because it is desirable to develop the software and add more features
+in a testbed, while the `official instance' operates on the official
+repository in a predictable way.
+
+It is recommended that you `build' the @code{sync} target from a cron
+job, some time before the general build occurs.  That way,
+prerequisites (e.g. original @file{.html} articles) will be updated
+from the canonical repository and the subsequent @command{make}
+invocation, possibly run by cron as well, will update all
+translations.
+
+The @code{VCS} variable affects the behavior: if it is defined to
+`yes' then the synchronized files are committed to the `testing'
+repository, e.g. the @var{destination}.  In addition, if a file meant
+to be synchronized disappeared from the @var{source}, a warning mail
+will be sent to the address defined in the @code{devel_addr} variable
+(defined only in @file{GNUmakefile}).  The build will continue without
+failure, and will sync and commit all other files, but will send the
+same email message again if the file is still present in the
address@hidden variable during a subsequent invocation.
+
address@hidden has no effect on this target, as well as
address@hidden
+
address@hidden clean
address@hidden The @code{clean} target
+
+Not implemented yet.
+
address@hidden distclean
address@hidden The @code{distclean} target
+
+Not implemented yet.
+
address@hidden Main Variables
address@hidden Defining Articles to be Built
+
+The file @file{gnun.mk} contains variable definitions, based on which
+almost all other important variables are computed.  In other words,
+the variables defined in that file directly affect the overall
+behavior of the build process.
+
+There are two types of variables, which are specifically separated in
+order to make translators' life easier: variables that translators are
+free to modify and variables that are modified by the web-translators
address@hidden because presumably, they are more familiar with
address@hidden Nations' internals.  From a purely technical point
+of view, there is no difference.}, ideally after performing some local
+tests.  A translation team leader should update only
address@hidden and @code{HOME_LINGUAS}; everything else is
+supposed to be built auto-magically, without manual intervention.  If
+not, that is a bug that should be reported and fixed.
+
address@hidden @samp
address@hidden TEMPLATE_LINGUAS
+Add here the your language code @emph{if and only if} you have all the
+server templates translated, and have committed
address@hidden/po/banner.xx.po} and  @file{server/po/footer-text.xx.po},
+as well as the templates that are not under @acronym{GNUN}'s control,
+like @file{server/header.xx.html} and @file{server/footer.xx.html}.
+
address@hidden HOME_LINGUAS
+Add your language code if you have already committed
address@hidden/home.xx.po}, that way the homepage for your language will be
+built.  It is not acceptable to have your language code defined in
+this variable, but not in @code{TEMPLATE_LINGUAS}.
+
address@hidden ROOT
+Add here articles that are in the server root, like
address@hidden and @file{provide.html}.  Always write only the
+basename of the article, i.e. if you add these two articles, the value
+of @code{ROOT} should be @code{keepingup provide}.  This is true for
+all the variables that expect values in the form of article names.
+
address@hidden ALL_DIRS
+The list of directories containing articles, like @file{philosophy},
address@hidden, @file{licenses}, etc.
+
address@hidden gnu
address@hidden philosophy
address@hidden @address@hidden
+A space-separated list of basenames for articles residing in
address@hidden, for which POTs will be generated and updated when the
+original article changes.  If an article is missing here, there is no
+way its translations to be maintained via @acronym{GNUN}.
address@hidden table
+
address@hidden PO Files
address@hidden Working with PO Files
+
+We anticipate that some gnu.org translators will find this format odd
+or inconvenient, if they never happened to work with PO files before.
+Don't worry, you will soon get accustomed to it.  It is the
+established format for translations in the Free World, and you should
+have no problems if you have translated software before.
+
+The most efficient way to edit a PO file is using a specialized PO
+editor, because each of them represents and treats gettext messages in
+a consistent and predictable way.  It is possible to edit a PO file
+with an ordinary plain text editor, but extra effort would be
+necessary to make it valid.  Here is a list of widely used PO editors:
+
address@hidden
address@hidden 
+PO mode.  We recommend using @acronym{GNU} Emacs in PO mode, because
+Emacs is the program that is suitable for performing any task when it
+comes to maintaining the @acronym{GNU} Project's website.  Provided
+that you have @acronym{GNU} gettext installed, any @file{.po} file you
+visit should automatically switch to PO mode.  You can enable/disable
+it by @code{M-x po-mode @key{RET}}.  On some @acronym{GNU}/Linux
+distros such as gNewSense, PO mode is available in a separate package,
address@hidden See @uref{http://www.gnu.org/software/gettext}.
+
address@hidden
+gTranslator---the @acronym{GNOME} PO editor.  Has some known bugs, but
+they shouldn't affect gnu.org translations as formulas that express
+plural forms are not used.  See
address@hidden://gtranslator.sourceforge.net}.
+
address@hidden
+KBabel---likewise for @acronym{KDE}.  See
address@hidden://kbabel.kde.org}.
+
address@hidden
+Poedit---another editor that is based on the @code{wxWidgets}
+toolkit.  See @uref{http://www.poedit.net}.
address@hidden itemize
+
address@hidden
+* New Translation::     How to start a new translation.
+* Migrating::           How to migrate an existing translation to a PO
+                          format under @acronym{GNUN}'s control.
+* generic.xx.html::     Specifying information that will propagate in
+                          every translation in a certain language.
address@hidden menu
+
address@hidden New Translation
address@hidden Starting a New Translation
+
+To start a new translation, the easiest way is to copy the existing
+POT as @file{article.xx.po}, where @code{xx} is your language code.
+For example, to prepare for a new translation of the essay
address@hidden://www.gnu.org/philosophy/freedom-or-copyright.html}, you
+can simply do @command{cd philosophy/po ; cp freedom-or-copyright.pot
+freedom-or-copyright.xx.po} and then edit the latter.  If
address@hidden does not exist it is because either
+the article is not yet ``templated'' (i.e. migrated to the new style),
+or the @acronym{GNUN} maintainers have not yet added it to the value
+of the appropriate variable in @file{prep/gnun/gnun.mk}.  In that
+case, just ask them to do the necessary in order the POT to be
+generated.
+
+You could also use the @command{msginit} utility that would populate
+the PO file header with the right information, provided your
+environment is set up correctly.  @xref{msginit Invocation, ,,
+gettext, GNU gettext tools}.
+
+The PO file header as generated usually looks like this:
+
address@hidden
+# SOME DESCRIPTIVE TITLE
+# Copyright (C) YEAR Free Software Foundation, Inc.
+# This file is distributed under the same license as the PACKAGE package.
+# FIRST AUTHOR <EMAIL@@ADDRESS>, YEAR.
+#
+#, fuzzy
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"POT-Creation-Date: 2008-02-06 16:25-0500\n"
+"PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
+"Last-Translator: FULL NAME <EMAIL@@ADDRESS>\n"
+"Language-Team: LANGUAGE <LL@@li.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=CHARSET\n"
+"Content-Transfer-Encoding: ENCODING"
address@hidden example
+
+You have to edit the header to match the already established
+conventions, and the rules for gnu.org translations.  Here is an
+example of a properly edited header:
+
address@hidden
+# Bulgarian translation of 
http://www.gnu.org/philosophy/@/freedom-or-copyright.html
+# Copyright (C) 2008 Free Software Foundation, Inc.
+# This file is distributed under the same license as the gnu.org article.
+# Yavor Doganov <yavor@@gnu.org>, 2008.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: freedom-or-copyright.html\n"
+"POT-Creation-Date: 2008-02-06 16:25-0500\n"
+"PO-Revision-Date: 2008-02-09 15:23+0200\n"
+"Last-Translator: Yavor Doganov <yavor@@gnu.org>\n"
+"Language-Team: Bulgarian <dict@@fsa-bg.org>\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8-bit"
address@hidden example
+
+Notice the absence of the ``fuzzy'' marker; you should ``unfuzzy'' the
+header after entering the necessary information (this is done by
+simply pressing @key{TAB} in PO mode).  The @code{PO-Revision-Date}
+is automatically filled in when you save the file in PO mode and in
+most of the other PO editors.
+
+The @code{Lanuage-Team} field should contain the mailing list on which
+the translation team can be reached---sometimes this is the alias
address@hidden@@gnu.org}, but in some cases it is a
+separate, address@hidden list.
+
+There are some special messages that appear in the POT and PO:
+
address@hidden @samp
address@hidden *GNUN-SLOT: TRANSLATOR'S NOTES*
+This is for translator's notes that are injected in the resulting
+translation.  See FIXME:Foo, for more information.  If your
+translation does not have notes, you @emph{must} translate this as a
+space, that is, @key{SPC}.
+
address@hidden *GNUN-SLOT: TRANSLATOR'S CREDITS*
+This is again optional, and should contain the name (and address) of
+the person who made the translation.  For example:
+
address@hidden
+<b>Traduction</b>: Benjamin Drieu <a
+href="mailto:foo@@example.org";>&lt;foo@@example.org&gt;</a>, 2007,
+2008.
address@hidden example
+
+``Translate'' this string as a space (@key{SPC}) if you do not want
+your name to appear there.
address@hidden table
+
+Most of the PO editors do not wrap long lines that inevitably appear
+in @code{msgstr}'s.  If that happens, long lines make reading
+subsequent diffs harder, and are generally annoying for most people.
+If this issue bothers you, you can ``normalize'' the already finished
+PO translation by executing on the command line @command{cat
address@hidden | msgcat - -o @var{file}.po}, before installing it in
+the repository.  Either way, the build system will treat it is a valid
+PO file.
+
+It is highly desirable that you check if the PO file you finished
+translating (or editing) is valid, before committing it.  This is done
+by running @command{msgfmt -cv -o /dev/null @var{file}} or by simply
+pressing @kbd{V} in PO mode.  The build system automatically verifies
+each PO file when invoked with @code{VALIDATE=yes}, but you won't get
+a warm and fuzzy feeling if a stupid typo you made halts the whole
+update of all translations.  Such things happen to everyone, so it is
+a good practice to check before you actually commit.
+
address@hidden Migrating
address@hidden Transforming existing translation in PO format
+
+Migrating an existing translation to a PO file format is basically
+editing the header as described in the previous section, and
+populating each of the messages by copying the already translated text
+and/or markup from the existing translation in HTML format in the
+relevant message.
+
+Typically, you will visit @file{po/foo.xx.po} (in PO mode) and
address@hidden (in HTML mode) in another buffer.  Then you can
+copy a paragraph or an element from the latter and yank it in the
+relevant message in the former.  Be extra careful, since this is the
+time to check @emph{precisely} that the translation corresponds to the
+original.  Further changes will be reflected, but if your ``initial''
+PO file is not a 100% match, that would not necessarily mean that it
+is an improvement.
+
+There is no need to delete the existing HTML translation,
address@hidden will automatically overwrite it.  The only thing a
+translator should do is to commit the PO file in the repository.
+
+When an essay has been translated by several people through the years,
+it is important that this information is recorded and reflected in the
+PO file.  In the future, special targets may be added to enable the
address@hidden to check who translated a particular article, and when.
+
+A recommended way to do this is as follows:
+
address@hidden
+# French translation of http://www.gnu.org/philosophy/@/bsd.html
+# Copyright (C) 2006, 2007, 2008 Free Software Foundation, Inc.
+# This file is distributed under the same license as the gnu.org article.
+# C@'edric Corazza <cedric.corazza@@wanadoo.fr>, 2006, 2008.
+# address@hidden Dominguez <taz@@gnu.org>, 2007.
address@hidden example
+
+In this example, it is clear that C@'edtric made the initial
+translation, address@hidden made some changes in 2007, and the original
+translator returned in 2008 and continued maintaining it.
+
address@hidden generic.xx.html
address@hidden The @file{generic.xx.html} file
+
+The files @file{prep/gnun/generic.xx.html} are special: if no such
+file exists for your language, an empty file will will be created (and
+added to the repository if specified @code{VCS=yes}).  This file is
+optional, and should contain a short message in your native language,
+ideally providing more information about the translation team or where
+to report bugs.  For example:
+
address@hidden
+<p>To join the Fooish translation team, see <a
+href="http://gnu.org/@/server/@/standards/@/translations/@/www-foo";>the
+Foo team homepage</a>.</p>
address@hidden example
+
+The contents of @file{generic.xx.html} is injected right after the
+translators' credits, if any, and before the timestamp.  It should be
+valid XHTML markup.
+
+When you modify this file, for example, adding a message to the
+existing empty file or changing a URL, such modification will affect
address@hidden articles of the language @code{xx} in
address@hidden  The next time a build occurs, all
+translations of the language code @code{xx} (i.e. all @file{.xx.html},
+including the homepage), will be modified to include the contents of
+this special file.
+
address@hidden Internals
address@hidden Unexciting Information for @acronym{GNUN}'s Operation
+
+This chapter might be of interest probably only to people who would
+have special interest in the software, plan to enhance it or develop a
+front-end.
+
address@hidden
+* Scripts::      Helper scripts.
+* Rules::        The knotty rules explained.
address@hidden menu
+
address@hidden Scripts
address@hidden Internally Used Scripts
+
+For the time being there are two helper scripts, used internally as
+commands with certain arguments in the makefile rules.  They can be
+invoked separately, as stand-alone programs, and sometimes they are
+useful on their own.
+
address@hidden
+* make-prototype::
+* validate-html::
address@hidden menu
+
address@hidden make-prototype
address@hidden The @command{make-prototype} Script
+
+This is a Guile script which makes the ``prototype'' file,
address@hidden, from which the POT is generated.  @acronym{GNUN}
+is designed in such a way, because it would be no big improvement if
+links to other translations ended up in the POT---it would mean that
+translators would have to manually update their PO file when a new
+translation is added.
+
+In addition, @command{make-prototype} guards the timestamp (the
address@hidden RCS keyword) in order the timestamp of the translation to
+be updated @emph{only} when there are actual changes, being automatic
+or not.
+
+Finally, @command{make-prototype} ``injects'' the artificial elements
+`*GNUN-SLOT: TRANSLATOR'S NOTES*' and `*GNUN-SLOT: TRANSLATOR'S
+CREDITS*', thanks to which it is possible to insert the name of the
+translator and translator's notes, if necessary.  @xref{New
+Translation}.
+
+Here are the options that @command{make-prototype} accepts:
+
address@hidden @option
address@hidden --article
+Process the input file as an article.  This is the default.
+
address@hidden --home
+Process the input article as a homepage.  Specify this when you want
+to create a @file{.proto} file for a homepage.
+
address@hidden -i
address@hidden address@hidden
+Input file, which can be a common article (essay) or a homepage.
+
address@hidden -g
address@hidden address@hidden
+Common notes for a translation team; this is the
address@hidden file.  @xref{generic.xx.html}.
+
address@hidden -o
address@hidden address@hidden
+The file where to write the output of the script.
+
address@hidden -t
address@hidden address@hidden
+The file containing the translation links.  This makes sense only for
+articles, since the homepage has its own @file{translations.include}
+which gets included via an SSI directive.
address@hidden FIXME: This should be improved, it is not clear.
+
address@hidden --version
+Print copyright and version information on the standard output.
+
address@hidden --help
+Print usage information on stdout.
address@hidden table
+
address@hidden validate-html
address@hidden The @command{validate-html} Script
+
+This is a Bash script whose purpose is to ``validate'' both the
+original and translated articles to make sure that they conform to the
+respective W3C standard.  Sometimes webmasters make mistakes, and
+translators too, so this tool is useful to catch errors of that kind.
+
address@hidden enforces XHTML validation at build time if invoked with
address@hidden
+
+The script expects only one @var{file} as an argument and will exit
+with an error if it is not specified (which might be the case when an
+automatic variable is not expanded properly due to a bug in the
+makefile).
+
address@hidden Rules
address@hidden How The Recipes Work
+
+Read the source for now.
+
address@hidden Copying This Manual
address@hidden GNU Free Documentation License
+
address@hidden fdl.texi
+
address@hidden Index
address@hidden Index
+
address@hidden cp
+
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 gnun.texi"
+ispell-local-dictionary: "american"
+End:




reply via email to

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