msgid "" msgstr "" "Project-Id-Version: centos-art-0.4\n" "POT-Creation-Date: 2013-06-10 16:05-0400\n" "PO-Revision-Date: 2013-06-10 16:05-0400\n" "Last-Translator: Documentation SIG\n" "Language-Team: Español\n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=UTF-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=2; plural=(n != 1);\n" #. When image changes, this message will be marked fuzzy or untranslated for you. #. It doesn't matter what you translate it to: it's not used at all. msgid "" "@@image: 'Images/Manuals/Corporate/monolithic.png'; md5=THIS FILE " "DOESN'T EXIST" msgstr "" #. Front matter msgid "The CentOS Artwork Repository" msgstr "" msgid "User's Guide" msgstr "" msgid "Alain" msgstr "" msgid "Reguera Delgado" msgstr "" msgid "2009" msgstr "" msgid "2010" msgstr "" msgid "2011" msgstr "" msgid "2012" msgstr "" msgid "2013" msgstr "" msgid "" "The CentOS " "Project. All rights reserved." msgstr "" msgid "" "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 ." msgstr "" msgid "1.0" msgstr "" msgid "Today" msgstr "" msgid "Under development." msgstr "" msgid "Preface" msgstr "" msgid "Overview" msgstr "" msgid "" "Welcome to The CentOS Artwork Repository User's Guide, the official documentation of The CentOS Artwork " "Repository." msgstr "" msgid "" "This book describes the corporate visual identity of The CentOS Project " "and the way it is produced. If you are interested in making The CentOS Project a more beautiful project, this book is definitly for you." msgstr "" msgid "" "To make the information in this book managable, it has been " "organized in the following parts:" msgstr "" msgid "" " describes the convenctions you should " "follow to keep everything organized and consistent inside the " "repository directory structure, how to to install and configure a " "working copy inside your workstation. At the end of this part you " "will find a history of most relevant changes committed to the " "repository along the years." msgstr "" msgid "" " describes the corporate visual " "identity of the organization known as The CentOS Project and the " "production tasks related to image rendition inside The " "CentOS Artwork Repository. If you are a graphic designer, " "this part of the book might result interesting to you." msgstr "" msgid "" " describes production tasks related to " "content internationalization and localization inside The " "CentOS Artwork Repository. If you are a translator, this " "part of the book might result interesting to you." msgstr "" msgid "" " describes production tasks related to " "content documentation inside The CentOS Artwork Repository. If you are a documentor, this part of the book might result " "interesting to you." msgstr "" msgid "" " describes automation of production " "tasks inside The CentOS Artwork Repository. If you are " "a programmer, this part of the book might result interesting to you." msgstr "" msgid "" " organizes the licenses mentioned in " "this book." msgstr "" msgid "" "This book assumes you have a basic understanding of The CentOS " "Distribution. If you need help with it, go to the Help page inside The CentOS Wiki for or a list of different places you can find help." msgstr "" msgid "Document Convenctions" msgstr "" msgid "" "In this manual, certain words are represented in different fonts, " "typefaces, sizes, and weights. This highlighting is systematic; " "different words are represented in the same style to indicate their " "inclusion in a specific category. The types of words that are " "represented this way include the following:" msgstr "" msgid "command" msgstr "" msgid "" "Linux commands (and other operating system commands, when used) are " "represented this way. This style should indicate to you that you " "can type the word or phrase on the command line and press " "Enter to invoke a command. Sometimes a command " "contains words that would be displayed in a different style on " "their own (such as file names). In these cases, they are considered " "to be part of the command, so the entire phrase is displayed as a " "command. For example:" msgstr "" msgid "" "Use the centos-art render Identity/Images/Themes/" "TreeFlower/4/Distro/5/Anaconda --filter=\"01-welcome\" " "command to produce the first slide image used by Anaconda in the " "branch 5 of The CentOS Distribution using the version 4 of " "TreeFlower artistic motif." msgstr "" msgid "file name" msgstr "" msgid "" "File names, directory names, paths, and RPM package names are " "represented this way. This style indicates that a particular file " "or directory exists with that name on your system. Examples:" msgstr "" msgid "" "The init.sh file in Scripts/Bash/Cli/ directory is the initialization " "script, written in Bash, used to automate most of tasks in the " "repository." msgstr "" msgid "" "The centos-art command uses the " "ImageMagick RPM package to convert images from " "PNG format to other formats." msgstr "" msgid "key" msgstr "" msgid "A key on the keyboard is shown in this style. For example:" msgstr "" msgid "" "To use Tab completion to list particular files in " "a directory, type ls, then a character, and " "finally the Tab key. Your terminal displays the " "list of files in the working directory that begin with that " "character." msgstr "" msgid "combination" msgstr "" msgid "" "A combination of keystrokes is represented in this way. For example:" msgstr "" msgid "" "The CtrlAltBackspace key combination exits " "your graphical session and returns you to the graphical login " "screen or the console." msgstr "" #, no-wrap msgid "computer output" msgstr "" msgid "" "Text in this style indicates text displayed to a shell prompt such " "as error messages and responses to commands. For example, the " "ls command displays the contents of a directory " "using this style:" msgstr "" #, no-wrap msgid "" "\n" "render_doTranslation.sh render_getDirTemplate.sh render_doBaseActions.sh\n" "render_getConfigOption.sh render_getOptions.sh render_doThemeActions.sh \n" "render_getDirOutput.sh render.sh\n" msgstr "" msgid "" "The output returned in response to the command (in this case, the " "contents of the directory) is shown in this style." msgstr "" msgid "prompt" msgstr "" msgid "" "A prompt, which is a computer's way of signifying that it is ready " "for you to input something, is shown in this style. Examples:" msgstr "" msgid "$" msgstr "" msgid "#" msgstr "" msgid "[centos@projects centos]$" msgstr "" msgid "projects login:" msgstr "" #, no-wrap msgid "user input" msgstr "" msgid "" "Text that the user types, either on the command line or into a text " "box on a GUI screen, is displayed in this style. In the following " "example, text is displayed in this style: To " "boot your system into the text based installation program, you must " "type in the text command at the boot:" " prompt." msgstr "" msgid "replaceable" msgstr "" msgid "" "Text used in examples that is meant to be replaced with data " "provided by the user is displayed in this style. In the following " "example, version-number is displayed in " "this style: The directory for the kernel source is /usr/src/kernels/version-number/, where version-number is the version and type of kernel installed on this " "system." msgstr "" msgid "" "Additionally, we use several different strategies to draw your " "attention to certain pieces of information. In order of urgency, " "these items are marked as a note, tip, important, caution, or " "warning. For example:" msgstr "" msgid "" "Remember that Linux is case sensitive. In other words, a rose is " "not a ROSE is not a rOsE." msgstr "" msgid "" "The directory /usr/share/doc/ contains additional documentation for packages installed " "on your system." msgstr "" msgid "" "If you modify the DHCP configuration file, the changes do not take " "effect until you restart the DHCP daemon." msgstr "" msgid "" "Do not perform routine tasks as root — use a regular user account " "unless you need to use the root account for system administration " "tasks." msgstr "" msgid "" "Be careful to remove only the necessary partitions. Removing other " "partitions could result in data loss or a corrupted system " "environment." msgstr "" msgid "Send In Your Feedback" msgstr "" msgid "" "If you find a bug in The CentOS Artwork Repository or " "this manual, we would like to hear about it. To report bugs related " "to this manual, send an e-mail to the centos-devel@centos." "org mailing list. When you write the bug report, take care " "of being specific about the problem you are reporting on (e.g., " "where it is, the section number, etc.) so we can found it easily." msgstr "" msgid "Repository" msgstr "" msgid "Repository Conventions" msgstr "" msgid "Repository Mission" msgstr "" msgid "" "The CentOS Artwork Repository exists to produce The CentOS Project corporate visual identity." msgstr "" msgid "Repository Layout" msgstr "" msgid "" "The CentOS Artwork Repository is made of one " "central repository and many working copies of that central repository. The working copies are " "independent one another, can be distributed all around the world " "and provide a local place for designers, documenters, translators " "and programmers to perform their work in a decentralized way. The " "central repository, on the other hand, provides a common place for " "all independent working copies to interchange data in the community." msgstr "" msgid "" "The current infrastructure that holds The CentOS Artwork " "Repository is supported by Subversion, a version control system which " "allows you to keep old versions of files and directories (usually " "source code), keep a log of who, when, and why changes occurred, " "etc., like CVS, RCS or SCCS and Trac, a web-based software project management and " "bug/issue tracking system emphasizing ease of use and low ceremony." msgstr "" msgid "" "In addition to current Subversion infrastructure, we are working on " "a Git infrastructure with the intention of migrating the central " "repository to it, progressively. Here we use Gitolite to manage Git " "repositories, Gitweb to make changes browsable through the web and " "Mantis to track repository issues. The main reason for this " "migration is to take advantage of distributed version control " "system inside The CentOS Artwork Repository. It also " "let people to commit changes locally, without any network access, " "and later push local commits up to central repository, when the " "network access be re-established. This could be very useful in very " "different kind of situations." msgstr "" msgid "Subversion" msgstr "" msgid "" "In this layout, the first level of directories inside The " "CentOS Artwork Repository provides the Subversion's " "standard trunk-branches-tags layout. The second level of " "directories provides organization for different work lines, as " "described in . All other " "subsequent directory levels from second level on exist to organize " "specific concepts related to the work line they belong to." msgstr "" msgid "Git" msgstr "" msgid "" "In this layout, the first level of directories provides " "organization for different work lines, as described in . All other subsequent directory " "levels from second level on exist to organize specific concepts " "related to the work line they belong to." msgstr "" msgid "Repository Work Lines" msgstr "" msgid "" "The content production inside The CentOS Artwork Repository has been divided into individual work lines that relate one " "another based on the idea of doing one thing well. In this model, " "the content produced individually by each work line is combined one " "another later to achieve higher purposes (e.g., corporate identity " "for The CentOS " "Project). The repository work lines, as conceived here, " "provide a relaible environment for people to work syncronized and " "descentralized." msgstr "" msgid "" "The action of combining work lines inside The CentOS Artwork " "Repository is known as the corporate identity production " "cycle. The rest of this section describes the work lines available " "in the repository and how they fit inside the corporate identity " "production cycle." msgstr "" msgid "Visual Identity" msgstr "" msgid "" "The visual identity is the first component we work out in order to " "produce a new corporate identity. Through this work line, graphic " "designers create models and motifs " "for all the visual manifestation The CentOS Project is made of. Once design " "models and artistic motifs are set in place, graphic designers use " "the render functionality described in to combine both design models and " "artistic motifs into final images." msgstr "" msgid "" "The main purposes of this work line is define all the visual " "manifestations the The CentOS Project is made of and provide design models " "and artistic motifs for them in order to render the set of images " "required to transmit the visual style that identifies The CentOS Project " "as unique organization. To know more about The CentOS Project Corporate " "Visual Identity, read ." msgstr "" msgid "" "The visual identity work line takes palce in the Identity directory." msgstr "" msgid "Localization" msgstr "" msgid "" "The content localization is the second component that must be " "worked out in the corporate identity production cycle. Through this " "work line translators localize source files (e.g., SVG, DocBook, " "Shell scripts) which are later use to produce localized images, " "localized documentation and localized automation scripts. To " "localize source files, translators use the locale functionality described in which takes care of retriving translatable strings from " "source files and provide a consistent localization interface based " "on GNU gettext multi-lingual message " "production tool set and xml2po command." msgstr "" msgid "" "The main purpose of this work line is extend the visual identity " "(produced in English language) to as many native languages as " "possible in order for people which doesn't understand English " "languague to feel more confortable with The CentOS Project and its " "messages. To know more about the specific localization process read " "." msgstr "" msgid "" "The localization work line takes palce in the Locales directory." msgstr "" msgid "Documentation" msgstr "" msgid "" "The documentation work line is the third component that must be " "worked out in the corporate identity production cycle. Through this " "work line documentors settle down the conceptual and practical used " "to edificate The CentOS Artwork Repository. To write " "documentation, documentors use the help " "functionality described in " "which provides a consistent interface for building documentation " "through different documentation backends (e.g., Texinfo, DocBook, " "LaTeX, etc.)." msgstr "" msgid "" "The main purpose of this work line is describe the standard " "procedures The CentOS Artwork Repository realies on, as " "well as conceive a place to help you understand what The " "CentOS Artwork Repository is and what can you do with it." msgstr "" msgid "" "The documentation work line takes palce in the Manuals directory." msgstr "" msgid "Packaging" msgstr "" msgid "" "The packaging work line is the fourth component that must be worked " "out in the corporate identity production cycle. Through this work " "line packager gather final images, final translations and final " "documentation related to art works and put all together inside RPM " "packages. For this purpose, packagers use the pack describe in which " "provides a consistent interface for building packages inside the " "repository." msgstr "" msgid "" "The main purpose of this work line is pack all the information " "The CentOS " "Project requires to rebrand The CentOS Distribution " "according Red Hat redistribution guidelines." msgstr "" msgid "" "The packaging work line takes palce in the Packages directory." msgstr "" msgid "Automation" msgstr "" msgid "" "The automation work line is the fifth and last component that must " "be worked out in the corporate identity production cycle. This work " "line closes the production cycle and provides the production " "standards graphic designers, documentors, translators and packagers " "need to make their work consistent and reusable. For this purpose, " "programmers develop the centos-art.sh script " "described in ." msgstr "" msgid "" "The main purpose of this work line is standardize the interaction " "of work lines in a reliable way." msgstr "" msgid "" "The automation work line takes palce in the Scripts directory." msgstr "" msgid "Repository File Names" msgstr "" msgid "Regular Files" msgstr "" msgid "" "Inside The CentOS Artwork Repository, file names are " "always written in lowercase. Digits (e.g., 0, 1, 2), hyphen (

