I am new to the list, although not new to Red Hat Linux. I am
interested in writing docs for anaconda, so, is anyone was already
working on them?
Taking a look at the Documentation project site, I see that I need
Docbook XML, stylesheets, Emacs PSGML (or NXML), etc. What is the
learning curve for these? I have never done XML, and I am not an Emacs
user (sorry to start a flamewar). Perhaps I could write the text and
someone with more knowledge of XML/Emacs could put it into the right
format. I am not unwilling to learn XML/Emacs, but my time might be
spent better elsewhere.
Let me know what you all think.
It is a question about fedora-docs.
Almost all the file names of fedora-docs do not correspond to multilingual.
Originally you should be as follows.
Is such correction made?
Tadashi Jokagi/Shibuya city mailto:email@example.com
Yokukitana with PukiWiki http://elf.no-ip.org/wiki/
I would like to volunteer to the fedora-docs project as a technical
writer/editor. I have already started a HOWTO/tutorial on the topic of
keeping multiple fedora systems up2date with yum. Would this be useful
for the project? Is there somewhere I can send or check in my XML
sources I have so far?
Hello everyone, I looking to help out where I can with the documentation
project. However, I have a few questions which I could not find answers
1. Are sections on the project site the only ones being pursued?
The main site shows --
Tammy Fox: Installation Guide
Paul W. Frields: TBD
Luiz Rocha: Configuring and Using PDAs
2. For sections underway, what are their status?
3. Are there any priorities or road maps for this project?
4. The main Red Hat site already has some great documentation which is
largely applicable to Fedora, is anybody "converting" or "borrowing"
from this to get started? (better yet, are we allowed to do so, legally)
[ sorry if this is posted twice - my fault ]
I think it is time to do some research on how we should handle the
translations. There were some messages about this in the past, but we
should also look at other projects and how they handled it. I suggest
you reply to this message with information about other translation
efforts, so we can learn from them.
I'll start with a description of the PHP Manual, since I spend some of
my time there.
The whole documentation [ http://php.net/manual ] is a DocBook document,
split over many files. Every function is kept in a single file, and all
those files are then merged in the build process. Many entities exist,
especially for URL's.
A summary of the directory tree, sorted for clarity:
RFC/ -> internal discussion
howto/ -> documentation for newcomers
scripts/ -> scripts giving info about the manual
images/ -> all images
dtds/ -> the docbook XML 4.1.2 dtd, with some extensions
entities/ -> all used entities
dsssl/ -> DSSSL files, for converting the DocBook source
xsl/ -> XSL files, for converting to some newer formats
chm/ -> information to make CHM (Windows help) files
htmlhelp/ -> same, but newer (I think)
en/ -> the xml sources
README --> Some info about the stuff you downloaded
contacts.txt -> main contact for each translation
configure[.in] --> Need to explain these?
manual.xml[.in] -> the main file, which holds everything together
The main documentation tree resides in en/. Other translations use the
same directory structure (filenames!) and entities (references!), but in
their own directory (nl/, fr/, ...). If a file or entity is missing, the
English version is used.
When running ./configure, some scripts are run to fill up the missing
entities, and create the manual.xml file. The makefile then executes
(open)jade or other XML tools, depending on the requested output format.
Because the transformation can take a long time (30-150 mins per format,
about 6 formats, about 30 languages), the real site isn't updated that
often. They want to change from the 'real' DocBook conversion to a
homemade 'LiveDocs' project, that would convert the pages on-the-fly.
All translations have their own mailinglist (phpdoc-nl(a)php.net, for
example). CVS commits go to these mailinglists (the commits to the main
en/ tree go to phpdoc(a)php.net). Bugs that are filed in the Documentation
category also end up here. Normal discussions also take place in these
All translators have CVS access to their directory tree, and to the main
tree. This way, they can clean up errors in the main text as they find
them while translating.
The CVS tree can be viewed at [ http://cvs.php.net ].
The main inconv: of fedora now is we users powerusers of linux are unable to find out or innnovate the Fedora only bcosa we are not getting the Any PDF MANUALS OR INSTALLATION GUIDE OR CUSTOMISATION GUIDES THAT KIND OF STUFF AS WE ARE AVAILABLE as in REDHAT LINUX 9; So if anyone is hjaving the Fedora PDF manauals please send me to maild id:
So that we can customise the Fedora how it works and what are the pros and cons between the RedhatLinux and Fedora new releases..
Senior Support Engineer
FIRST SIGHT COMPUTING
E mail: nagaraj(a)1care.org
Are there any plans to documentate the configuration files, and their
relationship to each other? I know Fedora is a end-user-oriented
project, but for that one case when you need to change something for
which there is no GUI, it's not always easy to know where to start ("if
I want to add a directory to my path, where should I put it?").
The man pages alone don't always offer all the information you need:
configuration files can be very distro-specific, and might put the usual
configuration files in a totally different context.
If this doesn't fall under the scope of this project, I might start
something like this on my own, but of course it's always easier if we
I was just curious as to what sort of qualifications are needed to
become an editor? I'm not a programmer by any means (basic scripting
etc) but would be very interested in editing/proof-reading etc. I
apologize in advance if this is not the correct forum in which to ask my
dgonzo at optonline dot net
spam_me_silly at linux dot net
Conglomerate just got "stable", and I'm sure RPM's will flow in soon
(if they're not already there). How can we use this tool to integrate
into the Fedora Docs Project, for folk that do not want to use Emacs?
 - www.conglomerate.org
Colin Charles, byte(a)aeon.com.my