diff --git a/Identity/Manual/Introduction/layout.texi b/Identity/Manual/Introduction/layout.texi index 8e22ade..33fee34 100644 --- a/Identity/Manual/Introduction/layout.texi +++ b/Identity/Manual/Introduction/layout.texi @@ -62,75 +62,90 @@ single place to look for fixes and improvements. @subsection Repository work flow As repository work flow we understand a serie of normalized steps used -to produce contents inside CentOS Artwork Repository. There are two -relevant components inside the repository that we need to normalize -work flow for, they are: @emph{content rendition}, @emph{content -localization} and @emph{programming}. - -@subsubsection Content rendition - -The CentOS Project Corporate Identity, in part, is made of several -visual manifestations. These visual manifestations implement the -Corporate Identity by means of images placed in key visible areas of -each manifestation visual space. As work flow to produce these images, -we decompose images in design models and artistic motifs. Design -models provide the image structure (i.e., dimension, translation -markers, common designs, etc.) and artistic motifs the visual style -(i.e., the background information provide the look and feel). +to produce contents inside CentOS Artwork Repository. There are three +remarkable actions inside the repository that we need to provide a +normalized work flow for, they are: @emph{Rendition}, +@emph{Localization} and @emph{Programming}. + +@subsubsection Rendition + +@xref{Directories trunk Identity}. + +Rendition is the action through which The CentOS Project Corporate +Identity is produced inside the repository. The CentOS Project +Corporate Identityis is made, in part, of several visual +manifestations. These visual manifestations implement the Corporate +Identity by mean of images placed in key areas of each manifestation +visual space. + +As work flow to produce these images, we decompose them in design +models and artistic motifs. Design models provide the image structure +(i.e., dimension, translation markers, common designs, etc.) and +artistic motifs the visual style (i.e., the background information +provide the look and feel). Design models are created for each visual manifestation the CentOS Project is made of. This way we describe the visual manifestation and provide a template system for it where several artistic motifs can be applied. Artistic motifs are created with design models in mind, not -the visual manifestation such design models are applied to. - -The combination of both design models and artistic motifs is what we -know as @emph{Theme}. Themes let us create several design models and -several background images apart one another that can be later combined -albitrarily one another to provide a flexible way of producing images -for different visual manifestations. - -In addition to themes, you can find another way of image production, a -more direct way of image production where there is no artistic motif -at all, but design models only. This configuration is useful to -produce content that don't need specific background information like -icons and illustrations used in documentation. - -@subsubsection Content localization +the visual manifestation such design models is built for. + +The combination of one design models with one artistic motifs is what +we know as one @emph{theme}. Inside themes directory structure, you +can find several design models and several artistic motifs, apart one +another, that can be albitrarily combined one another through +@emph{theme rendition}, a flexible way to produce images for different +visual manifestations inside CentOS Artwork Repository. Theme +rendition takes place in @file{trunk/Identity/Themes/Models} and +@file{trunk/Identity/Themes/Motifs} directory structures. + +In addition to theme rendition, you can find another way of image +production, a more direct way of image production where there is no +artistic motif at all, but design models only. Such configuration is +named @emph{direct rendition} and is very useful to produce simple +content that doesn't need specific background information like icons +and illustrations used in documentation. Direct rendition takes place +in @file{trunk/Identity/Models} and @file{trunk/Identity/Images} +directory structures. + +@subsubsection Localization + +@xref{Directories trunk Locales}. Whatever content rendition you perform, sometimes you need to produce -the content in different languages. Production of content in different +content in different languages. Production of content in different languages is known as localization or l10n for short. Inside CentOS Artwork Repository, content localization is performed using the -@command{gettext} standard internationalization process as base. +processed provided by @command{gettext} internationalization standard. -Basically, the @command{gettext} standard internationalization process +Basically, the @command{gettext} internationalization standard consists on retriving translatable strings from source files and -create Portable Objects and Machine Objects. Portable Objects contain -the information translators used to do their work, it is file that can -be edited by any convenctional text editor like Vim, Emacs or Nano. On -the other hand, Machine Objects are produced to be machine-redable as -its name implies, and are produced from Portable Objects. +creating Portable Objects and Machine Objects. Portable Objects +contain the information used by translators to do their work, they are +files that can be edited by any convenctional text editor like Vim, +Emacs or Nano. On the other hand, Machine Objects are produced to be +machine-redable as its name implies, and are produced from Portable +Objects. Since @command{gettext} needs to extract translatable strings form source files in order to let translators to localize them, the types of source files we use inside the repository are limitted to the file types supported by @command{gettext} program. Most of source files supported by @command{gettext} are those from programming languages -like C, C++, Bash, Python and Perl just to mention a few from the long -list of supported formats. However, formats like SVG, XHTML and +like C, C++, Bash, Python and Perl just to mention a few ones from the +long list of supported formats. However, formats like SVG, XHTML and Docbook don't figure as supported in the long list of @command{gettext} supported source files. For these formats we use the -@command{xml2po} program that come in @file{gnome-doc-utils} package -instead. The @command{xml2po} program reads one XML based file and -extracts translatable strings from it and creates one Portable Object -that is use to create a translated XML based file with the same -definition of the source file translatable strings were taken from -(e.g., if we extract translatable strings from a SVG file, as result -we get the same SVG file but with translatable strings already -localized ---obviously, for this to happen translators need to +@command{xml2po} program that come in the @file{gnome-doc-utils} +package instead. The @command{xml2po} program reads one XML based +file and extracts translatable strings from it and creates one +Portable Object that is use to create a translated XML based file with +the same definition of the source file where translatable strings were +taken from (e.g., if we extract translatable strings from a SVG file, +as result we get the same SVG file but with translatable strings +already localized ---obviously, for this to happen translators need to localize translatable strings inside the Portable Object first, -localization don't appear as art of magic---). When using +localization won't appear as art of magic---). When using @command{xml2po}, the Machine Object file is used just temporally to produce the final translated XML based file. @@ -142,6 +157,8 @@ Artwork Repository be sure to use source files supported by @subsubsection Programming +@xref{Directories trunk Scripts}. + So far, we've seen a conceptual view of how image production inside CentOS Artwork Repository is performed, but how all this is implemented, what is the practical view? diff --git a/Identity/Manual/repository.info.bz2 b/Identity/Manual/repository.info.bz2 index d61d666..57e2f5f 100644 Binary files a/Identity/Manual/repository.info.bz2 and b/Identity/Manual/repository.info.bz2 differ diff --git a/Identity/Manual/repository.pdf b/Identity/Manual/repository.pdf index a0a7855..8999a75 100644 Binary files a/Identity/Manual/repository.pdf and b/Identity/Manual/repository.pdf differ diff --git a/Identity/Manual/repository.txt.bz2 b/Identity/Manual/repository.txt.bz2 index c891d05..b6a3407 100644 Binary files a/Identity/Manual/repository.txt.bz2 and b/Identity/Manual/repository.txt.bz2 differ diff --git a/Identity/Manual/repository.xhtml.tar.bz2 b/Identity/Manual/repository.xhtml.tar.bz2 index e466134..d3a433b 100644 Binary files a/Identity/Manual/repository.xhtml.tar.bz2 and b/Identity/Manual/repository.xhtml.tar.bz2 differ diff --git a/Identity/Manual/repository.xml b/Identity/Manual/repository.xml index b0218d0..26c5791 100644 --- a/Identity/Manual/repository.xml +++ b/Identity/Manual/repository.xml @@ -312,21 +312,24 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh Repository work flow - As repository work flow we understand a serie of normalized steps used to produce contents inside CentOS Artwork Repository. There are two relevant components inside the repository that we need to normalize work flow for, they are: content rendition, content localization and programming. + As repository work flow we understand a serie of normalized steps used to produce contents inside CentOS Artwork Repository. There are three remarkable actions inside the repository that we need to provide a normalized work flow for, they are: Rendition, Localization and Programming. - Content rendition - The CentOS Project Corporate Identity, in part, is made of several visual manifestations. These visual manifestations implement the Corporate Identity by means of images placed in key visible areas of each manifestation visual space. As work flow to produce these images, we decompose images in design models and artistic motifs. Design models provide the image structure (i.e., dimension, translation markers, common designs, etc.) and artistic motifs the visual style (i.e., the background information provide the look and feel). - Design models are created for each visual manifestation the CentOS Project is made of. This way we describe the visual manifestation and provide a template system for it where several artistic motifs can be applied. Artistic motifs are created with design models in mind, not the visual manifestation such design models are applied to. - The combination of both design models and artistic motifs is what we know as Theme. Themes let us create several design models and several background images apart one another that can be later combined albitrarily one another to provide a flexible way of producing images for different visual manifestations. - In addition to themes, you can find another way of image production, a more direct way of image production where there is no artistic motif at all, but design models only. This configuration is useful to produce content that don't need specific background information like icons and illustrations used in documentation. + Rendition + See Directories trunk Identity. + Rendition is the action through which The CentOS Project Corporate Identity is produced inside the repository. The CentOS Project Corporate Identityis is made, in part, of several visual manifestations. These visual manifestations implement the Corporate Identity by mean of images placed in key areas of each manifestation visual space. + As work flow to produce these images, we decompose them in design models and artistic motifs. Design models provide the image structure (i.e., dimension, translation markers, common designs, etc.) and artistic motifs the visual style (i.e., the background information provide the look and feel). + Design models are created for each visual manifestation the CentOS Project is made of. This way we describe the visual manifestation and provide a template system for it where several artistic motifs can be applied. Artistic motifs are created with design models in mind, not the visual manifestation such design models is built for. + The combination of one design models with one artistic motifs is what we know as one theme. Inside themes directory structure, you can find several design models and several artistic motifs, apart one another, that can be albitrarily combined one another through theme rendition, a flexible way to produce images for different visual manifestations inside CentOS Artwork Repository. Theme rendition takes place in trunk/Identity/Themes/Models and trunk/Identity/Themes/Motifs directory structures. + In addition to theme rendition, you can find another way of image production, a more direct way of image production where there is no artistic motif at all, but design models only. Such configuration is named direct rendition and is very useful to produce simple content that doesn't need specific background information like icons and illustrations used in documentation. Direct rendition takes place in trunk/Identity/Models and trunk/Identity/Images directory structures. - Content localization - Whatever content rendition you perform, sometimes you need to produce the content in different languages. Production of content in different languages is known as localization or l10n for short. Inside CentOS Artwork Repository, content localization is performed using the gettext standard internationalization process as base. - Basically, the gettext standard internationalization process consists on retriving translatable strings from source files and create Portable Objects and Machine Objects. Portable Objects contain the information translators used to do their work, it is file that can be edited by any convenctional text editor like Vim, Emacs or Nano. On the other hand, Machine Objects are produced to be machine-redable as its name implies, and are produced from Portable Objects. - Since gettext needs to extract translatable strings form source files in order to let translators to localize them, the types of source files we use inside the repository are limitted to the file types supported by gettext program. Most of source files supported by gettext are those from programming languages like C, C++, Bash, Python and Perl just to mention a few from the long list of supported formats. However, formats like SVG, XHTML and Docbook don't figure as supported in the long list of gettext supported source files. For these formats we use the xml2po program that come in gnome-doc-utils package instead. The xml2po program reads one XML based file and extracts translatable strings from it and creates one Portable Object that is use to create a translated XML based file with the same definition of the source file translatable strings were taken from (e.g., if we extract translatable strings from a SVG file, as result we get the same SVG file but with translatable strings already localized —obviously, for this to happen translators need to localize translatable strings inside the Portable Object first, localization don't appear as art of magic—). When using xml2po, the Machine Object file is used just temporally to produce the final translated XML based file. + Localization + See Directories trunk Locales. + Whatever content rendition you perform, sometimes you need to produce content in different languages. Production of content in different languages is known as localization or l10n for short. Inside CentOS Artwork Repository, content localization is performed using the processed provided by gettext internationalization standard. + Basically, the gettext internationalization standard consists on retriving translatable strings from source files and creating Portable Objects and Machine Objects. Portable Objects contain the information used by translators to do their work, they are files that can be edited by any convenctional text editor like Vim, Emacs or Nano. On the other hand, Machine Objects are produced to be machine-redable as its name implies, and are produced from Portable Objects. + Since gettext needs to extract translatable strings form source files in order to let translators to localize them, the types of source files we use inside the repository are limitted to the file types supported by gettext program. Most of source files supported by gettext are those from programming languages like C, C++, Bash, Python and Perl just to mention a few ones from the long list of supported formats. However, formats like SVG, XHTML and Docbook don't figure as supported in the long list of gettext supported source files. For these formats we use the xml2po program that come in the gnome-doc-utils package instead. The xml2po program reads one XML based file and extracts translatable strings from it and creates one Portable Object that is use to create a translated XML based file with the same definition of the source file where translatable strings were taken from (e.g., if we extract translatable strings from a SVG file, as result we get the same SVG file but with translatable strings already localized —obviously, for this to happen translators need to localize translatable strings inside the Portable Object first, localization won't appear as art of magic—). When using xml2po, the Machine Object file is used just temporally to produce the final translated XML based file. Tip If you want to have your content localized inside CentOS Artwork Repository be sure to use source files supported by gettext and xml2po programs. @@ -334,6 +337,7 @@ manual_deleteCrossReferences.sh manual_searchIndex.sh Programming + See Directories trunk Scripts. So far, we've seen a conceptual view of how image production inside CentOS Artwork Repository is performed, but how all this is implemented, what is the practical view? The practical view can be found through centos-art.sh script, a bash script specially designed to automate most frequent tasks inside CentOS Artwork Repository. The centos-art.sh script is stored in trunk/Scripts directory structure and is there where the main development for centos-art.sh script takes place. Basically, the centos-art.sh script is divided in several functionalities that perform specific tasks inside the repository. Such functionalities relay on repository organization to work as expected. Maiking the centos-art.sh script to automate tasks is the only possible work flow that I can think about right now. If you are a programmer, take a functionality from centos-art.sh script, study it, look how to improve it and share your ideas at centos-devel@centos.org mailing list.