-"
"

), dot (.) and low line (_) " "characters are also accepted. In case you use hyphen and dot " "characters, don't use them as first character in the file name." msgstr "" msgid "Files Written Correctly" msgstr "" msgid "The following file names are written correctly:" msgstr "" msgid "01-welcome.png" msgstr "" msgid "splash.png" msgstr "" msgid "anaconda_header.png" msgstr "" msgid "Files Written Incorrectly" msgstr "" msgid "The following file names are written incorrectly:" msgstr "" msgid "01-Welcome.png" msgstr "" msgid "-welcome.png" msgstr "" msgid "Splash.png" msgstr "" msgid "AnacondaHeader.png" msgstr "" msgid "Exceptions" msgstr "" msgid "When you name files, consider the following exceptions:" msgstr "" msgid "" "In the very specific case of repository documentation entries " "written in Texinfo format, file names follow the directory " "structure naming convenction. This is because they are documenting " "directories and that is something we want to remark. So, to better " "describe what we are documenting, files related to documentation " "entries follow the name convenction used by the item they document." msgstr "" msgid "Symbolic Links" msgstr "" msgid "" "Inside The CentOS Artwork Repository, symbolic link " "names follow the same convenctions described in ." msgstr "" msgid "Directories" msgstr "" msgid "" "Inside The CentOS Artwork Repository, directory names " "are all written capitalized and sometimes in cammel case. Digits (e." "g., 0, 1, 2), hyphen (-), dot (.) and low " "line (_) characters are also accepted. In case you use " "hyphen and dot characters, don't use them as first character in the " "directory name." msgstr "" msgid "Directories Written Correctly" msgstr "" msgid "The following directory names are written correctly:" msgstr "" msgid "" "Identity, Themes, Motifs, TreeFlower" msgstr "" msgid "Tcar-ug" msgstr "" msgid "" "0.0.1, 0.0.1-35" msgstr "" msgid "Directories Written Incorrectly" msgstr "" msgid "The following directory names are written incorrectly:" msgstr "" msgid "" "identitY, theMes, MOTIFS, treeFlower" msgstr "" msgid "tcar-ug" msgstr "" msgid "" ".0.1, .0.1-35" msgstr "" msgid "When you name directories, consider the following exceptions:" msgstr "" msgid "No one so far." msgstr "" msgid "Repository Path Relations" msgstr "" msgid "" "In order for automation scripts to produce content inside a working " "copy of The CentOS Artwork Repository, it is required " "that all work lines be related somehow. The automation scripts take " "the relation between work lines as reference to determine the place " "the information they will work with will be retrieve from (e.g., " "scalable vector graphics, documentation, translations, etc.), as " "well as the place where it will store the final files produced as " "result of automation process (e.g., portable network graphics, " "documentation ready for printing and reading online, etc.)." msgstr "" msgid "" "In order to implement the relation between work lines it is " "required to establish a path name convenction, so we can " "conceptually organize different components and relate them one " "another using predictable path constructions in a scalable way. " "Based on this need, we identify three different path types inside " "The CentOS Artwork Repository. These path types are: " "Output Paths, Input Paths, and Auxiliary Paths." msgstr "" msgid "Output Paths" msgstr "" msgid "" "The output paths point to directories inside the working copy which " "contain files produced from files inside the input paths. For " "example, the following paths are consider as output paths:" msgstr "" msgid "Identity/Images/Brands/" msgstr "" msgid "Documentation/Manuals/Tcar-ug/" msgstr "" msgid "Identity/Images/Themes/Modern/2/Distro/5/Anaconda/" msgstr "" msgid "" "Output paths are also known as Render-able " "Directories because they are the type of path " "you should provide as argument to functionality so as to produce content through it." msgstr "" msgid "Input Paths" msgstr "" msgid "" "The input paths point to a directories inside the working copy " "which contain files used to produce files inside output paths. For " "example, the following paths are considered as input paths:" msgstr "" msgid "Identity/Models/Brands/" msgstr "" msgid "Documentation/Models/Tcar-ug/" msgstr "" msgid "Identity/Models/Themes/Default/Distro/5/Anaconda/" msgstr "" msgid "Auxiliary Paths" msgstr "" msgid "" "The auxiliary paths point to directories inside the working copy " "which contain files used to create modified instances of inside " "input paths which are use in turn to produce files inside output " "paths. For example, the following paths are considered as auxiliary " "paths:" msgstr "" msgid "Locales/Documentation/Models/Docbook/Tcar-ug/es_ES/" msgstr "" msgid "" "Locales/Identity/Models/Themes/Default/Distro/5/Anaconda/es_ES/" msgstr "" msgid "" "The relationship between input, output and auxiliary paths is " "created by combining the first directory level of input paths with " "the first directory level in the repository directory layout. In " "the repository directory layout, the first level includes the " "Identity, Documentation and Scripts directories. These directories are " "always used to create input and output paths. The Locales directory, on the other hand, is " "always used to create auxiliary paths only for input paths " "available under Identity, " "Documentation and " "Scripts directories." msgstr "" msgid "" "For example, if the LANG environment variable is " "set to es_ES.UTF-8 and you execute the functionality of centos-art.sh script with the Documentation/Manuals/Docbook/Tcar-ug/ input path as " "argument, it will produce The CentOS Artwork Repository " "User's Guide in Spanish language using translation " "messages from Locales/Documentation/Models/Docbook/Tcar-" "ug/es_ES/ auxiliary path and would save final " "documentation files under Documentation/Manuals/Docbook/Tcar-ug/es_ES/ output " "path." msgstr "" msgid "Syncronizing Repository Paths" msgstr "" msgid "" "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 connected between themselves is known " "as path syncronization." msgstr "" msgid "" "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. Through path syncronization we " "organize and extend the content production inside the repository." msgstr "" msgid "" "Path syncronization affects 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 has been moved." msgstr "" msgid "" "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. Instead, " "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." msgstr "" msgid "" "There is no support for URLs actions inside centos-art.sh script. The centos-art.sh 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." msgstr "" msgid "" "At this moment there isn't full implementation of path " "syncronization inside centos-art.sh script and " "that is somthing we need to do oursleves. However, the " "texinfo backend inside the help " "functionality does provide a restricted implementation of path " "syncronization to documentation area through the and " "options. You can read this implementation and use it as reference " "to implement path syncronization in other areas." msgstr "" msgid "" "The plan for a full implementation of path syncronization inside " "centos-art.sh script would be to create " "individual restricted implementations like the one in " "texinfo 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 can know which are all the restricted actions that " "should be performed in order to make the full path syncronization." msgstr "" msgid "" "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." msgstr "" msgid "Extending Repository Layout" msgstr "" msgid "" "Occasionly, you may find that new components of The CentOS Project " "Corporate Visual Identity 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: What is the right place to store it?" "" msgstr "" msgid "" "To build a directory structure inside the repository you need to " "define the concept behind it first. Later you need to create a new " "directory inside the repository, remembering that there are " "locations inside the repository that already define concepts you " "probably would prefer to reuse. For example, the Identity/Images/Themes directory stores " "artistic motifs of different themes, the Identity/Models/Themes directory stores design models " "for themes, the Manuals " "directory stores documentation, the Locales stores translation messages, and the " "Scripts stores automation " "scripts." msgstr "" msgid "" "The best suggestion we can probably give you would be to send a " "mail with your questions to the CentOS developers mailing list (centos-devel@centos.org). This is the place where development of The CentOS " "Artwork Repository takes place and surely, in community, it " "will be possible to find a place for your new component inside the " "repository." msgstr "" msgid "Repository Publishing" msgstr "" msgid "" "When you perform changes inside your working copy, those changes " "are local to your working copy only. In order for you to share your " "changes with others, you need to commit them up to the central " "repository the working copy you are using was initially downloaded " "from. To commit your changes up to the central repository you use " "the commit command from the Subversion's client " "you've installed in your workstation." msgstr "" msgid "" "Initially, when you get registered inside The CentOS Artwork " "Repository, you won't be able to publish your changes to " "The CentOS Artwork Repository immediatly. It is " "necessary that you prove your interest in contributing first " "sending a mail to the CentOS Developers mailing list " "(centos-devel@centos." "org), preferably in conjunction with a description of the " "changes you pretend to commit. This restriction is necessary in " "order to protect the source repository from spammers." msgstr "" msgid "" "Once you've received access to publish your changes, they will " "remain valid to you and there is no need for you to request " "permission to publish new changes as long as you behave as a good " "cooperating citizen." msgstr "" msgid "" "As a good cooperating citizen one understand of a person who " "respects the work already done by others and share ideas with " "authors before changing relevant parts of their work, specially in " "situations when the access required to realize the changes has been " "granted already. Of course, there is a time when conversation has " "taken place, the paths has been traced and changing the work is so " "obvious that there is no need for you to talk about it; that's " "because you already did, you already built the trust to keep going. " "As complement, the mailing list mentioned above is available for " "sharing ideas in a way that good relationship between community " "citizens could be constantly balanced." msgstr "" msgid "" "The relationship between community citizens is monitored by " "repository administrators. Repository administrators are " "responsible of granting that everything goes the way it needs to go " "in order for The CentOS Artwork Repository to " "accomplish its mission (see )." msgstr "" msgid "Repository Authoring" msgstr "" msgid "" "The content produced inside The CentOS Artwork Repository is copyright of The CentOS Project. This is something you, as author, " "should be aware of because you are contributing your creation's " "rights to someone else; The CentOS Project in this case. This way, " "your work is distributed using The CentOS Project as " "copyright holder, not your name (even you remain as natural author " "of the work). Because The CentOS Project is the copyright holder, is the " "license chosen by The CentOS Project the one applied to your work, so it " "is the one you need to agree with before making a creation inside " "The CentOS Artwork Repository." msgstr "" msgid "" "The CentOS " "Project is a community project controlled by its own " "community of users. Inside the community, The CentOS Administrators " "group is the higher authority and the only one able to set core " "desition like the kind of license used inside the project and " "subprojects like The CentOS Artwork Repository." msgstr "" msgid "" "The redistribution conditions of The CentOS Artwork " "Repository are described in ." msgstr "" msgid "Repository Copying Conditions" msgstr "" msgid "" "The CentOS " "Project uses The CentOS Artwork Repository to " "produce The " "CentOS Project corporate visual identity." msgstr "" msgid "" "The The CentOS Artwork Repository is not in the " "public domain; it is copyrighted and there are restrictions on " "their distribution, but these restrictions are designed to permit " "everything that a good cooperating citizen would want to do. What " "is not allowed is to try to prevent others from further sharing any " "version of this work that they might get from you." msgstr "" msgid "" "Specifically, we want to make sure that you have the right to give " "away copies of The CentOS Artwork Repository, that you " "receive source code or else can get it if you want it, that you can " "change this work or use pieces of it in new free works, and that " "you know you can do these things." msgstr "" msgid "" "To make sure that everyone has such rights, we have to forbid you " "to deprive anyone else of these rights. For example, if you " "distribute copies of the The CentOS Artwork Repository, you must give the recipients all the rights that you have. " "You must make sure that they, too, receive or can get the source " "code. And you must tell them their rights." msgstr "" msgid "" "Also, for our own protection, we must make certain that everyone " "finds out that there is no warranty for the The CentOS Artwork " "Repository. If this work is modified by someone else and " "passed on, we want their recipients to know that what they have is " "not what we distributed, so that any problems introduced by others " "will not reflect on our reputation." msgstr "" msgid "" "The The CentOS Artwork Repository is released as a " "GPL work. Individual packages used by The CentOS Artwork " "Repository include their own licenses and the The " "CentOS Artwork Repository license applies to all packages " "that it does not clash with. If there is a clash between the The " "CentOS Artwork Repository license and individual package " "licenses, the individual package license applies instead." msgstr "" msgid "" "The precise conditions of the license for the The CentOS Artwork " "Repository are found in . " "This manual specifically is covered by the conditions found in " "." msgstr "" msgid "Preparing Your Workstation" msgstr "" msgid "Introduction" msgstr "" msgid "" "The workstation is the machine you use to store your working copy " "of The CentOS Artwork Repository. The working copy " "is an ordinary directory tree on your workstation, containing a " "collection of files that you can edit however you wish. The working " "copy is your own private work area related to The CentOS Artwork " "Repository where you perform changes and receive changes " "from others." msgstr "" msgid "" "In order to make your workstation completely functional, it is " "necessary that you install it and configure it to satisfy the needs " "demanded by the working copy of The CentOS Artwork Repository you later download in it." msgstr "" msgid "" "This chapter describes the steps you need to follow in order to " "install and configure a workstation for using a working copy of " "The CentOS Artwork Repository in all its extention." msgstr "" msgid "Installing Your Workstation" msgstr "" msgid "" "To install your workstation use The CentOS Distribution default " "configuration as proposed by The CentOS Distribution installer. " "This includes default partitioning and packages. The CentOS " "Artwork Repository is been completly develop upon The " "CentOS Distribution and realies on such environment to achieve most " "automation tasks. In order to get a reproducable environment, it is " "convenient that you, too, use the same operating system that we do." msgstr "" msgid "Supported Platforms" msgstr "" msgid "" "The CentOS Artwork Repository has been tested in the " "following platforms:" msgstr "" msgid "" "The CentOS Distribution major release 5 update 5, for i386 and i686 " "architectures." msgstr "" msgid "" "In case you be using a working copy of The CentOS Artwork " "Repository in a different platform from those listed here, " "please send a mail to centos-devel@centos.org notifying it. It is our " "intention to make The CentOS Artwork Repository as " "portable as possible through different major releases of The CentOS " "Distribution." msgstr "" msgid "Configuring Your Workstation" msgstr "" msgid "" "Once your workstation has been installed, it is time for you to " "configure it. The configuration of your workstation consists on " "defining your workplace, download a working copy from The " "CentOS Artwork Repository and finally, run the " "prepare functionality of centos-art." "sh script to install/update the software needed, render " "images, create links, and anything else needed." msgstr "" msgid "Define Your Workplace" msgstr "" msgid "" "Once you've installed the workstation and it is up and running, you " "need to register the user name you'll use for working. In this task " "you need to use the commands useradd and " "passwd to create the user name and set a " "password for it, respectively. These commands require " "administrative privileges to be executed, so you need to login as " "root superuser for doing so." msgstr "" msgid "" "Do not use the root username for regular tasks " "inside your working copy of The CentOS Artwork Repository. This is dangerous and might provoke unreversable damages to " "your workstation." msgstr "" msgid "" "When you've registered your user name in the workstation, it " "provides an identifier for you to open a user's session in the " "workstation and a place to store the information you produce, as " "well. This place is known as your home directory and is unique for " "each user registered in the workstation. For example, if you " "register the user name john in your workstation, your home " "directory would be located at /home/" "john/." msgstr "" msgid "" "At this point it is important to define where to download the " "working copy of The CentOS Artwork Repository inside your " "home directory. This desition deserves special attention and should " "be implemented carefully in order to grant a standard environment " "that could be distributed. Let's see some alternatives." msgstr "" msgid "Different absolute paths" msgstr "" msgid "" "Consider that you store your working copy under /home/john/Projects/artwork/ and I store " "mine under /home/al/Projects/artwork/" ", we'll end up refering the same files inside our " "working copies through different absolute paths. This alternative " "generates a contradiction when files which hold path information " "inside are committed up to the central repository from different " "working copies. The contradiction comes from the question: which is " "the correct absolute path to use inside such files, yours or mine? " "(None of them is, of course.)" msgstr "" msgid "One unique absolute path" msgstr "" msgid "" "Another case would be that where you and I ourselves use one unique " "home directory (e.g., /home/centos/" "Projects/artwork/) to store the working copy of The " "CentOS Artwork Repository in our own workstations, but " "configure the subversion client to use different user names to " "commit changes up from the working copy to the central repository. " "This alternative might be not so good in situations where you and I " "have to share the same workstation. In such cases, it would be " "required that we both share the password information of the same " "system user (the centos user in our example) which, " "in addition, gives access to that user's subversion client " "configuration and this way provokes the whole sense of using " "different subversion credentials for committing changes to be lost." msgstr "" msgid "Different absolute paths through dynamic expansion" msgstr "" msgid "" "Most of the absolute paths we use inside the working copy are made " "of two parts, one dynamic and one relative fixed. The dynamic part " "is the home directory of the current user and its value can be " "retrived from the $HOME environment variable. The " "fixed part of the path is the one we set inside the repositroy " "structure itself as a matter of organization. What we need here is " "to find a way to expand variables inside files that don't support " "variable expansion. This alternative had worked rather fine when we " "produce produce PNG files from SVG files and XTHML from DocBook " "files, but the same is not true for absolute paths inside files " "that are used as in their permanent state inside the repository (e." "g., CSS files and other files similar in purpose)." msgstr "" msgid "" "Different absolute paths, dynamic expansion, symbolic links, " "relative links, and environment variables" msgstr "" msgid "" "With this solution it is possible to store working copies of The " "CentOS Artwork Repository on different locations inside the " "same workstation without lose relation between files. Here we use " "the TCAR_WORKDIR environment variable to set the location of the " "working copy inside the workstation. Later the centos-art.sh " "scripts uses this value as reference to determine where the working " "copy is. This value is also the one used for dynamic expansion " "inside design models and other similar files. In the case of web " "projects where different components are required to produce the " "final content, we create symbolic links between them and use " "relative paths so it is possible to reuse them and retain the " "relation between them in different contexts." msgstr "" msgid "" "For example, lets consider the organization of XHTML manuals " "rendered from DocBook source files. When you render a DocBook " "manual inside The CentOS Artwork Repository it creates " "XHTML files. This XHTML files use images and common style sheets " "for better presentation. Both of these images and styles components " "live outside the XHTML structure so, in order to make them " "available relatively to the XHTML structure, we created symbolic " "links from the XHTML structure to the outside location where they " "are in. The creation of symbolic links takes place automatically " "when each DockBook manual is rendered through centos-art." "sh, which uses the value of TCAR_WORKDIR environment " "variable as reference to determine the absolute path of the working " "copy." msgstr "" msgid "" "Bacause absolute paths are no longer stored inside permanent files " "and centos-art.sh script uses the TCAR_WORKDIR " "environment variable to determine where the working copy is stored " "in the workstation, it should be safe to download working copies of " "The CentOS Artwork Repository anywhere in the " "workstation. One just have to be sure that the value of " "TCAR_WORKDIR environment variable does match the location of the " "working copy you are using." msgstr "" msgid "Download Your Working Copy" msgstr "" msgid "" "In order to use The CentOS Artwork Repository you need to " "download a working copy from the central repository into your " "workstation. To download such working copy use the following " "command:" msgstr "" #, no-wrap msgid "git clone https://projects.centos.org/~al/artwork.git" msgstr "" msgid "" "This command will create your working copy inside your home " "directory, specifically in a directory named artwork.git. Inside this directory you " "will find all the files you need to work with inside The " "CentOS Artwork Repository. If you want to have your working " "copy in a location different to that one shown above, see ." msgstr "" msgid "" "The first time you download the working copy it contains no image " "files, nor documentation, or localized content inside it. This is " "because all the files provided in the working copy are source files " "(e.g., the files needed to produce other files) and it is up to you " "to render them in order to produce the final files (e.g., images " "and documentation) used to implement The CentOS Project Corporate " "Visual Identity." msgstr "" msgid "Configure Administrative Tasks" msgstr "" msgid "" "Most of the administrative tasks you need to perform in your " "working copy of The CentOS Artwork Repository are " "standardized inside the prepare functionality " "of centos-art.sh script. Inside centos-" "art.sh script, all administrative task are invoked " "through the sudo command. Thus, in order for the " "centos-art.sh script to perform administrative " "tasks, you need to update the sudo's " "configuration in a way that such administrative actions be allowed." msgstr "" msgid "" "At time of this writing the centos-art.sh script " "implements just one administrative task, that is package " "management. Nevertheless, in the future, other administrative tasks " "might be included as well (e.g., installing themes locally from the " "working copy for testing purposes.)." msgstr "" msgid "" "To update the sudo's configuration, execute the " "visudo command as root. Later, " "uncoment the Cmnd_Alias related to " "SOFTWARE and add a line for your username allowing " "software commands. This configuration is illustrated in ." msgstr "" msgid "The /etc/sudoers configuration file" msgstr "" msgid "/etc/sudoers configuration file" msgstr "" #, no-wrap msgid "" "\n" "## Installation and management of software\n" "Cmnd_Alias SOFTWARE = /bin/rpm, /usr/bin/up2date, /usr/bin/yum\n" "\n" "## Next comes the main part: which users can run what software on\n" "## which machines (the sudoers file can be shared between multiple\n" "## systems).\n" "## Syntax:\n" "##\n" "## user MACHINE=COMMANDS\n" "##\n" "## The COMMANDS section may have other options added to it.\n" "##\n" "## Allow root to run any commands anywhere\n" "root ALL=(ALL) ALL\n" "\n" "## Allow the centos user to run installation and management of\n" "## software anywhere.\n" "al ALL=(ALL) SOFTWARE\n" msgstr "" msgid "Run Preparation Tool" msgstr "" msgid "" "Once you've both downloaded a working copy from The CentOS " "Artwork Repository and configured the sudo's configuration file successfully, run the " "prepare functionality of centos-art." "sh script to complete the configuration process using the " "following command:" msgstr "" #, no-wrap msgid "~/artwork/Scripts/Bash/centos-art.sh prepare" msgstr "" msgid "" "To know more about the prepare functionality " "of centos-art.sh script, see ." msgstr "" msgid "Changing Your Working Copy Default Path" msgstr "" msgid "" "By default your working copy should be store in your home " "directory, specifically in the location ~/artwork. This location may not be the final " "location where you want to have your working copy in situations " "where you are working on several projects at the same time or you " "already have a define location to organize your projects inside " "your home directory. Thus, you may need to change the default " "location of your working copy to a more appropriate location." msgstr "" msgid "" "The default path to your working copy is controlled by the " "TCAR_WORKDIR environment variable. This variable is " "firstly defined in your personal profile after running the prepare " "functionality of centos-art.sh script. So, to " "change the path of your working copy correctly, do the following:" msgstr "" msgid "" "Create the parent directory you will use to store your working " "copy. For example: mkdir -p ~/Projects/CentOS" msgstr "" msgid "" "Move the currently downloaded working copy from ~/artwork to your " "new location. For example: mv ~/artwork ~/Projects/CentOS/" msgstr "" msgid "" "Update the environment variables set in ~/.bash_profile by running the centos-art.sh script " "from the new location. For example: ~/Projects/CentOS/" "artwork/Scripts/Bash/centos-art.sh prepare --set-environment" msgstr "" msgid "" "Do log out from your active user's seesion and do log in again so " "the environment changes take effect. Or just update the current " "environment information by running the following command: . " "~/.bash_profile" msgstr "" msgid "" "Update internal links by running the centos-art.sh script. For example: ${TCAR_WORKDIR}/Scripts/Bash/" "centos-art.sh prepare --links" msgstr "" msgid "Repository History" msgstr "" msgid "" "This chapter summarizes relevant changes committed to The " "CentOS Artwork Repository along the years." msgstr "" msgid "2008's" msgstr "" msgid "" "The CentOS Artwork Repository started at The CentOS Developers Mailing " "List around 2008, on a discussion about how to automate " "slide images used by Anaconda (The CentOS Distribution installer). " "In such discussion, Ralph Angenendt rose up his hand to ask —" "Do you have something to show?—." msgstr "" msgid "" "To answer the question, Alain Reguera Delgado suggested a " "bash script which combined SVG and SED files in order to produce " "PNG images in different languages —in conjunction with the " "proposition of creating a Subversion repository where translations " "and image production could be distributed inside The CentOS " "Community—." msgstr "" msgid "" "Karanbir Singh considered the idea intresting and provided the " "infrastructure necessary to support the effort. This way, The " "CentOS Artwork SIG and The CentOS Artwork Repository were officially created and made world wide available. In " "this configuration, users were able to register themselves and " "administrators were able to assign access rights to registered " "users inside The CentOS Artwork Repository, both using " "a web interface." msgstr "" msgid "" "Once The CentOS Artwork Repository was available, " "Alain Reguera Delgado uploaded the bash script used to produce the " "Anaconda slides;See Ralph Angenendt documented it very well;" "See and people started to download working copies of The " "CentOS Artwork Repository to produce slide images in their " "own languages.See the following Google search." msgstr "" msgid "" "From this time on The CentOS Artwork Repository has " "been evolving into an automated production environment where The " "CentOS Community can conceive The CentOS Project corporate visual identity." msgstr "" msgid "" "The exact changes commited to The CentOS Artwork Repository through history can be found in the repository logs " "so you can know the real history about it. For those of you who " "just want to get a glance of changes committed, see ." msgstr "" msgid "2009's" msgstr "" msgid "" "Around 2009, the rendition script was at a very rustic state where " "only slide images could be produced, so it was redesigned to extend " "the image production to other areas, different from slide images. " "In this configuration, one SVG file was used as input to produce a " "translated instance of it which, in turn, was used to produce one " "translated PNG image as output. The SVG translated instance was " "created through SED replacement commands. The translated PNG image " "was created from the SVG translated instance using Inkscape command-" "line interface." msgstr "" msgid "" "The repository directory structure was prepared to receive the " "rendition script using design templates and translation files in " "the same location. There was one directory structure for each art " "work that needed to be produced. In this configuration, if you " "would want to produce the same art work with a different visual " "style or structure, it was needed to create a new directory " "structure for it because both the image structure and the image " "visual style were together in the design template." msgstr "" msgid "" "The rendition script was moved to a common place and linked from " "different directory structures. There was no need to have the same " "code in different directory structures if it could be in just one " "place and then be linked from different locations." msgstr "" msgid "" "Corporate identity concepts began to be considered. As referece, it " "was used the book \"Corporate Identity\" by Wally Olins (1989) and " "Wikipedia " "related links. This way, the rendition script main's goal " "becomes to: automate the production process of a " "monolithic corporate visual identity structure, based on the " "mission and the release schema of The CentOS Project." msgstr "" msgid "" "The repository directory structures began to be documented by mean " "of flat text files. Later, documentation in flat text files was " "moved onto LaTeX format and this way The CentOS Artwork " "Repository User's Guide was initiated." msgstr "" msgid "2010's" msgstr "" msgid "" "Around 2010, the rendition script changed its name from " "render.sh to centos-art.sh " "and became a collection of functionalities where rendition was just " "one among others (e.g., documentation and localization)." msgstr "" msgid "" "The centos-art.sh was initially conceived to " "automate frequent tasks inside the repository based in the idea of " "Unix toolbox: to create small and specialized tools that do one " "thing well. This way, functionalities inside centos-art." "sh began to be identified and separated one another. For " "example, when images were rendered, there was no need to load " "functionalities related to documentation manual. This layout moved " "us onto common functionalities and specific " "functionalities inside centos-art.sh " "script. Common functionalities are loaded when centos-art." "sh script is initiated and are available to specific " "functionalities." msgstr "" msgid "" "Suddenly, no need was found to keep all the links spreaded around " "the repository in order to execute the centos-art.sh script from different locations. The centos-art command-line interface was used instead. The " "centos-art command-line interface is a symbolic " "link stored inside the ~/bin directory pointing to centos-art.sh " "script. As default configuration, inside The CentOS Distribution, " "the path to ~/bin is " "included in the search path for commands (see PATH " "environment variable). This way, using the centos-art command-line interface, it is possible to execute the " "centos-art.sh script from virtually anywhere " "inside the workstation, just as we frequently do with regular " "commands." msgstr "" msgid "" "Start using GNU getopt as default option parser inside the " "centos-art.sh script." msgstr "" msgid "" "The repository directory structure was updated to improve the " "implementation of corporate visual identity concepts. Specially in " "the area related to themes. Having both structure and style in the " "same file introduced content duplication when producing art works. " "Because of this reason, they were separated into two different " "directory structures: the design models and the artistic motifs " "directory structures. From this point on, the centos-art." "sh was able to produce themes as result of arbitrary " "combinations between design models (structure) and artistic motifs " "(visual styles)." msgstr "" msgid "" "In the documentation area, the documents in LaTeX format were " "migrated to Texinfo format. In this configuration, each directory " "structure in the repository has a documentation entry associated in " "a Texinfo structure which can be read, edited and administered (e." "g., renamed, deleted and copied) interactively through " "centos-art.sh script. Additionally, the " "texi2html program was used to produced customized XHTML output in " "conjunction with CSS from The CentOS Web." msgstr "" msgid "2011's" msgstr "" msgid "" "Around 2011, the centos-art.sh script was " "redesigned to start translating XML-based files (e.g., SVG and " "Docbook files) through xml2po program and shell " "scripts (e.g., Bash scripts) through GNU gettext tools. This " "configuration provided a stronger localization interface for " "graphic designers, translators and programmers. The SED replacement " "files are no longer used to handle localization." msgstr "" msgid "" "The render, help and " "locale functionalities consolidated themselves " "as the most frequent tasks performed in The CentOS Artwork " "Repository working copy. Additionally, the " "prepare and tuneup " "functionalities were also maintained as useful tasks." msgstr "" msgid "" "In the documentation area, it was introduced the transformation of " "localized DocBook XML DTD instances through the render and locale functionalities. In this " "configuration, you use locale functionality to " "localize DocBook source files to your prefered language and later, " "using the render functionality, you can " "produce the localized XTHML and PDF output as specified in a XSLT " "layer. Unfortunly, the transformation DocBook XML -> FO -> " "PDF (through PassiveTex) seems to be buggy inside CentOS 5.5, so it " "was commented inside the centos-art.sh script. " "Most documentation is now organized in DocBook format, even Texinfo " "format remains as the only format with automated production tasks." msgstr "" msgid "" "In the automation area, the centos-art.sh script " "introduced the capability of reading configuration files. The main " "goal here was moving some command-line options from functionalities " "onto a more persistent medium. Most configuration files were set to " "define the position of brands inside images and documentation " "manual specific options." msgstr "" msgid "2012's" msgstr "" msgid "" "The CentOS Artwork Repository development was eventually " "stopped at November 2011 until July 2012 when we needed to make the " "centos-art.sh script a bit more customizable " "than it presently was. For example, it was considered as a need " "that functionalities inside the centos-art.sh " "script must be not just conceived independent one another but " "reusable in different contexts as well." msgstr "" msgid "" "Make Localization Of centos-art.sh Script " "Specific To Different Contexts" msgstr "" msgid "" "The procedure used to locale messages inside the centos-" "art.sh script has to be re-designed in order to accept " "such pluggable behavior into the script. We couldn't publish unique " "centos-art.sh.po and centos-art.sh." "mo files because they may contain different information " "in different contexts. For example, if you are using the " "render and help " "functionalities you only need translation messages for them and not " "those from other functionalities that may exist in the central " "repository but you didn't download nor use into your working copy." msgstr "" msgid "" "One solution for this could be to have independent PO files for " "each functionality of centos-art.sh script which " "are combined to create the final PO and MO files that " "gettext uses to retrive translated " "strings when centos-art.sh script is running. " "For this solution to be effective, you must be selective about the " "functionalities and locales directories you download into your " "working copy. For example, if you want to use the render " "functionality and its locale messages only, you must download the " "required directories and exclude others." msgstr "" msgid "" "In case you don't want to be selective and download the whole " "repository, the creation of the centos-art.sh.po, centos-art.sh.pot and " "centos-art.sh.mo files will occur " "automatically the first time you run the prepare functionality (which require the locale functionality to be available), or later, by running the " "following command: centos-art locale Scripts/Bash --update" msgstr "" msgid "" "For more information about the prepare and " "locale functionalities, see and respectively." msgstr "" msgid "" "As shown in , both " "Commons and Locales " "functionalities will always be required directories. The " "Commons directory contains the common " "functionalities and the Locales directory " "contains the standard procedures you need to run in order to build " "the final centos-art.sh.mo file used by " "gettext to retrive translation strings " "when the centos-art.sh script is running. " "Remember that centos-art.sh.pot, " "centos-art.sh.po files aren't under version " "control and they are built by combining each funtionality message." "po file into a PO and later a MO file." msgstr "" msgid "Directory structure of a rendering-only context" msgstr "" #, no-wrap msgid "" "\n" "/home/centos/Projects/artwork/\n" "|-- Locales/\n" "| `-- Scripts/\n" "| `-- Bash/\n" "| `-- es_ES/\n" "| |-- Functions/\n" "| | |-- Commons/\n" "| | | |-- messages.po\n" "| | | `-- messages.pot\n" "| | |-- Locales/\n" "| | | |-- messages.po\n" "| | | `-- messages.pot\n" "| | `-- Render/\n" "| | |-- messages.po\n" "| | `-- messages.pot\n" "| |-- LC_MESSAGES/\n" "| | `-- centos-art.sh.mo\n" "| |-- centos-art.sh.po\n" "| `-- centos-art.sh.pot\n" "`-- Scripts/\n" " `-- Bash/\n" " |-- Functions/\n" " | |-- Commons/\n" " | |-- Locales/\n" " | `-- Render/\n" " `-- centos-art.sh\n" msgstr "" msgid "" "A practical example of using the solution described above may be " "found when you are working on the corporate identity of The CentOS Project " "and then need to start a new corporate identity project for another " "organization. You want to keep the directory structure of The " "CentOS Artwork Repository and its automation tool, the " "centos-art.sh script. Your new project requires " "you to introduce new functionalities to centos-art.sh which don't fit the needs of The CentOS Project (e.g., you " "want to introduce a report functionality to " "mesure how much connect time do you consume through your PPP " "internface.) or you just want to keep the directory structure of " "your new project as simple as possible." msgstr "" msgid "" "To go through this it is possible to mix specific parts of " "different central repositories into one single working copy. This " "is the working copy you'll use to manage your new project. In , we see how the Render, Locales and Commons directories which come from the The CentOS Artwork " "Repository has been integrated into the working copy of " "your new project." msgstr "" msgid "Mixing automation functionalities." msgstr "" #, no-wrap msgid "" "\n" "/home/al/Projects/Myapp/\n" "|-- Locales/ \n" "| `-- Scripts/\n" "| `-- Bash/ \n" "| `-- es_ES/\n" "| |-- Functions/\n" "| | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/\n" "| | | |-- messages.po\n" "| | | `-- messages.pot\n" "| | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/\n" "| | | |-- messages.po\n" "| | | `-- messages.pot\n" "| | |-- Render/ <--| from https://projects.centos.org/svn/artwork/\n" "| | | |-- messages.po\n" "| | | `-- messages.pot\n" "| | `-- Report/\n" "| | |-- messages.po\n" "| | `-- messages.pot\n" "| |-- LC_MESSAGES/\n" "| | `-- myapp.sh.mo\n" "| |-- myapp.sh.po\n" "| `-- myapp.sh.pot\n" "`-- Scripts/\n" " `-- Bash/\n" " |-- Functions/\n" " | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/\n" " | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/\n" " | |-- Render/ <--| from https://projects.centos.org/svn/artwork/\n" " | `-- Report/\n" " `-- myapp.sh\n" msgstr "" msgid "" "At this point, your working copy contains files from two different " "central repositories. One repository provides the files of your new " "organization project and the other one provides the files related " "to the render functionality from The " "CentOS Artwork Repository. In this environment, all updates " "commited to the Render, " "Locales and Commons directories at The " "CentOS Artwork Repository will be available to you too, the " "next time you update your working copy. Likewise, if you change " "something in any of these directories and commit your changes, your " "changes will be available to poeple working in The CentOS " "Artwork Repository the next time they update their working " "copies." msgstr "" msgid "" "Understanding the need of mixing different central repositories " "into a single working copy is an important step for reusing the " "functionalities that come with centos-art.sh script, but it is not " "enough if you want to customize the information produced by it. By " "default, the centos-art.sh script uses information related to " "The CentOS " "Project. You probably need to change this if you are " "producing images to a different organization than The CentOS Project. For " "example, some of the information you might need to change would be " "the copyright holder, brands, domain names, mailing lists, and so " "forth. To change this information you need to duplicate the file " "centos-art.sh and rename it to something else. " "Later, you need to edit the renamed version and change variables " "inside according your needs. In , we used the name myapp.sh instead of " "centos-art.sh so the information we set inside " "it could reflect the specific needs that motivated the creation of " "a new project without affecting those from The CentOS Project." msgstr "" msgid "" "Most of the information you need to change in your duplicated " "version of centos-art.sh file is controlled by " "a set of read-only variables. You modify these variables here and " "they will be available all along the script execution time. For " "example, you can change the value of CLI_WRKCOPY " "variable inside your duplicated version of centos-art.sh to change the absolute path you use to store your working " "copy." msgstr "" msgid "Enhance The CentOS Logo Construction" msgstr "" msgid "" "The CentOS Logo is made of two different components known as The " "CentOS Symbol and The CentOS Type. Presently (at the end of " "September), to produce these components, we create one " "SVG image for each PNG image we want to produce, " "store it in Identity/Models/Brands/" "Logos directory structure and run the command:" msgstr "" msgid "centos-art render Identity/Images/Brands/Logos" msgstr "" msgid "" "This model works and scales well in situations when there isn't a " "need to reuse final images among themselves. However, when you need " "to reuse images among themselves, a better solution is required. " "The goal here would be: don't create SVG images " "for PNG images you can build based on other PNG images." msgstr "" msgid "This might be achieved through one of the following ways:" msgstr "" msgid "" "Create a new specific functionality to achieved the goal. Needed " "because the specific " "functionality uses SVG files as reference to " "build images (i.e., one SVG image produces one " "PNG image)." msgstr "" msgid "" "Modify functionality to " "work in different modes based on file type or file extension. The " "first mode would use SVG files as reference to " "build PNG images (just as it was doing so far). The second mode " "would use a configuration file named render.conf as reference inside the design models directory you want " "to produce images for so as to build the related PNG images. In " "this second case, the configuration file specifies how final PNG " "images will be produced (e.g., by appending or overlapping them one " "another)." msgstr "" msgid "For example, consider the following command-line:" msgstr "" msgid "" "This command should evaluate which type of rendition will be done, " "based on whether the source file is a scalable vector graphic " "(SVG) or a configuration file. To make this " "decision, the centos-art.sh script looks for " "SVG files first, and configuration files later. " "When SVG files are found, the centos-" "art.sh script uses a list of SVG files " "and process them one by one excluding any related configuration " "file that could exist. On the other hand, if no SVG file is found inside the related design model directory " "structure, the centos-art.sh script will use the " "configuration file with the name render.conf " "to create images as specified inside it. When neither a " "SVG or a configuration file is found inside the " "design model directory structure, the centos-art.sh script finishes its execution without any error message. " "For example, if no SVG file is found inside " "Identity/Models/Brands/Logos/ directory and the Identity/Models/Brands/Logos/" "images.conf configuration file exists therein with the " "following content:" msgstr "" #, no-wrap msgid "" "\n" "[centos.png]\n" "models = \"Identity/Models/Brands/Symbols/centos-symbol-forlogos.svgz Identity/Models/Brands/Types/centos.svgz\"\n" "formats = \"xpm jpg\"\n" "heights = \"48 78\"\n" "fgcolor = \"000000 ffffff\"\n" "bgcolor = \"ffffff-0\"\n" "command = \"/usr/bin/convert +append\"\n" "\n" "[centos-artwork.png]\n" "models = \"Identity/Models/Brands/Symbols/centos-symbol-forlogos.svgz Identity/Models/Brands/Types/centos.svgz Identity/Models/Brands/Types/artwork.svgz\"\n" "formats = \"xpm jpg\"\n" "heights = \"48 78\"\n" "fgcolor = \"000000 ffffff\"\n" "bgcolor = \"ffffff-0\"\n" "command = \"/usr/bin/convert +append\"\n" msgstr "" msgid "" "The centos-art.sh script should produce the " "following image files:" msgstr "" #, no-wrap msgid "" "\n" "Identity/Images/Brands/Logos/000000/ffffff-0/48/centos.jpg\n" "Identity/Images/Brands/Logos/000000/ffffff-0/48/centos.png\n" "Identity/Images/Brands/Logos/000000/ffffff-0/48/centos.xpm\n" "Identity/Images/Brands/Logos/000000/ffffff-0/48/centos-artwork.png\n" "Identity/Images/Brands/Logos/000000/ffffff-0/48/centos-artwork.jpg\n" "Identity/Images/Brands/Logos/000000/ffffff-0/48/centos-artwork.xmp\n" "Identity/Images/Brands/Logos/000000/ffffff-0/78/centos.jpg\n" "Identity/Images/Brands/Logos/000000/ffffff-0/78/centos.png\n" "Identity/Images/Brands/Logos/000000/ffffff-0/78/centos.xpm\n" "Identity/Images/Brands/Logos/000000/ffffff-0/78/centos-artwork.png\n" "Identity/Images/Brands/Logos/000000/ffffff-0/78/centos-artwork.jpg\n" "Identity/Images/Brands/Logos/000000/ffffff-0/78/centos-artwork.xmp\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos.jpg\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos.png\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos.xpm\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos-artwork.png\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos-artwork.jpg\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/48/centos-artwork.xmp\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos.jpg\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos.png\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos.xpm\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos-artwork.png\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos-artwork.jpg\n" "Identity/Images/Brands/Logos/ffffff/ffffff-0/78/centos-artwork.xmp\n" msgstr "" msgid "" "The final location for storing images output inside the repository " "is determined by using the design model directory provided as " "argument. Basically, the centos-art.sh script " "changes the path components from Models to Images and adds " "foreground color, background color, height value and image name to " "it to differentiate rendered images." msgstr "" msgid "" "In case you need to restrict the amount of files you want to " "produce including their formats, heights, colors and commands, you " "need to modify the content of the related render.conf configuration file. There is not any command-line option " "available for such tasks. The most command-line options can do for you " "is when there are more than one configuration file inside the same " "design model directory and you need to specify which one of them " "will be used as reference. In such case you can use the option." msgstr "" msgid "" "When images are produced through configuration files, the " "centos-art.sh script takes the order provided in " "the list of design models to build the list of images you will work " "with through the command specified. For example, the order in which " "images will be appended or overlapped." msgstr "" msgid "" "Localization of logo images will not be and must not be supported " "in any way. That would bring disastrous confusion in the area of " "visual recognition." msgstr "" msgid "2013's" msgstr "" msgid "" "The CentOS Artwork Repository development was eventually " "stopped at November, 2012, when I moved myself from Cienfuegos to " "Havana city for working The first months were very difficult, " "specially at the moment of finding a stable place to set my " "personal desktop (I was moving myself from one apartment to " "another, frequently)." msgstr "" msgid "" "On May 14th, the work in Havana ends for me and I have to return to " "Cienfuegos city. I tried to take advantage of the situation " "dedicating more work and study hours to The CentOS Artwork " "Repository and the related automation scripts once again. " "At this point I consider a Git+Gitolite+Gitweb+MantisBT " "infrastructure for The CentOS Artwork Repository and " "start working on it in my workstation. This, in order to implement " "a distributed work flow for The CentOS Artwork Repository based on Git version control system." msgstr "" msgid "Update Version Control Environment" msgstr "" msgid "" "The function environment related to version control tasks was " "renamed from svn to in order to handle both Subversion and Git working copies of " "The CentOS Artwork Repository. This change prepares the " "centos-art.sh script to follow the suggestion of " "a complete migration from Subversion to " "Git, at some point." msgstr "" msgid "" "Because the Subversion infrastructure is " "the one in place right now and it is the one with most artwork " "history, it will be Subversion the " "version control system we are using as default in centos-" "art.sh. However this will surely change as soon as a " "Git infrastructure be approved for " "The CentOS Artwork Repository and everything could be " "moved there." msgstr "" msgid "Start Using The centos-art.conf File" msgstr "" msgid "" "Based on the need of supporting more than one application to handle " "version control tasks, it was added the centos-art.conf file into the Scripts/Bash directory. This file exists to customize specific " "behaviours of centos-art.sh script once it has " "been executed (e.g., what kind of application will be used as " "default for doing version control, or even if the actions related " "to version control will be performed or not)." msgstr "" msgid "Update Repository Directories Structure" msgstr "" msgid "" "I face the following situation: I am working on a documentation " "project named solinfo-network. While I was " "organizing it, I found that the directory structure of The " "CentOS Artwork Repository fits quite well the needs of " "solinfo-network documentation project. However, I " "don't want to duplicate automation scripts in two separate " "projects, but share them between themselves (i.e., changes " "committed to automation scripts are pushed to one single place, not " "two.)." msgstr "" msgid "" "When we use Subversion repositories, it is possible to checkout " "specific parts of different repositories into a new repository. " "This is very useful if we need to create several projects that " "share the same component and we don't want to duplicate the common " "component in two or more different projects but share it between them. See ." msgstr "" msgid "" "When we use Git repository, it is not possible to checkout specific " "parts of a repository but the complete tree. So, in order to share " "common components of a repository we need to create one repository " "for each common component we want to share and then use Git " "submodulessee progit-book, page 152. This " "requires that brand new repositories be created for each component " "we want to share." msgstr "" msgid "" "In both situations, including Git and Subversion repositories, it " "is necessary that we define very well the structure of each " "component we want to share, so it can be plugged " "nicely into other projects. Likewise, other projects must have the " "same directory structure the pluggable component was design to fit " "in. If these two conditions can be reached, it would be possible to " "reuse repositories components and concentrate efforts. The current " "directory structure The CentOS Artwork Repository is " "set in allows components inside Subversion repositories to be " "reused by related working copies. However, we cannot do the same if " "it is stored in a Git repository. In order for Git repositories to " "be able to share components with other Git repositories, The " "CentOS Artwork Repository directory structure needs to be " "reorganized to better delineate each component the repository is " "made of." msgstr "" msgid "For more information see ." msgstr "" msgid "Corporate Visual Identity" msgstr "" msgid "..." msgstr "" msgid "The CentOS Project" msgstr "" msgid "" "The CentOS Project Corporate Identity is the persona " "of the organization known as The CentOS Project. The CentOS Project " "Corporate Identity plays a significant role in the way The CentOS " "Project, as organization, presents itself to both internal and " "external stakeholders. In general terms, The CentOS Project " "Corporate Identity expresses the values and ambitions of The CentOS " "Project organization, its business, and its characteristics." msgstr "" msgid "" "The CentOS Project Corporate Identity provides visibility, " "recognizability, reputation, structure and identification to The " "CentOS Project organization by means of Corporate Design, Corporate " "Communication, and Corporate Behaviour." msgstr "" msgid "The CentOS Project Corporate Identity." msgstr "" msgid "Corporate Mission" msgstr "" msgid "" "The CentOS " "Project exists to produce The CentOS Distribution, an " "Enterprise-class Linux Distribution derived from sources freely " "provided to the public by a prominent North American Enterprise " "Linux vendor. The CentOS Distribution conforms fully with the " "upstream vendors redistribution policy and aims to be 100% binary " "compatible. (The CentOS Distribution mainly changes packages to " "remove upstream vendor branding and artwork.)." msgstr "" msgid "" "The CentOS Distribution is developed by a small but growing team of " "core developers. In turn the core developers are supported by an " "active user community including system administrators, network " "administrators, enterprise users, managers, core Linux contributors " "and Linux enthusiasts from around the world." msgstr "" msgid "" "The CentOS Distribution has numerous advantages including: an " "active and growing user community, quickly rebuilt, tested, and " "QA'ed errata packages, an extensive mirror network, developers who " "are contactable and responsive of a reliable Enterprise-class Linux " "Distribution, multiple free support avenues including a Wiki, IRC Chat, Email Lists, Forums, and a " "dynamic FAQ." msgstr "" msgid "Corporate Graphic Design" msgstr "" msgid "" "The corporate design is focused on the effective presentation of " "corporate messages. As corporate messages we understand all the " "information emitted from the organization; and when we say " "all we mean everything that can be perceived " "through the human senses. The corporate design takes care of " "defining what this information is and controlling the way it goes " "out the organization producing it." msgstr "" msgid "" "When the organization doesn't take control over the corporate " "messages it produces, the organization is letting that area of its " "identity to the unknown and the results might be good or not so " "good, it is hard to know. The issue to see here is that even the " "organization doesn't take control over its corporate messages, they " "are always talking about the organization. Taking control of " "corporate messages is a decition the organization needs to take by " "itself, based on its need of better describe what it is." msgstr "" msgid "" "In the very specific case of The CentOS Project, we'll concentrate our " "attention on corporate messages that reach us through the visual " "sense. This is, all the visual manifestations The CentOS Project is made " "of. As visual manifestaions we understand all the visible media " "The CentOS " "Project uses to manifest its existence on. At this point it " "is necessary to consider what The CentOS Project is, what its mission is and " "what it is producing. This, in order to identify which visual " "manifestations the organization is demanding attention of corporate " "design for." msgstr "" msgid "" "Inside The " "CentOS Project we identify and apply corporate design to " "the following visual manifestations:" msgstr "" msgid "" "The CentOS Distribution — This visual manifestation exists to cover " "all actions related to artwork production and rebranding, required " "by The CentOS Distribution in order to comply with upstream's " "redistribution guidelines. This visual manifestation is described " "in ." msgstr "" msgid "" "The CentOS Web — This visual manifestation exists to cover all " "actions related to artwork production required by The CentOS Project to " "manifest its existence in the World Wide Web medium. This visual " "manifestation is described in ." msgstr "" msgid "" "The CentOS Symbol — This visual manifestation exists to cover all " "actions related to artwork production required by The CentOS Project to " "manifest its existence through media produced industrially (e.g., " "stationery, clothes, CDs, DVDs, etc.). This visual manifestation is " "described in ." msgstr "" msgid "" "The visual manifestations identified above seem to cover most media " "required by The " "CentOS Project, as organization, to show its existence. " "However, other visual manifestations could be added in the future, " "as long as they be needed, to cover different areas like stands, " "buildings, offices, road transportation or whaterver visual " "manifestation The CentOS Project thouches to show its existence." msgstr "" msgid "" "Once all visual manifestations have been identified and defined " "through design models, it is time to visually remark their " "connection with The CentOS Project. This kind of connection is realized " "by applying The CentOS Brand to design models inside visual " "manifestations supported through corporate design." msgstr "" msgid "Corporate Communication" msgstr "" msgid "" "The CentOS " "Project corporate communication is focused on the effective " "propagation of corporate messages. Propagation of corporate " "messages is closely related to the media the organization uses as " "vehicle to distribute its corporate messages." msgstr "" msgid "" "The CentOS " "Project corporate communication takes place through the " "following visual manifestations:" msgstr "" msgid "The CentOS Distribution" msgstr "" msgid "" "This visual manifestation communicates its existence through " "software packages. There are packages that make a remarkable use of " "images, packages that make a moderate use of images, and packages " "that don't use images at all. This visual manifestation is focused " "on providing The " "CentOS Project images required by software packages that do " "use images in a remarkable way, specially those holding the " "upstream brand (e.g., anaconda, grub, syslinux, gdm, " "kdebase)." msgstr "" msgid "" "The Community Enterprise Operating System itself (communicates the " "essense of The " "CentOS Project existence.)." msgstr "" msgid "" "Release Schema (Lifetime) and all the stuff related (e.g., Release " "Notes, Documentation, Erratas, etc.)." msgstr "" msgid "The CentOS Web" msgstr "" msgid "" "This visual manifestation communicates its existence through web " "applications. These web applications are free software and come " "from different providers which distribute their work with " "predefined visual styles. Frequently, these predefined visual " "styles have no visual relation among themselves and introduce some " "visual contraditions when they all are put together. Removing these " "visual contraditions is object of work for this visual " "manifestation." msgstr "" msgid "The CentOS Chat." msgstr "" msgid "The CentOS Mailing Lists." msgstr "" msgid "The CentOS Forums." msgstr "" msgid "The CentOS Wiki." msgstr "" msgid "Special Interest Groups (SIGs)." msgstr "" msgid "Social Events, Interviews, Conferences, etc." msgstr "" msgid "" "The extensive network of mirrors available for downloading ISO " "files as well as RPMs and SRPMs used to build them up in different " "architectures." msgstr "" msgid "The CentOS Symbol" msgstr "" msgid "" "This visual manifestation communicates its existence through " "production of industrial objects carrying The CentOS Brand. These " "branded objects are directed to be distributed on social events and/" "or shops. They provide a way of promotion and commercialization " "that may help to reduce The CentOS Project expenses (e.g., electrical " "power, hosting, servers, full-time-developers, etc.), in a similar " "way as donations may do." msgstr "" msgid "Stationery (e.g., Posters, Stickers, CD Lables and Sleeves)." msgstr "" msgid "Clothes (e.g., Shirts, T-shirts, Pullovers, Caps)." msgstr "" msgid "Installation media (e.g., CDs, DVD, Pendrives)." msgstr "" msgid "Corporate Behaviour" msgstr "" msgid "" "The CentOS " "Project corporate behaviour is focused on the effective " "interaction of each member involved in the organization (e.g., core " "developers, community members, etc.). It is related to ethics and " "politics used to do the things inside the organization. It is " "related to the sense of direction chosen by the organization and " "they way the organization projects itself to achieve it." msgstr "" msgid "" "The CentOS " "Project corporate behaviour takes place through The CentOS Project " "corporate communication, as described in ." msgstr "" msgid "Corporate Structure" msgstr "" msgid "" "The CentOS " "Project corporate structure is based on a Monolithic " "Corporate Visual Identity Structure. In this configuration, one " "unique name and one unique visual style is used in all visual " "manifestation The CentOS Project is made of." msgstr "" msgid "" "In a monolithic corporate visual identity structure, internal and " "external stakeholders use to feel a strong sensation of uniformity, " "orientation, and identification with the organization. No matter if " "you are visiting web sites, using the distribution, or acting on " "social events, the one unique name and one unique visual style " "connects them all to say: Hey! we are all part of The CentOS Project." msgstr "" msgid "" "Other corporate structures for The CentOS Project have been considered as " "well. Such is the case of producing one different visual style for " "each major release of The CentOS Distribution. This structure isn't " "inconvenient at all, but some visual contradictions could be " "introduced if it isn't applied correctly and we need to be aware of " "it. To apply it correctly, we need to know what The CentOS Project is made " "of." msgstr "" msgid "" "The CentOS " "Project, as organization, is mainly made of (but not " "limited to) three visual manifestions: The CentOS Distribution, The " "CentOS Web and The CentOS Symbol. Inside The CentOS Distribution " "visual manifestations, The CentOS Project maintains near to four different " "major releases of The CentOS Distribution, parallely in time. " "However, inside The CentOS Web visual manifestations, the content " "is produced for no specific release information (e.g., there is no " "a complete web site for each major release of The CentOS " "Distribution individually, but one web site to cover them all). " "Likewise, the content produced in The CentOS Symbol is industrially " "created for no specific release, but The CentOS Project in general." msgstr "" msgid "" "In order to produce the The CentOS Project Monolithic Corporate Visual " "Identity Structure correctly, we need to concider all the visual " "manifestations The CentOS Project is made of, not just one of them. If " "one different visual style is implemented for each major release of " "The CentOS Distribution, which one of those different visual styles " "would be used to cover the remaining visual manifestations The CentOS Project is made of (e.g., The CentOS Web and The CentOS Symbol)?" msgstr "" msgid "" "Probably you are thinking: yes, I see your point, but The CentOS " "Brand connects them all already, why would we need to join them up " "into the same visual style too, isn't it more work to do, and " "harder to maintain?" msgstr "" msgid "" "Harder to maintain, more work to do, probably. Specially when you " "consider that The CentOS Project has proven stability and consistency " "through time and, that, certainly, didn't come through swinging " "magical wands or something but hardly working out to automate tasks " "and providing maintainance through time. With that in mind, we " "consider The " "CentOS Project Corporate Visual Identity Structure must be " "consequent with such stability and consistency tradition. It is " "true that The CentOS Brand does connect all the visual " "manifestations it is present on, but that connection is " "strengthened if one unique visual style backups it. In fact, " "whatever thing you do to strength the visual connection among " "The CentOS " "Project visual manifestations would be very good in favor " "of The CentOS " "Project recognition." msgstr "" msgid "" "Obviously, having just one visual style in all visual " "manifestations for eternity would be a very boring thing and would " "give the idea of a visually dead project. So, there is no problem " "on creating a brand new visual style for each new major release of " "The CentOS Distribution, in order to refresh The CentOS " "Distribution visual style; the problem itself is in not propagating " "the brand new visual style created for the new release of The " "CentOS Distribution to all other visual manifestations The CentOS Project " "is made of, in a way The CentOS Project could be recognized no matter what " "visual manifestation be in front of us. Such lack of uniformity is " "what introduces the visual contradition we are precisely trying to " "solve by mean of themes production in The CentOS Artwork " "Repository." msgstr "" msgid "The CentOS Brand" msgstr "" msgid "" "The CentOS Brand is the main visual manifestaion of The CentOS Project. " "The CentOS " "Project uses The CentOS Brand to connect all the visual " "manifestions it is made of (e.g., GNU/Linux Distributions, Web " "sites, Stationery, etc.) and, this way, provides recognition " " ... just as a GPG signature might do for RPM " "packages. among similar projects available on " "the Internet. The CentOS Brand is made of a graphical component " "() and a typographical " "component () that, when put " "together, make . The " "components that make The CentOS Brand can be used together or " "separately, considering that, in hierarchy order, is rather prefered than , as well as is rather prefered than ." msgstr "" msgid "" "In addition to those components mentioned above, The CentOS Brand " "includes another component named . is mainly used " "as background on images and is directly related to the look and " "feel of all visual manifestations The CentOS Project shows its existence on. " "In contrast with , and ; might " "change from time to time providing a vehicle to refresh how The " "CentOS Project looks and feels." msgstr "" msgid "" "The CentOS Brand and all the visual manifestations derivated from " "it are available for you to study and propose improvement around a " "good citizen's will inside The CentOS Community, but you are not " "allowed to redistribute them elsewhere, without the given " "permission of The CentOS Project." msgstr "" msgid "" "If you need to redistribute either or any visual manifestation derived from it, write your " "intentions to the The CentOS Developers mailing list (centos-devel@centos.org)." msgstr "" msgid "" "The CentOS Symbol is the graphical part of The CentOS Logo. As The " "CentOS Logo, The CentOS Symbol is used to brand " "images produced by The CentOS Project and provide a visual connection " "between images so they can be monolithically recognized as part of " "The CentOS " "Project. The CentOS Symbol must be exactly the same every " "time it is printed out and a route to reproduce it in such a way " "must be available so as to avoid reproduction mistakes when images " "are branded with it." msgstr "" msgid "The CentOS Type" msgstr "" msgid "" "The CentOS Type is the typographical part of The CentOS Logo. " "Comparing with both The CentOS Logo and The CentOS Symbol, The " "CentOS Type by its own, provides poor visual connection between " "images that intend to be recognized as a monolithic part of The CentOS Project and shouldn't be used alone. Instead, The CentOS Logo or The " "CentOS Symbol are preferred. The CentOS Symbol must be exactly the " "same every time it is printed out and a route to reproduce it in " "such a way must be available so as to avoid reproduction mistakes " "when images are branded with it." msgstr "" msgid "The CentOS Logo" msgstr "" msgid "" "The CentOS Logo is a construction made of The CentOS Symbol and The " "CentOS Type. The CentOS Symbol and The CentOS Logo are the main " "visual manifestations of the organization known as The CentOS Project. " "As The CentOS Symbol, The CentOS Logo is used to brand images produced by The CentOS Project and provide a visual " "connection between images so they can be monolithically recognized " "as part of The " "CentOS Project. The CentOS Logo must be exactly the same " "every time it is printed out and a route to reproduce it in such a " "way must be available so as to avoid reproduction mistakes when " "images are branded with it." msgstr "" msgid "The CentOS Motif" msgstr "" msgid "Release Schema" msgstr "" msgid "The CentOS Showroom" msgstr "" msgid "" "The CentOS Artwork Repository documentation work line is " "implemented through documentation manuals. Documentation manuals " "are implemented through different documentation formats provided " "inside The CentOS Distribution (e.g., Docbook, Texinfo, " "LaTeX, etc.). Structuring tasks related " "to documentation systems (e.g., creating, editing, deleting, " "copying, renaming, etc.) are standardized through the

