From Fedora Project Wiki

< Websites‎ | workflow

Revision as of 04:46, 8 October 2018 by Davisclick (talk | contribs) (Minor change)



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 &gt; html code'))}
  3. ${Markup(_('String with a &lt;a href="%s"&gt;link&lt;/a&gt;') % '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:

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.

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.

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