pages/01.home/home.es.md

@@ -10,11 +10,14 @@ content:
     pagination: true
 ---
 
-### Bienvenidxs al sitio de Guías y Tutoriales de Disroot.
+### Les damos la bienvenida al sitio de Guías y Tutoriales de Disroot.
 
-El objetivo principal de este sitio es orientarte a través de los varios servicios de **Disroot**.
+El objetivo principal de este sitio es orientarles a través de los varios servicios de **Disroot**.
 
-Cubrir todos los servicios, con todas las características provistas por **Disroot**, para todas las plataformas y/o Sistemas Operativos es un proyecto muy ambicioso, que demanda mucho tiempo y requiere mucho trabajo. Y como pensamos que puede ser beneficioso no solo para nuestrxs usuarixs (disrooters) sino para todas las comunidades de **Software Libre** y de **Código Abierto** que use los mismos programas o similares, toda ayuda de lxs disrooters es siempre necesaria y bienvenida.<br>
-Así que, si piensas que falta un tutorial, que la información no es correcta o puede mejorarse, por favor, contáctanos o (mejor aún) empieza a escribir una guía o tutorial tú mismx.<br>
+Aspiramos a cubrir todos los servicios, con todas las características provistas por **Disroot**, para todas las plataformas y/o Sistemas Operativos así como también para el mayor número posible de clientes de los dispositivos más ampliamente utilizados.
 
-Para conocer las diferentes maneras en que puedes contribuir, por favor, revisa esta [sección](/contribute).
+Es un proyecto muy ambicioso, que demanda mucho tiempo y requiere mucho trabajo. Pero como pensamos que puede ser beneficioso no solo para las personas usuarias de nuestros servicios (disrooters) sino para todas las comunidades de **Software Libre** y de **Código Abierto** que utilicen los mismos programas o similares, también pensamos que vale la pena. Por esto, cualquier ayuda es siempre necesaria y bienvenida.
+
+Así que, si piensan que falta un tutorial, que la información no es correcta o puede mejorarse, por favor, contáctennos o (mejor aún) comiencen ustedes también a escribir una guía o tutorial.
+
+Para conocer las diferentes maneras en que pueden contribuir, por favor, revisen esta [sección](/contribute).

pages/04.Contribute/01.procedure/docs.es.md

@@ -14,7 +14,7 @@ page-toc:
 ---
 
 # Procedimientos Howto: ¿Qué significa?
-La posibilidad de escribir un tutorial y hacerlo accesible para todxs en sus propios idiomas es fundamental no solo para fomentar y promover el uso de software libre y de código abierto sino también pensamientos y acciones colectivas. Así que coordinar la cantidad de información a ser escrita y traducida es una tarea importante, por lo tanto desarrollamos una serie básica de pasos a seguir para que nos ayude a lograrlo.
+La posibilidad de escribir un tutorial y hacerlo accesible para todas las personas, en sus propios idiomas, es fundamental no solo para fomentar y promover el uso de software libre y de código abierto sino también pensamientos y acciones colectivas. Así que coordinar la cantidad de información a ser escrita y traducida es una tarea importante, por lo tanto desarrollamos una serie básica de pasos a seguir para que nos ayude a lograrlo.
 
 El procedimiento es bastante simple:
 1. obtenemos una copia de los archivos sobre los que vamos a trabajar;
@@ -30,7 +30,7 @@ Elegimos **Git** por varias razones, la principal es la estructura y el lenguaje
 
 Muy bien, repasemos nuestras herramientas:
 