help functionality of centos-art.sh script, as "
"described in . This way, "
"people writting documentation don't need to deal with underlaying "
"tasks like creating files, updating menus, nodes, cross references "
"and wondering where to put everything in The CentOS Artwork "
"Repository."
msgstr ""

msgid "Documentation Production Cycle"
msgstr ""

msgid ""
"This chapter describes the procedure you should follow to create "
"and maintain documentation manuals inside The CentOS Artwork "
"Repository."
msgstr ""

msgid ""
"This chapter describes general concepts that can be applied through "
"the documentation formats supported inside the help functionality of centos-art.sh script. "
"To illustrate the production process related to documentation "
"manuals inside The CentOS Artwork Repository, this "
"chapter uses the The CentOS Artwork Repository File "
"System (TCAR-FS) documentation manual as example."
msgstr ""

msgid "Identifying Document Goals"
msgstr ""

msgid ""
"The first step in producing a documentation manual is to clearly "
"understand what you exactly need to document and why you need to do "
"so. The obvious answer to this question would be to describe the "
"basic ideas behind an implementation so it can be useful once "
"published. It is important that you find out the reasons you need "
"to do what you are doing and, also, those helping you to retain the "
"motivation to keep doing it in the future. Otherwise, without such "
"foundations, you'll surely end up leaving the effort soon enough to "
"make a lost cause from your initial work."
msgstr ""

