Websites/workflow/es

Click here to set up this language box

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.

Para información general sobre las plantillas de Genshi, vea:

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

Variables

Como se describe en los ejemplos anteriores, notará que hay muchas variables en lugar de codificación. Estas variables se han configurado para facilitar la actualización de nuestras páginas web. Cuando se fusiona de una rama a la siguiente, es decir, de la versión beta a la versión final, se puede actualizar todo el contenido de nuestras páginas mediante la edición de un solo archivo, donde se definen todas las variables.
Este archivo se usa en realidad en los sitios fedoraproject.org y en spins.fedoraproject.org y se encuentra en ~/build.d/globalvar.py

l10n

Todas las archivos POs se descargan dos veces al día. Cualquier error debe informarse a nuestro sistema de rastreo. Descargamos solo los archivos traducidos al menos al 10%. Tenga en cuenta que no podrá realizar la revisión solo si no ha llegado tan lejos. Este valor se encuentra en Makefile.in para la prueba local y en puppet/ yncTranslation.sh para los sitios web en línea.

Siempre que cambie el contenido HTML, debemos actualizar el POT como se explica en la sección anterior. Luego, debemos enviar este POT a la plataforma de traducción, zanata.org. Esto se hace con el comando make pushpot. Pero solo los mantenedores de la versión fedora-web pueden subir un nuevo POT. Pregúnteles si necesita hacerlo abriendo un nuevo boleto o pregunte directamente en IRC.

Para saber si el builder está realmente realizando las traducciones en una rama/sitio web específico, verifique en repo si un archivo llamado PO_FREEZE existe en la carpeta del sitio web. Esto podría usarse mientras se edita el POT Transifex sin anular las traducciones existentes en producción.

La adición de un nuevo idioma se realiza a través de 4 pasos:

1. primero, créelo en zanata.org cargando una nueva traducción en el sitio web.
2. Luego, actualice el archivo translations.ini para las compilaciones locales.
3. Actualice el archivo LINGUAS (tools/l10N_update.sh puede ser de ayuda) - para builds locales.
4. Actualice el archivo local httpd/conf/language.conf (ejecutando make en test por ejemplo) y solicite hacer este cambio en la infraestructura (puppet). Probablemente sea necesario ya que tenemos la misma copia exacta de este archivo allí. Presente un ticket para eso en nuestro Trac.

Unirse / Colaborar

Por favor, lea las páginas Websites/Join y Cómo corregir errores.

Ramas reales utilizadas para cada (sub) dominio

Todos nuestros sitios web en producción ahora están construidos contra la rama maestra. Esto hace que sea mucho más fácil para los contribuyentes enviar sus cambios a la rama correcta. Por otra parte, los sitios web de Staging se construyen contra la rama de release-state en desarrollo real: esto podría ser alfa o beta, pero en algunos casos también puede ser una rama específica. De hecho, usamos la rama de staging (stg) para mejoras específicas, esto nos permite mantener la rama alfa o beta limpia.
El nuevo flujo de trabajo significa que haremos merge de cada rama de desarrollo a la rama master de día D, ya que los sitios de producción se crean solo contra la rama maestra.
Esta descripción general debe ayudarlo a comprender qué rama de git se usa para crear un solo subdominio o dominio.

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