Websites/workflow/es

Click here to set up this language box

File:Artwork DesignService fedorawebsitesbanner 3.png

La arquitectura de los sitios web (build, dev and trans)

Nuestro sistema de build

Nuestros sitios web son reconstruidos cada hora. Esto se hace usando el script syncStatic que es administrado por Puppet. En otras palabras, debes estar en el equipo de infraestructura para cambiarlo. Aquí se carga una copia de muestra. Aquí es donde decidimos en qué rama construimos cada sitio web. También hay un script syncStatic.stg específico para los sitios web de staging. Ejemplo de sitios web de stg son stg.fedoraproject.org y spins.stg.fedoraproject.org

Para conocer el tiempo de publicación, consulte nuestra documentación específica. También tenemos un documento que le ayudará a no olvidar nada cuando se hace merge con la próxima versión de lanzamiento

Uso

Para crear las páginas de sitios web estáticos, puede ejecutar make desde el directorio raíz del sitio web específico. Esto construirá las páginas en todos los idiomas disponibles. Una lista de todas las traducciones existentes está disponible en el encabezado del archivo Makefile.
Este tipo de build es bastante largo, si quieres también puedes correr:

• make LANG: construye las páginas en un idioma específico, donde LANG es la abreviatura de dos letras para la traducción.
• make LANG test: crea una instancia de prueba en http://localhost:5000/ en un idioma específico, ejecute make stoptest para eliminarlo.
• make test: Igual que el anterior, creará una instancia de prueba para todos los idiomas disponibles.

Codificación

Muchos de nuestros sitios web utilizan el Bootstrap sistema Bootstrap, por lo que verá muchos divs en nuestros archivos fuente HTML. Es posible que desee ver una explicación.

Arquitectura

El repositorio web de fedora(fedora-web) se parece a lo siguiente (en su mayoría, todos los sitios web utilizan el mismo árbol que boot.fedoraproject.org).

  .
  |-- boot.fedoraproject.org
  |   |-- data
  |   |-- Makefile
  |   |-- po
  |   -- static
  |-- build.d
  |   |-- buildconf.py
  |   |-- build.py
  |   |-- construct-translations.py
  |   |-- globalvar.py
  |   |-- pybabel.cfg
  |   -- translations.ini
  …
  |-- httpd
  |-- Makefile.in
  `-- tools

Cada directorio de sitios web consiste en una carpeta data con código HTML, mientras que todos los códigos estáticos (JS, imágenes, CSS ...) están en carperta static. Algunos sitios web utilizan archivos de construcción específicos en el directorio build, si los hay. build.d contiene los scripts de construcción de python y la plantilla de Genshi, así como el nombre del idioma localizado para cada idioma. La carpeta httpd contiene archivos apache independientes para probar localmente nuestros sitios web. tools es el lugar para el script manual que ejecutamos de vez en cuando. Para actualizar el archivo LINGUAS, o consultar los sitios web ..

i18n

Utilizamos el framework Genshi para la internacionalización. Nuestras plantillas actuales necesitan tener un markup especial alrededor de las cadenas para marcarlas como traducibles.

Hay varias formas de utilizar los markups.

1. ${_('String')}
2. ${Markup(_('String with > html code'))}
3. ${Markup(_('String with a <a href="%s">link</a>') % 'http://fedoraproject.org')}
4. ${_('%(size)s, DVD ISO disc image for %(arch)s-bit PC') % {'size':'3.1 GB', 'arch':'32'}}
5. ${Markup(_('If you think you\'ve found a bug, read <a href="%s">here</a> fist.') % ('http://fedoraproject.org/wiki/Common_F'+global_variables.release['prev_id']+'_bugs'))}

Primero tienes el ejemplo más sencillo. Luego, el markup que podría usarse en todas partes (funciona con código html incorporado, no como el primero). Entonces, tienes un ejemplo usando una variable. Eso es realmente útil para evitar que los traductores vuelvan a traducir la cadena al cambiar la variable. El último ejemplo es el más completo que le muestra cómo lidiar con múltiples variables. El traductor podrá cambiar el orden de las variables usando su nombre.

Para probar que no hace falta nada (por ejemplo, necesita evitar la simple comillas de la cadena), intente con make en test para construir el sitio web para el idioma en.

Una vez que sea correcto, debe generar el nuevo archivo de plantilla de traducción (POT) con code>make pot.

For general information about Genshi templates, see:

• http://genshi.edgewall.org/wiki/Documentation, and in particular,
• http://genshi.edgewall.org/wiki/Documentation/xml-templates.html

Variables

As described in the examples above, you will note there are a lot of variables instead of hard codes. These variables have been set to make it easier to update our webpages. When merging from one branch to the next, i.e. from beta to final release, all the content of our pages can be updated by editing simply one single file, where all the variables are defined.
This file actually is used in the sites of fedoraproject.org and in spins.fedoraproject.org and is located in ~/build.d/globalvar.py

l10n

All POs are download twice a day. Any error should be reported to our tracking system. We download only the files translated at least at 10%. Please note that you won't be able to proofread only if you didn't get so far. This value is in the Makefile.in for the local test and in puppet/syncTranslation.sh for the online websites.

Whenever the HTML content change, we need to update the POT as explained on the previous section. Then, we need to push this POT to the translation platform, zanata.org. This is done by the command make pushpot. But only the maintainers of the fedora-web release are able to push a new POT. Ask them if you need to do so opening a new ticket or ask directly on IRC.

In order to know if the builder is actually pulling the translations in a specific branch/website, check on the repo if a file named PO_FREEZE exists on the website folder. This could be used while editing the Transifex POT without overriding the existing translations on production.

Adding a new language is done through 4 steps:

1. first, create it at zanata.org by uploading a new translation on the website.
2. Then, update the translations.ini file accordingly for local builds
3. update the LINGUAS file (tools/l10N_update.sh might be of help) - for local builds
4. update the local httpd/conf/language.conf file (by running make en test for example) and ask to make this change in the infra (puppet). That is probably needed as we have the same exact copy of this file there. File a ticket for that on our Trac.

Joining/helping

Please read the Websites/Join and How to fix bugs pages.

Actual used branches for each (sub)domain

All our websites in production now are built against master branch. This makes it much easier for contributors to push their commits to the right branch. Staging websites on the other hand are built against the actual developing release-state branch: this could be alpha or beta, but in some cases can also be a specific branch. In fact we use the staging (stg) branch for specific enhancements, this allows us to keep the alpha or beta branch clean.
The new workflow means we will merge every single development branch to master at D-day, as production sites are built only against master branch.
This overview should help you to understand which git-branch is used to build a single subdomain or domain.

Domain	Branch
getfedora.org	master
spins.fedoraproject.org	master
labs.fedoraproject.org	master
arm.fedoraproject.org	master
stg.getfedora.org	f24-beta
spins.stg.fedoraproject.org	f24-beta
labs.stg.fedoraproject.org	f24-beta
arm.stg.fedoraproject.org	f24-beta
fudcon.fedoraproject.org	master
boot.fedoraproject.org	master
fedoracommunity.org	master
fadorahosted.org	master
fedorapeople.org	master
flocktofedora.org	master
start.fedoraproject.org	master