msgid ""
"Before The CentOS Artwork Repository File System documentation manual would exist, there was an emerging "
"need to understand what each directory inside the growing directory "
"layout was for, how it could be used and each directory could be "
"connected one another. At that moment, the directory layout was "
"very unstable and explaining the whole idea behind it was not "
"possible, there were too many changing concepts floating around "
"which needed to be considered in the same changing way. So, to "
"understand what was happening, the The CentOS Artwork "
"Repository File System documentation manual was created."
msgstr ""

msgid ""
"The The CentOS Artwork Repository File System manual was conceived based on the idea of documenting "
"each directory inside the repository individually and, later, by "
"considering all directory documentations altogether, it would be "
"(hypothetically) possible to correct the whole idea through an "
"improvement cycle that would consolidate the final idea we were "
"trying to implement."
msgstr ""

msgid ""
"Other documentation manuals can be based on reasons different from "
"those described above, however, no matter what those reasons are, "
"it will be helpful to make yourself a clean idea about what you are "
"going to document exactly before putting your hands on it."
msgstr ""

msgid "Identifying Document Title"
msgstr ""

msgid ""
"Once you've make yourself an clean idea of what the documentation "
"manual is for and the needs behind it, it is time for you to define "
"the manual's title and the manual's directory name. Both manuals' "
"title and manual's directory name describe what the documentation "
"manual is about. The manual's title is used inside the "
"documentation while the manual's directory name is used to store "
"the related source files inside The CentOS Artwork Repository directory structure. Generally, the manual's title is a "
"phrase of few words and the manual's directory name is the "
"abbreviation of that phrase set as manual's title."
msgstr ""