-1. **Git**: Si eres usuarix de **GNU/Linux** es altamente probable que ya lo tengas instalado (puedes chequearlo en tu gestor de software o a través de la terminal con el comando `which git`). Si estás usando **Microsoft Windows** o **Mac OS**, puedes descargarlo desde [aquí](https://git-scm.com/downloads).
+1. **Git**: Si eres una persona usuaria de **GNU/Linux** es altamente probable que ya lo tengas instalado (puedes chequearlo en tu gestor de software o a través de la terminal con el comando `which git`). Si estás usando **Microsoft Windows** o **Mac OS**, puedes descargarlo desde [aquí](https://git-scm.com/downloads).
 
 2. **Un editor de texto**: Aunque hay muchos de ellos, sugerimos utilizar uno con soporte para el formato **Markdown** e integración con **Git**. Los editores **Kate**, **Atom** y **VSCodium**, cumplen con este criterio de forma nativa, y también son programas multiplataforma con licencias libres y de código abierto. Pero, **por razones prácticas, solo veremos cómo trabajar en Atom** (en el futuro incluiremos otras herramientas).
 

pages/04.Contribute/02.git/01.editors/01.atom/01.interface/docs.es.md

@@ -0,0 +1,64 @@
+---
+title: Interfaz
+published: true
+visible: true
+updated:
+        last_modified: "Enero 2022"
+        app: Atom Text Editor
+        app_version: 1.58.0
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - atom
+        - git
+page-toc:
+    active: true
+---
+
+# Familiarizándonos con Atom
+Comencemos por conocer un poco la interfaz. Una vez que hayamos iniciado Atom veremos que es bastante directo.
+
+![](en/atom_01.png)
+
+Lo primero que necesitamos hacer es abrir la carpeta del proyecto Howto que acabamos de clonar. Para esto podemos ir al **menú Archivos** --> **Abrir carpeta** y seleccionar el directorio, o directamente con el botón **Agregar carpetas** que está a la izquierda.
+
+![](en/atom_interface.png)
+
+En el panel izquierdo está el árbol de navegación del proyecto y la ventana principal es el editor donde editaremos los archivos.
+
+![](en/navigation.gif)
+
+En la parte de abajo está la "barra de estado" que muestra, a la izquierda, la ruta del archivo en el que estamos trabajando, y, a la derecha, información relativa al lenguaje del código, la rama actual, algunos menús de acciones de Git y el número de archivos que hemos modificado.
+
+![](en/status.bar.png)
+
+Haciendo clic en el botón **Git** en el lado derecho de la barra de estado se mostrará el panel de Git donde podemos ver todos los archivos que hemos modificado así como también algunas operaciones de Git que podemos realizar (y eso lo veremos a continuación).
+
+![](en/git.panel.gif)
+
+También podemos contraer los paneles si necesitamos enfocarnos solo en el editor.
+
+![](en/panels.gif)
+
+Podemos activar la **vista previa Markdown** para tener una idea visual de lo que estamos haciendo sobre un archivo presionando las teclas `Ctrl` + `Shift` + `m`...
+
+![](en/preview.gif)
+
+... y podemos abrir y trabajar sobre múltiples archivos en pestañas o dividiendo la pantalla en varios paneles.
+
+![](en/splitted.panels.png)
+
+**Atom** es altamente personalizable, hasta el punto que podemos modificar prácticamente todas y cada una de sus partes para que se ajuste mejor a nuestras necesidades.
+
+Las últimas dos cosas para notar antes de comenzar a trabajar son:
+
+- Los archivos con modificaciones locales no guardados son marcados con un punto azul (dependiendo del tema que estemos usando).
+
+![](en/unsaved.png)
+
+- Para salvar los cambios podemos usar el **menú Archivos** --> **Guardar** o el atajo 
+de teclado `Ctrl` + `s`.
+
+Ahora que conocemos nuestro espacio de trabajo, es momento de ponernos a trabajar.

pages/04.Contribute/02.git/01.editors/01.atom/02.working/docs.es.md

@@ -0,0 +1,203 @@
+---
+title: Trabajando con Atom + Git
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - atom
+        - git
+page-toc:
+    active: true
+---
+
+# Trabajando con Atom + Git
+¡Finalmente llegamos a la parte más interesante! Revisemos lo que hicimos hasta ahora.
+
+Obtuvimos una copia exacta de la carpeta **Howto de Disroot** donde están todos los archivos que podemos ver en línea cuando necesitamos aprender algo acerca de cómo funciona un servicio o cómo configurar un cliente.
+
+Hemos **clonado** el repositorio y lo hicimos utilizando nuestro primer comando Git: `git clone`. El siguiente paso será crear una **rama**.
+
+## Creando ramas
+Cada proyecto Git, el proyecto Howto en este caso, tiene una rama **principal (main)** (o rama "master") que contiene todos los archivos que podemos ver en *producción*. Los cambios que realizamos en esta rama se sincronizan automáticamente con el sitio, y se hacen visibles inmediatamente. Y esa es la razón por la cual agregar cambios a esta rama **principal** está limitado a las personas propietarias del proyecto.
+
+En términos generales, una rama es básicamente un espacio de trabajo independiente creado a partir de la línea principal de desarrollo sobre la cual podemos trabajar y probar cosas sin comprometer el código original.
+
+![](es/ramas.png)
+
+En la imagen de arriba tenemos el contenido del sitio Howto representado por la línea principal (o *main*). Supongamos que queremos traducir uno de sus tutoriales. Creamos una nueva rama (rama 1) y comenzamos a trabajar localmente en ella. Mientras estamos traduciendo, alguien más quiere empezar a escribir una nueva guía así que crea una nueva rama (rama 2) con ese propósito. Como podemos ver, todo esto sucede en paralelo y al mismo tiempo pero sin afectar a la rama principal.
+
+Cuando una traducción está terminada, es "enviada" al repositorio remoto para ser revisada e integrada a la línea de producción. Mientras tanto, la escritura de la nueva guía continúa y cuando está lista sigue el mismo proceso, es revisada, actualizada con los cambios introducidos por las otras ramas si es necesario y finalmente también es integrada a la principal.
+
+Muy bien. Creemos nuestra rama así podemos comenzar a trabajar.
+
+En la esquina inferior derecha de **Atom**, hacemos clic en **main** o **master** (o cualquier otro nombre de rama) y elegimos **Nueva rama**. Una buena práctica es darle un nombre suficientemente descriptivo para que otras personas puedan darse cuenta fácilmente en qué estamos trabajando cuando la vean. Por ejemplo, si planeamos traducir la guía de Nextcloud, podríamos llamarla "cloud_spanish_translation" o algo parecido.
+
+Una vez hecho eso, presionamos **Enter** en nuestro teclado.
+
+![](en/atom-branch1.gif)
+
+En la terminal, deberíamos utilizar el comando `git branch` como sigue:
+
+`git branch -b nombre.de.nuestra.rama`
+
+Para cambiar entre ramas podemos también usar este menú. Nuestra rama de trabajo actual es visible en la barra inferior. Si hacemos clic en ella aparecerán otras ramas locales.
+
+![](en/atom-branch2.gif)
+
+Cambiar entre ramas en la terminal se hace con el comando `git checkout`. Si, por ejemplo, queremos cambiar de nuestra rama actual a la principal, deberíamos escribir:
+
+`git checkout main`
+
+Y viceversa, de la rama principal a la nuestra:
+
+`git checkout nombre.de.nuestra.rama`
+
+### Publicando nuestra rama
+Hemos creado una rama local y podemos comenzar a traducir o escribir una guía. Para que esta rama que acabamos de crear también exista en el repositorio remoto necesitamos **publicarla**. En Atom esto se hace usando la función **Publicar**. Cuando hacemos clic en ella, se nos pedirá ingresar nuestras credenciales. Necesitamos escribir nuestro nombre de usuaria o usuario y contraseña de Gitea.
+
+![](en/publish.png)
+
+En la terminal esto puede hacerse con el comando `git push`. En nuestro caso sería:
+
+`git push origin nombre.de.nuestra.rama`
+
+Cuando clonamos el repositorio **Howto**, Git automáticamente establece su URL como el "remoto" por defecto llamado `origin`. En Git un "remoto" es un "alias" para un repositorio, así podemos usar este "alias" ("origin" en este caso) en lugar de escribir la URL completa del repositorio remoto cada vez que necesitamos interactuar con él.
+
+Para comprender esto, podemos escribir el comando `git remote -v` para ver los remotos que hemos configurado en nuestro repositorio local y las URLs a las que refieren.
+
+![](en/remote.png)
+
+Ahora que hemos creado una rama y ya la publicamos, podemos crear nuevos archivos y modificar los existentes en esta (nuestra) rama.
+
+## Remitiendo los cambios
+Ahora estamos en nuestra computadora traduciendo un tutorial existente o creando uno nuevo y hemos estado guardando los cambios que hicimos (usando, por ejemplo, `Ctrl`+`s`) pero esos cambios solamente se guardan en nuestro editor. Necesitamos hacer **commit** (remitirlos) a nuestra rama primero para luego hacer "push" (enviarlos) al repositorio remoto.
+
+Así que, lo primero que necesitamos entender es que un **commit** no es como hacer `Ctrl`+`s` porque Git no es "solo un sistema de respaldos". Un **commit** es más como una instantánea de nuestra carpeta de proyecto en un punto determinado. La idea principal detrás de un sistema de control de versiones (Git en este caso) es permitir llevar un registro de todos los cambios realizados a nuestro código a lo largo del tiempo así podemos mirar hacia atrás y verificar cuándo, cómo y por qué se ha "desarrollado". Cada "commit" es, entonces, un "hito" en el historial de registros de nuestro proyecto. Y cada "hito" es acompañado de un mensaje que describe qué ha cambiado. Necesitamos tener en cuenta que cuantos más commits realizamos más se llena la línea de tiempo, aumentando por consiguiente las posibilidades de generar un historial de registros "confuso".
+
+De una manera muy general, podríamos decir que un commit es un conjunto de archivos creados o modificados en nuestra rama local que queremos "enviar" al repositorio Git remoto.
+
+Así que cuando decidimos crear un commit necesitamos "decirle" a Git qué queremos incluir en él.
+
+Hacer un commit de los cambios es un proceso que consiste de los siguientes pasos:
+
+1. Asegurarnos que hemos guardado todos los archivos modificados,
+2. "preparar (stage)" aquellos archivos que queremos remitir,
+3. escribir un "mensaje de commit" descriptivo (un breve y muy específico resumen de lo que ha sido modificado), y finalmente
+4. "remitir", hacer commit de los archivos.
+
+Todos los cambios que hemos realizado hasta ahora en nuestra rama local, fueron hechos en nuestro "directorio de trabajo" y ahora necesitamos "moverlos" al área de preparación ("staging area"). "Staging" refiere al momento en el que esos cambios son seleccionados para ser incluidos en el siguiente commit.
+
+En Atom, este proceso es increíblemente fácil. Revisémoslo de nuevo:
+
+![](en/committing.png)
+
+1. Nos aseguramos que todos los archivos están guardados y hacemos **Stage all** de los archivos que hemos modificado y queremos remitir al repo,
+2. una vez que están en el "staging area" podemos ahora
+3. escribir un **mensaje de commit (commit message)** y finalmente
+4. hacer commit de los cambios (remitirlos) haciendo clic en el botón **Commit**.
+
+![](en/atom-commit.gif)
+
+Ahora veamos cómo hacer lo mismo pero en la terminal.
+
+1. El comando Git para "mover" los archivos desde el "directorio de trabajo" al "staging area" (área de preparación) es `git add` y si solo tenemos un archivo o dos para **agregar (add)** podemos simplemente escribir:
+
+  `git add nuestro.archivo`
+
+  Pero si tenemos varios archivos para hacer commit no necesitamos agregarlos archivo por archivo. Podemos usar
+
+  `git add .`
+
+  y esto incluirá todos los cambios actuales en el siguiente commit.
+
+2. Ahora que los archivos están el "área de preparación" necesitamos remitirlos. Podemos hacerlo utilizando el comando `git commit` con la opción `-m` para escribir un mensaje de commit. Por ejemplo:
+
+  `git commit -m "mi mensaje de commit"`
+
+  Noten que el mensaje de commit debe estar encerrado entre comillas `"` `"`.
+
+  Si no utilizamos la opción `-m` entonces se nos pedirá adjuntar un mensaje en nuestro editor de texto por defecto.
+
+  Otra opción muy útil es `-a`. No solo prepara todos los archivos modificados para el commit sino que también nos evita escribir el comando `git add`. Por ejemplo, podemos escribir:
+
+  `git commit -a -m "mi mensaje de commit"` o
+
+  `git commit -am "mi mensaje de commit"`
+
+Una vez que los archivos están "commiteados" (remitidos), es momento de hacer "**push**" (enviarlos) al repositorio remoto.
+
+## Enviando los cambios
+Hemos commiteado todos los cambios en nuestra rama local y ahora queremos "subirlos", como dijimos, al repositorio remoto.
+
+En Atom esto puede hacerse simplemente haciendo clic en la opción **Push** en la barra inferior.
+
+![](en/atom-push.gif)
+
+En la terminal, ya hemos visto el comando para esto: `git push`. Así que, para enviar nuestros cambios locales a la rama remota tenemos que escribir:
+
+`git push origin nombre.de.nuestra.rama`
+
+## Solicitando una "fusión"
+
+![](en/git-merge_chaos.gif)
+
+**Fusionar (merge)** es el proceso de integrar los commits de diferentes ramas. Habitualmente (pero no siempre) los commits hechos en una rama determinada en la principal.
+
+Una vez que pensamos que nuestro trabajo está terminado y listo para ser publicado en el sitio web, es el momento de fusionarlos en la **rama principal (main)**.
+
+Esta operación de fusión es realizada por los admins de **Disroot**. Pero es tarea nuestra solicitar que se haga.
+
+En **Gitea** se llama **Pull Request** y el procedimiento, en principio, es bastante simple.
+
+1. Vamos al sitio **Git de Disroot** en [**git.disroot.org**](https://git.disroot.org) y accedemos con nuestras credenciales de **Gitea**.
+
+2. A continuación necesitamos buscar nuestra rama en el repositorio **Howto**, seleccionarla y luego hacer clic en el botón **New Pull Request**.
+
+![](en/pull.request.gif)
+
+3. En la siguiente página podemos hacer una última y más visual revisión de los commits que hemos hecho y, si nos parece que está bien, entonces presionar de nuevo el botón **New Pull Request**.
+
+![](en/pull.request.2.png)
+
+4. Ahora se nos solicita escribir un mensaje de "solicitud de fusión (merge request)". No necesita ser largo y detallado pero sí descriptivo, parecido al mensaje de commit, para que a otras personas les resulte sencillo saber el por qué de los cambios. También podemos (y es recomendado) agregar etiquetas para una mejor identificación.
+
+![](en/pull.request.3.png)
+
+5. En el último paso podemos asignar "Revisores", agregar "Etiquetas" (si no los hicimos previamente), vincular nuestro "Pull Request" a un "Hito" o a un "Proyecto" y definir quién será asignado para gestionar la solicitud (usualmente, los mismos admins de **Disroot** con quienes hemos estado en contacto en la sala XMPP de Howto).
+
+![](en/pull.request.4.png)
+
+Eso es todo. \O/
+
+Una vez que el Pull Request está hecho, será revisado por los admins de **Disroot**. Si todo está bien y la documentación cumple con los lineamientos de **Disroot**, pueden entonces aprobar nuestros commits. Esto significa que nuestros cambios serán fusionados con la rama principal y por lo tanto visibles en el sitio web.
+
+Si hay algún inconveniente, los admins podrían solicitarnos corregir algo. Y, de nuevo, una vez que las correcciones son realizadas, nuestro Pull Request será fusionado a la rama principal.
+
+## Descargando cambios del repositorio
+"**Pull** (traer, jalar)" es una operación para actualizar la versión local de un repositorio remoto.
+
+Si queremos mantener la rama principal local para futuras traducciones o guías, necesitaremos hacer "pull", traer los cambios integrados a la rama remota recientemente actualizada porque la nuestra ya no estará al día con ella.
+
+En Atom solo necesitamos hacer clic en la función **Pull** que está a la derecha en la barra de estado.
+
+![](en/atom-pull.gif)
+
+En la terminal, esto se hace con el comando `git pull`. Así que si todavía estamos en nuestra rama local y queremos "actualizarla" después que se hayan remitido cambios y estos fueran aceptados, necesitamos:
+
+1. Asegurarnos que estamos en la rama principal local o en otra. Podemos usar el comando `git branch`que nos mostrará en qué rama estamos (para cambiar de rama, ya vimos el comando `git checkout` más arriba)
+
+2. Una vez que estamos en la rama principal, escribimos:
+
+  `git pull`
+
+  Esto descargará las modificaciones agregadas a la rama principal remota y actualizará nuestra copia local con ellas.
+
+Ya que siempre hay gente trabajando en el código y este cambia con frecuencia, es altamente recomendable hacer "pull" de la rama main remota a la local nuestra - especialmente antes de comenzar a trabajar en una nueva rama - así podemos ver fácilmente qué hay de nuevo y qué ha cambiado recientemente.
+
+---
+
+Mirar [Solución de problemas](/contribute/git/troubleshooting) para más ayuda y situaciones de conflicto comúnes

pages/04.Contribute/02.git/01.editors/docs.es.md

@@ -0,0 +1,27 @@
+---
+title: "Trabajando con Editores"
+published: true
+visible: true
+indexed: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - git
+        - editores
+        - atom
+page-toc:
+    active: true
+---
+
+# Editores
+La manera más fácil de trabajar y editar los archivos del **Howto** es a través de un editor de texto con Git integrado.
+
+Como mencionamos antes, por razones prácticas, solo veremos cómo hacerlo con el **editor de texto Atom**, aunque pueden elegir utilizar cualquier otro. El funcionamiento es similar en casi todos los casos. Junto a cada paso a seguir en el editor también veremos los comandos de Git en la terminal para aprender y entender qué están haciendo Atom y Git.
+
+Intentaremos agregar más guías sobre el uso de otros editores en el futuro. Si quieren y tienen tiempo, pueden también escribir uno ustedes acerca de sus editores prefereidos y podemos agregarlos a esta sección.
+
+
+## [Atom](atom/interface)

pages/04.Contribute/02.git/02.Troubleshooting/docs.es.md

@@ -0,0 +1,49 @@
+---
+title: Solución de problemas
+subtitle:
+published: true
+visible: true
+indexed: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - git
+        - soluciones
+page-toc:
+    active: true
+---
+
+# Solución de problemas
+<a name="detrás"></a>
+## Contenido
+- [Nuestra rama local está "detrás" de la rama principal remota](#detrás)
+
+---
+
+<a name="detrás"></a>
+## Nuestra rama local está "detrás" de la rama principal remota
+Mientras estamos trabajando en nuestra rama, otras personas posiblemente remitan y fusionen sus propios cambios, especialmente si estamos trabajando en archivos ya existentes. Si esos cambios de las otras personas usuarias ya han sido fusionados a la **rama principal (main)**, la versión de los archivos que modificamos podría no ser ya la actual y por lo tanto los cambios de las otras personas podrían no estar incluidos en nuestros archivos. En ese caso, si queremos que nuestros cambios puedan ser fusionados a la **rama main**, el proceso podría volverse bastante complicado.
+
+Así que necesitamos integrar los cambios realizados en la rama principal remota en la local nuestra **antes** que podamos hacer una **solicitud de fusión**, o **Pull request**. Hacer esto nos ahorrará, y a los admins también, un montón de trabajo innecesario.
+
+En Git hay dos maneras que nos permiten integrar/fusionar/actualizar ramas: **git merge** y **git rebase**.
+
+**Git merge** compara los últimos dos commits y el "ancestro común" entre las ramas que queremos fusionar y crea un nuevo commit con los cambios. Cuando fusionamos una rama con la nuestra, fusionamos el historial de ambas ramas juntas. Si luego hacemos eso de nuevo, comenzaremos a crear una serie de historiales intercalados.
+
+**Git rebase** rastrea uno por uno los commits hechos en una rama y los "replica" en la otra. Esto significa que todos nuestros commits locales aparecerán al final, después de los commits remotos y tendremos un historial más claro. Por esta razón, este es el método preferido.
+
+Es importante notar que el **rebase** es útil **solamente** si lo aplicamos sobre los commits locales que **todavía no han sido "subidos"** a ningún repositorio remoto. Si queremos hacer el "rebase" sobre una rama local cuyos commits ya fueron enviados a la remota, tendremos seguramente un montón de conflictos.
+
+Así que si estamos trabajando en una rama local y queremos integrar a ella los cambios realizados a la rama principal remota necesitaremos hacer "rebase".
+
+Pasos para hacer rebase:
+1. Asegurarnos que todos los cambios están commiteados solo en nuestra rama local.
+2. En la terminal:
+ - cambiar a la **rama principal**: `git checkout main`;
+ - actualizar la **rama principal**: `git pull`;
+ - volver a nuestra rama de trabajo: `git checkout nuestra.rama`;
+ - actualizar nuestra rama de trabajo desde la **rama principal** actualizada: `git rebase main`.
+3. Finalmente, verificar los cambios y hacer commit de estos al repositorio remoto.

pages/04.Contribute/03.styleguide/01.structure/docs.es.md

@@ -0,0 +1,93 @@
+---
+title: 'Estructura general'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - estilo
+page-toc:
+    active: true
+---
+
+# Estructura general
+
+El sitio **Howto** está compuesto de archivos de texto en formato Markdown contenidos en carpetas organizadas jerárquicamente en secciones.
+
+El sitio tiene **tres directorios principales**:
+- **pages**: esta carpeta contiene las páginas y tutoriales. Este es el único contenido que podemos editar y traducir.
+- **themes**: aquí están los archivos y configuraciones que le dan forma al sitio.
+- **vagrant**: esta carpeta contiene los archivos necesarios para ejecutar Vagrant, un programa para crear entornos virtuales.
+
+El único directorio que nos interesa para crear, editar y traducir guías es **pages**.
+
+![](en/structure.png)
+
+Como podemos ver en la imagen de arriba, el directorio **pages** contiene varios otros directorios y subdirectorios.
+
+- **01.home**: aquí está la página de inicio del sitio **Howto**.
+- **02.tutorials**: este el directorio donde todas las guías están alojadas y organizadas por categorías.
+- **03.Glossary**: aquí está la página donde intentamos reunir la mayoría de los términos que utilizamos a través de las guías y tutoriales.
+- **04.Contribute**: en este directorio encontraremos guías sobre cómo crear, editar y traducir las páginas del sitio.
+- **05.Licensing**: la licencia bajo la cual está el contenido del sitio.
+- **06.disroot.org**: el link al sitio de **Disroot**.
+- **archive**: esta carpeta contiene todas las guías que ya no están en línea.
+
+
+# Páginas (pages)
+Hay actualmente dos diferentes plantillas para las páginas del sitio **Howto**:
+
+- **docs.md**: estas son los archivos de texto más comúnes que podemos encontrar dentro del sitio Howto, las páginas que forman las guías.
+
+- **docsparent.md**: estas páginas son utilizadas para indexar todas las **páginas secundarias** que están marcadas como `indexed:true` en sus **cabeceras (headers)**, creando un menú de las páginas relacionadas. Si una imagen es ubicada en la carpeta de una *página secundaria*, una miniatura será mostrada en el índice (el tamaño preferido de la miniatura es de 400x300 píxeles).
+
+## Cabeceras de las páginas (page headers)
+La cabecera de una página es el lugar donde establecemos las variables para una página determinada. Es la parte que aparece arriba del contenido encerrada entre tres guiones `---`.
+
+Debajo hay una lista de las variables más comúnes que pueden ser especificadas en cada cabecera y sus propósitos.
+
+- **title**: "título". Es el nombre de la página y aparecerá en los menús e índices.
+
+- **subtitle**: "subtítulo". Los subtítulos son mostrados como items en las páginas principales.
+
+- **icon**: "ícono". Un ícono de Fork-awesome que se muestra en la página de inicio.
+
+- **visible**: establecido por un valor booleano, *true (verdadero)* o *false (falso)*. Cuando se establece como *false* en las páginas secundarias, estas no aparecerán en el índice.
+
+- **indexed**: "indexado". Establecido por un valor booleano, *true (verdadero)* o *false (falso)*. Las publicaciones configuradas como *true* aparecen en los índices de las páginas principales. También agrega una miniatura, si la hubiera, en los directorios de páginas (el tamaño preferido de la miniatura es de 400x300 píxeles).
+
+- **updated**: "actualizada". Cuando se especifica, se mostrará como "meta información" en la página.
+
+- **published**: "publicada". Establecido por un valor booleano, *true (verdadero)* o *false (falso)*.
+
+- **taxonomy**: "clasificación". Se utiliza para establecer categorías y etiquetas. Las publicaciones con la categoría 'topic' (tópico) aparecen como los tópicos principales en el menú de la página de inicio.
+
+- **page-toc**: "índice de la página". Establecido por un valor booleano, *true (verdadero)* o *false (falso)*. Determina si un índice (*table of content*) es visible o no en una página. Usualmente, se establece como *false* para las páginas principales (docsparent.md).
+
+Para comprender mejor cómo estas variables afectan a las páginas, podemos echar un vistazo a, por ejemplo, la cabecera de la página principal de la **Nube** (02.Cloud/docsparent.en.md):
+
+- _docsparent.md_ en la página de inicio
+
+![](en/docsparent_view.png)
+
+
+- _docs.md_ cabecera y vista en la página principal de la guía sobre la Nube (02.Cloud/docsparent.en.md)
+
+![](en/docs_view.png)
+
+
+## Meta información
+
+La meta información es establecida automáticamente cuando se especifica en la cabecera de una página debajo de la variable `updated:`. Es necesario que las personas usuarias sepan si una guía está actualizada. Los campos a completar son:
+
+`last_modified:` "última modificación". "Mes, Año" encerrados entre comillas `" "`. _(p.ej: "Junio, 2020")_<br>
+`app:` Nombre del programa o servicio. _(p.ej: Nextcloud)_<br>
+`app_version:` Número de versión del programa. _(p.ej: 18)_<br>
+
+### ¿Dónde colocar la meta información?
+Esta información no es necesaria en las páginas principales, sino en  aquellas donde la información pueda variar con las actualizaciones.
+
+![](en/meta.png)

pages/04.Contribute/03.styleguide/02.content/01.information/docs.es.md

@@ -0,0 +1,73 @@
+---
+title: 'Sobre la información'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - estilo
+page-toc:
+    active: true
+---
+
+# Construyendo los lineamientos sobre la información
+
+## Primera pregunta: ¿Sobre qué podemos escribir?
+Esta pregunta ya está parcialmente respondida en la página principal de este sitio:
+> *"Aspiramos a cubrir todos los servicios, con todas las características provistas por **Disroot**, para todas las plataformas y/o Sistemas Operativos así como también para el mayor número posible de clientes de los dispositivos más ampliamente utilizados."*
+
+Así que podemos escribir sobre los programas provistos por **Disroot**, cómo funcionan y que podemos hacer con ellos. Eso parece bastante evidente hasta que nos preguntamos si todas las personas usamos los mismos sistemas operativos en nuestras computadoras o dispositivos móviles.
+
+El hecho de que nuestro foco esté puesto exclusivamente en el uso, fomento y promoción de **software libre y de código abierto** (y por lo tanto nuestras guías están escritas principalmente para GNU/Linux) no debería hacernos olvidar que hay muchas personas que eligen utilizar programas propietarios y su acercamiento a nuestros servicios no está relacionado con razones éticas o políticas sino pragmáticas.
+
+Por eso decimos explícitamente:
+
+> *"para todas las plataformas y/o Sistemas Operativos así como también para el mayor número posible de clientes de los dispositivos más ampliamente utilizados."*
+
+Una lista básica de los principales sistemas operativos que intentamos cubrir sería la siguiente:
+
+- **GNU/Linux**, **Microsoft Windows** y **Apple macOS** en computadoras de escritorio y laptops y
+- **Google Android**, **Apple iOS**, **Jolla Sailfish OS** y **Microsoft Windows Mobile** en dispositivos móviles.
+
+!! **Todas las personas, sin importar el sistema operativo que usen, pueden colaborar escribiendo cómo utilizar un servicio. Recuerden que lo más importante es hacer que la información esté disponible para cualquiera.**
+
+## Segunda pregunta: ¿A quiénes están dirigidas las guías?
+En principio, cualquier persona mayor de 16 años puede utilizar los servicios de **Disroot**. Pero podemos pensar también en el hecho de que todos y todas tenemos, por ejemplo, familiares y gente conocida a las que nos gustaría introducir en el uso de herramientas socialmente éticas y técnicamente útiles o quizás quieran hacerlo ellas mismas.
+
+Así que cuando escribimos una guía debemos pensar que la información debe ser comprensible para cualquiera, independientemente de la edad o conocimientos técnicos. Por supuesto, siempre hay programas que son más complejos que otros, pero eso no debería significar que no hagamos el esfuerzo de intentar que sea posible para cualquier persona aprender a usarlos.
+
+Esto nos lleva a la siguiente pregunta.
+
+## Tercera pregunta: ¿Qué tipo de lenguaje deberíamos utilizar?
+Para poder hacer las guías lo más accesibles posible, no solo para las personas usuarias sino también para quienes nos ayudan a traducirlas, debemos utilizar el Inglés o el Español de la manera menos informal que podamos. Esto significa evitar el uso de jerga técnica, lunfardo, o contracciones lingüísticas (por ejemplo, en Inglés, es preferible escribir "it will not" en lugar de "it won't"). También debemos tener en cuenta que estas guías podrían ser utilizadas o traducidas por otros proyectos que brinden servicios o programas similares y queremos que la tarea de adaptarlas consuma lo menos posible de su tiempo.
+
+En aquellos casos donde el uso de términos técnicos sea inevitable, necesitaremos explicar brevemente qué significan o referir a una fuente externa que lo haga (p.ej., un artículo de la Wikipedia).
+
+Sugerimos que, en la medida de lo posible, se realice la traducción de todos los términos que tengan su equivalente en nuestro idioma. Por ejemplo, la palabra "software" (programa) es de uso común dentro de las comunidades y entre personas de habla hispana vinculadas con la tecnología, pero recordemos que el objetivo es hacer accesible las guías para cualquiera y no debemos asumir que todas las personas saben qué significa.
+
+## Cuarta pregunta: con respecto a las traducciones, ¿deberían ser literales?
+Aunque no existe un solo método específico y efectivo, hay por lo menos dos cosas importantes que deberíamos tener en cuenta cuando hacemos una traducción.
+
+1. **Entender el texto de la guía integralmente**. Antes de comenzar a traducir, es aconsejable leer el texto completo y "capturar" su esencia: "acerca de qué es", "cómo es presentada y/o estructurada la información", "es fácil/difícil de entender", etc. Esto nos ayudará a identificar el contexto de las palabras y expresiones que aparecen en un documento dado y del que depende su significado.
+
+2. **Seguir el texto original es fundamental como también lo es preservar su fuidez**. A veces podemos encontrar palabras o expresiones que son realmente difíciles de traducir a nuestro idioma o incluso intraducibles. Así que necesitamos tener cuidado de no omitirlas o cambiar demasiado sus significados originales porque esto puede afectar el sentido general de una línea, un párrafo o un documento completo. Si tenemos dudas acerca de ciertas adaptaciones siempre podemos consultar o preguntar en la sala de chat de Howto.
+
+Así que la literalidad de una traducción no siempre resulta en un texto coherente. Cuando es necesario realizar adaptaciones de expresiones o palabras, estas deben ser lo más fieles posible al sentido original del documento.
+
+Finalmente, siempre necesitaremos revisar nuestras traducciones antes de enviarlas. Es muy común encontrar pequeños errores recurrentes o inconsistencias, y corregirlas a tiempo evitará que la traducción nos sea devuelta.
+
+## Comentarios sobre las traducciones al español
+Entendemos que el lenguaje no es neutral. En muchos países de habla hispana hay actualmente fuertes cuestionamientos al respecto y acciones concretas para modificar lo que muchas personas entendemos como una situación no representativa de nuestra diversidad como sociedad. Parece cada vez más notorio que la política y el lenguaje avanzan mucho más lentamente que nuestra vida y desarrollo social.
+
+En español, tradicionalmente, las palabras se clasifican en dos géneros gramaticales: el femenino y el masculino, este último además cumple la función de representar lo genérico, o "neutro". Esta doble función, y su uso culturalmente extendido, del "masculino genérico" ha generado no pocos y muy interesantes y encendidos debates en diferentes ámbitos sociales que han ido creciendo a medida que las personas no binarias (aquellas que no se identifican o no se perciben como de género femenino o masculino) han ido ganando visibilidad y representación. También presenta un desafío para quienes asumimos la responsabilidad de escribir y traducir documentación. En ese sentido, nuestra posición como proyecto es clara: no podemos admitir el uso de formas del lenguaje que excluyan a nadie.
+
+Tampoco podemos obligar a nadie a escribir de tal o cual manera, pero es necesario hacer algunas aclaraciones y comentarios respecto a la documentación y las prácticas lingüísticas que decidimos mantener.
+
+Existen, básicamente, dos maneras de encarar el problema de la binariedad en nuestra lengua. Una es de tipo indirecta, que implica emplear estrategias lingüísticas y gramaticales que no denoten un género específico. Tomemos como ejemplo, la palabra inglesa "user". La forma indirecta del lenguaje no binario la traducirá como "la usuaria y/o usuario" o como "la persona usuaria". La forma directa del lenguaje no binario introduce el uso de neologismos y los llamados "neomorfemas" como la "e" o la "x". Siguiendo con el ejemplo de la palabra "user", su traducción sería, con este método directo, "le usuarie".
+
+Admitimos cualquiera de las dos maneras, tanto para la traducción como para la creación de documentación. En el caso de la forma directa, sugerimos no utilizar el morfema "x" puesto que genera dificultades para las personas ciegas o con baja visión que utilizan lectores de texto.
+
+Adicional y finalmente, es aconsejable tener presente que las guías en Inglés están escritas en el plural de segunda persona (you = ustedes / vosotres) y en el plural de la primera persona (we = nosotras/nosotres/nosotros).

pages/04.Contribute/03.styleguide/02.content/02.visuals/docs.es.md

@@ -0,0 +1,323 @@
+---
+title: 'Sobre el contenido visual'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - estilo
+page-toc:
+    active: true
+---
+
+# Lineamientos sobre el contenido visual
+
+Al igual que con la información, cuando incluimos contenido visual debemos seguir algún criterio de manera que una guía sea, sobre todo, didáctica y útil. Tengamos en cuenta que a veces demasiadas imágenes pueden hacer perder el foco sobre la información y resultar en un documento más bien confuso. Sin mencionar que esto puede incrementar innecesariamente el tiempo de carga de la página.
+
+Así que lo primero que necesitamos hacer es evaluar cuáles son las ayudas visuales básicas que requieren ser incluidas. Por ejemplo, para encontrar un menú o una configuración, para describir acciones, como ejecutarlas o comparar los efectos de su aplicación.
+
+
+# Criterio general
+En téminos generales, el contenido visual de una guía debería, entonces, seguir los siguiente criterios:
+
+1. **Uso de ayudas visuales** _(cuando sea posible)_ **como**:
+    - Capturas de pantalla
+    - Imágenes GIF / videos del escritorio o dispositivo móvil
+
+* Programas recomendados:
+ - [**Peek**](https://github.com/phw/peek): grabador de GIFs animados (Para escritorios)
+ - [**ScreenCam**](https://f-droid.org/en/packages/com.orpheusdroid.screenrecorder/): capturador de pantalla (Para móviles)
+ - [**scrcpy**](https://github.com/Genymobile/scrcpy): grabador de pantalla de móviles (Para escritorios)
+
+2. **Fáciles de adaptar para otros proyectos**: Para ello, las menciones a **Disroot** y otros identificadores únicos del **Proyecto Disroot**, deberían mantenerse en el mínimo necesario y el contenido lo más génerico y sin adjetivos posible. De esta manera, resulta más sencillo para otros proyectos utilizar, adaptar y editar las guías.
+
+3. **Texto del contenido conciso**: Escribir solamente lo que es necesario para explicar una tarea o una característica y advertir sobre información importante que las personas usuarias debería saber, por ejemplo utilizando "avisos" (ver más abajo).
+
+4. **Evitar párrafos de texto muy largos**
+
+5. **Utilizar viñetas en lugar de grandes párrafos cuando se describen varios pasos o características**
+
+6. **Evitar el uso de tablas, a menos que su propósito sea otro que el dar formato al texto.**
+
+## Utilizando "Avisos":
+Los "Avisos" son pequeñas piezas de texto que podemos usar para resaltar información importante, por ejemplo para enfatizar algo que las personas usuarias deberían tener en cuenta o estar al tanto cuando configuran algo o antes de realizar una acción.
+
+Para dar formato a un aviso necesitamos comenzar el texto que queremos resaltar con dos signos de exclamación `!!`.
+
+Por ejemplo:
+el siguiente "aviso"
+
+```
+!! **¡AVISO!** este es un ejemplo de información importante.
+```
+
+se verá así:
+
+!! **¡AVISO!** este es un ejemplo de información importante.
+
+
+---
+
+# Markdown: algunas sugerencias de formato
+
+El sitio de las guías y manuales de **Disroot** está construido con [Grav](https://getgrav.org/) (un gestor de contenidos que no requiere bases de datos), y utiliza **Markdown** como lenguaje de marcado/formato de texto porque es muy liviano y su sintaxis es fácil de aprender.
+
+Aquí abajo encontrarán algunas sugerencias acerca del formateo de texto de un tutorial y ejemplos de la sintaxis.
+
+## Títulos
+
+Además del título de la página, que está en su cabecera, podemos componer los correspondientes a cada sección de una guía, utilizando el signo `#` (almohadilla o numeral) seguido de un espacio antes del texto que queremos usar como título. Por ejemplo:
+
+Escribiendo...
+```
+# Título 1
+
+## Título 2
+
+### Título 3
+
+#### Título 4
+
+##### Título 5
+```
+...veremos lo siguiente:
+
+# Título 1
+
+## Título 2
+
+### Título 3
+
+#### Título 4
+
+##### Título 5
+
+
+Cuantos más signos `#` utilicemos más pequeño será el título.
+
+Los títulos son importantes por varias razones. Una de las principales es que Grav los utiliza para generar automáticamente el índice de una página. Por lo que pueden usarse para mostrar diferentes capítulos / secciones de una guía en la parte superior de una página.
+
+Los títulos más pequeños aparecen como "sub secciones" en el índice. 
+
+Recomendamos el uso de un signo `#` para el título principal de una página y dos (`##`) para los capítulos o sub secciones. Podemos también utilizar tres (`###`) para titular encabezados menores dentro del texto que preferimos que estén en el índice o incluso más pequeños para encabezados que no necesitamos que aparezcan en él.
+
+
+## Listas
+
+Para listar pasos o características en una guía, utilizamos las "listas".
+
+Las listas son formatos de viñetas muy simples de utilizar. Por ejemplo:
+
+El código de la siguiente lista
+~~~
+Mi lista:
+- Elemento 1
+    1. sub item 1
+    2. sub item 2
+- Elemento 2
+~~~
+...se mostrará así:
+
+Mi lista:
+- Elemento 1
+    1. sub item 1
+    2. sub item 2
+- Elemento 2
+
+Para crear estas listas podemos utilizar `*` (asteriscos), `-` (guiones) o `+` (signos de suma).
+
+Ejemplo de código de una lista "desordenada":
+```
+Lista 2:
+* Elemento 1
+- Elemento 2
++ Elemento 3
+```
+que se verá así:
+
+Lista 2:
+* Elemento 1
+- Elemento 2
++ Elemento 3
+
+Para generar una lista "anidada" (una lista contenida dentro de otra), solo tendremos que agregar cuatro espacios antes del elemento que queremos anidar. Como en el primer ejemplo:
+
+el resultado de escribir  
+~~~
+Mi lista anidada:
+- Elemento 1
+    * sub item 1
+    - sub item 2
+- Elemento 2
+~~~
+
+será:
+
+Mi lista anidada:
+- Elemento 1
+    * sub item 1
+    - sub item 2
+- Elemento 2
+
+
+## Negrita
+
+Utilizamos las negritas para resaltar:
+
+- Información importante
+- Avisos o sugerencias a las personas usuarias
+- O para títulos pequeños dentro de una sección que no es necesario que esté listada en el índice.
+
+Para resaltar una palabra o una línea con negritas, solo necesitamos insertar dos `*` (asteriscos) o dos `_` (guiones bajos) antes y después de lo que queremos marcar. Por ejemplo:
+
+`**Ejemplo de negritas**` o `"Ejemplo de resaltado con __negritas__"`
+
+se verá de la siguiente manera:
+
+**Ejemplo de negritas** o "Ejemplo de resaltado con __negritas__"
+
+
+## Cursiva
+
+La _cursiva_ funciona de manera similar a la **negrita**. Podemos usar un `_` (guión bajo) o un `*` (asterisco) antes y después de la palabra, línea o sección del texto sobre el que queremos aplicarla. Ejemplo:
+
+Si escribimos:
+
+`Este es un ejemplo de _cursiva_ (o *itálica*)`
+
+se verá así:
+
+Este es un ejemplo de _cursiva_ (o *itálica*)
+
+## Código
+
+Si necesitamos escribir un comando que estamos explicando o una línea de código y no queremos que se vea afectada por el formato de texto general, podemos insertar un símbolo ` (tilde grave o invertida) delante y al final de aquellas palabras que deseamos resaltar.
+
+Un ejemplo sería:  
+~~~
+Este es un ejemplo de `código`
+~~~
+
+que se verá:
+
+Este es un ejemplo de `código`
+
+Si queremos aplicarlo a un bloque entero de código, simplemente encerramos el párrafo entre dos líneas de tres símbolos **`** o tres **~** (virgulilla).
+
+Escribiendo  
+```
+~~~  
+En este ejemplo, podemos observar cómo afecta  
+la aplicación de código de bloque  
+a un párrafo completo  
+~~~
+```
+
+obtendremos:  
+~~~  
+En este ejemplo, podemos observar cómo afecta  
+la aplicación de código de bloque  
+a un párrafo completo  
+~~~
+
+
+## Vínculos
+
+A veces necesitaremos insertar vínculos (links) a otras páginas o sitios web. Para hacerlo escribimos, por ejemplo:
+
+`Este es un [vínculo al sitio de Disroot](disroot.org)`
+
+que será mostrado como:
+
+Este es un [vínculo al sitio de Disroot](disroot.org)
+
+
+## Insertando imágenes / videos en una guía
+
+Para insertar una imagen o incrustar un video debemos:
+
+- Primero: crear una carpeta donde estarán los archivos a insertar.  
+*Por lo general, estas carpetas se nombran según el idioma del tutorial. Por ejemplo, si estamos traduciendo o escribiendo una guía en español, la carpeta se denominará* `es`.
+
+- Segundo: es recomendable o bien nombrar los archivos según el orden en que aparecerán a lo largo del tutorial o de manera tal que sea fácil para cualquiera darse cuenta a qué parte del documento están vinculados.
+
+Luego creamos un vínculo con la ruta a la carpeta y el nombre del archivo en cuestión.
+
+En el siguiente ejemplo, insertaremos un archivo de imagen llamado `boton.png` que se encuentra en la carpeta `es` dentro del directorio de esta misma guía.
+
+Si escribimos
+
+`![](es/boton.png)`
+
+veremos:
+
+![](es/boton.png)
+
+También podemos insertar un archivo dentro de la misma línea escribiendo
+
+`Texto antes de la imagen ![](es/boton.png) texto después`
+
+para que se vea así:
+
+Texto antes de la imagen ![](es/boton.png) texto después.
+
+El código descrito para insertar imágenes funciona de la misma manera para los archivos gifs y videos .mp4.
+
+
+# Términos
+
+Para hacer los tutoriales más coherentes y sencillos de adaptar para otros grupos o proyectos, recomendamos utilizar el siguiente criterio:
+
+- Cuando escribimos una guía, el nombre **Disroot** debe comenzar con la primera letra mayúscula y en **negritas**.
+
+- Y los diferentes servicios deben ser referidos de acuerdo a lo que sigue:
+
+|Servicio|Nombre de Disroot|
+|-:|:-|
+|Lufi|**Subida de Disroot**|
+|Foro/Discourse|**Foro de Disroot**|
+|Etherpad|**Blocs de Disroot**|
+|XMPP|**Chat de Disroot**|
+|Servicios de correo en general|**Correo de Disroot**|
+|Roundcube|**Webmail de Disroot**|
+|Private Bin|**Bin de Disroot**|
+|Nextcloud:|**Nube de Disroot**|
+|Nextcloud Calendario|**Calendario de Disroot**|
+|Nextcloud Notas|**Notas de Disroot**|
+|Nextcloud Contactos|**Contactos de Disroot**|
+
+De esta manera, si las expresiones son regulares, es más fácil hacer simplemente un "*Buscar y remplazar*" ;)
+
+
+# Video-tutorial
+
+Para los video tutoriales también pensamos que el contenido debería **mantenerse al mínimo** y ser suficientemente **corto** para que las personas usuarias puedan completar una tarea y por el bien de su propia claridad.
+
+Al igual que las guías de texto, los video tutoriales deberían tener la siguiente estructura:
+
+1. **Meta información**
+2. **Contenido**
+3. **Información sobre la Licencia**
+
+## Descripción del contenido
+
+En la medida de lo posible, los videos deberían ir con:
+
+- Título de la guía
+- Breve descripción acerca de qué trata
+- La versión del programa al que se refiere
+
+Esta información, al igual que la **meta información** y **la información sobre la Licencia** serán colocadas por los admins de **Disroot** en la descripción del video en la instancia de Peertube donde estos estarán alojados.
+
+## Licencia de los video tutoriales
+
+Aunque, como ya se mencionó, la informción sobre la licencia será colocada por los admins de **Disroot**, recomendamos ubicar la siguiente imagen al final de los video por alrededor de 10 segundos con un efecto de fundido de entrada y de salida.
+
+![](en/licensing-pic.png)
+
+De esta forma, si el video es descargado y resubido en otro lado, la información de la licencia permanecerá allí.
+
+---

pages/04.Contribute/03.styleguide/02.content/docs.es.md

@@ -0,0 +1,21 @@
+---
+title: 'Lineamientos sobre el Contenido'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - estilo
+page-toc:
+    active: true
+---
+
+# Lineamientos sobre el Contenido
+Hay muchas maneras de escribir o traducir una guía, sin duda. Y si buscamos en la Internet, encontraremos toda clase de estilos: desde muy técnicas a algunas muy divertidas, pasando por algunas bastante aburridas, algunas visualmente impresionantes y otras ciertamente espartanas en más de un aspecto. Pero todas tienen una cosa en común: **la información**. Esa es nuestra materia prima.
+
+El **Proyecto Howto** se trata de brindar información, pero no cualquier información, sino aquella que es útil acerca de los programas y servicios disponibles en la plataforma **Disroot** de la manera más clara y accesible que podamos. Pero, ¿cómo lograr esto?
+
+Bueno, podemos hacernos algunas preguntas y ver si podemos construir en conjunto algunas definiciones que nos guíen en la tarea.

pages/04.Contribute/03.styleguide/docs.es.md

@@ -0,0 +1,29 @@
+---
+title: 'Lineamientos generales'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - estilo
+page-toc:
+    active: true
+---
+
+# Guías de Estilo
+
+![](h2_guide.jpg)
+
+El propósito de esta sección es brindar algunos lineamientos generales para tener en cuenta cuando escribimos o traducimos un tutorial para el **[sitio How-to](https://howto.disroot.org) de Disroot** y de esa manera mantener una cierta coherencia en la estructura de la documentación, tanto visual como en términos de escritura.
+
+
+---
+# Contenidos
+- ### [Estructura](structure)
+Directorios y páginas
+
+- ### [Contenido](content)
+Escritura, traducción y contenido visual

pages/04.Contribute/docs.es.md

@@ -0,0 +1,35 @@
+---
+title: Cómo contribuir
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+page-toc:
+    active: false
+---
+
+# Contribuir
+
+![](contribute.jpg)
+
+Pensamos que el conocimiento es una construcción colectiva: el resultado del trabajo en conjunto y cooperativamente, como una comunidad. Y ya sea que las contribuciones tomen la forma de una donación, escribiendo/traduciendo un tutorial o reportando errores, todas son esencialmente tiempo personal dedicado a otras personas. Un poco como el amor.
+
+El principal objetivo de esta parte del proyecto **Disroot** es proveer información clara y accesible acerca de cómo utilizar y configurar los servicios que ofrecemos y, además, hacerlo en la mayor cantidad de idiomas posible. Consiste mayormente de guías y tutoriales que se desarrollan conforme los programas lo hacen. Por lo que siempre estamos buscando ayuda para revisar, escribir y traducir manuales.
+
+Así que, para quienes quieran contribuir donando su tiempo y saberes, hemos intentado canalizar todos los esfuerzos a través de esta sección.
+
+Aquí encontrarán información básica y guías para las diferentes maneras de contribuir, desde comentar hasta escribir un manual o traducirlos a sus idiomas.
+
+---
+
+# Contenido
+
+## · [Procedimiento & Herramientas para las guías](procedure)
+## · [Git: Configuración & preparación](git)
+## · [Trabajando con editores de texto](git/editors)
+
+## · [Lineamientos generales sobre el contenido](styleguide)