So here is attached a change suggestion for your file.
I only looked at the translation part.
Lucien
Le 04/04/2016 11:44, Lucien Gentis a écrit :
Anyway, I'll take a look at your page, . . . , as well
Cheers
Lucien
Le 04/04/2016 11:38, Luis Gil a écrit :
On Mon, 4 Apr 2016 at 11:33 Luis Gil <ljgbpfeif...@googlemail.com> wrote:
Ok... OH god i press too much the S key =O
On Mon, 4 Apr 2016 at 11:19 Lucien Gentis
<lucien.gen...@univ-lorraine.fr
<mailto:lucien.gen...@univ-lorraine.fr>> wrote:
Le 04/04/2016 10:51, Luis Gil a écrit :
Is that a like or dislike ;)
El lun., 4 de abril de 2016 9:03, Lucien Gentis
<lucien.gen...@univ-lorraine.fr
<mailto:lucien.gen...@univ-lorraine.fr>> escribió:
Le 01/04/2016 20:04, Luis Gil a écrit :
Linkedin: https://linkd.in/Ljjt8L
Twitter : https://twitter.com/luigy_tspg
On 1 April 2016 at 18:49, Yann Ylavic
<ylavic....@gmail.com> wrote:
On Fri, Apr 1, 2016 at 6:36 PM, Luca Toscano
<toscano.l...@gmail.com> wrote:
>
> +1, let's concentrate on 2.4 :)
You know, there is still many 2.2 around, and some
people may have
backported 2.4 fixes to 2.2 and decide to propose
them some days.
If three PMC members (at least) think a 2.2.32 is
worth it, it may
well be out ;)
But I agree that we should mainly reference 2.4 in
the "generic" docs.
Regards,
Yann.
---------------------------------------------------------------------
To unsubscribe, e-mail:
docs-unsubscr...@httpd.apache.org
For additional commands, e-mail:
docs-h...@httpd.apache.org
<mailto:docs-h...@httpd.apache.org>
Hello:
Check this draft i have made of the docsformat page and
tell me how you see it.
i attach ass well a diff file so it can be easy to view
the changes.
=-O
Just reread your last sentence :-)
---------------------------------------------------------------------
To unsubscribe, e-mail:docs-unsubscr...@httpd.apache.org
<mailto:docs-unsubscr...@httpd.apache.org>
For additional commands, e-mail:docs-h...@httpd.apache.org
<mailto:docs-h...@httpd.apache.org>
--
Lucien GENTIS
UNIVERSITE DE LORRAINE - ESPE
Centre de Ressources Informatiques
5, Rue Paul Richard
C.O. 3 - MAXEVILLE
54528 LAXOU-CEDEX
Tél. 03 72 74 13 28
Email :lucien.gen...@univ-lorraine.fr
<mailto:lucien.gen...@univ-lorraine.fr>
--
Luis J.G
--
Lucien GENTIS
UNIVERSITE DE LORRAINE - ESPE
Centre de Ressources Informatiques
5, Rue Paul Richard
C.O. 3 - MAXEVILLE
54528 LAXOU-CEDEX
Tél. 03 72 74 13 28
Email :lucien.gen...@univ-lorraine.fr
<mailto:lucien.gen...@univ-lorraine.fr>
--
Luis J.G
By the way i have made a small change on the page, give it a review.
Regards
Luis
--
Luis J.G
---------------------------------------------------------------------
To unsubscribe, e-mail:docs-unsubscr...@httpd.apache.org
For additional commands, e-mail:docs-h...@httpd.apache.org
--
Lucien GENTIS
UNIVERSITE DE LORRAINE - ESPE
Centre de Ressources Informatiques
5, Rue Paul Richard
C.O. 3 - MAXEVILLE
54528 LAXOU-CEDEX
Tél. 03 72 74 13 28
Email :lucien.gen...@univ-lorraine.fr
--
Lucien GENTIS
UNIVERSITE DE LORRAINE - ESPE
Centre de Ressources Informatiques
5, Rue Paul Richard
C.O. 3 - MAXEVILLE
54528 LAXOU-CEDEX
Tél. 03 72 74 13 28
Email : lucien.gen...@univ-lorraine.fr
Title: Module Format and Transformation
Notice: Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
.
http://www.apache.org/licenses/LICENSE-2.0
.
Unless required by applicable law or agreed to in writing,
software distributed under the License is distributed on an
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
KIND, either express or implied. See the License for the
specific language governing permissions and limitations
under the License.
# Module Format and Transformation #
This document describes the format of the Apache HTTP Server documentation
xml source files and the technique used to transform them to html.
# Format #
A DTD is located in the [style
directory](http://httpd.apache.org/docs/2.2/style/) of the manual. An
example of the format with extensive comments is also available in
[mod_template.txt](mod_template.txt). Obviously, the file extension should
be `xml`. It was changed to make the online viewing simpler.
To ensure that your documentation follows the defined format, you should
parse it using the DTD. Some help using Emacs with XML files is available
from [IBM
developerWorks](http://www-106.ibm.com/developerworks/xml/library/x-emacs/).
Various formatting syntax can be used such as:
<table border="1">
<tr><th>Keyword</th><th>Purpose</th></tr>
<tr><td><example> ... </example></td><td>Format an example as
monospaced font</td></tr>
<tr><td><highlight language="config"> ... </highlight></td>
<td>A configuration example, syntax highlighted. Can also use language="perl",
"lua", or "C"</td></tr>
When translating the documentation, you should know the following:
- Set UTF-8 charset to your editor encoding type.
- Add encoding to the first line of XML file like this:
<?xml version="1.0" encoding="UTF-8" ?>
- We suggest you begin to translate the trunk branch of the documentation, then
port this translation to other branches (2.4 and 2.2).
- Make sure that each line has a max length of 80 characters, this is for a
better read.
- Remember to change the XML file top comment like:
> <code><!-- $LastChangedRevision: 1673947 $ --></code>
To:
> <code><!-- English Revision: 1673947 --></code>
This is a good practice so we can keep track on what have been updated and
translated here:
http://home.apache.org/~takashi/translation-status/test.html
In addition, if this "English Revision:" comment is not present, XML file
will always be considered "Out of date", and its translated HTML version
will display a warning on top.
- Make sure you put your name at the top of the file if you are translating or
reviewing the documentation like this:
> <code><!-- Translated by: <translator name> --></code>
> <code><!-- Reviewed by: <reviewer name> --></code>
as shows the [translation page](translations.html)
If you want to do any changes to the Web-page of the doc-project there is more
information about how is made [here.](http://www.apache.org/dev/cmsref#markdown)
</table>
# Transformation #
The easiest way to view the tranformed docs is to simply open the xml file
directly in a recent verions of MSIE, Netscape, or Mozilla. (MSIE 6 seems
to work consistently. The Gecko/Mozilla based browsers, however, do not
incorporate the referenced DTDs, so they have problems with documents
containing character entities). These browsers will read the xsl file and
perform the transformation for you automatically, so that you can see what
the final output will look like. This means that you can work on the docs
and check your work without any special transformation setup.
For the final presentation, it is still necessary to transform to html to
accomodate older browsers. Although any standards-compliant xslt engine
should do, changing engines can lead to massive diffs on the transformed
files. Therefore, we have chosen a single recommended transformation system
based on Xalan+Xerces Java and Ant. These are all Apache projects
distributed under the Apache license.
The only prerequisite for the transformation is a Java 1.2 or greater JVM
(which can be obtained free from Oracle). Assuming you already have
[httpd/httpd/branches/2.2.x/docs/](http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/docs/)
(or the equivalent from another branch for example
[current](http://httpd.apache.org/docs/current/)) checked
out from SVN (If you need instructions on setting up SVN, see
[this page](http://www.apache.org/dev/version-control.html).).
##Here is what you need to do to build##
You have to add the build scripts files to the `/httpd-trunk/docs/manual/`
location of your
actual working documentation brunch locally as shown below:
><code>$ cd docs/manual<br></br>$ svn co
http://svn.apache.org/repos/asf/httpd/docs-build/trunk build<br></br>$ cd
build<br></br>$./build.sh</code>
If every thing goes good you should get something like:
><code>BUILD SUCCESSFUL<br>Total time: 2 seconds</code>
If you are running under win32, the build.sh script will work if
[cygwin](https://www.cygwin.com/) is
installed. Alternatively, on Win32, you should be able to run the
`build.bat` script.
You may need to add the <code>JAVA_HOME</code> enviroment variable
when buillding the documentation, and change the amount of ram needed in the
`.bat` file
if you get a `java.lang.StackOverflow` error.
If you don't want to get the build files from SVN, you can download a
pkzipped version of the current build tools from our [distribution
directory](http://www.apache.org/dyn/closer.lua/httpd/docs/).
The default target builds only the english-language docs. To build other
docs, you should specify the language-code (ja, de, etc) as an argument, or
use the `all` target. To find the available languages, please see our
[translations page](translations.html).
You can get an overview of all possible build targets by typing:
> `
./build.sh -projecthelp
`
# Validating changes #
Before submitting or committing changes, you should check that the XML is
correct, and the generated HTML:
><code>./build.sh validate-xml<br></br>./build.sh validate-xhtml</code>
# Special Files #
When adding a new module, the transformation process tries to generate an
appropriate entry within `mod/allmodules.xml` and to create an accompanying
metafile ( `newfilename.xml.meta` ). Since these tasks are written in
[perl](http://www.perl.org/) , you'll need a working perl installation for
this. If not, you should take these steps manually, or just leave a note on
the project mailing list so that someone else can do it.
# Generating a PDF version #
The PDF version of the docs is generated by transforming the xml files to
LaTeX using the "latex-en" Ant target. The XSLT style files for the
transformation are under `style/latex/`. Once you have the `.tex`
equivalent of each `.xml` file, you can use `pdflatex` to convert this into
a pdf file. Recommended versions of pdflatex can be obtained as part of
TeTeX (unix) or MikTeX (win32), but any version of TeX should be fine, as
long as it is sufficiently complete and modern. To generate the PDF, you
should process the `sitemap.tex` file, which contains the main LaTeX
document code and will include all the other files. The outputed PDF will
then be called `sitemap.pdf` , which you can rename how you choose.
Some notes about the XML to LaTeX conversion are necessary. Although HTML
and LaTeX have many similarities, there are enough differences between the
two to make targetting both outputs a difficult task. In particular, the
methods for handling tables are very different. To aid in the conversion to
LaTeX of tables designed for HTML, a `<columnspec>` section should be
added to each table. Inside the `<columnspec>` , place a `<column
width=".xx"/>` for each column in the table, where `xx` is the
percentage of the line-width devoted to that column. This will assist in
the conversion of basic tables. More complex stuff (like spanning rows or
columns) is not currently convertible.
Further, `pdflatex` cannot incorporate GIF files in a generated PDF, so any
graphics must be available in PNG format.
There are various other restrictive assumptions embedded in the XSLT that
work for the current docs, but may need to be modified in the future. For
example, the code that transforms HTML-style links to LaTeX
cross-references will only work within the main directory and one level of
subdirectory. Also, `<pre>` sections rarely work well in LaTeX
because of differences in escaping and formatting rules in `verbatim`
sections.
Finally, there are various differences in escaping rules between XML/HTML
and LaTeX. Some characters need to be backslash-escaped in LaTeX, and all
XML entitites (&whatever;) must be converted to LaTeX equivalents. This
is currently handled for a limited set of characters using a big, ugly
search-replace in the XSLT. This may need to be modified in the future,
especially to handle translations. Pre-processing with a perl script and a
substitution table may be a better solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: docs-unsubscr...@httpd.apache.org
For additional commands, e-mail: docs-h...@httpd.apache.org
