how-to-use-git partially translated to ger

english doc minor spelling correction
This commit is contained in:
shadowsword 2019-08-26 23:19:04 +02:00 committed by Fede
parent 8bd9da0b7b
commit 86e314ed2b
54 changed files with 919 additions and 26 deletions

View File

@ -0,0 +1,40 @@
---
title: "How-to: Mitwirken - Wähle Deinen Weg"
published: true
visible: true
updated:
taxonomy:
category:
- docs
tags:
- contribute
- Mitwirken
page-toc:
active: false
---
# Wie kann ich an den How-to's mitwirken?
Es gibt verschiedene Wege, zwischen denen Du wählen kannst:
#### [GIT](/contribute/git)
Du kannst offline arbeiten, ein neues How-to schreiben oder ein bestehendes verbessern, und die Änderungen dann durch git zu **Disroot** "schieben"<br><br>**erforderliche Technikkenntnisse**: Anfänger.
#### [PAD](/contribute/pad)
Du kannst an einer gemeinschaftlichen Online-Textdatei arbeiten, ein How-to schreiben oder verändern, und dann mit dem **Disroot** How-to-Team kommunizieren.<br><br>**erforderliche Technikkenntnisse**: Keine.
#### [EMAIL](/contribute/email)
Du kannst ein How-to auf die von Dir gewünschte Art und Weise schreiben oder verändern und uns eine Email mit der fertigen Arbeit schicken. Wenn Du Vorschläge oder Feedback zu den How-to's loswerden möchtest, kannst Du ebenfalls auf diesem Weg mit uns in Kontakt treten. <br><br>**erforderliche Technikkenntnisse**: Anfänger.
#### [FORUM](/contribute/forum)
Über das Forum kannst Du ein How-to hochladen, schreiben oder teilen und außerdem Vorschläge machen, uns ein Feedback geben, etc. <br><br>**erforderliche Technikkenntnisse**: Anfänger.
#### [XMPP](/contribute/xmpp)
Du kannst über unsere **Disroot** How-To Gruppe mit uns kommunizieren.<br><br>**erforderliche Technikkenntnisse**: Absoluter Anfänger.
----
### [Disroot Übersetzungen](/contribute/translations_procedure)
Wenn Du mitwirken möchtest, indem Du **Disroot How-to's** in Deine Sprache übersetzt, sieh Dir bitte diese Anleitung an.
### [Disroots How-To Gestaltungsrichtlinie](/contribute/styleguide)
Einige grundlegende Richtlinien für den Inhalt und Formvorgaben für die How-to's.

Binary file not shown.

After

Width:  |  Height:  |  Size: 11 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 12 KiB

View File