msgid ""
"Following with our example, the manual's title chosen was "
"The CentOS Artwork Repository File System "
"and its directory name was set to Tcar-fs to comply with the file name convenctions "
"described at ."
msgstr ""

msgid "Identifying Document Structure"
msgstr ""

msgid ""
"Once both the manual's title and the manual's directory name have "
"been defined, it is time for you to plan the document structure "
"through which the manual's content will be organized."
msgstr ""

msgid ""
"The specific document structure you choose for a documentation "
"manuals is affected by the documentation format you use to write "
"documentation source files. Nevertheless, no matter what the "
"documentation format be, the document structure produced from the "
" functionality will always "
"follow and upside-down tree configuration for document structures. "
"In this configuration, documentation manuals can be organized "
"through different structural levels (e.g., parts, chapters, "
"sections, subsection, etc.) based on the support provided by the "
"documentation format you chose."
msgstr ""

msgid ""
"The The CentOS Artwork Repository File System documentation manual was conceived to document each "
"directory structure The CentOS Artwork Repository is "
"made of, using Texinfo as main documentation format."
msgstr ""

msgid ""
"At this point we find that The CentOS Artwork Repository had more levels deep than sectioning commands available "
"inside documentation format. This way it is not possible to use one "
"sectioning command for each directory level inside the repository "
"directory structure we need to document. Based on these issues, it "
"is imperative to re-accommodate the document structure in order to "
"be able of documenting every directory The CentOS Artwork "
"Repository is made of, using the sectioning levels "
"supported by that documentation format we chose, no matter how many "
"levels deep the repository directory structure had."
msgstr ""

