Contribute Howto update (#168)

How to Contribute howto:

1. Archived the original version in "archive" directory
2. Rewrite of the process and procedures
3. Update, rewrite and expand the Git + Atom howto
4. Added a Troubleshooting chapter for common issues

Co-authored-by: fede <fede@disroot.org>
Co-authored-by: Fede <fede@disroot.org>
Co-authored-by: meaz <meaz@disroot.org>
Reviewed-on: #168
Reviewed-by: meaz <meaz@no-reply@disroot.org>
Co-authored-by: Fede.- <fede@no-reply@disroot.org>
Co-committed-by: Fede.- <fede@no-reply@disroot.org>

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

@@ -0,0 +1,44 @@
+---
+title: Procedures
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - procedure
+page-toc:
+    active: true
+---
+
+# Howto Procedures: What does it mean?
+The possibility of writing a tutorial and making it accessible to everyone in their own languages is fundamental in order to encourage and promote not only the use of free/libre and open source software but also collective thoughts and actions. So coordinating the amount of information to be written and translated is an important task, therefore we developed a basic set of steps to follow to help us achieve this goal.
+
+The procedure is rather simple:
+1. we get a copy of the files we are going to work on;
+2. we work locally on the files,
+3. and once we have finished, we submit them.
+
+Sounds pretty easy, doesn't it? Well, it really is. Of course, every step of the process has its own set of actions, which we will see later on, but that is it basically.
+
+# What tools do we need?
+We use three tools for our work: **Git**, **a text editor** and **Gitea**.
+
+We choose **Git** for several reasons, the main one being our documents structure and code language. Even though there are many (and very good ones) translation tools which look more "user friendly", none of them fit our use case or have **Markdown** text format support out-of-the-box. In the best scenario, it will requires us to make massive modifications on the files in order to strip them down into several "text sections" or "strings". Another important reason is that **Git** allows us to keep track on the changes made on those files, making it easier to manage and collaborate on them. And one more reason is that **Gitea** (the code hosting software we use with **Git**) has a lot of useful features to organize and improve the work in one single place.
+
+OK, let's check our tools:
+
+1. **Git**: If you are a **GNU/Linux** user it is highly probable that you already have it installed (you can check in your software package manager or through the terminal with the command `which git`). If you are using **Microsoft Windows** or **Mac OS**, you can download it from [here](https://git-scm.com/downloads).
+
+2. **A text editor**: Although there are many of them, we suggest you to use one with **Markdown** format support and **Git** integration. **Kate Editor**, **Atom Text Editor** and **VSCodium**, meet this criteria natively, and they are also Free/Libre and Open Source multiplatform software. But, **for practical reasons, we will only see how to work in Atom** (in the future we will include other tools).
+
+  **Atom Text Editor**: [Download](https://atom.io/) · [Source code](https://github.com/atom/atom)
+
+
+3. **A Disroot Gitea account**: In order to be able to submit your work, you will need to register an account on our **Gitea** instance (**Disroot** credentials will not work) and request access to our repository.
+
+  [**Register a new account**](https://git.disroot.org/user/sign_up) on **Disroot's Gitea** instance.
+
+Once you have these tools, it is time to set them up.

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

@@ -0,0 +1,44 @@
+---
+title: Procedimientos
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuir
+        - procedimiento
+page-toc:
+    active: true
+---
+
+# 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.
+
+El procedimiento es bastante simple:
+1. obtenemos una copia de los archivos sobre los que vamos a trabajar;
+2. trabajamos localmente en ellos,
+3. y una vez que hemos terminado, los enviamos.
+
+Suena bastante fácil, ¿no?. Bueno, realmente lo es. Por supuesto, cada paso del procedimiento  tiene su propio conjunto de acciones, que veremos más adelante, pero es eso básicamente.
+
+# ¿Qué herramientas necesitamos?
+Usamos tres herramientas para nuestro trabajo: **Git**, **un editor de texto** y **Gitea**.
+
+Elegimos **Git** por varias razones, la principal es la estructura y el lenguaje de código de nuestros documentos. Aunque hay muchas (y muy buenas) herramientas de traducción que parecen más "fáciles de usar", ninguna de ellas se ajusta a nuestro caso de uso o tienen soporte para el formato de texto **Markdown** por defecto. En el mejor de los escenarios, requeriría que hagamos modificaciones enormes sobre los archivos para poder desglosarlos en muchas "secciones de texto" o "cadenas". Otra razón importante es que **Git** nos permite mantener un registro de los cambios realizados sobre esos archivos, haciéndo más sencillo manejarlos y colaborar sobre ellos. Y una razón más es que **Gitea** (el software para hospedar código que usamos con **Git**) tiene un montón de funcionalidades muy útiles para organizar y mejorar el trabajo en un solo lugar.
+
+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).
+
+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).
+
+  **Atom Text Editor**: [Descargar](https://atom.io/) · [Código fuente](https://github.com/atom/atom)
+
+
+3. **Una cuenta de Disroot Gitea**: Para poder enviar tu trabajo, necesitarás registrar una cuenta en nuestra instancia de **Gitea** (las credenciales de **Disroot** no funcionarán) y solicitar acceso a nuestro repositorio.
+
+  [**Registrar una cuenta nueva**](https://git.disroot.org/user/sign_up) en la instancia **Gitea** de **Disroot**.
+
+Una vez que tengas estas herramientas, es momento de configurarlas.

pages/04.Contribute/01.procedure/docs.fr.md.orig

@@ -0,0 +1,104 @@
+---
+title: Procédure de traduction
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuer
+        - style
+page-toc:
+    active: true
+---
+# Pourquoi une procédure de traduction ?
+Nous pensons que la possibilité de rendre l'information accessible à tous dans leur propre langue est fondamentale pour encourager et promouvoir les réflexions et les actions collectives. Coordonner la quantité d'informations à traduire est donc une tâche importante.
+
+Dans le cadre de ce guide, nous supposerons que vous savez ce qu'est **git** ou que vous avez lu [**ce guide pratique**](https://howto.disroot.org/en/contribute/git/how-to-use-git).
+
+---
+
+**Les traductions se déroulent en quatre étapes principales.**
+
+## Premièrement : Étapes uniques
+1. Enregistrez un compte sur [l'instance git de Disroot]https://git.disroot.org/user/sign_up)
+2. Ouvrez un terminal et démarrez git<br>.
+`git init`<br>
+
+3. Configurer le nom d'utilisateur et l'email de git<br>
+`git config --global user.email user@email`<br>
+`git config --global user.name "Nom d'utilisateur"`<br>
+
+
+## Deuxièmement : Sélection d'une section à traduire
+1. Vérifiez l'[état de traduction du Howto](state/Translations_Howto.pdf) ou l'[état des traduction du site web](state/Translations_Website.pdf) (*ces fichiers peuvent ne pas être à jour*)
+2. Connectez-vous au [**Projet des Traductions Disroot**](https://board.disroot.org/project/fede-disroot-translations/timeline)
+3. Sélectionnez le **Epic** (*l'ensemble des User Stories*) correspondant à la langue dans laquelle vous allez traduire.
+4. Sélectionnez la **User Story** (*la section à traduire*) et **assignez-la** à vous-même<br>.
+
+![](en/assign.gif)
+
+## Troisièmement : travailler sur les traductions
+1. **Clonez le dépôt de Disroot Howto**<br>.
+    a. Naviguez vers le dossier dans lequel vous allez travailler (ou ouvrez le terminal dans le dossier)<br>.
+    b. Clonez le dépôt<br>
+    `git clone https://git.disroot.org/disroot/howto`
+2. **Ouvrez l'éditeur de texte Atom**<br>
+    a. Allez dans **Fichier**, sélectionnez **Ajouter un dossier de projet** et naviguez jusqu'au dossier où le projet a été cloné.<br>
+![](en/atom_interface1.png)<br>
+    b. Créez une branche (la branche doit avoir ce format : section_du_site_à_traduire_LAngue<br>
+    Par exemple:<br>
+    howto_contribute_git_ES<br>
+    howto_email_webmail_IT<br>![](en/branch_01.gif)<br>
+    c. Commencez à travailler sur les traductions<br>
+    d. Enregistrez sous le nom de "nom-du-fichier.le-code-de-votre-langue.md"<br>
+    Par exemple, si vous travaillez sur la traduction française d'un fichier nommé "docs.md", vous devez l'enregistrer sous "docs.fr.md".
+
+3. **Envoi de la traduction**<br>
+    Une fois votre travail terminé, vous devrez "livrer" vos modifications. Un commit est un ensemble de fichiers créés ou modifiés. Pour valider vos modifications, vous devez :<br>
+    a. Assurez-vous que tous les fichiers sont enregistrés<br>
+    b. "Stagez" tous les fichiers que vous avez traduits et que vous voulez soumettre au serveur<br>
+    c. Rédiger un message de validation (un résumé court et très précis de ce qui a été modifié)<br>
+    d. Appuyez sur le bouton **Commit**<br>
+
+    ![](en/commit.gif)<br>
+
+    Une fois que les fichiers sont validés, vous devez les "pousser" (envoyer) vers le serveur :<br>
+    e. Ouvrir la fenêtre popup **Push/Pull**.<br>
+![](en/pull_push.png)<br>
+
+    f. Appuyer sur **Push**<br>
+
+    ![](en/push.gif)<br>
+
+## Quatrièmement : demander la fusion des traductions
+La dernière étape consiste à demander la fusion de votre travail dans la branche master. Cela signifie qu'une fois que vous avez terminé et envoyé la traduction, vous devez demander à l'équipe de traduction **Disroot** de vérifier s'il est possible de l'ajouter au site.<br>
+
+!! ![](en/note.png)**NOTE!!!**<br>
+
+Pendant que vous travaillez sur votre branche, d'autres utilisateurs peuvent livrer et fusionner leurs propres modifications, surtout s'ils travaillent sur des fichiers existants. Si les modifications des autres utilisateurs ont déjà été fusionnées dans la **branche principale**, la version des fichiers que vous avez modifiés peut ne plus être la version actuelle et donc les modifications des autres utilisateurs peuvent ne pas être incluses dans vos fichiers. Dans ces cas, si vous voulez laisser vos modifications être fusionnées dans la **branche principale**, ce processus peut être très chaotique.
+
+![](en/git-merge_chaos.gif)
+
+Une des principales fonctionnalités de **Git** est la possibilité de comparer les versions et d'insérer vos modifications dans les versions mises à jour des fichiers. Pour déclencher cela, vous devez mettre à jour votre branche **avant** de **créer** une **demande de fusion**. En faisant cela, vous épargnerez aux admins et à vous-même beaucoup de travail inutile :
+
+ - Tout d'abord, il faut s'assurer que toutes les modifications sont validées.
+ - Ouvrez un terminal (GNU/Linux)
+ - Passez à **la branche Master** : ***git checkout master***
+ - Mettez à jour **la branche Master** : ***git pull***
+ - Passez à la branche de travail : ***git checkout <Nom_Branch>***
+ - Mettez à jour votre branche de travail à partir de **la branche Master** : ***git rebase master***
+ - Vérifiez les changements et envoyez-les au serveur.
+
+ Now you can start with the final steps of merging your files to the **la branche Master**:
+
+1. Connectez-vous sur [https://git.disroot.org](https://git.disroot.org)<br>
+En haut à droite, vous verrez un bouton **Créer une demande de fusion** qui ouvrira le formulaire de demande de fusion, cliquez dessus.
+2. Ajoutez un titre
+3. Ajoutez une description
+4. Assurez-vous que la branche source est celle à partir de laquelle vous voulez fusionner (celle sur laquelle vous avez travaillé).
+5. S'assurer que la branche cible est celle vers laquelle vous voulez fusionner (généralement la branche Master)
+6. Cochez la case **Supprimer la branche source lorsque la demande de fusion est acceptée** si vous êtes complètement sûr que votre travail est terminé, de cette façon les chances de confusion des traductions ultérieures sont évitées.
+
+S'il y a un problème, les administrateurs peuvent vous demander de corriger quelque chose. Une fois que toutes les corrections sont effectuées et que la documentation répond aux directives de **Disroot**, votre demande de fusion sera transférée vers le master.

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

@@ -0,0 +1,63 @@
+---
+title: Interface
+published: true
+visible: true
+updated:
+        last_modified: "January 2022"
+        app: Atom Text Editor
+        app_version: 1.58.0
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - atom
+        - git
+page-toc:
+    active: true
+---
+
+# Getting familiar with Atom
+Let's start by getting to know the interface a little bit. Once we have started Atom we will see that it is quite straightforward.
+
+![](en/atom_01.png)
+
+First thing we need to do is to open the Howto project folder that we have just cloned. To do that we can either go to the **File menu** --> **Open Folder** and select the directory or directly from the **Add folders** button at the left.
+
+![](en/atom_interface.png)
+
+The left panel is the project's navigation tree and the main window is the editor where we will edit the files.
+
+![](en/navigation.gif)
+
+At the bottom is the "status bar" which displays, at the left, the path of the file we are working on and, at the right, information related to the code language, the current branch, some Git actions menu and the number of files we have modified.
+
+![](en/status.bar.png)
+
+Clicking on the **Git** button at the right side of the status bar will display the Git panel where we can view all the files we have modified as well as some Git operations that we can perform (and that we will see later on).
+
+![](en/git.panel.gif)
+
+We can also toggle the panels if we need to focus just on the text editor.
+
+![](en/panels.gif)
+
+We can activate the **Markdown preview** to have a visual idea of what are we doing on a file by pressing the keys `Ctrl` + `Shift` + `m`...
+
+![](en/preview.gif)
+
+... and we can open and work on multiple files in tabs or splitting the screen into several panels.
+
+![](en/splitted.panels.png)
+
+**Atom** is highly customizable, to the point we can tweak practically each and every one of its parts to better suit our needs.
+
+The two last things to note before we start to work are:
+
+- The unsaved files with local modifications are marked with a blue dot (depending on the theme we are using).
+
+![](en/unsaved.png)
+
+- To save the file changes we can use the **File menu** --> **Save** or the `Ctrl` + `s` keyboard shortcut.
+
+Now that we know our workspace, it is time to get down to work.

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

@@ -0,0 +1,203 @@
+---
+title: Working with Atom + Git
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - atom
+        - git
+page-toc:
+    active: true
+---
+
+# Working with Atom + Git
+Finally we get to the most interesting part! Let's review what we have done so far.
+
+We have got an exact copy of the **Disroot Howto** folder where are all the files we can see online when we need to learn something about how a service works or how to configure a client.
+
+We have **cloned** the repository and we did it using our first git command: `git clone`. The next step will be to create a **branch**.
+
+## Creating branches
+Every git project, the Howto's project in this case, has a **main** branch (or master branch) which contains all the files we can see in *production*. The changes we make on this branch are automatically synced with the site, and become visible immediately. And that is the reason why adding any changes to this **main** branch is restricted to the owners of the project.
+
+In general terms, a branch is basically an independent workspace created from the main line of development on which we can work and test things without compromising the original code.
+
+![](en/branches.png)
+
+In the image above we have the Howto's site content represented by the main line (main). Suppose we want to translate one of its tutorials. We create a new branch (branch 1) and we start working locally on it. While we are translating, someone else wants to start writing a new howto so creates a new branch (branch 2) for that purpose. As we can see, all this happens in parallel and at the same time but without affecting the main branch.
+
+When the translation is done, it is "submitted" to the remote repository to be reviewed and integrated to the production line. In the meantime, the writing of the new howto continues and when it is ready it follows the same process, it is reviewed, updated with the changes introduced by the other branches if necessary and finally it is also integrated to the main one.
+
+OK. Let's create our branch so we can start working.
+
+In the bottom-right corner of **Atom**, click on **master** (or any other branch name) and choose **New Branch**. A good practice is to give it a name descriptive enough so that others can easily figure out what we are working on when they see it. For example, if we plan to translate the Nextcloud howto, we could call it "cloud_language_translation" or something similar.
+
+Once we are done we press **Enter** on our keyboard.
+
+![](en/atom-branch1.gif)
+
+In the terminal, we should use the `git branch` command like this:
+
+`git branch -b our.branch.name`
+
+To switch between branches we can also use this menu. Our current working branch is visible on the bottom bar. If we click on it other local branches will appear.
+
+![](en/atom-branch2.gif)
+
+Switching between branches in the terminal is done with the command `git checkout`. If, for example, we want to switch from our current branch to the main one, we should write:
+
+`git checkout master`
+
+And viceversa, from the main branch to our branch:
+
+`git checkout our.branch.name`
+
+### Publishing our branch
+We have created a local branch and we can start translating or writing a howto. For this branch we just created to also exist in the remote repository we need to **publish** it. In Atom it is done using the **Publish** function. When we click on it, we will be asked to enter our credentials. We need to enter our Gitea username and password.
+
+![](en/publish.png)
+
+In the terminal this can be done with the `git push` command, specifying the remote and the branch name we want to push. In our case it would be:
+
+`git push origin our.branch.name`
+
+When we cloned the **Howto** repository, Git automatically set up its URL as the default "remote" called `origin`. In Git a "remote" is an "alias" for a repository, so we can use this "alias" (origin in this case) instead of writing the entire URL of the remote repository every time we need to interact with it.
+
+To understand this, we can write the command `git remote -v` to see the remotes we have set up in our local repository and the URLs that they refer to.
+
+![](en/remote.png)
+
+Now that we have created a branch and already published it, we can create new files and modify the existing ones on this (our) branch.
+
+## Committing changes
+We are now on our computer translating an existing tutorial or creating a new one and we have been saving the changes we made (using `Ctrl`+`s`, for example) but those changes are only saved in our text editor. We need to **commit** them to our branch first to then "push" them to the remote repository.
+
+So, the first thing we need to understand is that a **commit** is not like doing `Ctrl`+`s` because Git is not "just a backup system". A **commit** is more like a snapshot of our project folder at a certain point. The main idea behind a version control system (Git in this case) is being able to keep track of all the changes made to our code over time so we can look back and check when, how and why it has "evolved". Every commit is, then, a "milestone" in the track history of our project. And every "milestone" is accompanied by a message which describes what has changed. We need to keep in mind that the more commits we make the more populated gets the project timeline, thus increasing the chances of generate a "confusing" record history.
+
+In a very general way, we could say a commit is a set of files created or modified on our local branch that we want to "submit" to the remote git repository.
+
+So when we have decided to create a commit we need to "tell" Git what we want to include in it.
+
+To do a "commit" of the changes is a process that consists of the following steps:
+
+1. Make sure we have saved all the modified files,
+2. "stage" those files we want to commit,
+3. write a descriptive "commit message" (a short and very specific summary of what has been changed), and finally
+4. commit the files.
+
+All the changes we have done so far in our local branch, they were made in our "working directory" and now we need to "move" them to the "staging" area. "Staging" refers to the moment in which those changes are selected to be included in the next commit.
+
+In Atom, this process is incredibly easy. Let's check the process again:
+
+![](en/committing.png)
+
+1. Make sure all files are saved and **Stage all** the files we have modified and want to commit to the repo,
+2. once they are in the "staging area" we can now
+3. write a **commit message** and finally
+4. commit the changes by clicking the **Commit** button.
+
+![](en/atom-commit.gif)
+
+Now let's see how to do the same but in the terminal.
+
+1. The Git command to "move" the files from the "working directory" to the "staging area" is `git add` and if we only have a file or two to **add** we can simply write:
+
+  `git add our.file`
+
+  But if we have several files to commit we do not need to add the changes file by file. We can use
+
+  `git add .`
+
+  and it will include all the current changes into the next commit.
+
+2. Now that the files are in the "staging area" we need to commit them. We can do that by using the `git commit` command with the option `-m` to write a commit message. For example:
+
+  `git commit -m "my commit message"`
+
+  Note that the commit message must be wrapped in quotations `"` `"`.
+
+  If we do not use the `-m` option then we will be prompted to add a message in our default text editor.
+
+  Another useful option is `-a`. It not only will automatically stages all modified files to be committed but we can also skip the `git add` command with it. For example, writing:
+
+  `git commit -a -m "my commit message"` or
+
+  `git commit -am "my commit message"`
+
+Once the files are committed, it is time to **push** (send) them to the remote repository.
+
+## Pushing the changes
+We have committed all the changes in our local branch and we want now "upload" them to the remote repository.
+
+In Atom this can be done by simply clicking on the **Push** option in the bottom bar.
+
+![](en/atom-push.gif)
+
+In the terminal, we have already seen the command to do this: `git push`. So, to push our local changes to the remote branch we have to write:
+
+`git push origin our.branch.name`
+
+## Requesting a Merge
+
+![](en/git-merge_chaos.gif)
+
+**Merging** is the process of integrating commits from different branches. Usually (but not only) the commits made on a given branch into the main one.
+
+Once we think our work is finished and ready to be published on the website, it is time to merge it to the **main branch**.
+
+This merge operation is done by the **Disroot** admins. But it is us who have to request that it be done.
+
+In **Gitea** it is called **Pull Request** and the procedure, in principle, is pretty simple.
+
+1. We go to **Disroot's Git** site at [**git.disroot.org**](https://git.disroot.org) and login with our **Gitea** credentials.
+
+2. Next we need to look for our branch in the **Howto** repository, select it and then click on the **New Pull Request** button.
+
+![](en/pull.request.gif)
+
+3. In the next page we can do a last and more visual revision of the commits we have made and, if we find it OK, then press the **New Pull Request** again.
+
+![](en/pull.request.2.png)
+
+4. Now we are required to write a "merge request" message. It does not need to be long and detailed but descriptive enough, similar to the commit message one, in order to make it easy to others to know what the changes are about. We can also (and it is recommended) add labels for better identification.
+
+![](en/pull.request.3.png)
+
+5. In the last step we can assign "Reviewers", add "Labels" (if we did not do it previously), link our Pull Request to a "Milestone" or a "Project" and define who will be assigned to manage the request (usually the same **Disroot** admins with whom we have been in contact in the Howto's XMPP room).
+
+![](en/pull.request.4.png)
+
+That's it. \O/
+
+Once the Pull Request is done, it will be reviewed by **Disroot** admins. If it is all right and the documentation meets the **Disroot** guidelines, they can approve our commits then. This means our changes will be merged with the main branch and therefore visible on the website.
+
+If there is any issue, admins could request us to correct something. And, again, once all the corrections are made, our Pull Request will be merged to the main branch.
+
+## Pulling changes from the repository
+Pull is an operation to update a local version of a remote repository.
+
+If we want to keep the local main branch for future translations or howtos we will need to "pull" the changes integrated to the recently updated remote because ours will no longer be up-to-date with the remote main one.
+
+In Atom we only need to click on the **Pull** function at the right in the status bar.
+
+![](en/atom-pull.gif)
+
+In the terminal, this is done with the command `git pull`. So if we are still on our local branch and we want to "update" it after commits were sent and accepted, we need:
+
+1. Make sure we are on the local main branch or in another. We can use the `git branch` command which will shows us the branch we are
+
+2. Once we are on the main branch, write:
+
+  `git pull`
+
+  This will download the modifications added to the main branch and update our local copy with them.
+
+Since always there are people working on the code and it changes frequently, it is highly recommended to "pull" from the remote main branch to our local one - specially before we start working on new branch - so we can easily see what is new and what has changed recently.
+
+---
+
+Check [Troubleshooting](/contribute/git/troubleshooting) for more help and common conflict situations

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

@@ -0,0 +1,27 @@
+---
+title: "Working with Editors"
+published: true
+visible: true
+indexed: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - git
+        - editors
+        - atom
+page-toc:
+    active: true
+---
+
+# Editors
+The easiest way to work and edit the **Howto** files is through a text editor with Git integrated.
+
+As we mentioned before, for practical reasons, we will only see how to do it in **Atom Text Editor**, although you can choose to use any other. Along with every step to follow in the editor we will also see the Git commands in the terminal to learn and understand what are Atom and Git doing.
+
+We will try to add more howtos about using other editors in the future. If you want and have time, you can also write one yourself about your favorite editor and we can add it to this section.
+
+
+## [Atom](atom/interface)

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

@@ -0,0 +1,49 @@
+---
+title: Troubleshooting
+subtitle:
+published: true
+visible: true
+indexed: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - git
+        - troubleshooting
+page-toc:
+    active: true
+---
+
+# Troubleshooting
+<a name="behind"></a>
+## Table of Content
+- [Our local branch is "behind" the remote main branch](#behind)
+
+---
+
+<a name="behind"></a>
+## Our local branch is "behind" the remote main branch
+While we are working on our branch, other users possibly commit and merge their own changes, especially if we are working on existing files. If those changes from the other users have already been merged to the **main branch**, the version of the files we changed may no longer be the actual ones and therefore the changes from other users may not be included in our files. In that case, if we want to let our changes be merged to the **main branch**, the process could become quite complicated.
+
+So we need to integrate the changes made on the remote main branch into our local main one **before** we can **request** a **Pull** (a merge request). By doing this we will spare the admins and ourselves a lot of needless work.
+
+In Git there are two ways that allow us to integrate/merge/update branches: **git merge** and **git rebase**.
+
+**Git merge** compares the last two commits of each branch and the "common ancestor" of both branches we want to merge and creates a new commit with the changes. When we merge one branch into our own, we merge the history of both branches together. If we then do that again, we will start to create a series of interleaved histories.
+
+**Git rebase** tracks one by one the commits made on one branch and "replicates" them into the other. This means that all our local commits will appear at the end, after the remote commits and we will have a clearer history. That is why this is the preferred method.
+
+It is important to note that **rebase** is helpful **only** if we apply it on the local commits that have not yet been "uploaded" to any remote repository. If we do the "rebase" on a local branch which commits were already pushed to the remote one, we will surely have a number of conflicts.
+
+So if we are working on a local branch and we want to integrate to it the changes made to the remote main branch we will need to "rebase".
+
+Steps to rebase:
+1. Make sure all the changes are committed on our local branch only.
+2. In the terminal:
+ - switch to the **Main Branch**: `git checkout master`;
+ - update the **Main Branch**: `git pull`;
+ - switch back to our working branch: `git checkout our.branch`;
+ - update our working branch from the updated **Main Branch**: `git rebase master`.
+3. Finally, verify the changes and commit the changes to the remote repository.

pages/04.Contribute/02.git/docs.en.md

@@ -0,0 +1,86 @@
+---
+title: "Git"
+published: true
+visible: true
+indexed: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - git
+        - settings
+page-toc:
+    active: true
+---
+
+# Git?
+Yes, **Git**. It is a control version system, a software that allows us to track modifications to files, keeping a record of all the changes made, so if we need to revert to a specific version we can do it in a relatively easy way. It is also a powerful collaboration tool, since it allows many people working on the same files of a project.
+
+To learn the basics of Git and to work with it can be not only very useful but also a fun experience.
+
+
+# Scope of this tutorial
+Our use of Git doesn't require a high level of technical knowledge, anyone can learn the set of basic commands needed. And, to make it even easier, there are several text editors with Git integrated to reduce the interaction with the terminal to the minimum.<br>
+So the aim of the following tutorials is to introduce you to the basics of Git, the main tool we use to manage the **Howto** project files. Therefore, we will not cover all the aspects of its usage, only some basic concepts and commands.
+
+If you get more interested about Git, there are lots of in-depth tutorials and documentation written about it that you can easily find on the Internet.
+
+
+# What does Git do?: Basic concepts
+
+![](en/git.png)
+
+When you read a **Disroot** tutorial, what you are seeing is the representation in your browser of a piece of code, in our case, a text file written in a formatting syntax called **Markdown**. The entire code of this site and its content is hosted in a **Git repository**, a folder containing all the project files and the changes history of each and every one of those files (what has changed, who has changed it and why it has changed).
+
+In this repository (or repo) there is a **main branch** (or "master branch"), which is the default project line of development and from which different other branches can be created without compromising it.
+
+Think of a tree: the "main branch" would be the trunk from which different branches "grow and develop". Once they complete their cycle, they can be integrated into the "trunk" or even "fall" from it without affecting it.
+
+So, the main branch is the one that contains the code we see online (or "in production") and the branches we create are the ones that contain our work.
+
+![](en/git_branches.png)
+
+This way, when a tutorial needs to be modified (e.g., because some software has been updated, typos were found in a document, there is information to be added/removed, etc) or translated, what we do is copy the remote repository into our machine so we can work locally on the files. This procedure is called **cloning** and once it is done, all modifications and Git operations are managed from our local repository.
+
+## Cloning the **Howto Disroot** repository
+As we mentioned before, the process of getting a copy of all the files within the project is called "**to clone**" a repository. And once we have cloned it, all modifications will be done on this copy in our local machine (most of the work is done offline).
+
+To clone the repository we just open a terminal, navigate to the directory we would like to clone the repository to, and run the `git clone` command, that is, we are "telling" git through this command to "download" it. The command is followed by the **url address** of the repo we want to clone. In our case it would be:
+
+`git clone https://git.disroot.org/Disroot/Howto`
+
+If we want to translate a page from the **Disroot Website** then we write:
+
+`git clone https://git.disroot.org/Disroot/Website`
+
+The process will then begin and in a few minutes, depending on our internet connection, we will have the repository "cloned" on our machine.
+
+![](en/cloning.png)
+
+Once this process has been completed, we will see a `Howto` (or a `Website`) directory containing all the files of the site. We can later move that directory to any place we want on our computer.
+
+Now, before we really get to work, let's setup our identity so we can move forward without distractions.
+
+## Setting your identity
+In order to be able to send our work from our machine to the remote repository, it is necessary to setup our username and email. This information is used by Git to "sign" the commits (the "snapshots" of our modifications, we will see this later on).
+
+1. We open a terminal in (or navigate to) the directory/folder where we have the cloned repository.
+
+2. Type and complete with your information the following commands:<br>
+`git config --global user.email` **user@email** `<- here goes your email address`<br>
+`git config --global user.name` **"Username"** `<- and here your username`
+
+We will not need to enter this information again.
+
+## Requesting access to the Disroot repository
+The faster and recommended way to request access is via our **Howto Chat room** at `howto@chat.disroot.org`. You can also send us an email to `howto@disroot.org`.
+
+Once admins grant you the access, you will be able to "*push*" (send) your changes to the server.
+
+!! **NOTE**<br>
+!! You could start working without access granted as all the changes happen on your local computer, and requesting it later.
+
+
+Ok. Let's move on.

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

@@ -0,0 +1,92 @@
+---
+title: 'General Structure'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - style
+page-toc:
+    active: true
+---
+
+# General Structure
+
+The **Howto** site is made up of text files in Markdown format contained in folders organized hierarchically in sections.
+
+The site has **three main directories**:
+- **pages**: this folder contains the pages and tutorials. This is the only content we can edit and translate.
+- **themes**: here are the files and configurations that shape the site.
+- **vagrant**: this folder contains the necessary files to run Vagrant, a software to create virtual environments.
+
+The only directory we are interested in for creating, editing and translating howtos is **pages**.
+
+![](en/structure.png)
+
+As we can see in the image above, the **pages** directory contains several other directories and subdirectories.
+
+- **01.home**: here is the **Howto** landing page.
+- **02.tutorials**: this is the directory where all the howtos are located and organized by categories.
+- **03.Glossary**: here is the page where we intend to gather most of the important terms we use through the howtos and guides.
+- **04.Contribute**: in this directory we will find guides on how to create, edit and translate the pages of the site.
+- **05.Licensing**: the license under which the site content is released.
+- **06.disroot.org**: the link to the **Disroot** website.
+- **archive**: this folder contains all the howtos that are no longer online.
+
+
+# Pages
+There are currently two different templates for the **Howto** pages:
+- **docs.md**: these are the most common text files we can find in the Howto site, the pages that make the howtos.
+
+- **docsparent.md**: these pages are used to index all the **child pages** that are marked as `indexed:true` in its **headers**, creating a menu of the related pages. If an image is placed in the folder of a *child page*, a thumbnail will be shown in the index (preferred thumbnail size is 400x300).
+
+## Page headers
+The page header is the place where we set all the variables for a given page. It is the part that appears above the content enclosed between three dashes `---`.
+
+Below there is a list of the most common variables that can be specified in each header and their purpose.
+
+- **title**: is the name of the page and it will appear in menus and indexes.
+
+- **subtitle**: is displayed as items in the home page.
+
+- **icon**: a Fork-awesome icon that is displayed on the home pages.
+
+- **visible**: set by a boolean value, *true* or *false*. When set to false on second degree children pages, they will not appear in the index.
+
+- **indexed**: set by a boolean value, *true* or *false*. Posts set to true appear in parent pages indexes. Also add a thumbnail in page directories if any (preferred thumbnail size is 400x300).
+
+- **updated**: when it is specified, the metadata information will be displayed on page.
+
+- **published**: set by a boolean value, *true* or *false*.
+
+- **taxonomy**: to set categories and tags. Posts with the category 'topic' appear as the main topics on the home page menu.
+
+- **page-toc**: set by a boolean value, *true* or *false*. Determines if a *Table of Content* is visible on page or not. Usually it is set to false for index pages (docsparent.md).
+
+To better understand how these variables affect the pages, we can take a look at, for example, the **Cloud** index page header (02.Cloud/docsparent.en.md):
+
+- _docsparent.md_ at the index/home page
+
+![](en/docsparent_view.png)
+
+
+- _docs.md_ header and view at the Cloud howto index (02.Cloud/docsparent.en.md)
+
+![](en/docs_view.png)
+
+
+## Meta information
+
+The meta information is set automatically when specified in the page header under the `updated:` variable. It is necessary to let readers know if the howto is up to date. The fields to complete are:
+
+`last_modified:` "Month and Year" wrapped between `" "` _(i.e: "June 2020")_<br>
+`app:` Software name _(i.e: Nextcloud)_<br>
+`app_version:` Number version of the software _(i.e: 18)_<br>
+
+### Where to place the Meta information?
+This information is not necessary in the indexes, but in those pages where there is data that may vary with updates.
+
+![](en/meta.png)

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

@@ -0,0 +1,56 @@
+---
+title: 'Information guidelines'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - style
+page-toc:
+    active: true
+---
+
+# Building the information guidelines
+
+## First question: What can we write about?
+This question is already partially answered in the main page of this site:
+> *"We aim to cover all the services, with all its **Disroot**'s provided features, for all platforms and/or Operating Systems as well as the largest possible number of clients for the most widely used devices"*
+
+So we can write about the software provided by **Disroot**, how they work and what can we do with them. That seems quite evident until we ask ourselves if we all use the same operating system in our computers or mobile devices.
+
+The fact that our focus is exclusively on the use, promotion and spreading of **free and open source software** (and therefore our howtos are written mainly for GNU/Linux) should not make us forget that there are many people who choose to use proprietary software and their approach to our services is not related to ethical or political reasons but pragmatic.
+
+That is why we explicitly say:
+
+> *"for all platforms and/or Operating Systems as well as the largest possible number of clients for the most widely used devices"*
+
+A basic list of the main operating systems we try to cover would be the following:
+
+- **GNU/Linux**, **Microsoft Windows** and **Apple macOS** on desktop and laptop computers and
+- **Google Android**, **Apple iOS**, **Jolla Sailfish OS** and **Microsoft Windows Mobile** on mobile devices.
+
+!! **Everyone, no matter the operating system they use, can collaborate by writing how to use a service. Remember that the most important thing is to make the information available to anyone.**
+
+## Second question: Who are the howtos aimed at?
+In principle, any person over 16 years of age can use the **Disroot** services. But we can also think about the fact we all have, for example, relatives and acquaintances who we would like to introduce to the use of socially ethical and technically useful tools or maybe they just want to do it by themselves.
+
+So when writing a howto we must think that the information must be understandable to anyone, regardless of age or technical knowledge. Of course, there are always software that are more complex than others, but that should not mean that we do not make the effort to try to make it possible for anyone to learn them.
+
+This leads to the following question.
+
+## Third question: What type of language should we use?
+In order to make the howtos as accessible as possible, not only to the users but also to those who help us translate them, we must use English in the least informal way we can. This means avoiding the use of technical jargon, slang or linguistic contractions (for example, it is preferable to write "it will not" instead of "it won't"). We must also keep in mind that these guides could be used or translated by other projects that provide similar services or software and we want the task of adapting them to consume as little of their time as possible.
+
+In those cases where the use of technical terms is unavoidable, we will need to explain briefly what they mean or refer to an external source (i.e., a Wikipedia article) that does so.
+
+## Fourth question: Regarding translations, should they be literal?
+Although there is not a specific and effective method, there are, at least, two important things we should keep in mind when doing a translation.
+1. **Understand the text of the howto integrally**. Before we start translating, it is advisable to read the entire text and "capture" its essence: "what is it about", "how the information is presented and/or structured", "is it hard/easy to understand", etc. This will help us to identify the context of the words and expressions that appear in a given document and which meaning depends on it.
+2. **Follow the original text is fundamental as is preserving its fluidity**. Sometimes we could find words or expressions that are really hard to translate into our language or even untranslatable. So we need to be careful not to omit them or change their original meaning too much because this can affect the overall meaning of a line, a paragraph or an entire document. If we have doubts about certain adaptations we can always consult or ask in the Howto chat room.
+
+So the literalness of a translation does not always result in a coherent text. When it is necessary to make adaptations of expressions or words, these must be as faithful as possible to the original meaning of the document.
+
+Finally, we will always need to proofread our translations before submitting them. It is very common to find small recurring mistakes or inconsistencies and correcting them in time will prevent a translation from being returned to us.

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

@@ -0,0 +1,262 @@
+---
+title: 'Visual guidelines'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - style
+page-toc:
+    active: true
+---
+
+# Visual content guidelines
+
+As with information, when including visual content we must follow some criteria so that a howto is, above all, didactic and useful. Keep in mind that sometimes too many images can make lose focus on the information and result in a rather confusing document. Not to mention that this can unnecessarily increase the loading time of the page.
+
+So the fist thing we need to do is to evaluate which are the basic visual aids that need to be included. For example, to find a menu or a configuration, to describe actions, how to perform them or compare the effects of their execution.
+
+# General criteria
+In general terms, the visual content of a howto then should meet the following criteria:
+
+1. **Use of visual aids** _(whenever possible)_ **like**:
+    - Screen shots
+    - GIF images / video recording of the desktop or mobile
+
+* Recommended software:
+ - [**Peek**](https://github.com/phw/peek): animated GIF recorder (Desktop)
+ - [**ScreenCam**](https://f-droid.org/en/packages/com.orpheusdroid.screenrecorder/): screen recorder (Mobile)
+ - [**scrcpy**](https://github.com/Genymobile/scrcpy): mobile screen recorder (Desktop)
+
+2. **Easy to adapt by other projects**: In order to do so, mentions to **Disroot** and other unique identifiers of the **Disroot project**, should be kept at the necessary minimum and the content the more generic and adjectiveless as possible. This way, it is easier for other projects to use, adapt and edit the howtos.
+
+3. **Concise text content**: Write only what is necessary to explain a task or a feature and warn about important things users should know, for example by using "notices" (see below).
+
+4. **Avoid long text paragraphs**
+
+5. **Use bullet points instead of a big paragraphs when describing several steps or features**
+
+6. **Avoid using tables, unless it serves a purpose other then text formating.**
+
+## Using "Notices":
+"Notices" are small pieces of text we may use to highlight important information, for example to emphasize something users should keep in mind or be aware of when configuring something or before they perform an action.
+
+To format a notice we need to start the text with two exclamation marks `!!`.
+
+For example:
+```
+!! **NOTE!** this an example of an important information.
+```
+
+it will look like:
+!! **NOTE!** this an example of an important information.
+
+#### Inline images
+
+Images are centered by default in the next line. To use an image inline, so on the same line of a sentence use  {.inline} right after. Like in this example:
+
+```
+![](en/07_share_button.png) {.inline}
+```
+----------------------------------------------------------------------
+
+
+# Markdown: Some formating tips
+
+As we already mentioned, **Disroot**'s [How-to Website](https://howto.disroot.org/) is built with [Grav](https://getgrav.org/), and it uses **Markdown** as markup / formating text composing language because it is lightweight and its syntax is easy to learn.
+
+Here below you will find some tips and recommendations about the text formating of a tutorial.
+
+## Titles
+
+The how-to title itself goes in the page header, you can edit it if you use git.
+
+As for the different sections titles of a how-to you can compose it in Markdown by using the `#` symbol and a space before the title itself. For example:
+
+Writing this...
+```
+# Title 1
+## Title 2
+### Title 3
+#### Title 4
+##### Title 5
+```
+...will be displayed as:
+
+# Title 1
+## Title 2
+### Title 3
+#### Title 4
+##### Title 5
+
+The more `#` you use the smaller the title will be.
+
+Titles are important for several reasons. One of the main is that Grav uses them to automatically generate the TOC (Table of Content) of the page. So they can be used to show the different chapters / sections of the howto at the top of the page index.
+
+
+
+Smaller titles appear as "sub chapters" in the TOC. This could be useful to do something like this:
+
+We recommend the using of one `#` for the main page title and two `##` for sub chapters. You can use `###` titles for minor headers within the text, that you want to be in the TOC and even smaller titles for headers that do not need to be in the TOC.
+
+
+## Lists
+
+Please, use lists to list steps or features in a howto.
+
+Making bullet points is easy. Writing...
+```
+My List:
+- something 1
+1. sub item 1
+2. sub item 2
+- something 2
+```
+...will show this:
+
+My List:
+- something 1
+    1. sub item 1
+    2. sub item 2
+- something 2
+
+
+## Bold
+
+Please, use bold to highlight:<br>
+- Important information
+- Warnings to the user
+- Or a smaller title inside a section that is not necessary to be listed in the TOC.
+
+To highlight a word or a line with bold, use two `*` symbol before and after the part it needed.<br> For example, if you write...
+
+`**Something**`
+
+it will be displayed as:
+
+**Something**
+
+
+## Italic
+
+Italic works in a similar way as bold. You can use the `_` symbol or one `*` symbol before and after the word or text section you want to apply the format.<br>
+Examples:<br>
+Writing...<br>
+
+`_example_`<br>
+`*example*`
+
+... will show this:
+
+_example_<br>
+*example*
+
+
+## Links
+
+Sometimes we need to insert links to some pages or websites. It can be done this way:
+
+Writing `[link to Disroot website](disroot.org)`
+
+will be displayed as:
+
+[link to Disroot website](disroot.org)
+
+
+## Embedding videos / gifs / screenshots in the howto
+
+As we've mentioned, we like images / videos in the tutorials. You can embed them by doing the following:
+
+- First: Creating a folder where to put the videos / gifs / images
+- Second: Naming the files by the order in which they will appear troughout the how-to
+
+Then create a link with the path to the folder and name of the file in question.<br>
+So if you write...
+
+`![](name_of_folder_full_of_media_files/example_1.png)`
+
+... you will see this:
+
+![](en/name_of_folder_full_of_media_files/example_1.png)
+
+And if you do this:
+
+`text before ![](name_of_folder_full_of_media_files/example_1.png) text after`
+
+you'll get this:
+
+text before ![](en/name_of_folder_full_of_media_files/example_1.png) text after
+
+The structure described above also works to embed gifs and .mp4 videos.
+
+
+## Code
+
+If you need to show some terminal commands, code lines, instructions or examples like the ones we've been doing through this guide, you can use the **`** symbol before and after the text you want to show.<br>
+For example:<br>
+
+This is a command line command: `sudo apt update`
+
+# Terminologies
+
+To make the tutorials more coherent and easier to be adapted by other groups, we recommend the use of the following criteria:
+
+- When writing a how-to, **Disroot**'s name should be referred as: **Disroot**, starting with capital letter and bold type.
+
+- And the different services refered as follows:
+
+|Service|Disroot name|
+|-:|:-|
+|Lufi|**Disroot Upload**|
+|Forum/Discourse|**Disroot Forum**|
+|Etherpad|**Disroot Pad**|
+|XMPP|**Disroot Chat**|
+|Email services in general|**Disroot Email**|
+|Rainloop|**Disroot Webmail**|
+|Private Bin|**Disroot Bin**|
+|Nextcloud:|**Disroot Cloud**|
+|Nextcloud Calendar App|**Disroot Calendar**|
+|Nextcloud Notes App|**Disroot Notes**|
+|Nextcloud Contacts App|**Disroot Contacts**|
+
+This way, if the expressions are regular, it's easier to just do a "*Search and replace*" :wink:
+
+
+# Video how-to's
+
+For video how-tos we also think that the content should be **kept at the minimum** and **short** enough for the user to be able to complete a task and for the clarity sake of it.
+
+Same as the text how-tos, the tutorials should have the following structure:
+
+1. **Meta information**
+2. **Content**
+3. **Licensing information**
+
+**Meta information** and **licensing information** will be placed by the **Disroot** admins in the video description of the Peertube instance where the videos will be hosted.
+
+## Description of Content
+
+To the extent possible, videos should go with:
+
+- Title of the how-to
+- Brief description of what it is about
+- Software version it refers to
+
+So that they can be placed by **Disroot** admins on the video description at the Peertube instance.
+
+## Content
+
+## Licensing of video how-to's
+
+As we mentioned before, the licensing information will be placed by **Disroot**'s Admins in the video description.
+
+However we recommend that you place the following image at the end of your video for about 10 seconds fade in and out:
+
+![](en/licensing-pic.png)
+
+In this case if the video is downloaded and reuploaded somewhere else the license information is still there.
+
+---

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

@@ -0,0 +1,21 @@
+---
+title: 'Content guidelines'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - style
+page-toc:
+    active: true
+---
+
+# Content guidelines
+There are several ways to write or translate a guide, no doubt. And if we search on the Internet we will find all kind of styles: from very technical to some very funny ones, passing through some quite boring, some visually impressive and others certainly spartan in more than one aspect. But they all have one thing in common: **the information**. That is our raw material.  
+
+The **Howto Project** is about providing, not just any information, but useful information about the software available on the **Disroot** platform in the clearest and most accessible way we can. But how to achieve this?
+
+Well, we can ask ourselves some questions and see if we can build together some definitions to guide us in the task.

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

@@ -0,0 +1,353 @@
+---
+title: How-to Mitwirken Gestaltungsrichtlinie
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - style
+        - Mitwirken
+        - Gestaltung
+page-toc:
+    active: true
+---
+
+
+# Gestaltungsrichtlinie
+
+Dieser Bereich soll einige grundlegende Richtlinien bereitstellen, wie ein Tutorial oder How-to für die **Disroot**-[How-to Website](https://howto.disroot.org) geschrieben werden sollen.
+Das Ziel ist hierbei, eine einheitliche Struktur in den How-to's zu erreichen und sicherzustellen, dass die How-to's die Beiträge enthält, welche die **Disroot**-Gemeinschaft (nach einigen Diskussionen) für wichtig hält.
+
+Wie wir bereits in den [git-Basics](/contribute/git/how-to-use-git) erläutert haben, arbeiten wir mit git, dem Atom-Texteditor und der Markdown Markup Sprache als Werkzeuge der Wahl.
+
+Wenn Du Dich mit diesen Werkzeugen nicht wohl fühlst, kannst Du natürlich auch jeden anderen Texteditor benutzen. Wir nehmen alles :smiley:
+
+## Seiten
+
+Aktuell gibt es zwei verschiedene Vorlagen für die How-to-Seiten, "docs.md" und "docsparent.md". "docparent.md" wird alle Nachfolger-Seiten indizieren, die im Header mit "indexed:true" markiert sind, und dadurch ein Menü der zugehörigen Seiten erstellen. Wenn im Verzeichnis der Nachfolger-Seite eine Bilddatei abgelegt ist, wird im Index ein Thumbnail (400x300) dargestellt.
+
+# Seiten-Header
+
+Der Seiten-Header ist die Stelle, an der Du alle Variablen für die Seite setzen kannst. Er erscheint über dem Seiteninhalt, eingeschlossen von drei Bindestrichen (---).
+
+Im Folgenden findest Du die Variablen, die im Header definiert werden können:
+
+*title*: Der Name der Seite. Er erscheint in Menüs und Indizes.
+*subtitle*: Erscheint unter Items auf der Homepage.
+*icon*: Fork-Awesome Icon, das auf der Homepage erscheint.
+*visible*: Boolean. Wird dieser Wert Nachfolgern zweiten Grades auf false gesetzt, erscheinen diese nicht im Index.
+*indexed*: Boolean. Wird dieser Wert auf true gesetzt, erscheint die Seite im Index der Eltern-Seite. Fügt ein Thumbnail der Bilddatei im Seiten-Verzeichnis (400x300) ein.
+*updated*: Wenn definiert, werden die Metadaten auf der Seite angezeigt.
+*published*: Boolean
+*taxonomy*: Setzt Kategorien und Tags. Seiten mit der Kategorie 'topic' erscheinen als Hauptthema im Homepage-Menü.
+*page-toc*: Boolean. Bestimmt, ob ein Inhaltsverzeichnis auf der Seite angezeigt wird. Wird normalerweise auf false gesetzt bei Index-Seiten (docsparent.md).
+
+
+#### Beispiele:
+
+
+```
+---
+title: Cloud
+subtitle: "Basics, settings, syncing, clients"  
+icon: fa-cloud
+updated:
+________last_modified: "April 2019"		 
+________app: Nextcloud
+________app_version: 15
+published: true
+taxonomy:
+____category:
+________- docs
+________- topic				
+____tags:
+________- cloud
+page-toc:
+____active: false			
+---
+```
+_docsparent.md_
+
+
+```
+---
+title: 'Cloud: Nextcloud Introduction'		
+published: true
+visible: true
+indexed: true    			
+updated:
+________last_modified: "April 2019"		
+________app: Nextcloud
+________app_version: 15
+taxonomy:
+____category:
+________- docs
+____tags:
+_______- cloud
+page-toc:
+____active: true					
+---
+```
+_docs.md_
+
+
+## Metainformationen
+
+Metainformation werden automatisch erstellt, wenn sie im Seiten-Header unter 'updated' definiert sind:
+
+```
+updated:
+________last_modified: "April 2019"
+________app: Nextcloud
+________app_version: 15
+```
+
+# Inhalts-Richtlinien
+
+Wir sind der Meinung, dass die How-to-Texte der Übersichtlichkeit und Übertragbarkeit zuliebe so kurz wie möglich gehalten werden sollten. Im Idealfall enthalten sie nur die nötigsten Hintergrundinformationen, die grundlegenden Schritte und, wann immer möglich, visuelle Unterstützung (Screenshots, gifs), welche die erklärten Schritte verdeutlicht.
+
+Der Inhalt eines How-to sollte die folgenden Kriterien erfüllen:
+
+1. **Nutzung visueller Hilfen**:
+    - Screenshots
+    - Gif- / Video-Aufnahmen des Desktop oder Smartphones
+
+!!    
+!! Für Gif- / Video-Aufnahmen arbeiten wir normalerweise mit [**Peek**](https://github.com/phw/peek)
+!!
+!! Für mobile Endgeräte kannst Du [**ScreenCam**](https://f-droid.org/de/packages/com.orpheusdroid.screenrecorder/) nutzen
+
+2. **Einfach durch andere Projekte anzupassen**:
+Um dies zu erreichen, sollten unserer Meinung nach Erwähnungen von **Disroot** und besonderer Identifizierungsmerkmale des **Disroot**-Projekts auf ein notwendiges Minimum beschränkt werden. Auf diese Weise ist für andere Projekte einfacher, die How-to's zu verwenden und anzupassen.
+
+3. **Prägnanter Inhalt**:
+Schreibe nur, was notwendig ist, um eine Aufgabe oder eine Funktion zu beschreiben und weise auf wichtige Dinge hin, die ein Nutzer wissen sollte.
+
+4. **Vermeide lange Absätze**
+
+5. **Benutze Aufzählungen anstatt langer Absätze, wenn Du mehrere Schritte oder Funktionen beschreibst**
+
+6. **Vermeide Tabellen, es sei denn, sie dienen einem anderen Zweck als der Textformatierung**
+
+#### Notes:
+
+Starte eine Zeile mit !! um wichtige Hinweie zu formatieren. Füge das Ausrufezeichen-Bild mit \!\[]\(/home/icons/note.png) hinzu.
+
+Beispiel:
+
+!! ![](/home/icons/note.png)
+!! **ACHTUNG!**
+
+Wenn Du Dein Passwort verlierst oder vergisst, hast Du **keine** Möglichkeit mehr, an Deine Dateien zu kommen, da diese verschlüsselt sind. Nicht mal die Server-Administratoren können den Inhalt Deiner Dateien sehen.
+
+
+#### Inline-Bilder
+
+Bilder werden standardmäßig zentriert in der nächsten Zeile eingefügt. Um ein Inline-Bild zu erzeugen, also ein Bild in der selben Zeile wie dem Satz einzufügen, schreibe  {.inline} direkt dahinter. So wie in diesem Beispiel:
+
+```
+![](de/07_share_button.png) {.inline}
+```
+----------------------------------------------------------------------
+
+
+# Einige Formatierungshinweise
+
+**Disroot**'s [How-to Website](https://howto.disroot.org/) wurde mit [Grav](https://getgrav.org/) erstellt, und nutzt **Markdown** als Markup- / Formatierungs-Texterstellungssprache, weil dies eine einfache Möglichkeit darstellt.
+
+Wenn Du also ein How-To für **Disroot** erstellen möchtest und mit Markdown keine Erfahrung hast, wollen wir Dir hier ein paar Tipps und Empfehlungen zur Textformatierung eines Tutorials geben:
+
+## Titel
+
+Der How-To-Titel selbst steht im Seiten-Header. Du kannst ihn ändern, wenn Du git benutzt.
+
+Für die Titel der unterschiedlichen Bereiche oder Abschnitte in einem How-to kannst Du in Markdown das '#'-Symbol und ein Leerzeichen vor dem Titel selbst benutzen. Zum Beispiel:
+
+Schreibst Du dieses...
+```
+# Titel 1
+## Titel 2
+### Titel 3
+#### Titel 4
+##### Titel 5
+```
+...wird es so angezeigt:
+
+# Titel 1
+## Titel 2
+### Titel 3
+#### Titel 4
+##### Titel 5
+
+Je mehr `#` Du benutzt desto kleiner wird der Titel.
+
+Titel sind aus verschiedenen Gründen wichtig. Einer der Hauptgründe ist, dass Grav automatisch aus den Titeln die TOC (Table of Content, Inhaltsverzeichnis) der Seite generiert. Auf diese Weise können Titel genutzt werden, um bereits am Anfang der Seite einen Überblick über die verschiedenen Kapitel oder Bereiche der Seite zu geben.
+
+Kleinere Titel erscheinen als Unterkapitel in der TOC. Das kann sehr hilfreich sein, benötigt für die Ausführung natürlich eine gewisse Ordnung:
+
+Wir empfehlen, das einzelne `#` ein einziges Mal auf der Seite zu nutzen, nämlich für den Seitentitel, und zwei `#` für Unterkapitel. Du kannst Titel mit drei `#` für untergeordnete Überschriften im Text benutzen, die Du auch noch in der TOC erscheinen lassen willst, und noch kleinere Titel für Überschriften, die nicht in der TOC enthalten sein müssen.
+
+
+## Listen
+
+Bitte, benutze Listen für schrittweise Erläuterungen oder Funktionsaufzählungen in einem How-to.
+
+Aufzählungszeichen zu erzeugen ist ganz einfach. Schreibst Du...
+```
+Meine Liste:
+- irgendwas 1
+1. Unterpunkt 1
+2. Unterpunkt 2
+- irgendwas 2
+```
+...wird das Ganze später so aussehen:
+
+Meine Liste:
+- irgendwas 1
+    1. Unterpunkt 1
+    2. Unterpunkt 2
+- irgendwas 2
+
+
+## Fett
+
+Bitte benutze die "Fett"-Formatierung um folgendes hervorzuheben:<br>
+- Wichtige Informationen
+- Warnungen an den Benutzer
+- Kleinere Titel innerhalb eines Bereichs, die nicht unbedingt in der TOC aufgeführt werden müssen.
+
+Um ein Wort oder eine Zeile "Fett" zu formatieren, füge zwei `**` vor und hinter dem zu formatierenden Text ein.<br> Wenn Du zum Beispiel schreibst...
+
+`**Irgendetwas**`
+
+wird es dargestellt als:
+
+**Irgendetwas**
+
+
+## Kursiv
+
+Kursiv funktioniert genauso wie Fett. Du kannst einen `_` oder einen `*` vor und hinter dem zu formatierenden Text einfügen. <br>
+Beispiele:<br>
+Schreibst Du...<br>
+
+`_Beispiel_`<br>
+`*Beispiel*`
+
+...wird das so aussehen:
+
+_Beispiel_<br>
+*Beispiel*
+
+
+## Links
+
+Manchmal müssen wir Links zu anderen Seiten oder Websites einfügen. Dies kannst Du folgendermaßen erreichen:
+
+Schreibst Du `[Link zur Disroot-Website](disroot.org)`
+
+wird dies so aussehen:
+
+[link to Disroot website](disroot.org)
+
+
+## Einbetten von Videos / gifs / Screenshots in die How-to's
+
+Wie wir schon erwähnt haben, wir lieben Bilder / Videos in den Tutorials. Du kannst sie folgendermaßen einbinden:
+
+- Erstens: Erstelle ein Verzeichnis, in welchem die Videos / gifs / Bilder gespeichert werden
+- Zweitens: Benenne bzw. nummeriere die Dateien in der Reihenfolge, in der sie im Verlauf des How-to verwendet werden
+
+Dann erstellst Du einen Link mit dem Verzeichnispfad und dem Namen der fraglichen Datei.<br>
+Wenn Du also schreibst...
+
+`![](Name_des_Verzeichnisses_voller_Mediendateien/Beispiel_1.png)`
+
+... erhältst Du dies:
+
+![](de/Name_des_Verzeichnisses_voller_Mediendateien/Beispiel_1.png)
+
+Wenn Du schreibst:
+
+`Text vorher ![](Name_des_Verzeichnisses_voller_Mediendateien/Beispiel_1.png) Text nachher`
+
+erhältst Du dies:
+
+Text vorher ![](de/Name_des_Verzeichnisses_voller_Mediendateien/Beispiel_1.png) Text nachher
+
+Mit der gleichen Vorgehensweise kannst Du auch gifs und .mp4-Videos einbetten.
+
+
+## Code
+
+Wenn Du in Deinem Tutorial Terminal-Kommandos, Codezeilen, Anweisungen oder Beipiele aufführen musst, wie wir das in diesem Ratgeber die ganze Zeit machen, kannst Du das **`** vor und hinter den entsprechenden Text setzen.<br>
+Zum Beispiel:<br>
+
+Dies ist eine Komanndozeilen-Anweisung: `sudo apt update`
+
+# Terminologie
+
+Um die Tutorials kohärenter und außerdem die Adaption durch andere Gruppen einfacher zu gestalten, empfehlen wir die Anwendung der folgenden Regeln:
+
+- In einem How-to sollte **Disroot**'s Name sollte benannt werden als: **Disroot**, wobei der erste Buchstabe groß geschrieben und das ganze Wort Fett formatiert wird.
+
+- Die verschiedenen Services werden wie folgt benannt:
+
+|Service|Disroot-Name|
+|-:|:-|
+|Lufi|**Disroot Upload**|
+|Forum/Discourse|**Disroot Forum**|
+|Etherpad|**Disroot Pad**|
+|EtherCalc|**Disroot Calc**|
+|XMPP|**Disroot Chat**|
+|Email services im Allgemeinen|**Disroot Email**|
+|Rainloop|**Disroot Webmail**|
+|Hubzilla Instanz|**DisHub**|
+|Private Bin|**Disroot Bin**|
+|Polls|**Disroot Polls**|
+|Nextcloud:|**Disroot Cloud**|
+|Nextcloud Kalender-App|**Disroot Calendar**|
+|Nextcloud Notizen-App|**Disroot Notes**|
+|Nextcloud Kontakt-App|**Disroot Contacts**|
+
+Auf diese Weise, wenn die Bezeichnungen den Regeln entsprechen, ist es einfacher zu "*suchen und ersetzen*" :wink:
+
+
+# Video How-to's
+
+Im Bezug auf Video-How-to's denken wir, dass der Inhalt im Sinne der Klarheit ebenfalls **auf ein Minimum reduziert** und **kurz** genug gehalten werden sollte, damit der Benutzer in die Lage versetzt wird, seine Aktivitäten durchzuführen.
+
+WIe auch bei den Text-How-to's sollten die Video-Tutorials die folgende Struktur haben:
+
+1. **Metainformationen**
+2. **Inhalt**
+3. **Lizenzinformationen**
+
+Die Punkte **Metainformationen** and **Lizenzinformationen** werden durch die **Disroot**-Admins in der Videobeschreibung auf der Peertube-Instanz eingefügt, auf der die Videos gehostet werden.
+
+## Inhaltsbeschreibung
+
+Soweit möglich angeliefert werden mit:
+
+- Titel des How-to
+- Kurze Beschreibung, worum es geht
+- Softwareversion, auf die es sich bezieht
+
+Auf diese Weise können die **Disroot**-Admins diese Informationen in die Videobeschreibung auf der Peertube-Instanz einfügen.
+
+## Inhalt
+
+## Lizensierung von Video-How-to's
+
+Wie wir bereits zuvor erwähnt haben, werden die **Disroot**-Admins die Lizenzinformationen in die Videobeschreibung einfügen.
+
+Nichtsdestotrotz empfehlen wir, dass Du das folgende Bild am Ende Deines Videos für etwa 10 Sekunden mit einem fade in / fade out einsetzt:
+
+![](de/licensing-pic.png)
+
+Auf diese Weise sind die Lizenzinformationen immer noch vorhanden, wenn das Video heruntergeladen und an anderer Stelle wieder hochgeladen wird.
+
+---

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

@@ -0,0 +1,29 @@
+---
+title: 'How-to Contribute: Style guide'
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribute
+        - style
+page-toc:
+    active: true
+---
+
+# Style Guide
+
+![](h2_guide.jpg)
+
+The purpose of this section is to provide some general guidelines to keep in mind when writing or translating a tutorial for the **Disroot's [How-to site](https://howto.disroot.org)** and thus maintain a certain coherence in the structure of the documentation, both visually and in terms of writing.
+
+
+---
+# Table of Content
+- ### [Structure](structure)
+Directories and pages
+
+- ### [Content](content)
+Writing, translating and visual content

pages/04.Contribute/docs.en.md

@@ -1,5 +1,5 @@
 ---
-title: How-to: Contribute
+title: How-to Contribute
 published: true
 visible: true
 updated:
@@ -14,15 +14,21 @@ page-toc:
 
 # Contribute
 
-We think that knowledge is a collective construction. In other words, knowledge is the result of working together and cooperatively, as a community.
+![](contribute.jpg)
 
-Disroot platform cost money besides our most precious value: time. While the costs of maintaining all the services working on started being covered a few months ago thanks to donations, documentation requires time.
-*"A lot of precious time..."*
+We think that knowledge is a collective construction: the result of working together and cooperatively, as a community. And whether the contributions take the form of a donation, writing/translating a tutorial or reporting bugs, they are all essentially personal time devoted to others. A bit like love.
+
+The main goal of this part of the **Disroot** project is to provide clear and accessible information about how to use and configure the services we offer and, moreover, to do so in as many languages as possible.
+It consists mostly of guides and tutorials that evolve as the software does. So we are always looking for help to check, write and translate howtos.
+
+So, for those of you who may want to contribute by donating your time and knowhow, we have tried to channel all the efforts through this section.
 
-For those users who may want to contribute to Disroot by donating their time and knowhow, we've tried to channel all the efforts through this section.
 Here you'll find basic information and guidelines for different ways to contribute, from feedback to write a how-to or translate them to your language.
 
-Thanks to all of you who support and collaborate with Disroot.
+---
 
+# Table of Contents
 
-![](contribute.png)
+## · [Howto Procedure & Tools](procedure)
+## · [Git: Configuration & set-up](git)
+## · [Working with a text editor](git/editors)

pages/archive/Contribute.Old/00.ways2contribute/docs.fr.md.orig

@@ -0,0 +1,39 @@
+---
+title: "Contribuer au How-to: Choisissez la voie"
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuer
+page-toc:
+    active: false
+---
+
+# Comment contribuer aux Howto's ?
+
+Voici quelques moyens que vous pouvez choisir :
+
+#### [GIT](/contribute/git)
+Vous pouvez travailler hors ligne, en rédigeant un mode d'emploi ou en améliorant un mode d'emploi existant, puis " pousser " les modifications via Git.<br><br>**Niveau technique requis** : Basique.
+
+#### [PAD](/contribute/pad)
+Vous pouvez travailler sur un fichier texte collaboratif en ligne, en rédigeant ou modifiant un how-to, puis en communiquant avec l'équipe HowTo de Disroot.<br><br>**Niveau technique requis** : Aucun.
+
+#### [EMAIL](/contribute/email)
+Vous pouvez écrire ou modifier un mode d'emploi comme vous le souhaitez, et nous envoyer un courriel avec le travail terminé. Si vous avez des suggestions ou des commentaires sur les H2, vous pouvez également communiquer avec nous par ce biais. <br><br>**Niveau technique requis** : Basique.
+
+#### [FORUM](/contribute/forum)
+Grâce au forum, vous pouvez télécharger, rédiger ou partager un mode d'emploi, mais aussi faire des suggestions, nous donner votre avis, etc. <br><br>**Niveau technique requis** : Basique.
+
+#### [XMPP](/contribute/xmpp)
+Vous pouvez communiquer avec nous sur notre salle XMPP How-To **Disroot**.<br><br>**Niveau technique requis** : très basique.
+
+----
+### [Traductions Disroot](/contribute/translations_procedure)
+Si vous voulez collaborer en traduisant les **HowTo Disroot** dans votre langue, veuillez consulter ce guide.
+
+### [Guide de style pour les How-To Disroot](/contribute/styleguide)
+Quelques directives de base concernant le contenu et les critères de style pour les modes d'emploi.

pages/archive/Contribute.Old/01.git/docs.fr.md.orig

@@ -0,0 +1,30 @@
+---
+title: Contribuer au How-to: Git
+published: true
+visible: true
+updated:
+taxonomy:
+    category:
+        - docs
+    tags:
+        - contribuer
+        - git
+page-toc:
+    active: false
+---
+
+
+![](en/git.png)
+
+# Qu'est-ce que git ?
+
+**Git** est un système de contrôle de version distribué, un outil de suivi des fichiers, du code et du contenu. Il permet à plusieurs personnes de travailler sur les codes et de suivre toutes les modifications en même temps avec une copie du projet dans tous les ordinateurs des développeurs. Il est très populaire parmi les développeurs et les administrateurs système, mais ses fonctionnalités peuvent être facilement appliquées partout où l'historique des modifications et la possibilité de soumettre du contenu et de collaborer en groupe sont nécessaires.
+
+Nous l'utilisons comme outil principal pour le développement de nos howtos et de notre site web. Et c'est celui que nous préférons, principalement parce que son utilisation est assez simple, rapide et très puissante. En outre, nous utilisons également **Atom**, un éditeur de texte riche et de code, bien que vous puissiez utiliser l'éditeur de texte de votre choix.
+
+Dans les pages suivantes, nous verrons comment les utiliser pour la documentation de **Disroot**.
+
+### [Git: Bases des How-to](how-to-use-git)
+
+----
+Vous pouvez trouver plus d'informations sur git [ici](https://en.wikipedia.org/wiki/Git) et dans [cet article](https://medium.freecodecamp.org/what-is-git-and-how-to-use-it-c341b049ae61?gi=805863b5a598).