@ -0,0 +1,31 @@
---
title: How-to Mitwirken Git
published: true
visible: true
updated:
taxonomy:
category:
- docs
tags:
- contribute
- git
- mitwirken
page-toc:
active: false
---
![](de/git.png)
# Was ist git?
**git** ist eine freie Software zur verteilten Versionsverwaltung, ein Werkzeug, um Dateien, Code und Inhalt zu verfolgen. Es ermöglicht vielen Menschen gleichzeitig, an den Codes zu arbeiten und allen Änderungen zu folgen, indem auf den Computern der Entwickler eine Kopie des Projekts vorliegt. git ist sehr beliebt bei Entwicklern und Systemadministratoren. Darüber hinaus können seine Funktionen überall dort Anwendung finden, wo der Verlauf von Änderungen und die Möglichkeit, Inhalt einzureichen und in Gruppen zusammenzuarbeiten, nötig sind.
Wir nutzen git als Hauptwerkzeug für die Entwicklung unserer How-to's und Website. Es ist auch das Werkzeug, das wir bevorzugen, hauptsächlich, weil seine Anwendung wirklich einfach und schnell und es gleichzeitig sehr mächtig ist. Für die Bearbeitung der Texte nutzen wir **Atom**, einen mächtigen Text- und Code-Editor, wobei Du natürlich einen beliebigen Texteditor Deiner Wahl benutzen kannst.
Auf den nächsten Seiten werden wir Dir zeigen, wie Du diese für die Arbeit an der Dokumentation von **Disroot** nutzen kannst.
### [git: Basics How-to](how-to-use-git)
----
Mehr Informationen über git findest Du [hier](https://de.wikipedia.org/wiki/Git) und in [diesem Onlinebuch](https://git-scm.com/book/de/v2).

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 37 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 287 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 537 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 531 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 259 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.0 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.5 KiB

View File

@ -0,0 +1,26 @@
---
title: 'Vorlage' <!-- Titel ändern -->
visible: false <!-- ändere visibility in tree: true or false -->
page-toc:
active: true
published: true
taxonomy:
category:
- docs
---
---
|```Meta information```|
|:--:|
|```Dieses How-to wurde zuletzt am ``` **date here** *(Datum kann im Format mm-dd-yy oder yyyy-mm-dd dargestellt werden, z.B.: 01-04-19 or 2019-01-04)* ``` und bezieht sich auf:```<br>**Software name: version 00.0.0-0 for GNU/Linux distro:**<br> <!-- ändere Software und Version auf die aktuelle Software -->|
**Wichtig:**```When sich das How-to auf eine ältere als die von ```**Disroot**``` derzeit bereitgestellte oder von Dir lokal genutzte Softwareversion bezieht, könnten einige Funktionen nicht beschrieben sein oder sich kleinere Teile der bereitgestellten Informationen geändert haben. ```<br> **Disroot's** ``` How-to-Dokumentation ist ein Gemeinschaftsprojekt. Wir versuchen stets so gut es möglich ist, sie auf dem neuesten STand zu halten.```
---
# Hier kommt der tatsächliche Inhalt des How-to hin
---
<center><a rel="license" href="http://creativecommons.org/licenses/by- sa/4.0/"><img alt="Creative Commons License" style="border-width:0" src="https://i.creativecommons.org/l/by-sa/4.0/88x31.png" /></a><br />This work is licensed under a <br><a rel="license" href="http://creativecommons.org/licenses/by-sa/4.0/">Creative Commons Attribution-ShareAlike 4.0 International License</a>.</center>
---

View File

@ -0,0 +1,168 @@
---
title: How-to Mitwirken Git Basics
published: true
visible: false
updated:
last_modified: "21 August 2019"
app: Git and Atom
app_version: 1.40
taxonomy:
category:
- docs
tags:
- contribute
- git
- mitwirken
page-toc:
active: true
---
# git Basics
Wir werden in diesem Tutorial nicht alle Aspekte der Arbeit mit git abdecken. Es gibt eine Menge umfangreicher Tutorials und Bücher zu diesem Werkzeug und unser Ziel in diesem Tutorial ist es, Dir einen kurzen und einfachen Einstieg zu bieten, damit Du an Tutorials und Übersetzungen für **Disroot** mitwirken kannst.
# Bevor Du mit der Arbeit beginnst
## git installieren
Da alle Änderungen auf Deinem lokalen Rechner stattfinden, musst Du [git installieren](https://gist.github.com/derhuerst/1b15ff4652a867391f03), sowohl um Deine Änderungen einreichen als auch die Änderungen von anderen synchronisieren zu können. Je nach Betriebssystem können sich die einzelnen Schritte zur Installation von git unterscheiden. Folge daher am besten dem Link oder suche nach einer spezifischen Dokumentation, die zu Deinem Betriebssystem passt.
## Atom installieren
Wenn Du ihn bisher noch nicht hast, wird es jetzt Zeit, [Atom](https://atom.io) zu installieren. **Atom** ist ein funktionsreicher Texteditor mit spezieller git-Integration. Wenn Dein Betriebssystem auf der Installationsseite nicht automatisch erkannt wird oder aufgeführt wird, wenn Du auf die[Atom](https://atom.io)-Website gehst, sieh unter [Other platforms](https://github.com/atom/atom/releases/latest) nach. Arch-Nutzer können **Atom** ganz einfach installieren, indem sie `pacman -S atom` oder einen anderen Paketmanager ihrer Wahl nutzen.
## Einen Account auf einer git-Instanz erstellen
Nach der Installation von **git** und **Atom** benötigst Du einen Account auf der git-Instanz, die **Disroot** nutzt. Unglücklicherweise ist git noch kein mit **Disroot** verbündeter Service, daher musst Du Dir einen eigenen Account erstellen und kannst nicht Deinen **Disroot**-Account nutzen.
Wir hosten all unsere Arbeit auf der gitlab-Instanz unserer Freunde bei der **FOSS Community India**.
Um einen Account zu erstellen, gehe einfach zur [FOSS Community India](https://git.fosscommunity.in) und registriere Dich. Neben der Registrierung kannst Du auch einen ID-Provider wie gitlab.com, Github, Twitter, Gitbucket oder Google nutzen, falls Du auf einer dieser Plattformen bereits einen Account hast.
## Den Arbeitsplatz vorbereiten
Git trägt von Natur aus die Zusammenarbeit in seinem Herzen. Als erstes benötigst Du eine Kopie aller Dateien des Projekts auf Deiner lokalen Festplatte. Dieser Vorgang wird "*Klonen eines Repository*" genannt. Alle Veränderungen finden auf Deinem lokalen Rechner statt (die meiste Arbeit wird offline erledigt). Wenn Du der Meinung bist, mit den Änderungen fertig zu sein, kannst Du sie zurück zum Repository auf dem Server senden/synchronisieren (*push*).
### Das **Howto Disroot** Repository klonen
Um das Repository zu klonen, öffne einfach ein Terminal, gehe zu dem Verzeichnis, in welches Du das Repository klonen möchtest und starte das `git clone <url>`-Kommando, wobei grundsätzlich *<url>* die Adresse des Repository ist, das Du klonen möchtest. In unserem Fall wäre das:
`git clone https://git.fosscommunity.in/disroot/howto`
Es wird nun eine 1:1-Kopie des Repository auf Deiner Festplatte erstellt.
Später kannst Du dieses Verzeichnis an jeden Platz auf Deinem Rechner verschieben, wo auch immer Du möchtest.
### Zugang zum Repository
Um Änderungen beim **Disroot** git-Repository einreichen zu können, musst Du einen Zugang beantragen. Dies kannst Du über unsere [git-Projektseite](https://git.fosscommunity.in/disroot/howto) machen.
![](de/git-request_access.png)
Wenn ein Administrator Dir Zugang gewährt hat, kannst Du Deine Änderungen auf den Server schieben (*push*).
!! ![](/home.icons/note.png)
!! TIPP: Du kannst auch schon anfangen zu arbeiten, bevor Dir Zugang gewährt wurde. Die Änderungen finden nur auf Deinem lokalen Rechner statt.
# Mit der Arbeit beginnen
Jetzt kannst Du **Atom** starten.
Gehe zum Menüpunkt ***File***, wähle `Open Folder` und suche das Verzeichnis, das Du gerade geklont hast (*howto*).
Die Benutzeroberfläche von **Atom** ist übersichtlich und einfach zu verstehen. Auf der linken Seite findest Du die Ordnerstruktur der Projekts, in der Mitte befindet sich das Fenster, in dem Du die Dateien bearbeitest, und in der unteren Leiste zeigt Dir die Anzahl der geänderten Dateien, die aktuelle "branch" und die schnelle Möglichkeit an, Dateien von git zu ziehen oder zu git zu schieben (*push/pull*).
![](de/atom1.png)
Du kannst gleichzeitig mehrere Dateien öffnen und in ihnen arbeiten, indem Du mehrere Tabs oder einen Split-Screen öffnest.
Ungespeicherte Dateien mit lokalen Änderungen werden mit einem blauen Punkt markiert (abhängig von dem Theme, das Du nutzt). Um die Änderungen zu speichern, benutze das *File*-Menü oder den Shortcut *Strg+s*.
**Bevor** Du mit der Arbeit beginnen kannst, musst Du noch eine eigene **Branch** erstellen.
## Branches erstellen
Branches sind im Prinzip Dein eigener, privater Arbeitsplatz.
Jedes git-Projekt hat seine eigene **Master**-Branch. Die Master-Branch ist die Hauptkopie des Projekts, die Produktivversion. Diese Branch wird automatisch mit der Website synchronisiert, jede Änderung an dieser Branch wird also sofort auf der Website umgesetzt. Aus diesem Grund sind die Änderungsrechte an der **Master**-Branch auf die Eigentümer des Projekts beschränkt.
Um mit der Arbeit zu beginnen, erstelle Deine eigene Branch. Diese wird im Prinzip ein Klon der **Master**-Branch sein.
In **Atom** klickst DU in der unteren rechten Ecke auf **master** (oder einen anderen Branch-Namen) und wählst ***New Branch***. Überlege Dir einen Name für Deine Branch, irgendetwas Einfaches, anhand dessen die anderen Beteiligten erkennen können, woran Du arbeitest. Wenn Du zum Beispiel an einem Nextcloud How-to arbeiten willst, kannst Du Deine Branch "nextcloud_howto" nennen. Bei der Namensvergabe sind einige Zeichenregeln zu beachten. Nutze keine Sonderzeichen und verbinde die einzelnen Worte mit "\_", dann sollte es keine Probleme geben.
Drücke **Enter** auf Deiner Tastatur, wenn Du soweit bsit.
![](de/atom-branch1.gif)
Jetzt musst Du Deine neue Branch noch veröffentlichen (**publish**), damit sie auch auf dem Server erstellt wird. **Atom** wird Dich nach Deinen Anmeldedaten fragen, gib hier die Daten für unsere git-Instanz ein.
![](de/publish.png)
In diesem Menü kannst Du auch zwischen Branches wechseln. Die aktuelle Arbeits-Branch wird Dir in der Fußleiste angezeigt. Wenn Du darauf klickst, werden Dir die anderen lokalen Branches angezeigt.
![](de/atom-branch2.gif)
Wenn Du Deine Branch erstellt und veröffentlicht hast und Deine aktuelle Arbeits-Branch ausgewählt ist, kannst Du neue Dateien erstellen, bestehende bearbeiten, etc.
## Änderungen übergeben
Deine Arbeit, das Erstellen neuer oder Übersetzen bestehender Tutorials, findet nun auf Deinem Computer statt. Abgesehen vom Speichern der Änderungen auf Deinem Speichermedium kannst/solltest Du Deine Änderungen auch übergeben (**commit**).
Das Übergeben der Änderungen synchronisiert die von dir erledigte Arbeit mit Deiner Branch auf dem git-Server. Ein "Commit" ist also ein Satz erstellter oder veränderter Dateien. Wenn die Branch in dem Repository nicht existiert, wird sie erstellt und alle Deine Änderungen und neuen Dateien werden auf den Server hochgeladen. Auf diese Weise kannst Du an verschiedenen Geräten an Deinen Dateien arbeiten oder andere Entwickler können übernehmen und bei der Arbeit an Deiner Branch helfen.
Um Deine Änderungen zu übergeben musst Du:
- Sicherstellen, dass alle Dateien gespeichert sind (ohne blauen Markierungspunkt)
- Die geänderten Dateien, die übergeben werden sollen, bereitstellen (**stage**)
- Eine **Übergabenachricht** schreiben (eine kurze und knackige Zusammenfassung der Änderungen)
- Den ***commit***-Button klicken
![](de/atom-commit.gif)
Wenn Deine Dateien bereitgestellt sind, ist es Zeit, sie auf den Server zu schieben (**push**):
- Öffne das ***Push/Pull***-Popup-Fenster
- Klicke auf ***Push***
![](de/atom-push.gif)
## Zusammenführung beantragen (Merge request)
Wenn Du denkst, dass Deine Arbeit beendet und bereit für die Veröffentlichung ist, wird es Zeit, sie mit der **Master**-Branch zusammenzuführen.
![](de/note.png) <br>**WICHTIG!!!**
Während Du an Deiner Branch arbeitest, kann es parallel zu weiteren Änderungen durch andere Nutzer kommen, insbesondere wenn Du bestehende Dateien bearbeitest. Wenn diese Änderungen anderer Nutzer bereits mit der Masterbranch zusammengeführt wurden, kann es passieren, dass diese Änderungen in Deiner Version noch nicht enthalten sind. Versuchst Du nun, Deine Änderungen der nun veralteten Dateien mit der Masterbranch zusammenführen zu lassen, kann es ziemlich chaotisch werden.
![](de/git-merge_chaos.gif)
Glücklicherweise ist git in der Lage, Versionen zu vergleichen und Deine Änderungen in die aktualisierten Dateien einzufügen. Dazu musst Du jedoch, bevor Du eine Zusammenführung beantragst (**Create Merge Request**), Deine Arbeitsbranch aktualisieren. Durch diese Vorgehensweise kannst Du den Admins und Dir selbst eine Menge unnötiger Arbeit ersparen:
- Stelle zunächst sicher, dass alle Änderungen übergeben wurden
- Öffne ein Terminal (Linux)
- Wechsle in die **Master Branch**: ***git checkout master***
- Aktualisiere Deine lokale **Master Branch**: ***git pull***
- Wechsle zurück in Deine Arbeitsbranch: ***git checkout <Branch_Name>***
- Aktualisiere die Arbeitsbranch aus der lokalen **Master Branch**: ***git rebase master***
- Verifiziere alle Änderungen und übergib die Dateien an den Server
Nun kannst Du loslegen mit den finalen Schritten, um Deine Dateien mit der **Master Branch** zusammenzuführen:
- Stelle zunächst sicher, dass alle Änderungen übergeben wurden
- Log Dich in unsere [git-Instanz](https://git.fosscommunity.in) ein
- Wenn Du Änderungen zu unserer Branch geschoben hast, wirst Du in der rechten oberen Ecke einen **"Create Merge Request"**-Button sehen. Klicke ihn an, es öffnet sich ein Formular
- Füge einen Titel hinzu (falls er nicht automatisch eingefügt wurde)
- Füge eine Beschreibung hinzu (falls sie nicht automatisch hinzugefügt wurde)
- Überprüfe, dass die Quelle (**source branch**) diejenige ist, von der aus zusammengeführt werden soll (die Branch, in der Du gearbeitet hast)
- Überprüfe, dass das Ziel (**target branch**) die Branch ist, in der die Änderungen zusammengeführt werden sollen (normalerweise die **Master**-Branch)
- Die Checkbox **Delete source branch when merge request is accepted** auszuwählen ist eine gute Idee, wenn Du mit Deiner Arbeit an Deiner Branch vollständig fertig bist
![](de/git-merge_request.gif)
Wenn Du eine Zusammenführungsanfrage erstellt hast, wird sie durch die **Disroot**-Admins überprüft und, wenn alles in Ordnung ist, können sie Deine Übergabe genehmigen. Das heißt, dass Deine Änderungen mit der **Master**-Branch zusammengeführt werden und ab sofort auf der Website sichtbar sind.
Wenn es irgendwelche Probleme gibt, können die Admins Dich bitten, etwas nachzuarbeiten. Wenn Du Deine Korrekturen erledigt hast und die Dokumentation den **Disroot**-Richtlinien entspricht, wird Die Übergabe Deiner Änderungen stattfinden. Es ist nicht nötig, dass Du eine neue Zusammenführungsanfrage erstellst.
## Änderungen vom Server ziehen
Wenn Du Deine lokale **Master**-Branch und Deine lokalen Arbeitsbranches aktuell halten möchtest (was DU definitiv tun solltest, da es ansonsten ein ziemlich großes Durcheinander geben kann), muss Du, am besten regelmäßig, Änderungen vom Server ziehen.
Jedes Mal, wenn Änderungen von einem Beteiligten mit der **Master**-Branch zusammengeführt werden, sollte jeder die Änderungen auch in seine lokalen Branches ziehen. Dann kannst Du auch ganz einfach sehen, welche Änderungen aktuell durchgeführt wurden und welchen EInfluss sie eventuell auf Deine Arbeit haben. In der **Master**-Branch halten wir eine Datei vor, die **CHANGELOG** genannt wird und in der alle wichtigen Änderungen an den How-to's festhalten.
Das Ziehen von Änderungen sollte regelmäßig stattfinden (insbesondere, bevor Du anfängst, an einer neuen Branch zu arbeiten).
- Öffne das ***Push/Pull*** Popup-Fenster
- Klicke auf ***Pull***
![](de/atom-pull.gif)
## Vorlage für die How-to's
Du kannst Dir [hier](de/template.txt) den Inhalt kopieren und Deine eigene How-to-Datei erstellen.

View File

@ -3,9 +3,9 @@ title: How-to Contribute: Git Basics
published: true
visible: false
updated:
last_modified: "17 April 2019"
last_modified: "22 August 2019"
app: Git and Atom
app_version: 1.33
app_version: 1.40
taxonomy:
category:
- docs
@ -95,10 +95,10 @@ Switching between branches can also be done from that menu. Current working bran
Once the branch is created and published, and you have change the current work on this new branch, you can create new files, modify existing ones, etc.
## Commiting changes
## Committing changes
Now you're working on your computer creating new tutorials or translating existing ones. Apart from saving changes to your laptop, you can/should also **commit** your changes.
Commiting changes syncs the work you've done on your branch to the git server. So a commit is a set of files created of modified. If the branch doesn't exist on repository, it will be created and all your modifications and new files will be uploaded to the server. In that case you can work on your files on multiple machines, or other people can take over, help working on your branch.
Committing changes syncs the work you've done on your branch to the git server. So a commit is a set of files created or modified. If the branch doesn't exist on repository, it will be created and all your modifications and new files will be uploaded to the server. In that case you can work on your files on multiple machines, or other people can take over, help working on your branch.
To commit your changes need to:
- Make sure all files are saved
@ -108,7 +108,7 @@ To commit your changes need to:
![](en/atom-commit.gif)
Once the files are commited, it's time to **push** (send) them to the server:
Once the files are committed, it's time to **push** (send) them to the server:
- Open Push/Pull popup window
- Press Push
@ -118,7 +118,25 @@ To commit your changes need to:
## Merge request
Once you think your work is finished and ready to be published on the website, it's time to merge it to the **master branch**.
- First of all is to make sure all the changes are commited.
![](en/note.png) <br>**NOTE!!!**
While you are working on your branch, other users possibly commit and merge their own changes, esp. if you are working on existing files. If those changes from the other users have already been merged to the **master branch**, the version of the files you changed may no longer be the actual ones and therefore the changes from other users may not be included in your files. In that state, if you want to let your changes be merged to the **master branch**, this process may be very chaotic.
![](en/git-merge_chaos.gif)
Luckily git is able to compare versions and to insert your changes into the updated file versions. To trigger this, you need to update your branch **before** you **Create** a **Merge Request**. By doing this you will spare the admins and yourself a lot of needless work:
- First of all is to make sure all the changes are committed
- Open Terminal (Linux)
- Switch to **Master Branch**: ***git checkout master***
- Update **Master Branch**: ***git pull***
- Switch to working branch: ***git checkout <Branch_Name>***
- Update your working branch from **Master Branch**: ***git rebase master***
- Verify the changes and commit the changes to the Server
Now you can start with the final steps of merging your files to the **Master Branch**:
- First of all is to make sure all the changes are committed.
- Login to https://git.fosscommunity.in
- If you pushed any changes to the server on your branch, in the top right you'll see a **"Create Merge Request"** button that will open the merge request form.
- Add a title
@ -129,7 +147,7 @@ Once you think your work is finished and ready to be published on the website, i
![](en/git-merge_request.gif)
Once you've created a merge request, it will be reviewed by **Disroot** admins and, if it's all right, they can aprove your commit then. This means your changes will be merged with the master branch and therefore visible on the website.
Once you've created a merge request, it will be reviewed by **Disroot** admins and, if it's all right, they can approve your commit then. This means your changes will be merged with the master branch and therefore visible on the website.
If there's any issue, admins could request you to correct something. Once all the corrections are made and the documentation meets the **Disroot** guidelines, your merge request will be pulled to the master.

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.6 MiB

View File

@ -0,0 +1,19 @@
---
title: How-to Mitwirken Pads
published: false
visible: true
updated:
taxonomy:
category:
- docs
tags:
- contribute
- mitwirken
page-toc:
active: false
---
# Ein gutes Beispiel
Hier haben wir ein gutes Beispiel für die Arbeit, die noch nötig ist. Leider hat sich noch niemand bereit gefunden, ein How-to für diesen Bereich zu schreiben. Vielleicht möchtest Du dies ja zu Deinem ersten Projekt machen?!

View File

@ -11,4 +11,8 @@ taxonomy:
page-toc:
active: false
---
ToDo
# Open Task
This is a good example for the work still to do. Until now, no one was found to write this Tutorial. Maybe you want to make it your first project?

View File

@ -0,0 +1,20 @@
---
title: How-to Mitwirken Email
published: true
visible: false
updated:
taxonomy:
category:
- docs
tags:
- contribute
- email
- mitwirken
page-toc:
active: false
---
# Ein gutes Beispiel
Hier haben wir ein gutes Beispiel für die Arbeit, die noch nötig ist. Leider hat sich noch niemand bereit gefunden, ein How-to für diesen Bereich zu schreiben. Vielleicht möchtest Du dies ja zu Deinem ersten Projekt machen?!

View File

@ -12,4 +12,8 @@ taxonomy:
page-toc:
active: false
---
ToDo
# Open Task
This is a good example for the work still to do. Until now, no one was found to write this Tutorial. Maybe you want to make it your first project?

View File

@ -0,0 +1,21 @@
---
title: How-to Mitwirken Forum
published: false
visible: true
updated:
last_modified: "July 2019"
taxonomy:
category:
- docs
tags:
- contribute
- forum
- mitwirken
page-toc:
active: false
---
# Ein gutes Beispiel
Hier haben wir ein gutes Beispiel für die Arbeit, die noch nötig ist. Leider hat sich noch niemand bereit gefunden, ein How-to für diesen Bereich zu schreiben. Vielleicht möchtest Du dies ja zu Deinem ersten Projekt machen?!

View File

@ -13,4 +13,8 @@ taxonomy:
page-toc:
active: false
---
ToDo
# Open Task
This is a good example for the work still to do. Until now, no one was found to write this Tutorial. Maybe you want to make it your first project?

View File

@ -0,0 +1,22 @@
---
title: How-to Mitwirken XMPP
published: false
visible: true
updated:
last_modified: "July 2019"
taxonomy:
category:
- docs
tags:
- contribute
- xmpp
- chat
- mitwirken
page-toc:
active: false
---
# Ein gutes Beispiel
Hier haben wir ein gutes Beispiel für die Arbeit, die noch nötig ist. Leider hat sich noch niemand bereit gefunden, ein How-to für diesen Bereich zu schreiben. Vielleicht möchtest Du dies ja zu Deinem ersten Projekt machen?!

View File

@ -14,4 +14,8 @@ taxonomy:
page-toc:
active: false
---
ToDo
# Open Task
This is a good example for the work still to do. Until now, no one was found to write this Tutorial. Maybe you want to make it your first project?

Binary file not shown.

After

Width:  |  Height:  |  Size: 443 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 45 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 51 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 287 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 30 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 98 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 2.6 MiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 537 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 38 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 531 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 1.0 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 6.5 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 8.1 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 34 KiB

View File

@ -0,0 +1,111 @@
---
title: Übersetzungsschema
published: true
visible: true
updated:
taxonomy:
category:
- docs
tags:
- contribute
- style
- mitwirkung
- Übersetzung
- Stil
page-toc:
active: true
---
# Warum ein Übersetzungsschema?
Wir sind der Meinung, dass die Möglichkeit, allen Menschen in ihrer eigenen Sprache Zugriff auf Informationen zu ermöglichen, fundamental ist, um gemeinschaftliches Denken und Handeln zu fördern und zu beleben. Daher ist die Koordination der Menge an Informationen, die zu übersetzen sind, eine äußerst wichtige Aufgabe.
Das Übersetzungsschema besteht aus **vier** übergeordneten Schritten.
## Erstens: Einmalige Schritte
1. Erstelle Dir einen Account bei der [FOSS Community India](https://git.fosscommunity.in/users/sign_in)
2. Öffne ein Terminal und starte git<br>
`git init`<br>
3. Konfiguriere den git-Benutzernamen und -email<br>
`git config --global user.email user@email`<br>
`git config --global user.name "User Name"`<br>
## Zweitens: Einen zu übersetzenden Bereich auswählen
1. Melde Dich im [**Disroot Translations Board**](https://board.disroot.org/project/fede-disroot-translations/timeline) an
2. Wähle das **Epic** (*ein Satz User Stories*), das zu der Sprache gehört, in die Du übersetzen möchtest
3. Wähle die **User Story** (*der zu übersetzende Bereich*) und ordne ihn Dir zu (**assign**)<br>
![](de/assign.gif)
## Drittens: An der Übersetzung arbeiten
1. **Klone das Disroot How-to-Repository**<br>
a. Wechsel in das Verzeichnis, in dem Du arbeiten möchtest<br>
b. Klone das Repository<br>
`git clone https://git.fosscommunity.in/disroot/howto`
2. **Öffne den Atom-Texteditor**<br>
a. Gehe zu **File**, wähle **Add Project Folder** und wähle das Verzeichnis aus, in welches das Projekt geklont wurde.<br>
![](de/atom_interface1.png)<br>
b. Erstelle eine **Branch** (die Branchbezeichnung sollte dieses Format haben: Website_Bereich.zum.übersetzen_Sprache<br>
Zum Beispiel:<br>
howto_contribute_git_ES<br>
howto_email_webmail_IT)<br>![](de/branch_01.gif)<br>
c. Beginne mit der Arbeit an der Übersetzung<br>
d. Speichere die Datei nach dem Benennungsmuster "Dateiname.Dein-Sprachcode.md"<br>
Wenn Du zum Beispiel an einer deutschen Übersetzung einer Datei namens "docs.md" arbeitest, musst Du sie als "docs.de.md" abspeichern.
3. **Sende die Übersetzung**<br>
Wenn Du Deine Arbeit beendet hast, musst Du Deine Änderungen übersenden ("commit"). Ein commit ist ein Satz erstellter oder veränderter Dateien. Deine Änderungen übersendest Du wie folgt:<br>
a. Stelle sicher, dass alle Dateien gespeichert sind<br>
b. Nun musst Du alle Dateien, die Du übersetzt hast und an den Server übergeben willst, bereitstellen ("Stage")<br>
c. Schreibe eine Übersendungsnachricht (eine kurze und knackige Zusammenfassung Deiner Änderungen)<br>
d. Klicke den Button **Commit**<br>
![](de/commit.gif)<br>
Wenn die Dateien übersendet sind, musst Du sie noch auf den Server schieben ("push"):<br>
e. Öffne das **Push/Pull**-Popupfenster<br>
![](de/pull_push.png)<br>
f. Klicke auf **Push**<br>
![](de/push.gif)<br>
## Viertens: Die Zusammenführung der Übersetzungen beantragen
Der letzte Schritt besteht darin, die Zusammenführung Deiner Arbeit in der Master-Branch zu beantragen. Das heißt, wenn Deine Arbeit beendet ist und Du die Übersetzung an den Server übergeben hast, musst Du das **Disroot Übersetzungsteam** bitten, Deine Änderungen zu überprüfen und der Website hinzuzufügen.<br>
![](de/note.png) <br>**WICHTIG!!!**
Während Du an Deiner Branch arbeitest, kann es parallel zu weiteren Änderungen durch andere Nutzer kommen, insbesondere wenn Du bestehende Dateien bearbeitest. Wenn diese Änderungen anderer Nutzer bereits mit der Masterbranch zusammengeführt wurden, kann es passieren, dass diese Änderungen in Deiner Version noch nicht enthalten sind. Versuchst Du nun, Deine Änderungen der nun veralteten Dateien mit der Masterbranch zusammenführen zu lassen, kann es ziemlich chaotisch werden.
![](de/git-merge_chaos.gif)
Glücklicherweise ist git in der Lage, Versionen zu vergleichen und Deine Änderungen in die aktualisierten Dateien einzufügen. Dazu musst Du jedoch, bevor Du eine Zusammenführung beantragst (**Create Merge Request**), Deine Arbeitsbranch aktualisieren. Durch diese Vorgehensweise kannst Du den Admins und Dir selbst eine Menge unnötiger Arbeit ersparen:
- Stelle zunächst sicher, dass alle Änderungen übergeben wurden
- Öffne ein Terminal (Linux)
- Wechsle in die **Master Branch**: ***git checkout master***
- Aktualisiere Deine lokale **Master Branch**: ***git pull***
- Wechsle zurück in Deine Arbeitsbranch: ***git checkout <Branch_Name>***
- Aktualisiere die Arbeitsbranch aus der lokalen **Master Branch**: ***git rebase master***
- Verifiziere alle Änderungen und übergib die Dateien an den Server
Nun kannst Du loslegen mit den finalen Schritten, um Deine Dateien mit der **Master Branch** zusammenzuführen:
- Stelle zunächst sicher, dass alle Änderungen übergeben wurden
- Log Dich in unsere [git-Instanz](https://git.fosscommunity.in) ein
- Wenn Du Änderungen zu unserer Branch geschoben hast, wirst Du in der rechten oberen Ecke einen **"Create Merge Request"**-Button sehen. Klicke ihn an, es öffnet sich ein Formular
- Füge einen Titel hinzu (falls er nicht automatisch eingefügt wurde)
- Füge eine Beschreibung hinzu (falls sie nicht automatisch hinzugefügt wurde)
- Überprüfe, dass die Quelle (**source branch**) diejenige ist, von der aus zusammengeführt werden soll (die Branch, in der Du gearbeitet hast)
- Überprüfe, dass das Ziel (**target branch**) die Branch ist, in der die Änderungen zusammengeführt werden sollen (normalerweise die **Master**-Branch)
- Die Checkbox **Delete source branch when merge request is accepted** auszuwählen ist eine gute Idee, wenn Du mit Deiner Arbeit an Deiner Branch vollständig fertig bist
![](de/git-merge_request.gif)
Wenn Du eine Zusammenführungsanfrage erstellt hast, wird sie durch die **Disroot**-Admins überprüft und, wenn alles in Ordnung ist, können sie Deine Übergabe genehmigen. Das heißt, dass Deine Änderungen mit der **Master**-Branch zusammengeführt werden und ab sofort auf der Website sichtbar sind.
Wenn es irgendwelche Probleme gibt, können die Admins Dich bitten, etwas nachzuarbeiten. Wenn Du Deine Korrekturen erledigt hast und die Dokumentation den **Disroot**-Richtlinien entspricht, wird Die Übergabe Deiner Änderungen stattfinden. Es ist nicht nötig, dass Du eine neue Zusammenführungsanfrage erstellst.
<br>
Um einen besseren Überblick über die Arbeit mit git und Atom zu erhalten, schau Dir bitte auch [**dieses Tutorial**](https://howto.disroot.org/en/contribute/git/how-to-use-git) an.

View File

@ -63,7 +63,7 @@ For the purposes of this guide, we will assume that either you know what **git**
![](en/commit.gif)<br>
Once the files are commited, you have to "push" (send) them to the server:<br>
Once the files are committed, you have to "push" (send) them to the server:<br>
e. Open **Push/Pull** popup window<br>
![](en/pull_push.png)<br>
@ -72,7 +72,26 @@ For the purposes of this guide, we will assume that either you know what **git**
![](en/push.gif)<br>
## Fourth: Requesting the merge of the Translations
Final step is to request the merge of your work into the master branch. This means that once your finished and sent the translation, you need to request **Disroot Translation Team** to check if it's all right to finally add it to the site.<br>
Final step is to request the merge of your work into the master branch. This means that once you finished and sent the translation, you need to request **Disroot Translation Team** to check if it's all right to finally add it to the site.<br>
![](en/note.png) <br>**NOTE!!!**
While you are working on your branch, other users possibly commit and merge their own changes, esp. if you are working on existing files. If those changes from the other users have already been merged to the **master branch**, the version of the files you changed may no longer be the actual ones and therefore the changes from other users may not be included in your files. In that state, if you want to let your changes be merged to the **master branch**, this process may be very chaotic.
![](en/git-merge_chaos.gif)
Luckily git is able to compare versions and to insert your changes into the updated file versions. To trigger this, you need to update your branch **before** you **Create** a **Merge Request**. By doing this you will spare the admins and yourself a lot of needless work:
- First of all is to make sure all the changes are committed
- Open Terminal (Linux)
- Switch to **Master Branch**: ***git checkout master***
- Update **Master Branch**: ***git pull***
- Switch to working branch: ***git checkout <Branch_Name>***
- Update your working branch from **Master Branch**: ***git rebase master***
- Verify the changes and commit the changes to the Server
Now you can start with the final steps of merging your files to the **Master Branch**:
1. Login to https://git.fosscommunity.in<br>
At the top right you'll see a **Create Merge Request** button that will open the merge request form, click on it
2. Add a title

Binary file not shown.

After

Width:  |  Height:  |  Size: 960 B

Binary file not shown.

After

Width:  |  Height:  |  Size: 191 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 127 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 80 KiB

View File

@ -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 Taellen, 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. 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>
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.
---

View File

@ -20,11 +20,11 @@ The purpose of it is to help keep a similar structure to all the how-to's, and t
As we mentioned in our contribute page [here](/contribute/git/how-to-use-git), we work with Git, Atom text editor and Markdown Markup language as the tools to write them.
But if you're not feel comfortable with these tools you can just write a pad, email, etc. We'll take it all :smiley:
But if you're not feeling comfortable with these tools you can just write a pad, email, etc. We'll take it all :smiley:
## Pages
there are now two different templates for the howto pages, docs.md and docsparent.md. docparent.md will index all children pages that are marked indexed:true in the header, creating a menu of the related pages. if an image is placed in the folder of the child page, a thumbnail will show in the index (size 400x300)
There are currently two different templates for the howto pages, docs.md and docsparent.md. docparent.md will index all children pages that are marked indexed:true in the header, creating a menu of the related pages. If an image is placed in the folder of the child page, a thumbnail will show in the index (size 400x300)
# Page headers
@ -104,7 +104,7 @@ ________app_version: 15
# Content guide lines
We think that how-to's text content should be kept at the minimum for the clarity and portabilaty sake of it. In the ideal case, just the specific context necessary, the essential steps to do a task and, whenever it's possible, supported by visual aids (screenshots, gifs) showing how a task is being done.
We think that how-to's text content should be kept at the minimum for the clarity and portability sake of it. In the ideal case, just the specific context necessary, the essential steps to do a task and, whenever it's possible, supported by visual aids (screenshots, gifs) showing how a task is being done.
The content of a how-to then should meet the following criteria:
@ -139,7 +139,7 @@ Example:
#### Inline images
Images are centered by default in the bext line. To use an image inline, so on the same line of a sentence use {.inline} right after. Like in this example:
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}
@ -168,13 +168,13 @@ Writing this...
##### 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.
@ -285,7 +285,7 @@ This is a command line command: `sudo apt update`
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 refered as: **Disroot**, starting with capital letter and bold type.
- 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:
@ -313,13 +313,13 @@ This way, if the expressions are regular, it's easier to just do a "*Search and
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 folowing structure:
Same as the text how-tos, the tutorials should have the following structure:
1. **Meta Information**
1. **Meta information**
2. **Content**
3. **Licensing**
3. **Licensing information**
**Meta information** and **licensing information** will be place by the **Disroot** admins in the video description of the Peertube instance where the videos will be hosted.
**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
@ -335,12 +335,12 @@ So that they can be placed by **Disroot** admins on the video description at the
## Licensing of video how-to's
As we mentioned before, the licensing information will be placed by Disroot's Admins in the video description.
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
In this case if the video is downloaded and reuploaded somewhere else the license information is still there.
---

View File

@ -0,0 +1,29 @@
---
title: How-to: Mitwirken
published: true
visible: true
updated:
taxonomy:
category:
- docs
tags:
- contribute
- Mitwirken
page-toc:
active: false
---
# Mitwirken
Wir sind der Überzeugung, dass Wissen ein kollektives Konstrukt ist. Mit anderen Worten: Wissen ist das Ergebnis einer gemeinsamen und kooperativen Arbeit, als Gemeinschaft.
Die Disroot-Plattform kostet neben Geld auch eine unserer wertvollsten Ressourcen: Zeit. Während die Kosten für die Bereitstellung und Aufrechterhaltung aller Services seit ein paar Monaten dank Spenden gedeckt werden können, erfordert die Dokumentation Zeit.
*"Eine Menge kostbarer Zeit..."*
Für all die Benutzer, die ihren Beitrag zu **Disroot** durch eine Spende ihrer wertvollen Zeit und ihres nicht minder wertvollen Wissens leisten wollen, haben wir versucht, mit dieser gebündelten Dokumentation ein Eingangstor zur Mitwirkung an **Disroot** zu schaffen.
Hier findest Du grundlegende Informationen und Richtlinien zu den unterschiedlichen Möglichkeiten der Mitwirkung, ob nun per Feedback, dem Schreiben eines How-to's oder der Übersetzung eines solchen in Deine Sprache.
Unser Dank geht an all jene unter Euch, die **Disroot** unterstützen und daran mitwirken.
![](contribute.png)