msgid ""
"As consequence, The CentOS Artwork Repository File "
"System ended up being organized through the following "
"documentation structure:"
msgstr ""

msgid ""
"Chapter 1. The trunk "
"Directory"
msgstr ""

msgid ""
"This chapter describes the trunk directory inside the repository and all subdirectories "
"inside it. The first level of directories (i.e., the trunk directory itself) is described "
"inside the chapter entry. Deeper directory levels are all "
"documented through sections and have a file for their own. It is "
"also possible to write subsections and subsubsections, however, "
"they don't have a file for their own as sections do. Subsections "
"and Subsubsections should be written as part of section files (i."
"e., when writting sections)."
msgstr ""

msgid ""
"Chapter 2. The branches "
"Directory"
msgstr ""

msgid ""
"This chapter describes the branches directory and all directories inside it following the "
"same structure described for trunk directory above."
msgstr ""

msgid ""
"Chapter 3. The tags "
"Directory"
msgstr ""

msgid ""
"This chapter describes the tags directory and all directories inside it following the "
"same structure described for trunk directory above."
msgstr ""

msgid "Appendix A. Licenses"
msgstr ""

msgid ""
"This appendix is confined to organize licenses mentioned in the "
"manual. The content of this appendix is out of documenatation "
"manual scope itself and is shared among all documentation manuals "
"written through the  "
"functionality."
msgstr ""

