diff --git a/Manuals/Repository/Docbook/Commons.ent b/Manuals/Repository/Docbook/Commons.ent
index 88dad24..3091319 100644
--- a/Manuals/Repository/Docbook/Commons.ent
+++ b/Manuals/Repository/Docbook/Commons.ent
@@ -20,7 +20,7 @@
<!ENTITY C "CentOS">
<!ENTITY TC "The &C;">
-<!ENTITY TCP "<ulink url='http://www.centos.org'>&TC; Project</ulink>">
+<!ENTITY TCP "<ulink type='http' url='http://www.centos.org'>&TC; Project</ulink>">
<!ENTITY TCC "&TC; Community">
<!ENTITY TCD "&TC; Distribution">
<!ENTITY TCA "&TC; Artwork">
@@ -31,13 +31,13 @@
<!ENTITY TCPCVIS "&TCP; &CVIS;">
<!ENTITY TCPMCVIS "&TCP; &MCVIS;">
-<!ENTITY TCAR "<ulink url='https://projects.centos.org/svn/artwork'>&TCA; Repository</ulink>">
-<!ENTITY TCAS "<ulink url='https://projects.centos.org/trac/artwork'>&TCA; SIG</ulink>">
+<!ENTITY TCAR "<ulink type='https' url='https://projects.centos.org/svn/artwork'>&TCA; Repository</ulink>">
+<!ENTITY TCAS "<ulink type='https' url='https://projects.centos.org/trac/artwork'>&TCA; SIG</ulink>">
<!ENTITY TCARUG "&TCAR; User's Guide">
<!ENTITY TCDRS "&TCD; Release Schema">
-<!ENTITY TCAML "<ulink url='http://lists.centos.org/mailman/centos-artwork'>&TCA; Mailing List</ulink>">
-<!ENTITY TCDML "<ulink url='http://lists.centos.org/mailman/centos-devel'>&TC; Developers Mailing List</ulink>">
+<!ENTITY TCAML "<ulink type='http' url='http://lists.centos.org/mailman/centos-artwork'>&TCA; Mailing List</ulink>">
+<!ENTITY TCDML "<ulink type='http' url='http://lists.centos.org/mailman/centos-devel'>&TC; Developers Mailing List</ulink>">
<!ENTITY TCW "&TC; Web Environment">
<!ENTITY TCS "&TC; Showroom">
<!ENTITY TCB "&TC; Brand">
diff --git a/Manuals/Repository/Docbook/Introduction.docbook b/Manuals/Repository/Docbook/Introduction.docbook
index cfc091d..d483c3b 100644
--- a/Manuals/Repository/Docbook/Introduction.docbook
+++ b/Manuals/Repository/Docbook/Introduction.docbook
@@ -9,11 +9,10 @@
</para>
<para>
- &TCARUG; describes how The CentOS Project corporate visual
- identity is organized and produced inside &TCAR;. If you are
- looking for a comprehensive, task-oriented guide for
- understanding how &TCPCI; is produced, this is the manual for
- you.
+ &TCARUG; describes how &TCPCVI; is organized and produced
+ inside &TCAR;. If you are looking for a comprehensive,
+ task-oriented guide for understanding how &TCPCI; is produced,
+ this is the manual for you.
</para>
<para>
@@ -29,9 +28,6 @@
&intro-copying;
&intro-policy;
&intro-worklines;
- &intro-relbdirs;
- &intro-syncpaths;
- &intro-extending;
&intro-filenames;
&intro-layout;
diff --git a/Manuals/Repository/Docbook/Introduction.ent b/Manuals/Repository/Docbook/Introduction.ent
index 6cf79cb..d730bd1 100644
--- a/Manuals/Repository/Docbook/Introduction.ent
+++ b/Manuals/Repository/Docbook/Introduction.ent
@@ -10,13 +10,17 @@
<!ENTITY intro-docconvs SYSTEM "Introduction/Docconvs.docbook">
-<!ENTITY intro-copying SYSTEM "Introduction/Copying.docbook">
-<!ENTITY intro-policy SYSTEM "Introduction/Policy.docbook">
-<!ENTITY intro-worklines SYSTEM "Introduction/Worklines.docbook">
-<!ENTITY intro-relbdirs SYSTEM "Introduction/Relbdirs.docbook">
-<!ENTITY intro-syncpaths SYSTEM "Introduction/Syncpaths.docbook">
-<!ENTITY intro-extending SYSTEM "Introduction/Extending.docbook">
-<!ENTITY intro-filenames SYSTEM "Introduction/Filenames.docbook">
-<!ENTITY intro-layout SYSTEM "Introduction/Layout.docbook">
+<!ENTITY intro-copying SYSTEM "Introduction/Copying.docbook">
+<!ENTITY intro-policy SYSTEM "Introduction/Policy.docbook">
+<!ENTITY intro-worklines SYSTEM "Introduction/Worklines.docbook">
+<!ENTITY intro-worklines-identity SYSTEM "Introduction/Worklines/identity.docbook">
+<!ENTITY intro-worklines-l10n SYSTEM "Introduction/Worklines/l10n.docbook">
+<!ENTITY intro-worklines-manuals SYSTEM "Introduction/Worklines/manuals.docbook">
+<!ENTITY intro-worklines-scripts SYSTEM "Introduction/Worklines/scripts.docbook">
+<!ENTITY intro-worklines-relbdirs SYSTEM "Introduction/Worklines/relbdirs.docbook">
+<!ENTITY intro-worklines-syncpaths SYSTEM "Introduction/Worklines/syncpaths.docbook">
+<!ENTITY intro-worklines-extending SYSTEM "Introduction/Worklines/extending.docbook">
+<!ENTITY intro-filenames SYSTEM "Introduction/Filenames.docbook">
+<!ENTITY intro-layout SYSTEM "Introduction/Layout.docbook">
<!ENTITY intro-feedback SYSTEM "Introduction/Feedback.docbook">
diff --git a/Manuals/Repository/Docbook/Introduction/Extending.docbook b/Manuals/Repository/Docbook/Introduction/Extending.docbook
deleted file mode 100644
index e0bfa67..0000000
--- a/Manuals/Repository/Docbook/Introduction/Extending.docbook
+++ /dev/null
@@ -1,42 +0,0 @@
-<chapter id="intro-repoconvs-extending">
-
- <title>Extending Repository Organization</title>
-
- <para>
- Occasionly, you may find that new components of &TCPCVI; need
- to be added to the repository in order to work them out. If
- that is the case, the first question we need to ask ourselves,
- before starting to create directories blindly all over, is:
- <emphasis>What is the right place to store it?</emphasis>
- </para>
-
- <para>
- When the repository structure is extended, it is very useful
- to bear in mind &TCPCVIS;, &TCM; and &TCDRS;. The rest is a
- matter of choosing appropriate names. It is also worth to
- know that each directory in the repository responds to one or
- more concepts that justify its existence.
- </para>
-
- <para>
- To build a directory structure inside the repository, you need
- to define the concept behind it first and later create the
- directory, remembering that there are locations inside the
- repository that define concepts you probably would prefer to
- reuse. For example, the <filename
- class="directory">trunk/Identity/Images/Themes</filename>
- directory stores artistic motifs of different themes, the
- <filename
- class="directory">trunk/Identity/Models/Themes</filename>
- directory stores design models for themes, the <filename
- class="directory">trunk/Manuals</filename> directory stores
- documentation, the <filename
- class="directory">trunk/L10n</filename> stores translation
- messages, and the <filename
- class="directory">trunk/Scripts</filename> stores automation
- scripts. Using this information and the one provided in <xref
- linkend="intro-repoconvs-layout" />, it is possible for you to
- find out good places for extending &TCAR;.
- </para>
-
-</chapter>
diff --git a/Manuals/Repository/Docbook/Introduction/Layout.docbook b/Manuals/Repository/Docbook/Introduction/Layout.docbook
index 4b29108..048a0a6 100644
--- a/Manuals/Repository/Docbook/Introduction/Layout.docbook
+++ b/Manuals/Repository/Docbook/Introduction/Layout.docbook
@@ -46,7 +46,7 @@
<para>
The second level of directories in the repository provides
organization for each work line described in <xref
- linkend="intro-repoconvs-worklines" />.
+ linkend="intro-worklines" />.
</para>
<para>
diff --git a/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook
deleted file mode 100644
index 48e2f81..0000000
--- a/Manuals/Repository/Docbook/Introduction/Relbdirs.docbook
+++ /dev/null
@@ -1,128 +0,0 @@
-<chapter id="intro-repoconvs-relbdirs">
-
- <title>Relation Between Directories</title>
-
- <para>
- In order for automation scripts to produce content inside a
- working copy of &TCAR;, it is required that all work lines be
- related somehow. The relation between work lines is used by
- automation scripts to know where to retrive the information
- they need to work with (e.g., input files, translation
- messages, output locations, etc.). This kind of relation is
- built using two path constructions known as <emphasis>master
- paths</emphasis> and <emphasis>auxiliar paths</emphasis>.
- </para>
-
- <variablelist>
- <varlistentry>
- <term>Master Paths</term>
- <listitem>
- <para>
- A master path refers to a directory inside the repository that
- contain input files required to produce output files through
- automation scripts. Examples of master paths inside the
- repository include:
-
- <itemizedlist>
- <listitem>
- <para>
- <filename class="directory">trunk/Identity/Models/Brands</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Manuals/Repository/Docbook</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Identity/Models/Themes/Default/Distro/5/Anaconda</filename>
- </para>
- </listitem>
- </itemizedlist>
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Auxiliar paths</term>
- <listitem>
- <para>
- An auxiliar path refers a directory inside the repository
- considered auxiliar for the master path. Auxiliar path can be
- either for output or localization. Assuming the master path
- provides the input information, the auxiliar paths provide the
- auxiliar information which describes how and where that input
- information is rendered by automation scripts. Examples of
- auxiliar paths inside the repository include:
-
- <itemizedlist>
- <listitem>
- <para>
- <filename class="directory">trunk/Identity/Images/Brands</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Manuals/Repository/Docbook/es_ES</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Locales/Manuals/Repository/Docbook/es_ES</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES</filename>
- </para>
- </listitem>
- <listitem>
- <para>
- <filename class="directory">trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES</filename>
- </para>
- </listitem>
- </itemizedlist>
-
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
-
- <para>
- The relationship between master and auxiliar paths is built by
- combining the second directory level of master paths with
- directories in the second directory level of repository
- layout. In the second directory level of repository layout,
- the <filename class="directory">Identity</filename>, <filename
- class="directory">Manuals</filename> and <filename
- class="directory">Scripts</filename> directories are always
- used to create the master paths and the output auxiliar paths.
- The <filename class="directory">Locales</filename> directory,
- on the other hand, is always used to create localization
- auxiliar paths for all the master paths available under
- <filename class="directory">Identity</filename>, <filename
- class="directory">Manuals</filename> and <filename
- class="directory">Scripts directories</filename>.
- </para>
-
- <para>
- For example, if the <envar>LANG</envar> environment variable
- is set to <literal>es_ES.UTF-8</literal> and you execute the
- <function>render</function> functionality of
- <command>centos-art.sh</command> script with the <filename
- class="directory">trunk/Manuals/Repository/Docbook</filename>
- master path as argument, it will produce &TCARUG; in Spanish
- language using translation messages from <filename
- class="directory">trunk/Locales/Manuals/Repository/Docbook/es_ES</filename>
- auxiliar path and saving output files inside <filename
- class="directory">trunk/Manuals/Repository/Docbook/es_ES</filename>
- auxiliar path.
- </para>
-
- <para>
- To better understand what each directory inside the repository
- means, read <xref linkend="intro-repoconvs-layout" />.
- </para>
-
-</chapter>
diff --git a/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook
deleted file mode 100644
index 3d6245b..0000000
--- a/Manuals/Repository/Docbook/Introduction/Syncpaths.docbook
+++ /dev/null
@@ -1,93 +0,0 @@
-<chapter id="intro-repoconvs-syncpaths">
-
- <title>Syncronizing Paths</title>
-
- <para>
- Once both master and auxiliar paths have been set in the
- repository, they shouldn't be changed. However, assuming you
- need to change them, it is required that you also change the
- relation between them, in order for both master and auxiliar
- paths to retain their relation one another. This process of
- keeping relation between master and auxiliar paths updated is
- known as <emphasis>path syncronization</emphasis>.
- </para>
-
- <para>
- Path syncronization is required for automation scripts to know
- where to store final output, where to retrive translation, and
- any information that might be desired. If the relation between
- master paths and auxiliar paths is lost, there is no way for
- <command>centos-art.sh</command> script to know where to
- retrive the information it needs to work with. Path
- syncronization is the way we use to organize and extend the
- information stored in the repository.
- </para>
-
- <para>
- Path syncronization involves both movement of files and
- replacement of content inside files. Movement of files is
- related to actions like renaming files and directories inside
- the repository. Replacement of content inside files is
- related to actions like replacing information (e.g., paths
- information) inside files in order to keep file contents and
- file locations consistent one another after the movement.
- </para>
-
- <para>
- The order followed to syncronize path information is very
- important because the versioned nature of the files we are
- working with. When a renaming action is performed, we avoid
- making replacements inside files first and file movements
- later. This would require two commit actions: one for the
- files' internal changes and another for the file movement
- itself. Otherwise, we prefer to perform file movements first
- and file internal replacements later. This way it is possible
- to commit both changes as if they were just one.
- </para>
-
- <note>
- <para>
- There is no support for URLs actions inside
- <command>centos-art.sh</command> script. The
- <command>centos-art.sh</command> script is designed to
- work with local files inside the working copy only. If you
- need to perform URL actions directly, use Subversion
- commands instead.
- </para>
- </note>
-
- <para>
- At this moment there is no full implementation of path
- syncronization process inside <command>centos-art.sh</command>
- script and it is somthing we need to do oursleves. However,
- the <quote>texinfo</quote> backend of <code>help</code>
- functionality which provides a restricted implementation of
- path syncronization to this specific area of documentation
- through the <option>--copy</option>, <option>--delete</option>
- and <option>--rename</option> options you can take as
- reference to implement it in other areas.
- </para>
-
- <para>
- The plan for a full implementation of path syncronization
- would be to create individual restricted implementations like
- the one in <quote>texinfo</quote> backend for other areas that
- demand it and then, create a higher implmentation that
- combines them all as needed. This way, if we try to rename a
- repository directory the higher action will define which are
- all the restricted actions that should be performed in order
- to make the full path syncronization.
- </para>
-
- <para>
- For example, if the directory we are renaming is a master
- path, it is required to syncronize the related output and
- localization auxiliar paths. On the other hand, if the
- directory we are renaming through full path syncronization is
- an auxiliar path, it is required to determine first what is
- the related master path and later, perform the syncronization
- from master path to auxiliar paths as if the path provided
- would be the master path not the auxiliar path.
- </para>
-
-</chapter>
diff --git a/Manuals/Repository/Docbook/Introduction/Worklines.docbook b/Manuals/Repository/Docbook/Introduction/Worklines.docbook
index 14beb48..6f6987c 100644
--- a/Manuals/Repository/Docbook/Introduction/Worklines.docbook
+++ b/Manuals/Repository/Docbook/Introduction/Worklines.docbook
@@ -1,93 +1,24 @@
-<chapter id="intro-repoconvs-worklines">
+<chapter id="intro-worklines">
<title>Repository Work Lines</title>
<para>
To organize content production inside &TCAR;, production has
been divided into individual work lines that relate one
- another. The is based on the idea of doing one thing well and
- later combine the result of each individual part to achieve a
- higher purpose. Work lines, as conceived here, provide
- relayable output components that combine one another to close
- the production cycle inside &TCAR;.
+ another based on the idea of doing one thing well. Later, the
+ results produced individually by each work line are combined
+ to achieve a higher purpose. Work lines, as conceived here,
+ provide the relayable output components the production cycle
+ inside &TCAR; needs to let everyone to work syncronized in a
+ descentralized environment.
</para>
-
- <variablelist>
- <varlistentry>
- <term>Visual Identity (<filename class="directory">trunk/Identity</filename>)</term>
- <listitem>
- <para>
- In the production cycle, the first step takes place through
- graphic design. It is focused on preparing design models for
- all the visual manifestation &TCP; is made of. Here, graphic
- designers describe the visual characteristics of each visual
- manifestation (e.g., image dimensions, position of text in the
- visible area, translation markers, etc.). Later, once design
- models have been defined, graphic designers take care of
- artistic motifs to define the visual style of those design
- models already created (e.g., how the look and feel).
- Furthermore, graphic designers use the
- <function>render</function> functionality of
- <command>centos-art.sh</command> script to combine both design
- models and artistic motifs in order to produce the final
- images required by each visual manifestaions.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Localization (<filename class="directory">trunk/L10n</filename>)</term>
- <listitem>
- <para>
- The second step in the production cycle is to localize
- source files (e.g., SVG, DocBook, Shell scripts). This step
- makes possible to produce localized images, localized
- documentation and localized automation scripts. The
- localization tasks are carried on by translators using the
- <function>locale</function> functionality of the
- <command>centos-art.sh</command> script which take care of
- retriving translatable strings from source files and provide a
- consistent localization interface based on the ideas behind
- GNU <application>gettext</application> multi-lingual message
- production.
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Documentation (<filename class="directory">trunk/Manuals</filename>)</term>
- <listitem>
- <para>
- The third step in the production cycle is to document &TCAR;,
- what it is and how to use it. This step provides the
- conceptual ideas used as base to edificate &TCPCVI; and is
- implemented by mean of &TCARUG;. To write documentation,
- documentors use the <function>help</function> functionality of
- <command>centos-art.sh</command> script which provide an
- consistent interface for building documentation through
- different documentation backends (e.g., Texinfo, DocBook).
- </para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>Automation (<filename class="directory">trunk/Scripts</filename>)</term>
- <listitem>
- <para>
- The fourth step in the production cycle is to automate
- frequent tasks inside &TCAR;. This step closes the production
- cycle and provides the production standards needed by all
- different work lines to coexist together. Here is where we
- develop the <command>centos-art.sh</command> script and all
- its functionalities (e.g., <function>render</function> for
- rendition, <function>help</function> for documentation,
- <function>locale</function> for localization, etc.). At this
- point it should be obvious, but we consider worth to remember
- that: there is no need to type several tasks, time after time,
- if they can be programmed into just one executable script.
- </para>
- </listitem>
- </varlistentry>
- </variablelist>
+ &intro-worklines-identity;
+ &intro-worklines-l10n;
+ &intro-worklines-manuals;
+ &intro-worklines-scripts;
+ &intro-worklines-relbdirs;
+ &intro-worklines-syncpaths;
+ &intro-worklines-extending;
+
</chapter>
diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/extending.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/extending.docbook
new file mode 100644
index 0000000..5c9978a
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Worklines/extending.docbook
@@ -0,0 +1,42 @@
+<sect1 id="intro-worklines-extending">
+
+ <title>Extending Repository Layout</title>
+
+ <para>
+ Occasionly, you may find that new components of &TCPCVI; need
+ to be added to the repository in order to work them out. If
+ that is the case, the first question we need to ask ourselves,
+ before starting to create directories blindly all over, is:
+ <emphasis>What is the right place to store it?</emphasis>
+ </para>
+
+ <para>
+ When the repository structure is extended, it is very useful
+ to bear in mind &TCPCVIS;, &TCM; and &TCDRS;. The rest is a
+ matter of choosing appropriate names. It is also worth to
+ know that each directory in the repository responds to one or
+ more concepts that justify its existence.
+ </para>
+
+ <para>
+ To build a directory structure inside the repository, you need
+ to define the concept behind it first and later create the
+ directory, remembering that there are locations inside the
+ repository that define concepts you probably would prefer to
+ reuse. For example, the <filename
+ class="directory">trunk/Identity/Images/Themes</filename>
+ directory stores artistic motifs of different themes, the
+ <filename
+ class="directory">trunk/Identity/Models/Themes</filename>
+ directory stores design models for themes, the <filename
+ class="directory">trunk/Manuals</filename> directory stores
+ documentation, the <filename
+ class="directory">trunk/L10n</filename> stores translation
+ messages, and the <filename
+ class="directory">trunk/Scripts</filename> stores automation
+ scripts. Using this information and the one provided in <xref
+ linkend="intro-repoconvs-layout" />, it is possible for you to
+ find out good places for extending &TCAR;.
+ </para>
+
+</sect1>
diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook
new file mode 100644
index 0000000..4b7626d
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Worklines/identity.docbook
@@ -0,0 +1,26 @@
+<sect1 id="intro-worklines-idenity">
+
+ <title>Visual Identity</title>
+
+ <para>
+ In the production cycle, the first step takes place through
+ graphic design. It is focused on preparing design models for
+ all the visual manifestation &TCP; is made of. Here, graphic
+ designers describe the visual characteristics of each visual
+ manifestation (e.g., image dimensions, position of text in the
+ visible area, translation markers, etc.).
+ Later, once design models have been defined, graphic designers
+ take care of artistic motifs to define the visual style of
+ those design models already created (e.g., how they look and
+ feel).
+ </para>
+
+ <para>
+ Finally, graphic designers use the
+ <function>render</function> functionality of
+ <command>centos-art.sh</command> script to combine both design
+ models and artistic motifs in order to produce the final
+ images required by each visual manifestaions.
+ </para>
+
+</sect1>
diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook
new file mode 100644
index 0000000..31f5ebc
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Worklines/l10n.docbook
@@ -0,0 +1,22 @@
+<sect1 id="intro-worklines-l10n">
+
+ <title>Localization</title>
+
+ <para>
+ The second step in the production cycle is to localize
+ source files (e.g., SVG, DocBook, Shell scripts). This step
+ makes possible to produce localized images, localized
+ documentation and localized automation scripts.
+ </para>
+
+ <para>
+ The localization tasks are carried on by translators using the
+ <function>locale</function> functionality of the
+ <command>centos-art.sh</command> script which take care of
+ retriving translatable strings from source files and provide a
+ consistent localization interface based on GNU
+ <application>gettext</application> multi-lingual message
+ production tool set and <command>xml2po</command> command.
+ </para>
+
+</sect1>
diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook
new file mode 100644
index 0000000..1718f28
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Worklines/manuals.docbook
@@ -0,0 +1,20 @@
+<sect1 id="intro-worklines-manuals">
+
+ <title>Documentation</title>
+
+ <para>
+ The third step in the production cycle is to document &TCAR;,
+ what it is and how to use it. This step provides the
+ conceptual ideas used as base to edificate &TCPCVI; and is
+ implemented through &TCARUG;.
+ </para>
+
+ <para>
+ To write documentation, documentors use the
+ <function>help</function> functionality of
+ <command>centos-art.sh</command> script which provide an
+ consistent interface for building documentation through
+ different documentation backends (e.g., Texinfo and DocBook).
+ </para>
+
+</sect1>
diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/relbdirs.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/relbdirs.docbook
new file mode 100644
index 0000000..22bf7f8
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Worklines/relbdirs.docbook
@@ -0,0 +1,128 @@
+<sect1 id="intro-worklines-relbdirs">
+
+ <title>Relation Between Directories</title>
+
+ <para>
+ In order for automation scripts to produce content inside a
+ working copy of &TCAR;, it is required that all work lines be
+ related somehow. The relation between work lines is used by
+ automation scripts to know where to retrive the information
+ they need to work with (e.g., input files, translation
+ messages, output locations, etc.). This kind of relation is
+ built using two path constructions known as <emphasis>master
+ paths</emphasis> and <emphasis>auxiliar paths</emphasis>.
+ </para>
+
+ <variablelist>
+ <varlistentry>
+ <term>Master Paths</term>
+ <listitem>
+ <para>
+ A master path refers to a directory inside the repository that
+ contain input files required to produce output files through
+ automation scripts. Examples of master paths inside the
+ repository include:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Identity/Models/Brands</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Manuals/Repository/Docbook</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Identity/Models/Themes/Default/Distro/5/Anaconda</filename>
+ </para>
+ </listitem>
+ </itemizedlist>
+ </para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>Auxiliar paths</term>
+ <listitem>
+ <para>
+ An auxiliar path refers a directory inside the repository
+ considered auxiliar for the master path. Auxiliar path can be
+ either for output or localization. Assuming the master path
+ provides the input information, the auxiliar paths provide the
+ auxiliar information which describes how and where that input
+ information is rendered by automation scripts. Examples of
+ auxiliar paths inside the repository include:
+
+ <itemizedlist>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Identity/Images/Brands</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Manuals/Repository/Docbook/es_ES</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Locales/Manuals/Repository/Docbook/es_ES</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Identity/Images/Themes/Flame/3/Distro/5/Anaconda/es_ES</filename>
+ </para>
+ </listitem>
+ <listitem>
+ <para>
+ <filename class="directory">trunk/Locales/Identity/Models/Default/Distro/5/Anaconda/es_ES</filename>
+ </para>
+ </listitem>
+ </itemizedlist>
+
+ </para>
+ </listitem>
+ </varlistentry>
+ </variablelist>
+
+ <para>
+ The relationship between master and auxiliar paths is built by
+ combining the second directory level of master paths with
+ directories in the second directory level of repository
+ layout. In the second directory level of repository layout,
+ the <filename class="directory">Identity</filename>, <filename
+ class="directory">Manuals</filename> and <filename
+ class="directory">Scripts</filename> directories are always
+ used to create the master paths and the output auxiliar paths.
+ The <filename class="directory">Locales</filename> directory,
+ on the other hand, is always used to create localization
+ auxiliar paths for all the master paths available under
+ <filename class="directory">Identity</filename>, <filename
+ class="directory">Manuals</filename> and <filename
+ class="directory">Scripts directories</filename>.
+ </para>
+
+ <para>
+ For example, if the <envar>LANG</envar> environment variable
+ is set to <literal>es_ES.UTF-8</literal> and you execute the
+ <function>render</function> functionality of
+ <command>centos-art.sh</command> script with the <filename
+ class="directory">trunk/Manuals/Repository/Docbook</filename>
+ master path as argument, it will produce &TCARUG; in Spanish
+ language using translation messages from <filename
+ class="directory">trunk/Locales/Manuals/Repository/Docbook/es_ES</filename>
+ auxiliar path and saving output files inside <filename
+ class="directory">trunk/Manuals/Repository/Docbook/es_ES</filename>
+ auxiliar path.
+ </para>
+
+ <para>
+ To better understand what each directory inside the repository
+ means, read <xref linkend="intro-repoconvs-layout" />.
+ </para>
+
+</sect1>
diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook
new file mode 100644
index 0000000..0ceaa6b
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Worklines/scripts.docbook
@@ -0,0 +1,24 @@
+<sect1 id="intro-worklines-scripts">
+
+ <title>Automation</title>
+
+ <para>
+ The fourth step in the production cycle is to automate
+ frequent tasks inside &TCAR;. This step closes the production
+ cycle and provides the production standards needed by all
+ different work lines to coexist together. Here is where
+ the <command>centos-art.sh</command> script and all
+ its functionalities (e.g., <function>render</function> for
+ rendition, <function>help</function> for documentation,
+ <function>locale</function> for localization, etc.) are
+ developed.
+ </para>
+
+ <para>
+ At this point it should be obvious, but we consider worth to
+ remember that: there is no need to type several tasks, time
+ after time, if they can be programmed into just one executable
+ script.
+ </para>
+
+</sect1>
diff --git a/Manuals/Repository/Docbook/Introduction/Worklines/syncpaths.docbook b/Manuals/Repository/Docbook/Introduction/Worklines/syncpaths.docbook
new file mode 100644
index 0000000..a6e8219
--- /dev/null
+++ b/Manuals/Repository/Docbook/Introduction/Worklines/syncpaths.docbook
@@ -0,0 +1,96 @@
+<sect1 id="intro-worklines-syncpaths">
+
+ <title>Path Syncronization</title>
+
+ <para>
+ Once both master and auxiliar paths have been related in the
+ repository, they shouldn't be changed except you absolutly
+ need to do so. In this cases, when you need to change master
+ or auxiliar paths, it is required that you also change the
+ relation between them so as to retain their bond. This
+ process of keeping master and auxiliar paths
+ <quote>connected</quote> between themselves is known as
+ <emphasis>path syncronization</emphasis>.
+ </para>
+
+ <para>
+ Path syncronization is required for automation scripts to know
+ where to store final output, where to retrive translation
+ messages from, and whatever information you might need to
+ count with. If the relation between master paths and auxiliar
+ paths is lost, there is no way for automation scripts to know
+ where to retrive the information they need to work with or
+ where to store the output information produced from it. Path
+ syncronization is the way we use through to organize and
+ extend the information stored in the repository.
+ </para>
+
+ <para>
+ Path syncronization involves both movement of files and
+ replacement of content inside files. Movement of files is
+ related to actions like renaming files and directories inside
+ the repository. Replacement of content inside files is
+ related to actions like replacing information (e.g., paths
+ information) inside files in order to keep file contents and
+ file locations consistent one another after a file movement.
+ </para>
+
+ <para>
+ The order followed to syncronize path information is very
+ important because the versioned nature of the files we are
+ working with. When a renaming action needs to be performed
+ inside the repository, we avoid making replacements inside
+ files first and file movements later. This would demand two
+ commit actions: one for the files' internal changes and
+ another for the file movement itself. Otherwise, we prefer to
+ perform file movements first and files' internal replacements
+ later. This way it is possible to commit both changes as if
+ they were just one.
+ </para>
+
+ <note>
+ <para>
+ There is no support for URLs actions inside
+ <command>centos-art.sh</command> script. The
+ <command>centos-art.sh</command> script is designed to work
+ with local files inside the working copy only. If you need to
+ perform URL actions directly, use Subversion's commands
+ instead.
+ </para>
+ </note>
+
+ <para>
+ At this moment there is no full implementation of path
+ syncronization process inside <command>centos-art.sh</command>
+ script and it is somthing we need to do oursleves. However,
+ the <quote>texinfo</quote> backend of <code>help</code>
+ functionality which provides a restricted implementation of
+ path syncronization to this specific area of documentation
+ through the <option>--copy</option>, <option>--delete</option>
+ and <option>--rename</option> options you can take as
+ reference to implement it in other areas.
+ </para>
+
+ <para>
+ The plan for a full implementation of path syncronization
+ would be to create individual restricted implementations like
+ the one in <quote>texinfo</quote> backend for other areas that
+ demand it and then, create a higher implmentation that
+ combines them all as needed. This way, if we try to rename a
+ repository directory the higher action will define which are
+ all the restricted actions that should be performed in order
+ to make the full path syncronization.
+ </para>
+
+ <para>
+ For example, if the directory we are renaming is a master
+ path, it is required to syncronize the related output and
+ localization auxiliar paths. On the other hand, if the
+ directory we are renaming through full path syncronization is
+ an auxiliar path, it is required to determine first what is
+ the related master path and later, perform the syncronization
+ from master path to auxiliar paths as if the path provided
+ would be the master path not the auxiliar path.
+ </para>
+
+</sect1>