&TCAR; development was eventually stopped at November 2011 until July 2012 when it was decided to make the centos-art.sh script a bit more customizable than it presently was. For example, it was considered as a need that the centos-art.sh functionalities must be not just conceived independent one another but reusable in different contexts. As consequence of this autonomy we want to have among functionalities, the procedure used to locale messages inside the centos-art.sh script had to be modified in order to accept such pluggable behavior into the script. We cannot have a single centos-art.sh.po file for all the functionalities because all functionalities are not used in the same context. Instead, it is required that each functionality has its own messages.po file in order to treat them individually. Otherwise, we would end up having translations for functionalities that we don't need or use in our current context. As an example, consider a situation where you are working on the corporate identity of &TCP; and you 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 that 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.). To solve this issue, you need 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. The , illustrates how the render functionality living in &TCAR; has been integrated into the working copy of your new project. Mixing automation functionalities. /home/al/Projects/Myapp/ `-- trunk/ |-- Locales/ | `-- Bash/ | |-- Functions/ | | |-- Render/ <--| from https://projects.centos.org/svn/artwork/ | | | `-- es_ES/ | | | |-- messages.po | | | `-- messages.pot | | `-- Report/ | | `-- es_ES/ | | |-- messages.po | | `-- messages.pot | `-- es_ES/ | |-- LC_MESSAGES/ | | `-- centos-art.sh.mo | |-- centos-art.sh.po | `-- centos-art.sh.pot `-- Scripts/ `-- Bash/ |-- Functions/ | |-- Render/ <--| from https://projects.centos.org/svn/artwork/ | `-- Report/ `-- myapp.sh At this point you find yourself working with a mix of two different central repositories in the same working copy. One repository provides your organization files. The other repository provides the files of render functionality at &TCAR;. In this environment, all updates commited to the render functionality at &TCAR; will be available to you too, the next time you update your working copy. Understanding the need of mixing different repositories into a single working copy is an important setp 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 ispadm.sh instead of centos-art.sh so the information we set inside it could reflect the specific needs that motiveted 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 controled 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 of your working copy. Setting the absolute path of your working copy to something different than /home/centos/Projects/artwork will provoke that some components inside &TCAR; be processed correctly while others don't. For example, SVG design models will be processed correctly but CSS files won't. This is because before processing SVG files we expand translation markers inside them create a temporal file and then process the temporal file instead of the original SVG file. In the case of CSS files doing the same isn't appropriate.