&TCAR; 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. The procedure used to locale messages inside the centos-art.sh script had 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. 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. 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 trunk/Scripts/Bash --update For more information about the prepare and locale functionalities, see and respectively. 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. Directory structure of a rendering-only context /home/centos/Projects/artwork/trunk/ |-- Locales/ | `-- Scripts/ | `-- Bash/ | `-- es_ES/ | |-- Functions/ | | |-- Commons/ | | | |-- messages.po | | | `-- messages.pot | | |-- Locales/ | | | |-- messages.po | | | `-- messages.pot | | `-- Render/ | | |-- messages.po | | `-- messages.pot | |-- LC_MESSAGES/ | | `-- centos-art.sh.mo | |-- centos-art.sh.po | `-- centos-art.sh.pot `-- Scripts/ `-- Bash/ |-- Functions/ | |-- Commons/ | |-- Locales/ | `-- Render/ `-- centos-art.sh A practical example of using the solution described above may be found when you are working on the corporate identity of &TCP; and then need to start a new corporate identity project for another organization. You want to keep the directory structure of &TCAR; 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 &TCP; (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. 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 &TCAR; has been integrated into the working copy of your new project. Mixing automation functionalities. /home/al/Projects/Myapp/trunk/ |-- Locales/ | `-- Scripts/ | `-- Bash/ | `-- es_ES/ | |-- Functions/ | | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/ | | | |-- messages.po | | | `-- messages.pot | | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/ | | | |-- messages.po | | | `-- messages.pot | | |-- Render/ <--| from https://projects.centos.org/svn/artwork/ | | | |-- messages.po | | | `-- messages.pot | | `-- Report/ | | |-- messages.po | | `-- messages.pot | |-- LC_MESSAGES/ | | `-- myapp.sh.mo | |-- myapp.sh.po | `-- myapp.sh.pot `-- Scripts/ `-- Bash/ |-- Functions/ | |-- Commons/ <--| from https://projects.centos.org/svn/artwork/ | |-- Locales/ <--| from https://projects.centos.org/svn/artwork/ | |-- Render/ <--| from https://projects.centos.org/svn/artwork/ | `-- Report/ `-- myapp.sh 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 &TCAR;. In this environment, all updates commited to the Render, Locales and Commons directories at &TCAR; 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 &TCAR; the next time they update their working copies. 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 &TCP;. You probably need to change this if you are producing images to a different organization than &TCP;. 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 &TCP;. 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. ...