msgid "Index"
msgstr ""

msgid ""
"This chapter organizes links to those index definitions you defined "
"inside the documentation manual. The index information displayed by "
"this chapter is auto-generated each time the manual's output files "
"are created so this chapter is not editable."
msgstr ""

msgid ""
"The document structure illustrated above is also considered the "
"default document structure used by the  functionality of centos-art.sh script "
"when you produce new documentation manuals inside The "
"CentOS Artwork Repository. In contrast with document "
"structure illustrated above, the default document structure used by "
" functionality doesn't include "
"sectioning constructions like parts, chapters, sections, "
"subsections and the like in the document structure created. Such "
"structuring constructions should be specified by you when building "
"the documentation manual. The only exceptions to this restriction "
"are sectioning structures used to organize contents like "
"Index and Licenses, which are "
"considered inseparable components of documentation manuals stored "
"inside The CentOS Artwork Repository."
msgstr ""

msgid "Implementing Document Structure"
msgstr ""

msgid ""
"The document structure implementation is automated by the  functionality, as described in "
"."
msgstr ""

msgid "Maintaining Document Structure"
msgstr ""

msgid ""
"The document structure maintenance is implemented by the  functionality, as described in "
"."
msgstr ""

msgid "Documentation Formats"
msgstr ""

msgid ""
"The CentOS Distribution provides support for different "
"documentation formats, including Texinfo, LaTeX, DocBook and "
"LinuxDoc. These formats have their own specifications and "
"requirements to create and maintain documentation manuals written "
"through them. Inside The CentOS Artwork Repository, the "
" functionality provides the "
"interface you use to create and maintain documentation manuals "
"without needing to take care the underlaying structuring tasks."
msgstr ""

msgid ""
"This chapter describes how the  functionality implements the different documentation source "
"formats available inside The CentOS Distribution, and the "
"internationalization issues related to documentation manuals "
"produced through them."
msgstr ""

msgid "Texinfo"
msgstr ""

msgid ""
"This section describes the implementation of Texinfo documentation "
"format inside the  "
"functionality of centos-art.sh script. In this "
"section we assume you have a basic understanding of Texinfo "
"documentation system. Otherwise, if you don't know what Texinfo "
"documentation system is, read the Texinfo manual first (e.g., by "
"running the info texinfo command) and then, come "
"back here."
msgstr ""

msgid "Document Structure"
msgstr ""

msgid ""
"The  functionality of "
"centos-art.sh provides a document structure that "
"makes documentation manuals created through it to be scalable and "
"maintainable through time. This document structure follows the idea "
"of an upside-down tree to organize chapters, sections, subsections "
"and the like, as described in ."
msgstr ""

msgid ""
"The  functionality creates "
"documentation manuals source files in the Documentation/Models/Texinfo/ directory "
"and saves output produced from them in the Documentation/Manuals/Texinfo/ directory. "
"To produce documentation manuals initial source files, the  functionality uses Texinfo "
"documentation templates, as described in ."
msgstr ""

msgid ""
"Inside the documentation models directory, source files are stored "
"inside language-specific directories. The language-specific "
"directories are necessary to implement internationalization of "
"Texinfo source files, as described in ."
msgstr ""

msgid ""
"Inside the language-specific directory, the following files exist "
"to store the manual's main definitions (e.g., title, subtitle, "
"author, copyright notice, chapters, appendixes, indexes and all "
"similar stuff a documentation manual usually has). In addition to "
"these files, there is one directory for each chapter created inside "
"the manual. Inside each chapter directory, you'll find the files "
"controlling the section definitions related each chapter they "
"belong to. The section files (a.k.a. documentation entries) are suffixed with a texinfo extension and named arbitrarily, as it is illustrated in "
". "
"Inside section files it is where you write the manual's content "
"itself."
msgstr ""

msgid "Texinfo document structure"
msgstr ""

#, no-wrap
msgid ""
"Documentation/Models/Texinfo/${MANUAL_NAME}\n"
"`-- ${LANG}\n"
"    |-- ${CHAPTER_NAME}/\n"
"    |   `-- ${SECTION_NAME}.texinfo\n"
"    |-- ${CHAPTER_NAME}-menu.texinfo\n"
"    |-- ${CHAPTER_NAME}-nodes.texinfo\n"
"    |-- ${CHAPTER_NAME}.texinfo\n"
"    |-- Licenses -> Documentation/Models/Texinfo/Default/${LANG}/Licenses\n"
"    |-- Licenses-menu.texinfo -> Documentation/Models/Texinfo/Default/${LANG}/Licenses-menu.texinfo\n"
"    |-- Licenses-nodes.texinfo -> Documentation/Models/Texinfo/Default/${LANG}/Licenses-nodes.texinfo\n"
"    |-- Licenses.texinfo -> Documentation/Models/Texinfo/Default/${LANG}/Licenses.texinfo\n"
"    |-- ${MANUAL_NAME}.conf\n"
"    |-- ${MANUAL_NAME}-index.texinfo\n"
"    |-- ${MANUAL_NAME}-menu.texinfo\n"
"    |-- ${MANUAL_NAME}-nodes.texinfo\n"
"    `-- ${MANUAL_NAME}.texinfo"
msgstr ""

msgid ""
"Texinfo (as in texinfo-4.8-14.el5) doesn't "
"support part sectioning inside documentation manuals, so neither "
"the  functionality does. "
"Nevertheless, you can create several documentation manuals and "
"consider them as part of a bigger documentation manual to "
"workaround this issue."
msgstr ""

msgid ""
"In this document structure, the creation of documentation manuals, "
"chapters and sections is not limitted. You can create as many "
"documenation manuals, chapters and sections as you need. The only "
"limitation would be the amount of free space required to store the "
"Texinfo source files and the output files produced from them in "
"your workstation."
msgstr ""

msgid "Document Templates"
msgstr ""

msgid ""
"Texinfo document templates provide the initial document structure "
"the  functionality needs in "
"order to create and maintain document structures, as described in "
"."
msgstr ""

msgid ""
"Texinfo document templates are language-specific. This means that "
"there is (or, at least, must be) one Texinfo document template for "
"each language you plan to support documentation manuals for. By "
"default, The CentOS Artwork Repository provides a "
"default Texinfo document template under en_US directory. This template structure is used when "
"your current locale is English language or when you are creating/"
"editing a documentation manual in a language other than English, "
"but no language-specific document template for that language exists "
"in the Scripts/Documentation/Models/"
"Texinfo/Default/ directory."
msgstr ""

msgid ""
"The Scripts/Documentation/Models/"
"Texinfo/Default/ directory organizes all Texinfo "
"document templates using the format LL_CC, where LL is the language "
"code (as in ISO-639) and CC the country code (as in ISO-3166). The "
"directory structure of Texinfo document templates is illustrated in "
"the  "
"and implemented through the following files:"
msgstr ""

msgid "manual.texinfo"
msgstr ""

msgid ""
"This file can be found inside the language-specific directory and "
"contains the manual's main definitions (e.g., document title, "
"document language, document authors, copyright notice, etc.)."
msgstr ""

msgid "manual-menu.texinfo"
msgstr ""

msgid ""
"This file can be found inside the language-specific directory and "
"contains the menu definitions of chapters inside the manual. When "
" functionality creates "
"instances of this file, menu definitions inside it are "
"automatically updated when a new chapter is created or deleted "
"through the  functionality. "
"Generally, you don't need to edit instances of this file once the "
"documentation manual has been created."
msgstr ""

msgid ""
"When a documentation manual is created for first time, this file is "
"copied from Texinfo document template directory structure to the "
"documentation manual being currently created. At this specific "
"moment, the instance created contains the following Texinfo menu "
"definition:"
msgstr ""

#, no-wrap
msgid ""
"\n"
"@menu\n"
"* Licenses::\n"
"* Index::\n"
"@end menu\n"
msgstr ""

msgid ""
"Later, when chapters are added to or deleted from the documentation "
"manual, the content of this file varies adding or deleting menu "
"entries accordingly. Nevertheless, the two entries shown above are "
"ignored when new chapters are added to or removed from the list, so "
"they will always be present in instances of this file. To preserve "
"the manual consistency, the  "
"functionality prevents you from deleting any of these chapters once "
"the documentation manual has been created."
msgstr ""

msgid "manual-nodes.texinfo"
msgstr ""

msgid ""
"This file can be found inside the language-specific directory and "
"contains the node definitions of all chapters inside the manual. "
"When  functionality creates "
"instances of this file, node definitions inside it are "
"automatically created based on menu definitions (see "
"manual-menu.texinfo file above) and they don't "
"include any content here. Instead, as part of the node definition, "
"the @include command is used to connect each node with "
"its content. Generally, you don't need to edit instances of this "
"file once the documentation manual has been created."
msgstr ""

msgid "manual-index.texinfo"
msgstr ""

msgid ""
"This file can be found inside the language-specific directory and "
"contains the Texinfo commands used to generated an organized view "
"of all indexes you defined inside documentation entries so they can "
"be quickly accessed. Generally, you don't need to edit instnaces of "
"this file once the documentation manual has been created."
msgstr ""

msgid "manual.conf"
msgstr ""

msgid ""
"This file contains the initial configuration of documentation "
"manuals written in Texinfo format. When a documentation manual is "
"created for first time, this file is copied into its target "
"directory so you be able to customize specific information like "
"menu order, title styles and template assignments therein. The "
"content of this file is described in ."
msgstr ""

msgid "Chapters.texinfo"
msgstr ""

msgid ""
"This file contains Texinfo's main chapter definition used by  functionality when new chapters are "
"created inside documentation manuals. When chapters are created for "
"first time, they come without any introduction or documentation "
"entry inside."
msgstr ""

msgid ""
"In case you need to add/update the chapters definition files, edit "
"the related chapter definition file inside the documentation manual "
"you are working on, not the template file used to create it. To "
"edit the chapter definition file, don't provide any section "
"information in the documentation entry. For example, if you want to "
"update the chapter introduction related to trunk "
"chapter inside tcar-fs documentation manual, use the "
"tcar-fs::trunk: documentation entry."
msgstr ""

msgid "Chapters-menu.texinfo"
msgstr ""

msgid ""
"This file is part of Texinfo's main chapter definition and should "
"be initially empty. Later, when chapters are created for first "
"time, this file is copied as it is (i.e., empty) into the "
"documentation manual to store the Texinfo menu entries related to "
"all documentation entries created inside the chapter. The Texinfo "
"menu entries related to documentation entries are automatically "
"created using Texinfo source files as reference."
msgstr ""

msgid "Chapters-nodes.texinfo"
msgstr ""

msgid ""
"This file is part of Texinfo's main chapter definition and contains "
"the node definition the  "
"functionality uses as reference to create the list of Texinfo nodes "
"related to all documentation entries created inside the chapter. "
"The node definition of documentation entries is automatically "
"created from the menu definition of documentation entries (see "
"Chapters-menu.texinfo file above), once it has "
"been updated from Texinfo source files."
msgstr ""

msgid "section.texinfo"
msgstr ""

msgid ""
"This file contains the Texinfo section definition used by  functionality when new "
"documentation entries are created inside chapters of documentation "
"manuals. When documentation entries are created for first time, "
"they are created as empty documentation entries that you need to "
"fill up with content. Again, if you want to update the content of "
"sections inside the documentation manual, update the related "
"documentation entry inside the documentation manual, not the "
"template file used to create it."
msgstr ""

msgid ""
"The creation of documentation entries inside the documentation "
"manual is represented by the ${SECTION_NAME}.texinfo file, as described in . In this example, "
"${SECTION_NAME} is a variable string referring the file name "
"of documentation entries. The file names of documentation entries "
"are made of letters, numbers and the minus sign (which is generally "
"used as word separator)."
msgstr ""

msgid ""
"Documentation entries are not limited inside chapters of "
"documentation manuals. You can create as many documentation entries "
"as you need to describe the content of your manual."
msgstr ""

