708 lines
24 KiB
Plaintext
708 lines
24 KiB
Plaintext
\input texinfo @c -*-texinfo-*-
|
|
|
|
@setfilename README.info
|
|
@settitle Webmastering FSFE
|
|
@setchapternewpage odd
|
|
|
|
@set lastupdated $Id: README.texi,v 1.3 2006-05-08 14:31:35 reinhard Exp $
|
|
|
|
@titlepage
|
|
@title Webmastering FSFE
|
|
@subtitle Last updated @value{lastupdated}
|
|
|
|
@c Add yourself here if you add at least a couple of paragraphs of useful
|
|
@c information. :-)
|
|
|
|
@author Jonas Öberg
|
|
|
|
@page
|
|
@vskip 0pt plus 1filll
|
|
|
|
Last updated @value{lastupdated}
|
|
@end titlepage
|
|
|
|
@node Top, Webmastering, (dir), (dir)
|
|
@top Webmastering FSFE
|
|
|
|
This document contains a description of the FSFE web pages, both
|
|
the practice of maintaining them, and that of generating them. It is hoped
|
|
that this document will be continuously updated by the webmasters of FSF
|
|
Europe as the web pages evolve. It was last updated @value{lastupdated}.
|
|
|
|
If you find bugs in this file, or have other ideas on how to improve it;
|
|
please commit your ideas to paper in the README.texi file in CVS. All other
|
|
versions are automatically generated from the TexInfo source.
|
|
|
|
@menu
|
|
* Webmastering:: How to be a Webmaster in 10 easy steps
|
|
* Translating:: Doing it all again, 10 times over
|
|
* Building:: How to build the pages, in 10 less easy steps
|
|
* Administrating:: How to handle hits
|
|
* People:: Who did all this?
|
|
* Guides:: Step-by-step guides to certain functions
|
|
|
|
@detailmenu
|
|
--- The Detailed Node Listing ---
|
|
|
|
Webmastering
|
|
|
|
* Focuses:: How the user finds information
|
|
* Source files:: What files to edit
|
|
* Editing:: How to actually edit them
|
|
* Automatic updates:: Pages magically update themselves!
|
|
* Special files:: How to work with the magic glue
|
|
|
|
Building
|
|
|
|
* Requirements:: What you must have to build the pages
|
|
* Process:: How the build process works
|
|
* build.pl:: How the build script works
|
|
|
|
Administrating
|
|
|
|
* Apache:: Apache installation
|
|
* Perl:: Perl installation
|
|
|
|
People
|
|
|
|
* Webmasters:: List of current webmasters
|
|
* Translators:: List of translators
|
|
|
|
Guides
|
|
|
|
* Posting news:: How to post news items
|
|
* Adding a project:: How to add a project
|
|
|
|
@end detailmenu
|
|
@end menu
|
|
|
|
@node Webmastering, Translating, Top, Top
|
|
@chapter Webmastering
|
|
|
|
This chapter will describe how to be a webmaster of FSFE. It will
|
|
describe how the pages are envisioned, what files can be edited, how they
|
|
should be edited and various other bits that are of particular interest
|
|
to a webmaster.
|
|
|
|
@menu
|
|
* Focuses:: How the user finds information
|
|
* Source files:: What files to edit
|
|
* Editing:: How to actually edit them
|
|
* Automatic updates:: Pages magically update themselves!
|
|
* Special files:: How to work with the magic glue
|
|
@end menu
|
|
|
|
@node Focuses, Source files, Webmastering, Webmastering
|
|
@section Focuses
|
|
The FSFE web pages are divided into focuses. Each focus represents a
|
|
view of the web tree that contains all the information of global importance,
|
|
aswell as the information relevant to the focus. A focus is usually a
|
|
geographic area, such as Germany or France. A visitor can choose which focus
|
|
to browse the pages with and will see slightly different things depending
|
|
upon their choices.
|
|
|
|
The pages themselves always contain the same information, no matter what
|
|
focus is selected. The only exception to this is pages which are automatically
|
|
generated. The notable things that change depending upon focus is the menu,
|
|
and which projects are displayed on the project pages. This makes it easy
|
|
for people to find information relevant for their interest.
|
|
|
|
@node Source files, Editing, Focuses, Webmastering
|
|
@section Source files
|
|
As a webmaster, about the only information one is usually interested in is
|
|
the content of the pages. This content is in the files named @code{*.xhtml}.
|
|
Each file contains an XML document, conforming to XHTML 1.0. These files
|
|
are particularly easy to update, since they look very much like every other
|
|
HTML file.
|
|
|
|
The information in these files will be transformed by XSL to produce the
|
|
finished web page. Be sure to maintain a correct structure in these files. It
|
|
should be similar to this:
|
|
|
|
@verbatim
|
|
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
|
|
<html>
|
|
<head>
|
|
<title>Some title</title>
|
|
</head>
|
|
|
|
<body>
|
|
Content of the page
|
|
</body>
|
|
|
|
<timestamp>$Date: 2006-05-08 14:31:35 $ $Author: reinhard $</timestamp>
|
|
</html>
|
|
<!--
|
|
Local Variables: ***
|
|
mode: xml ***
|
|
End: ***
|
|
-->
|
|
@end verbatim
|
|
|
|
@node Editing, Automatic updates, Source files, Webmastering
|
|
@section Editing
|
|
Once you've gotten hold of the correct source file to edit, things should be
|
|
smooth sailing. Just follow standard XHTML 1.0, and things will render
|
|
well in most browsers. Also, do make sure that the file is able to be validated
|
|
as an XHTML document. You can use the validator at
|
|
@url{http://validator.w3.org/} if you're not sure. A source file can
|
|
simply be uploaded to the validator and it should validate as XHTML
|
|
1.0 Transitional.
|
|
|
|
There is a program in the CVS tree called @file{tools/validate.pl}. If
|
|
you install the XML::LibXML Perl module, you can use that program to
|
|
make sure that your pages at least parse as valid XML before you
|
|
commit them to CVS.
|
|
|
|
The XML::LibXML module can be found in the Debian package
|
|
libxml-libxml-perl.
|
|
|
|
You use the program like this (after having made a change to
|
|
index.en.xhtml and index.fr.xhtml):
|
|
|
|
@verbatim
|
|
$ tools/validate.pl index.en.xhtml index.fr.xhtml
|
|
@end verbatim
|
|
|
|
If the program croaks, you need to fix the file before committing it
|
|
to CVS. If it does not, chances are that the page will render
|
|
nicely. It's still not guaranteed though, but it's a good enough
|
|
guess.
|
|
|
|
@node Automatic updates, Special files, Editing, Webmastering
|
|
@section Automatic updates
|
|
It's often the case that one wants to have certain pages updated
|
|
automatically, for example to allow the front page list the latest
|
|
five newsitems, or to have a list of projects automatically
|
|
generated. There is a support system in the build process that will do
|
|
these things in a general enough way to be useful for most tasks.
|
|
|
|
This will be explained in more detailed in the section about building
|
|
the web pages, but sufficiently to say, the process involves parsing
|
|
XML data in an intermediate step, producing XHTML information, which
|
|
is then fed to the main XSL transformation.
|
|
|
|
For every page that is automatically updated, there exists two files;
|
|
page.sources and page.xsl. The first file gives a list of all the XML
|
|
source files that should be used as input. The format of this file is
|
|
as follows:
|
|
|
|
@verbatim
|
|
directory/*/filename:focus
|
|
@end verbatim
|
|
|
|
Several lines of this type can exist in each sources file. The first
|
|
part of the line is a filename glob. The above example would match the
|
|
source files @code{directory/2001/filename.en.xml},
|
|
@code{directory/duck/filename.fr.xml}, and so on, depending upon the
|
|
language.
|
|
|
|
The focus specifies for what focuses the source files should be
|
|
included. This can be either @code{global}, which would cause the
|
|
files to be included for all focuses, or a country specific two-letter
|
|
tag to include it only for that specific focus.
|
|
|
|
The XSL file takes the sum of all source files and should produce a
|
|
valid XHTML document. Please see index.xsl, news/news.xsl and other
|
|
files in CVS for an example of how this is done.
|
|
|
|
For the webmaster, it's usually enough to note that the XHTML files
|
|
should be updated as usual, and that the XML files contain the input
|
|
to the automatic build process.
|
|
|
|
@node Special files, , Automatic updates, Webmastering
|
|
@section Special files
|
|
There are several special files in CVS that a webmaster should care
|
|
particularly for. Besides the file mentioned in the previous section
|
|
about automatic updates, there exists a directory called tools/. This
|
|
directory holds all kinds of tools used by the build process. It also
|
|
contain information that relates to the menus and the static texts on
|
|
the pages.
|
|
|
|
@node Translating, Building, Webmastering, Top
|
|
@chapter Translating
|
|
As a translator, your job is to make sure that as many pages as
|
|
possible have translations into your local language. The process of
|
|
translating is simple; usually, you take the original file, translate
|
|
the contents, and then save it under another filename, indicating the
|
|
language you're translating into. For example, @file{eucd.en.xhtml}
|
|
becomes @file{eucd.de.xhtml} for the German translation, and so on.
|
|
|
|
The question that most often arises is; what should be translated?
|
|
This is not a simple question to answer, and it's up to each
|
|
translator to do the best possible job at deciding this. Here are some
|
|
guidelines though:
|
|
|
|
@enumerate
|
|
@item
|
|
Always make sure that the @file{texts-en.xml} file in tools/ are
|
|
translated into your language. If you're making a German translation,
|
|
you should name the resulting file @file{texts-de.xml}, and similarly
|
|
for other languages. If this file is out of date, or not translated,
|
|
some texts might appear in English on your pages, despite other
|
|
translations.
|
|
|
|
@item
|
|
Keep up to date with the news items in @file{news/YEAR/} and
|
|
@file{COUNTRY/news/YEAR/} (where YEAR is something like 2002 or 2003,
|
|
and COUNTRY is a countrycode such as de, or fr). Make sure that every
|
|
item is translated and put into the translated file.
|
|
|
|
@item
|
|
All projects have a file called @file{project.en.xml} in their root
|
|
directory. Take care to keep these translated and updated.
|
|
|
|
@item
|
|
Aside from the above files, you should work on translating the most
|
|
important pages first. What pages constitutes as important, apart from
|
|
these guidelines, are left open. Please take care to keep all pages
|
|
you translate updated though. If you have very little time to check
|
|
for updates, it might make sense to translate pages that are not
|
|
updated very frequently instead of those that is.
|
|
@end enumerate
|
|
|
|
@node Building, Administrating, Translating, Top
|
|
@chapter Building
|
|
This chapter of the FSFE webmastering manual will describe the
|
|
steps involved in building the web pages from scratch. Normally, this
|
|
is not something that anyone should have to bother about. As a
|
|
webmaster and translator, it's sufficient to know how it works so that
|
|
one can fix problems with it as they arise.
|
|
|
|
Building a complete set of pages can take up to 15-20 minutes, so it
|
|
should not be done frequently.
|
|
|
|
There are several sections to this problem. The first one describes
|
|
the software requirements that are needed to build the pages. The
|
|
second describes the actual process of building pages, and the third
|
|
describe the @file{build.pl} script that does the actual building.
|
|
|
|
@menu
|
|
* Requirements:: What you must have to build the pages
|
|
* Process:: How the build process works
|
|
* build.pl:: How the build script works
|
|
@end menu
|
|
|
|
|
|
@node Requirements, Process, Building, Building
|
|
@section Requirements
|
|
The build script is created using Perl and requires several Perl
|
|
modules to function properly. Most of them are included in the
|
|
standard Perl distribution, but a few are not.
|
|
|
|
The non-standard modules that needs to be installed are:
|
|
|
|
@itemize
|
|
@item
|
|
@file{File::Find::Rule}.
|
|
This module is a simple interface to make recursive searches for
|
|
files. It's used extensively by the build script. It does not exist in
|
|
any known packages, so it needs to be installed from CPAN with the
|
|
following command:
|
|
|
|
@verbatim
|
|
# perl -MCPAN -e 'install File::Find::Rule;'
|
|
@end verbatim
|
|
|
|
@item
|
|
@file{XML::LibXSLT} and @file{XML::LibXML}.
|
|
These modules are both wrappers to the GNOME projects libxml and
|
|
libxslt libraries. They exists in the Debian packages
|
|
libxml-libxml-perl and libxml-libxslt-perl.
|
|
|
|
Version 1.50 of XML::LibXST and version 1.52 of XML::LibXML is known
|
|
to work. Later versions should work too. Those versions are, as of
|
|
this writing, found in the Debian testing distribution. The versions
|
|
in Debian stable are slightly too old and the build script would have
|
|
to be modified somewhat to work with those.
|
|
@end itemize
|
|
|
|
@node Process, build.pl, Requirements, Building
|
|
@section Process
|
|
The first point in understanding how the web pages work on a technical
|
|
level is to understand how the build process works. There are two
|
|
items that require additional explanations; translations and focuses.
|
|
|
|
@itemize
|
|
@item
|
|
When we create the pages from their respective sources, we make sure
|
|
that we produce files for all languages that we have translations
|
|
into. If the source file does not exist in a particular language, we
|
|
use the language of the original source file instead, and put a
|
|
special marker on the page saying that a translation to the selected
|
|
language could not be found.
|
|
|
|
This means that links can point to, for example,
|
|
@url{/help/help.de.html}, even if the help page does not have a German
|
|
translation. This is mostly useful because it means that if all the
|
|
links in help.de.html (despite that the content of the page might be
|
|
in English), point to German pages, the user will retain his or her
|
|
choice of language thruought the web site.
|
|
|
|
The build script has a post-processing instruction that makes sure
|
|
that links are changed to reflect this. This does mean that language
|
|
negotiation does not work, as such. Language negotiation only works
|
|
when someone visits the first page. Thereafter, the user will retain
|
|
the selected language even if the preference in the browser is
|
|
changed.
|
|
|
|
This also means that if a user selects another language on our web
|
|
pages, that language will be retained thruought the site, despite the
|
|
preference of the users browser.
|
|
|
|
@item
|
|
Focuses are ment to aid visitors in finding the right information for
|
|
their interest. At the moment, we have three focuses; Global, French,
|
|
and German. More will be added as time permits.
|
|
|
|
Every focus will always contain the information that is of global
|
|
interest, but that information might be supplemented by localised
|
|
information.
|
|
|
|
The things that are ``focused'' today is news items on the front page,
|
|
and the projects that are shown to a visitor.
|
|
@end itemize
|
|
|
|
Having noted that, we will turn our attention to the technical
|
|
implementation of these things. The first thing we have in our hands
|
|
is a source file, such as @file{help.en.xhtml}. The format of this
|
|
file should be as follows:
|
|
|
|
@verbatim
|
|
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
|
|
<html>
|
|
<head>
|
|
<title>FSFE - What needs to be done?</title>
|
|
</head>
|
|
<body>
|
|
Some content for the page.
|
|
</body>
|
|
<timestamp>$Date: 2006-05-08 14:31:35 $ $Author: reinhard $</timestamp>
|
|
</html>
|
|
@end verbatim
|
|
|
|
It's important to note that not all pages follow this convention. It's
|
|
a nice gesture to make sure that they do, but the build script
|
|
contains some magic to be able to parse and handle files in other
|
|
(older) formats aswell.
|
|
|
|
This source file needs additional information before it can be sent to
|
|
the final XSL transformation. In particular, we need to know what
|
|
translations exists for it, what the menu should look like for this
|
|
page and some special static text strings for the page.
|
|
|
|
The build process should find all this information and create a new
|
|
document from the above, merged with the additional information. When
|
|
finished, the result should look like this:
|
|
|
|
@verbatim
|
|
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
|
|
<buildinfo>
|
|
<trlist> <!-- All translations that this page exists in -->
|
|
<tr id="sv">Svenska</tr>
|
|
<tr id="en">English</tr>
|
|
</trlist>
|
|
<menuset> <!-- The menu items for the right hand bar -->
|
|
<menu id="menu/about">/about/about.html</menu>
|
|
</menuset>
|
|
<textset> <!-- The static text set for this language -->
|
|
<text id="menu/about">About</text>
|
|
</textset>
|
|
<document> <!-- The actual document, as read from the XHTML -->
|
|
<head>
|
|
<title>FSFE - What needs to be done?</title>
|
|
</head>
|
|
<body>
|
|
Some content for the page.
|
|
</body>
|
|
<timestamp>$Date: 2006-05-08 14:31:35 $ $Author: reinhard $</timestamp>
|
|
</document>
|
|
</buildinfo>
|
|
@end verbatim
|
|
|
|
The translations are looked up in the filesystem. The menu is taken
|
|
from file menu files in the @file{tools} directory. The texts are also
|
|
taken from the text files in the @file{tools} directory. If possible,
|
|
the build process must try to pick the text files for the language
|
|
that it is currently building for. If they don't exist, it should fall
|
|
back on the English texts.
|
|
|
|
This is, unfortunately, not all information that the XSL
|
|
transformation needs. It needs additional information about filenames
|
|
and other things. We must add these attributes:
|
|
|
|
@itemize
|
|
@item
|
|
buildinfo/@@original.
|
|
This attribute gives the language code of the original document (en
|
|
for most pages).
|
|
|
|
@item
|
|
buildinfo/@@filename.
|
|
The XSL process is made self-aware with this tag. It includes the
|
|
filename that we're currently building, but without language tag or
|
|
the trailing @file{.html}.
|
|
|
|
@item
|
|
buildinfo/@@language.
|
|
The language that we're currently building the page for.
|
|
|
|
@item
|
|
buildinfo/@@outdated.
|
|
This attribute is set to ``yes'' if the original file is newer than
|
|
this translation.
|
|
|
|
@item
|
|
document/@@language.
|
|
Set to the language of the document. This might be different than the
|
|
language of the page, if we could not find a proper translation.
|
|
@end itemize
|
|
|
|
With these addition, the result could look like this:
|
|
|
|
@verbatim
|
|
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
|
|
<buildinfo original="en" filename="about/background"
|
|
language="de" outdated="no">
|
|
...
|
|
<document language="en">
|
|
...
|
|
</document>
|
|
</buildinfo>
|
|
@end verbatim
|
|
|
|
With all this information, the XSL transformation is ready to
|
|
begin. The resulting buildinfo node is passed to the
|
|
@file{fsfe-new.xsl} XSL file, which transforms the document into the
|
|
final XHTML file that is put into the web tree. Observe that this is
|
|
done once for every focus.
|
|
|
|
And if you thought that that was it, you're in for a surprise now! We
|
|
havn't even begun to mention automatically updated pages. Luckily,
|
|
they are not very complex.
|
|
|
|
If there exists a file, @file{name.xsl} in addition to the normal
|
|
source files, @file{name.lang.xhtml}, this means that the page is
|
|
updated automatically from the source files mentioned in
|
|
@file{name.sources}.
|
|
|
|
To unravel this mystery, we will first look at the sources file, which
|
|
can take the following form:
|
|
|
|
@verbatim
|
|
projects/*/project:global
|
|
de/projects/*/project:de
|
|
@end verbatim
|
|
|
|
The sources file contains a list of glob patterns and their respective
|
|
focus. The special focus, ``global'', means that the source files
|
|
matching that glob pattern, will be included for all focuses.
|
|
|
|
When the build process creates an automatically updated page, it
|
|
begins by picking out the glob patterns for the current focus and
|
|
adding ``.lang.xml'' to each pattern, once for each language. All
|
|
files that match that glob pattern are then assembled into one set.
|
|
Note that if we're generating a page in German, and there does not
|
|
exist a file, @file{projects/a/project.de.xml}, but there does exist a
|
|
file @file{projects/a/project.en.xml}, the English version of the file
|
|
will be included for completeness.
|
|
|
|
Suppose we have two files with the following content:
|
|
|
|
@verbatim
|
|
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
|
|
<newsset>
|
|
<news date="2002-12-18">
|
|
<title>..</title>
|
|
<body>..</body>
|
|
</news>
|
|
<news date="2002-12-14">
|
|
<title>..</title>
|
|
<body>..</body>
|
|
</news>
|
|
</newsset>
|
|
@end verbatim
|
|
|
|
and
|
|
|
|
@verbatim
|
|
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
|
|
<newsset>
|
|
<news date="2002-12-20">
|
|
<title>..</title>
|
|
<body>..</body>
|
|
</news>
|
|
</newsset>
|
|
@end verbatim
|
|
|
|
The assembled file will look like this:
|
|
|
|
@verbatim
|
|
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
|
|
<set>
|
|
<news date="2002-12-18">...</news>
|
|
<news date="2002-12-14">...</news>
|
|
<news date="2002-12-20">...</news>
|
|
</set>
|
|
@end verbatim
|
|
|
|
Note that we loose the name of the top node. This is irrelevant for
|
|
the transformation and having a common name means that we can,
|
|
theoretically, include sets of different names into the resulting
|
|
output.
|
|
|
|
This resulting file is then merged with the @file{file.en.xhtml} file
|
|
before it is passed to @file{file.xsl} for transformation. The way it
|
|
does this is to simply insert the <set> node as a child of the <html>
|
|
node.
|
|
|
|
This transformation MUST result in an XML file that can then be used
|
|
as input to @file{fsfe-new.xsl}, which in turn produces the finished
|
|
page.
|
|
|
|
@node build.pl, , Process, Building
|
|
@section build.pl
|
|
The @file{build.pl} script implements the build process described in
|
|
the previous section. It has not been extensively tested and has never
|
|
been optimized for speed.
|
|
|
|
The script reads files from the current directory and produces the
|
|
resulting web tree in the directory specified. It currently accepts
|
|
the following options:
|
|
|
|
@itemize
|
|
@item
|
|
-q.
|
|
Quiet more. This will cause the script to be quiet about everything
|
|
except plain errors.
|
|
|
|
@item
|
|
-u.
|
|
Update only. This can be used to speed up the processing a
|
|
bit. Normally, the script will remove everything from the destination
|
|
directory before creating new pages there. This will leave all files
|
|
in their former destinations and only build them if they have been
|
|
changed.
|
|
|
|
@item
|
|
-d.
|
|
Print some debug information.
|
|
|
|
@item
|
|
-n.
|
|
Dry-run only. Using this switch prevents the script from writing any
|
|
information to disk. All pages are generated, but the results are
|
|
discarded. Can be used to verify that a tree will build correctly.
|
|
|
|
@item
|
|
-o <directory>.
|
|
This switch must be specified. It lets the script know to which
|
|
directory it should write the finished pages. This top level directory
|
|
will contain a secondary directory for each focus.
|
|
|
|
@end itemize
|
|
|
|
|
|
@node Administrating, People, Building, Top
|
|
@chapter Administrating
|
|
|
|
@menu
|
|
* Apache:: Apache installation
|
|
* Perl:: Perl installation
|
|
@end menu
|
|
|
|
@node Apache, Perl, Administrating, Administrating
|
|
@section Apache
|
|
|
|
@node Perl, , Apache, Administrating
|
|
@section Perl
|
|
|
|
@node People, Guides, Administrating, Top
|
|
@chapter People
|
|
|
|
@menu
|
|
* Webmasters:: List of current webmasters
|
|
* Translators:: List of translators
|
|
@end menu
|
|
|
|
@node Webmasters, Translators, People, People
|
|
@section Webmasters
|
|
|
|
@node Translators, , Webmasters, People
|
|
@section Translators
|
|
|
|
@node Guides, , People, Top
|
|
@chapter Guides
|
|
This chapter contains simple step-by-step guides to performing certain
|
|
functions on the FSFE web site, such as posting news, adding new
|
|
projects and so on.
|
|
|
|
@menu
|
|
* Posting news::
|
|
* Adding a project::
|
|
@end menu
|
|
|
|
@node Posting news, Adding a project, Guides, Guides
|
|
@section Posting news
|
|
When you're posting a news item, you have a choice to make; should it
|
|
be a global item, or a localised item? The decision you make will
|
|
influence which directory to put the information in. For a global news
|
|
item, you should place it in @file{news/} and @file{country/news/} for
|
|
localised news.
|
|
|
|
Each directory mentioned should have one subdirectory for each
|
|
year. Those directories should contain files of the form
|
|
@file{news.en.xml} which can contain any number of news items. An
|
|
English version of the news files are mandatory.
|
|
|
|
Global news will be included for every focus. Localised news only for
|
|
each respective focus. A news item in @file{news.en.xml} can look like
|
|
this:
|
|
|
|
@verbatim
|
|
<news date="2002-02-01">
|
|
<title>Something happened</title>
|
|
<body>
|
|
Something happened today, but we're not quite sure what.
|
|
</body>
|
|
<link>http://www.example.com/</link>
|
|
</news>
|
|
@end verbatim
|
|
|
|
Once this has been commited to CVS, the item will be included in the
|
|
news listings once the next update has been run.
|
|
|
|
@node Adding a project, , Posting news, Guides
|
|
@section Adding a project
|
|
As for news items, the location of a project depends on whether it is
|
|
of global interest or a local project. Place a directory with all
|
|
project information in the @file{projects/} or
|
|
@file{country/projects/} hierarchy.
|
|
|
|
In addition to a directory, decide on a classification for the project
|
|
(one of community, legal, other and technical). Put that information
|
|
in a @file{project.en.xml} file in the root directory of the project.
|
|
|
|
|
|
|
|
@verbatim
|
|
<?xml version="1.0" encoding="iso-8859-1" ?>
|
|
|
|
<projectset>
|
|
<project type="legal">
|
|
<title>Some project</title>
|
|
<description>
|
|
A description of the project.
|
|
</description>
|
|
<link>/projects/some/project.html</link>
|
|
</project>
|
|
</projectset>
|
|
@end verbatim
|