msgid ""
"There are other files which aren't related to manual's source "
"files, but to manual's output files. Such files are described below "
"and can be found either inside or outside the language-specific "
"directories so you can control common and specific output settings "
"through them. These files aren't copied into the directory "
"structure of new documentation manuals created through the  functionality. Instead, they remain "
"inside the template directory structure so as to be reused each "
"time the output of documentation manuals is rendered."
msgstr ""

msgid "manual-init.pl"
msgstr ""

msgid ""
"This file can be found inside and outside language-specific "
"directories and contains the Texi2html initialization script. When "
"this file is outside the language-specific directory, it contains "
"common customizations to all language-specific outputs (e.g., "
"changing the output DTD). When this file is inside the language-"
"specific directory, it contains translations for that language-"
"specific output (e.g., special words like See, Index, Contents, "
"Top, etc., are localized here)."
msgstr ""

msgid "manual.sed"
msgstr ""

msgid ""
"This file can be found inside and outside language-specific "
"directories and contains special transformations for Texi2html "
"output. Again, when this file is inside language-specific "
"directories the transformation are applied to that language-"
"specific XHTML output and when it is outside language-specific "
"directories the transformations are applied to all language-"
"specific XHTML outputs. Most transformations achieved through this "
"file are to produce admonitions since Texinfo documentation format "
"(as in texinfo-4.8-14.el5) doesn't have an "
"internal command to build them."
msgstr ""

msgid "Template for texinfo document structures"
msgstr ""

#, no-wrap
msgid ""
"\n"
"Documentation/Models/Texinfo/Default/\n"
"|-- ${LANG}/\n"
"|   |-- Chapters/\n"
"|   |   |-- section.texinfo\n"
"|   |   `-- section-functions.texinfo\n"
"|   |-- Chapters-menu.texinfo\n"
"|   |-- Chapters-nodes.texinfo\n"
"|   |-- Chapters.texinfo\n"
"|   |-- Licenses/\n"
"|   |   |-- GFDL.texinfo\n"
"|   |   `-- GPL.texinfo\n"
"|   |-- Licenses-menu.texinfo\n"
"|   |-- Licenses-nodes.texinfo\n"
"|   |-- Licenses.texinfo\n"
"|   |-- manual-index.texinfo\n"
"|   |-- manual-init.pl\n"
"|   |-- manual-menu.texinfo\n"
"|   |-- manual-nodes.texinfo\n"
"|   |-- manual.conf\n"
"|   |-- manual.sed\n"
"|   `-- manual.texinfo\n"
"|-- manual-init.pl\n"
"`-- manual.sed\n"
msgstr ""

msgid ""
"Inside the directory structure of Texinfo document templates, the "
"Chapters directory stores "
"section specific models used to create and maintain section files "
"inside manuals. File names beginning with Chapters, "
"at the same level of Chapters directory, are used to create chapter specific files "
"inside manuals."
msgstr ""

msgid ""
"The Licenses directory "
"organizes the license information linked from all manuals. Notice "
"the license information is not copied into documentation manuals "
"when they are created, but referred from models location where they "
"are maintained. This configuration permits all documentation "
"manuals written in Texinfo format inside The CentOS Artwork "
"Repository to use the same license information. This way, "
"if a change is committed to license files, it will be immediately "
"propagated to all documentation manuals the next time their output "
"files be updated."
msgstr ""

msgid "Document Expansions"
msgstr ""

msgid ""
"The document expansions are special constructions the  functionality provides to generate content "
"dynamically inside Texinfo source files."
msgstr ""

msgid "The SeeAlso Expansion"
msgstr ""

msgid ""
"This expansion creates a list of links with section entries one "
"level ahead from the section entry being currently processed. In "
"this construction, the TYPE variable can be either itemize, enumerate or menu. When no "
"TYPE variable is provided, the itemize value is "
"considered as default."
msgstr ""

#, no-wrap
msgid ""
"@c -- <[centos-art(SeeAlso,TYPE)\n"
"@c -- ]>"
msgstr ""

msgid ""
"This expansion might result useful when you are documenting the "
"repository file system. For example, if you are currently editing "
"the documentation entry related to Identity directory and want to create a linkable list "
"of all documentation entries in the first level under it, the code "
"you'll have once the construction be expanded would look like the "
"following:"
msgstr ""

#, no-wrap
msgid ""
"\n"
"@c -- <[centos-art(SeeAlso)\n"
"@itemize\n"
"@item @ref{Trunk Identity Brushes}\n"
"@item @ref{Trunk Identity Fonts}\n"
"@item @ref{Trunk Identity Images}\n"
"@item @ref{Trunk Identity Models}\n"
"@item @ref{Trunk Identity Palettes}\n"
"@item @ref{Trunk Identity Patterns}\n"
"@item @ref{Trunk Identity Webenv}\n"
"@end itemize\n"
"@c -- ]>\n"
msgstr ""

msgid ""
"An interesting thing to notice here is that document expansions are "
"executed each time the related documentation entry is edited or "
"updated. Following with the example above, if the documentation "
"entries related to directories under Identity changes for some reason (e.g., they are "
"removed from documentation manual), the list generated as result of "
"document expansion will be updated automatically after editing the "
"documentation entry or updating the documentation manual structure."
msgstr ""

msgid "Document Configuration"
msgstr ""

msgid ""
"The document configuration is stored in the "
"${MANUAL_NAME}.conf file, inside the documentation "
"manual directory structure. This file is originally copied from "
"manual.conf template file when the "
"documentation manual is created for first time. The content of "
"${MANUAL_NAME}.conf file is organized in "
"sections. Each section here is written in one line of its own and "
"have the form [section_name]. Under sections, the "
"configuration settings take place through name=\"value\" pairs set in one line each. Notice that quotation marks "
"around the option_value are required. Comments are also possible "
"using the # character at the begining of lines. "
"Comments and empty lines (including tabs and white spaces) are "
"ignored. In case more than one section or option appear with the "
"same name inside the configuration file, the first one found will "
"be used. Nested section definitions are not supported."
msgstr ""

#, no-wrap
msgid ""
"[section_name]\n"
"# This is a comment.\n"
"option_name = \"option_value\""
msgstr ""

msgid ""
"The ${MANUAL_NAME}.conf file is specific to "
"document templates. If you are using Texinfo document template to "
"create documentation manuals, then the default configuration file "
"for that documentation manual is taken from Texinfo document "
"template directory structure. However, if you are using a document "
"template different to Texinfo document template, the default "
"configuration file will be taken from the related document template "
"directory structure you are creating the documentation manual from."
msgstr ""

msgid "The [main] Section"
msgstr ""

msgid ""
"The [main] section organizes settings that let you "
"customize the way sections and menu definitions are created inside "
"the documentation manual. The following options are available in "
"this section:"
msgstr ""

msgid "manual_format"
msgstr ""

msgid ""
"This option specifies the documentation format used by manual. To "
"write documentation manuals in Texinfo format, the value of this "
"option must always be:"
msgstr ""

#, no-wrap
msgid "manual_format = \"texinfo\""
msgstr ""

msgid ""
"Once the documentation manual has been created, you must not change "
"the value of  option. This will "
"produce an error because there is not a migration feature available "
"yet. In the future, when you change this value, it must be possible "
"to transform documentation manuals from one format to another."
msgstr ""

msgid "manual_section_style"
msgstr ""

msgid ""
"This option specifies the title style used by sections inside the "
"manual. Possible values to this option are `cap-each-word' to "
"capitalize each word in the section title, `cap-first-word' to "
"capitalize the first word in the section title only and `directory' "
"to transform each word in the section title into a directory path. "
"From all these options, `cap-each-word' is the one used as default."
msgstr ""

#, no-wrap
msgid "manual_section_style = \"cap-each-word\""
msgstr ""

msgid "manual_section_order"
msgstr ""

msgid ""
"This option specifies the order used by sections inside the manual. "
"By default new sections added to the manual are put on the end to "
"follow the section order in which they were `created'. Other "
"possible values to this option are `ordered' and `reversed' to sort "
"the list of sections alphabetically from A-Z and Z-A, respectively."
msgstr ""

#, no-wrap
msgid "manual_section_order = \"created\""
msgstr ""

msgid "The [templates] Section"
msgstr ""

msgid ""
"The [templates] section provides the assignment "
"relation between template files and documentation entry files "
"inside the manual. The template definition is set on the left side "
"using relative path and the documentation entry files are described "
"on the right side using a regular expression. The first match wins."
msgstr ""

#, no-wrap
msgid "Chapters/section.texinfo = \"^.+\\.texinfo$\""
msgstr ""

msgid "Document Localization"
msgstr ""

msgid ""
"To produce localized documentation manuals through Texinfo "
"documentation format it is necessary to create one documentation "
"manual for each language it is desired to support documentation "
"for. Documentation manuals created in this configuration don't have "
"a direct relation among themselves except that one adopted by "
"people writting them to keep their content syncronized. In this "
"configuration translators take one documentation manual as "
"reference (a.k.a. the source manual) and produce several translated "
"manuals based on its content. To keep track of changes inside the "
"source manual, the underlaying version control system must be used "
"considering that there is no direct way to apply gettext The gettext program "
"translates a natural language message into the user's language, by "
"looking up the translation in a message catalog. For more "
"information about the gettext program, run "
"info gettext.  procedures to "
"Texinfo source files."
msgstr ""

msgid ""
"In order to maintain localization of Texinfo source files through "
"gettext procedures, it is necessary to convert "
"the Texinfo source files into XML format first. This way it would "
"be possible to make use of  "
"and  functionalities to "
"maintain translation messages in different languages through "
"portable objects and producing localized XML files based on such "
"portable objects, respectively. Once the localized XML file is "
"available, it would be a matter of using an XSLT processor (see the "
"xsltproc command) to realize the convertion from "
"XML to a localize Texinfo (or possible other) format. Nevertheless, "
"this workaround fails because the Document Type Definition (DTD) "
"required to validate the XML file produced from makeinfo (as in texinfo-4.8-14.el5) is not "
"availabe inside The CentOS Distribution (release 5.5), nor it is "
"the XSLT files required to realize the transformation itself for "
"such DTD."
msgstr ""

msgid ""
"Another similar approach to maintain localization of Texinfo source "
"files through gettext procedures would be to "
"convert Texinfo source file to DocBook format; for who the required "
"DTD and XSLT files are available inside The CentOS Distribution. "
"This way, following a procedure similar to that one describe for "
"XML files above, it would be possible to end up having localized "
"DocBook files that can be used as source to produce localized "
"output for both online and printing media. However, the DocBook "
"output produced from makeinfo command (as in "
"texinfo-4.8-14.el5) isn't a valid DocBook "
"document according to DocBook DTDs available inside The CentOS "
"Distribution (release 5.5) thus provoking the validation and "
"transformation of such a malformed document to fail."
msgstr ""

msgid "Document Language"
msgstr ""

msgid ""
"The language information of those documentation manuals produced "
"through Texinfo documentation format is declared by Texinfo's "
"@documentlanguage command. This command receives one "
"argument refering the language code (as in ISO-639 standard) and "
"must be set inside the manual's main definition file. Generally, "
"there is no need to change the document language declaration once "
"it has been created by the  "
"functionality; unless you mistakently create the manual for a "
"locale code different to that one you previously pretended to do in "
"first place, of course."
msgstr ""

msgid ""
"The language information used in both Texinfo source files and "
"XHTML output produced by the  "
"functionality is determined by the user's session LANG environment variable. This variable can be customized in the "
"graphical login screen before login, or once you've login by "
"explicitly setting the value of LANG environment "
"variable inside the ~/.bash_profile file."
msgstr ""

msgid ""
"To create documentation manuals in English language the "
"LANG environment variable must be set to en_US."
"UTF-8 or something similar. Likewise, if you want to create "
"documentation manuals in a language other than English, be sure the "
"LANG environment variable is set to the appropriate "
"locale code. The appropriate locale code to set "
"here can be found in the output produced by the locale -a "
"| less command. "
msgstr ""

msgid ""
"When producing output from Texinfo source files using the "
"makeinfo command (as in the texinfo-4.8-"
"14.el5 package), the language information set by "
"@documentlanguage is ignored in Info and HTML output, "
"but cosidered by Tex program to redefine various English words used "
"in the PDF output (e.g., Chapters, Index, See, and so on) based on the current "
"language set in."
msgstr ""

msgid "Document Encoding"
msgstr ""

msgid ""
"The encoding information of documentation manuals produced through "
"Texinfo documentation format is declared by Texinfo's "
"@documentencoding command and can take either US-"
"ASCII, ISO-8859-1, ISO-8859-15 or "
"ISO-8859-2 as argument. Nevertheless, you should be "
"aware that the  functionality "
"doesn't declare the @documentencoding inside Texinfo "
"source files. Let's see why."
msgstr ""

msgid ""
"When the @documentencoding command is set in Texinfo "
"source files, the terminal encoding you use to read the Info output "
"produced from such files must be set to that encoding information "
"you provided as argument to @documentencoding command; "
"this, before using an Info reader to open the Info output file in "
"the terminal. Otherwise, when the terminal and the Texinfo source "
"files encoding definition differ one another, characters defined "
"through Texinfo's special way of producing floating accents won't "
"be displayed as expected (even when the