chore(i18n,docs): processed translations (#45079)
This commit is contained in:
camperbot
GitHub
105
docs/i18n/german/FAQ.md
Normal file
105
docs/i18n/german/FAQ.md
Normal file
@ -0,0 +1,105 @@
|
||||
### GitHub und Open Source sind neu für mich. Wo sollte ich anfangen?
|
||||
|
||||
Lies unseren Leitfaden ["How to Contribute to Open Source"](https://github.com/freeCodeCamp/how-to-contribute-to-open-source). Es ist ein umfassendes Nachschlagewerk für einsteigerfreundliche Projekte. Und er enthält eine Menge Tipps für Open-Source-Beiträge.
|
||||
|
||||
### Was muss ich wissen, um zur Codebasis beizutragen?
|
||||
|
||||
freeCodeCamp läuft auf einem modernen JavaScript-Stack. Wenn du daran interessiert bist, zu unserer Codebasis beizutragen, solltest du mit JavaScript und einigen der von uns verwendeten Technologien wie Node.js, MongoDB, OAuth 2.0, React, Gatsby und Webpack vertraut sein.
|
||||
|
||||
### Kann ich die Ressourcen von freeCodeCamp übersetzen?
|
||||
|
||||
Ja - Du kannst zu jeder der über 30 Sprachen beitragen, die wir auf unserer Übersetzungsplattform aktiviert haben.
|
||||
|
||||
In einigen Sprachen haben wir von Nutzern erstellte Übersetzungen online. Wir haben vor, das freeCodeCamp in mehrere wichtige Weltsprachen zu lokalisieren. Du kannst alles darüber in unserer in unserer [Ankündigung ](https://www.freecodecamp.org/news/world-language-translation-effort) lesen.
|
||||
|
||||
Wenn du daran interessiert bist, zu Übersetzungen beizutragen, stelle bitte sicher, dass du [diesen Leitfaden](how-to-translate-files.md) zuerst gelesen hast.
|
||||
|
||||
### Kann ich Artikel für die freeCodeCamp News oder Videos für den YouTube-Kanal von freeCodeCamp beisteuern?
|
||||
|
||||
Ja - du kannst zu unserem Newsblog und unserem YouTube-Kanal beitragen.
|
||||
|
||||
Wenn du daran interessiert bist, Artikel für freeCodeCamp News zu schreiben, schau dir bitte diesen [Veröffentlichungsleitfaden](https://www.freecodecamp.org/news/how-to-write-for-freecodecamp/) an. Lies außerdem unseren [Stil-Leitfaden](https://www.freecodecamp.org/news/developer-news-style-guide/), denn er wird dir helfen, aussagekräftige und effektive Artikel zu schreiben.
|
||||
|
||||
Um uns zu helfen, Lehrvideos für unseren YouTube-Kanal zu erstellen, kannst du den [YouTube-Kanal-Leitfaden](https://www.freecodecamp.org/news/how-to-contribute-to-the-freecodecamp-community-youtube-channel-b86bce4c865/) hier einsehen.
|
||||
|
||||
### Wie kann ich einen neuen Fehler melden?
|
||||
|
||||
Wenn du glaubst, dass du einen Fehler gefunden hast, lies zuerst den ["Hilfe, ich habe einen Fehler gefunden"](https://forum.freecodecamp.org/t/how-to-report-a-bug/19543) Artikel und folge den Anweisungen darin.
|
||||
|
||||
Wenn du sicher bist, dass es sich um einen neuen Fehler handelt, kannst du einen neuen Issue auf GitHub erstellen. Gib so viele Informationen wie möglich an, damit wir den Fehler reproduzieren können. Wir haben eine vorgefertigte Issue-Vorlage, die dir dabei hilft.
|
||||
|
||||
Bitte beachte, dass diese GitHub Issues für Codebasis-bezogene Probleme und Diskussionen gedacht sind - nicht um Hilfe beim Programmieren zu bekommen. Im Zweifelsfall solltest du [Hilfe im Forum suchen](https://forum.freecodecamp.org), bevor du ein GitHub-Problem erstellst.
|
||||
|
||||
### Wie kann ich ein Sicherheitsproblem melden?
|
||||
|
||||
Bitte erstelle keine GitHub-Issues für Sicherheitsprobleme. Schicke stattdessen bitte eine E-Mail an `security@freecodecamp.org` und wir werden uns sofort darum kümmern.
|
||||
|
||||
### Ich bin ein Student. Kann ich für akademische Credits an einem Feature arbeiten?
|
||||
|
||||
Ja. Bitte beachte, dass wir nicht in der Lage sind, uns an Fristen oder Papierkram zu halten, die von deiner Hochschule oder Universität vorgeschrieben werden könnten. Wir erhalten viele Pull-Requests und Code-Beiträge von freiwilligen Entwicklern, und wir respektieren ihre Zeit und ihren Einsatz. Aus Respekt vor allen anderen Beiträgen werden wir keinen PR eine besondere Priorität einräumen, nur weil sie einen Schulbezug haben.
|
||||
|
||||
Wir bitten dich, vorausschauend zu planen und deine Beiträge zum Code in diesem Sinne zu gestalten.
|
||||
|
||||
### Was bedeuten die verschiedenen Labels, mit denen die Themen versehen sind?
|
||||
|
||||
Die Code-Maintainer [Sortieren](https://en.wikipedia.org/wiki/Software_bug#Bug_management) Issues und Pull Requests nach ihrer Priorität, Schwere und anderen Faktoren. Du kannst [hier](https://github.com/freecodecamp/freecodecamp/labels) ein komplettes Glossar mit ihren Bedeutungen finden.
|
||||
|
||||
### Wo fange ich an, wenn ich an einem Thema arbeiten will?
|
||||
|
||||
Du solltest über [**`help wanted`**](https://github.com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22help+wanted%22) oder [**`first timers only`**](https://github. com/freeCodeCamp/freeCodeCamp/issues?q=is%3Aopen+is%3Aissue+label%3A%22first+timers+only%22) Issues gehen, um einen schnellen Überblick darüber zu bekommen, was für dich zur Verfügung steht.
|
||||
|
||||
> [!TIP] **`help wanted`** Issues sind frei zugänglich und du musst nicht um Erlaubnis bitten, bevor du sie bearbeitest. Issues mit dem **`first timers only`**-Label sind jedoch spezielle Issues, die für Leute gedacht sind, die noch nicht zur freeCodeCamp Codebasis beigetragen haben.
|
||||
|
||||
### Ich habe einen Schreibfehler gefunden. Sollte ich ein Issue melden, bevor ich einen Pull Request erstellen kann?
|
||||
|
||||
Bei Schreibfehlern und anderen Änderungen am Wortlaut kannst du direkt Pull Requests öffnen, ohne zuerst ein Issue zu erstellen. Bitte vergewissere dich, dass du Details in der Pull Request-Beschreibung angibst, damit wir deinen Beitrag besser verstehen und überprüfen können - selbst wenn es nur eine kleine Änderung ist.
|
||||
|
||||
Bitte erstelle ein Issue, wenn du größere Aspekte der Codebasis oder des Studienplans diskutieren möchtest.
|
||||
|
||||
### Wie kann ich mir ein Issue zuweisen lassen?
|
||||
|
||||
Normalerweise weisen wir die Issues nur langjährigen Mitwirkenden zu. Stattdessen befolgen wir die folgende Richtlinie, um allen gerecht zu werden:
|
||||
|
||||
1. Wir werden höchstwahrscheinlich den ersten Pull Request mergen, der das Problem behebt.
|
||||
2. Wenn mehrere Mitwirkende etwa zur gleichen Zeit einen Pull Request für dasselbe Problem öffnen, geben wir dem Pull Request den Vorrang, der das Problem am besten löst. Einige der Dinge, die wir berücksichtigen:
|
||||
- Hast du auch Tests durchgeführt?
|
||||
- Hast du alle Anwendungsfälle erfasst?
|
||||
- Hast du sichergestellt, dass alle Tests erfolgreich waren und dass alles lokal funktioniert?
|
||||
3. Schließlich geben wir Pull Requests Vorrang, die unseren empfohlenen Richtlinien entsprechen.
|
||||
- Hast du die Checkliste für Pull Requests befolgt?
|
||||
- Hast du deinem Pull Request einen aussagekräftigen Titel gegeben?
|
||||
|
||||
### Ich bin daran interessiert, beim freeCodeCamp als Moderator zu mitzuwirken. Wo sollte ich anfangen?
|
||||
|
||||
Unsere Community-Moderatoren sind unsere Helden. Ihre freiwilligen Beiträge machen das freeCodeCamp zu einer sicheren und einladenden Gemeinschaft.
|
||||
|
||||
In erster Linie möchten wir, dass du ein aktiver Teilnehmer in der Gemeinschaft bist und dich an unseren [Verhaltenskodex](https://www.freecodecamp.org/news/code-of-conduct/) hältst (und ihn nicht nur durchsetzt).
|
||||
|
||||
Hier sind einige empfohlene Wege für einige unserer Plattformen:
|
||||
|
||||
- Ein **Discord/Chat**-Moderator zu sein, eine aktive Präsenz in unserem Chat zu haben und positiv auf andere einzugehen und gleichzeitig zu lernen und zu üben, wie man mit möglichen Konflikten umgeht, die entstehen können.
|
||||
- Ein **Forum**-Moderator zu sein, ähnlich wie ein Chat-Moderator, eine aktive Präsenz zu zeigen und mit anderen Forumspostern in Kontakt zu treten, andere in ihrem Lernprozess zu unterstützen und auf Wunsch auch Feedback zu geben. Sieh dir das [Das Handbuch für Unterforenleiter](https://forum.freecodecamp.org/t/the-subforum-leader-handbook/326326) für weitere Informationen an.
|
||||
- Als **GitHub**-Moderator hilfst du bei der Bearbeitung von GitHub-Issues, die aufgeworfen werden und versuchst (idealerweise), Lösungen für diese Issues vorzuschlagen, die dann von anderen (oder von dir selbst) aufgegriffen werden.
|
||||
|
||||
Sei insgesamt respektvoll gegenüber anderen. Wir sind Menschen überall auf der Welt. Mit Blick darauf denke auch daran, eine ermutigende oder unterstützende Sprache zu verwenden und achte auf die interkulturelle Kommunikation.
|
||||
|
||||
Wenn du das oben genannte **eine Weile lang konsequent praktizierst** und unsere anderen Moderatoren dich empfehlen, wird ein Mitarbeiter auf dich zukommen und dich in das Moderatorenteam aufnehmen. Open-Source-Arbeit ist freiwillige Arbeit und unsere Zeit ist begrenzt. Wir erkennen an, dass dies wahrscheinlich auch in deiner Situation der Fall ist. Deshalb betonen wir **konsequent** zu sein, anstatt sich rund um die Uhr (24/7) in der Community zu engagieren.
|
||||
|
||||
In unserem [Moderatorenhandbuch](https://contribute.freecodecamp.org/#/moderator-handbook) findest du eine ausführliche Liste mit weiteren Aufgaben und Erwartungen, die wir an unsere Moderatoren haben.
|
||||
|
||||
### Ich komme mit etwas nicht weiter, das in dieser Dokumentation nicht enthalten ist.
|
||||
|
||||
**Frag einfach nach Hilfe in:**
|
||||
|
||||
- Der `Contributors` Kategorie von [unserem Community Forum](https://forum.freecodecamp.org/c/contributors).
|
||||
- Dem `#Contributors` Kanal auf[ unserem Chat Server](https://chat.freecodecamp.org/channel/contributors).
|
||||
|
||||
Wir freuen uns, dir dabei zu helfen, einen Beitrag zu den Themen zu leisten, an denen du gerne arbeiten möchtest. Wenn du uns in den entsprechenden Issue Threads Fragen stellst, helfen wir dir gerne weiter. Achte darauf, dass du nach deiner Frage suchst, bevor du eine neue stellst.
|
||||
|
||||
Vielen Dank im Voraus für deine Höflichkeit und Geduld. Vergiss nicht, dass diese Community hauptsächlich von Freiwilligen betrieben wird.
|
||||
|
||||
### Zusätzliche Hilfe
|
||||
|
||||
Wenn du Fragen zum Stack, zur Architektur der Codebasis, zu Übersetzungen oder zu anderen Themen hast, kannst du dich gerne an unser Team [im Forum](https://forum.freecodecamp.org/g/team) wenden.
|
||||
|
||||
**Du kannst unserem Entwicklerteam eine E-Mail schicken an: `dev[at]freecodecamp.org`**
|
||||
37
docs/i18n/german/_sidebar.md
Normal file
37
docs/i18n/german/_sidebar.md
Normal file
@ -0,0 +1,37 @@
|
||||
- **Erste Schritte**
|
||||
- [Einführung](index.md "Zur FreeCodeCamp.org Community beitragen")
|
||||
- [Häufig gestellte Fragen](FAQ.md)
|
||||
- [Eine Schwachstelle melden](security.md)
|
||||
- **Mitwirkung an der Übersetzung**
|
||||
- [Helfe bei der Übersetzung von Ressourcen](how-to-translate-files.md)
|
||||
- [Helfe beim Korrekturlesen von Übersetzungen](how-to-proofread-files.md)
|
||||
- **Mitwirkung am Code**
|
||||
- [freeCodeCamp lokal einrichten](how-to-setup-freecodecamp-locally.md)
|
||||
- [Befolge die besten Programmierpraktiken (best practices)](codebase-best-practices.md)
|
||||
- [Eröffne einen Pull Request](how-to-open-a-pull-request.md)
|
||||
- [Arbeite an den Programmieraufgaben](how-to-work-on-coding-challenges.md)
|
||||
- [Arbeite an Praxisprojekten](how-to-work-on-practice-projects.md)
|
||||
- [Arbeite an den Tutorials mit CodeRoad](how-to-work-on-tutorials-that-use-coderoad.md)
|
||||
- [Arbeite an der lokalisierten Client-Web-App](how-to-work-on-localized-client-webapp.md)
|
||||
- [Arbeite an den Cypress Tests](how-to-add-cypress-tests.md)
|
||||
- [Arbeite an den Videoaufgaben](how-to-help-with-video-challenges.md)
|
||||
- [Arbeite an dem News Theme](how-to-work-on-the-news-theme.md)
|
||||
- [Arbeite an dem Docs Theme](how-to-work-on-the-docs-theme.md)
|
||||
- **Zusätzliche Leitfäden**
|
||||
- [Übersetzungen lokal testen](how-to-test-translations-locally.md)
|
||||
- [Verstehe die Dateistruktur des Studienplans](curriculum-file-structure.md)
|
||||
- [Ausgehende Emails lokal debuggen](how-to-catch-outgoing-emails-locally.md)
|
||||
- [freeCodeCamp auf Windows einrichten (WSL)](how-to-setup-wsl.md)
|
||||
|
||||
---
|
||||
|
||||
- **Handbücher** (für Mitarbeiter & Moderatoren)
|
||||
- [Moderatorenhandbuch](moderator-handbook.md)
|
||||
- [DevOps-Handbuch](devops.md)
|
||||
|
||||
---
|
||||
|
||||
- **Unsere Community**
|
||||
- [**GitHub**](https://github.com/freecodecamp/freecodecamp)
|
||||
- [**Discourse Forum**](https://freecodecamp.org/forum/c/contributors)
|
||||
- [**Chatserver**](https://chat.freecodecamp.org/home)
|
||||
134
docs/i18n/german/codebase-best-practices.md
Normal file
134
docs/i18n/german/codebase-best-practices.md
Normal file
@ -0,0 +1,134 @@
|
||||
# Best Practices für die Codebasis
|
||||
|
||||
## JavaScript allgemein
|
||||
|
||||
In den meisten Fällen warnt unser [Linter](how-to-setup-freecodecamp-locally.md#follow-these-steps-to-get-your-development-environment-ready) vor jeder Formatierung, die gegen die bevorzugte Vorgehensweise dieser Codebasis verstößt.
|
||||
|
||||
Es wird empfohlen, funktionale Komponenten gegenüber klassenbasierten Komponenten zu verwenden.
|
||||
|
||||
## Spezifisches TypeScript
|
||||
|
||||
### Migration einer JavaScript-Datei zu TypeScript
|
||||
|
||||
#### Beibehalten des Git-Dateiverlaufs
|
||||
|
||||
Manchmal führt das Ändern der Datei von `<Dateiname>.js` zu `<Dateiname>.ts` (oder `.tsx`) dazu, dass die ursprüngliche Datei gelöscht und eine neue erstellt wird, und manchmal ändert sich nur der Dateiname - im Sinne von Git. Idealerweise möchten wir, dass der Dateiverlauf erhalten bleibt.
|
||||
|
||||
Um dies zu erreichen, gehe am besten wie folgt vor:
|
||||
|
||||
1. Umbenennen der Datei
|
||||
2. Commit mit dem Flag `--no-verify`, damit Husky sich nicht über die Lint-Fehler beschwert
|
||||
3. Refactoring zu TypeScript für die Migration, in einem separaten Commit
|
||||
|
||||
> [!NOTE] Editoren wie VSCode zeigen dir wahrscheinlich trotzdem an, dass die Datei gelöscht und eine neue erstellt wurde. Wenn du die CLI für `git add .` verwendest, zeigt VSCode die Datei als umbenannt im Stage an
|
||||
|
||||
### Namenskonventionen
|
||||
|
||||
#### Schnittstellen und Typen
|
||||
|
||||
In den meisten Fällen wird empfohlen, Schnittstellendeklarationen gegenüber Typdeklarationen zu verwenden.
|
||||
|
||||
React Component Props - Suffix mit `Props`
|
||||
|
||||
```typescript
|
||||
interface MyComponentProps {}
|
||||
// type MyComponentProps = {};
|
||||
const MyComponent = (props: MyComponentProps) => {};
|
||||
```
|
||||
|
||||
React Stateful Components - Suffix mit `State`
|
||||
|
||||
```typescript
|
||||
interface MyComponentState {}
|
||||
// type MyComponentState = {};
|
||||
class MyComponent extends Component<MyComponentProps, MyComponentState> {}
|
||||
```
|
||||
|
||||
Standard - Objektname in PascalCase
|
||||
|
||||
```typescript
|
||||
interface MyObject {}
|
||||
// type MyObject = {};
|
||||
const myObject: MyObject = {};
|
||||
```
|
||||
|
||||
<!-- #### Redux Actions -->
|
||||
|
||||
<!-- TODO: Once refactored to TS, showcase naming convention for Reducers/Actions and how to type dispatch funcs -->
|
||||
|
||||
## Redux
|
||||
|
||||
### Aktionsdefinitionen
|
||||
|
||||
```typescript
|
||||
enum AppActionTypes = {
|
||||
actionFunction = 'actionFunction'
|
||||
}
|
||||
|
||||
export const actionFunction = (
|
||||
arg: Arg
|
||||
): ReducerPayload<AppActionTypes.actionFunction> => ({
|
||||
type: AppActionTypes.actionFunction,
|
||||
payload: arg
|
||||
});
|
||||
```
|
||||
|
||||
### Wie man Reducer verwendet
|
||||
|
||||
```typescript
|
||||
// Base reducer action without payload
|
||||
type ReducerBase<T> = { type: T };
|
||||
// Logic for handling optional payloads
|
||||
type ReducerPayload<T extends AppActionTypes> =
|
||||
T extends AppActionTypes.actionFunction
|
||||
? ReducerBase<T> & {
|
||||
payload: AppState['property'];
|
||||
}
|
||||
: ReducerBase<T>;
|
||||
|
||||
// Switch reducer exported to Redux combineReducers
|
||||
export const reducer = (
|
||||
state: AppState = initialState,
|
||||
action: ReducerPayload<AppActionTypes>
|
||||
): AppState => {
|
||||
switch (action.type) {
|
||||
case AppActionTypes.actionFunction:
|
||||
return { ...state, property: action.payload };
|
||||
default:
|
||||
return state;
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
### Wie man Dispatch verwendet
|
||||
|
||||
Importiere innerhalb einer Komponente die benötigten Aktionen und Selektoren.
|
||||
|
||||
```tsx
|
||||
// Add type definition
|
||||
interface MyComponentProps {
|
||||
actionFunction: typeof actionFunction;
|
||||
}
|
||||
// Connect to Redux store
|
||||
const mapDispatchToProps = {
|
||||
actionFunction
|
||||
};
|
||||
// Example React Component connected to store
|
||||
const MyComponent = ({ actionFunction }: MyComponentProps): JSX.Element => {
|
||||
const handleClick = () => {
|
||||
// Dispatch function
|
||||
actionFunction();
|
||||
};
|
||||
return <button onClick={handleClick}>freeCodeCamp is awesome!</button>;
|
||||
};
|
||||
|
||||
export default connect(null, mapDispatchToProps)(MyComponent);
|
||||
```
|
||||
|
||||
<!-- ### Redux Types File -->
|
||||
<!-- The types associated with the Redux store state are located in `client/src/redux/types.ts`... -->
|
||||
|
||||
## Weitere Literatur
|
||||
|
||||
- [TypeScript Dokumentation](https://www.typescriptlang.org/docs/)
|
||||
- [TypeScript mit React CheatSheet](https://github.com/typescript-cheatsheets/react#readme)
|
||||
106
docs/i18n/german/curriculum-file-structure.md
Normal file
106
docs/i18n/german/curriculum-file-structure.md
Normal file
@ -0,0 +1,106 @@
|
||||
# Dateistruktur des Studienplans (Curriculum)
|
||||
|
||||
Unsere wichtigsten Lehrinhalte befinden sich in dem Verzeichnis mit dem aussagekräftigen Namen `Curriculum`. Auf dieser Seite erfährst du, wie diese Dateien organisiert sind.
|
||||
|
||||
## Terminologie
|
||||
|
||||
Es gibt ein paar Begriffe, die wir verwenden, wenn wir über unsere Studienplaninhalte sprechen.
|
||||
|
||||
- `certification` : Wenn in diesem Fall von einer Zertifizierung die Rede ist, geht es um das eigentliche Zertifikat, das die Nutzer/innen beantragen. Das ist unabhängig vom Namen des SuperBlocks.
|
||||
- `superBlock` : Ein Superblock ist die oberste Ebene einer Sammlung von Aufgaben. Jeder Superblock entspricht einem Zertifikat im Studienplan (d.h. Responsives Webdesign).
|
||||
- `block` : Ein Block ist ein Abschnitt innerhalb eines Superblocks. Ein Block entspricht einer Gruppe von Aufgaben in einer bestimmten Zertifizierung (d.h. Grundlagen HTML und HTML5)
|
||||
- `challenge` : Eine Aufgabe ist eine einzelne Unterrichtsstunde innerhalb des Studienplans (d.h. Sag Hallo zu HTML-Elementen)
|
||||
|
||||
## Dateibaum
|
||||
|
||||
Mit diesen Begriffen würde die Dateistruktur folgendermaßen definiert werden:
|
||||
|
||||
<!-- prettier-ignore -->
|
||||
```md
|
||||
|
||||
curriculum/
|
||||
├─ _meta/
|
||||
│ ├─ {block}/
|
||||
│ │ ├─ meta.json
|
||||
├─ {language}/
|
||||
│ ├─ {superBlock}/
|
||||
│ │ ├─ {block}/
|
||||
│ │ │ ├─ {challenge}.md
|
||||
```
|
||||
|
||||
## Das `_meta` -Verzeichnis
|
||||
|
||||
Das `_meta` -Verzeichnis ist ein besonderes Verzeichnis, welches `.json` -Dateien enthält. Diese Dateien entsprechen jedem Block im Studienplan und werden verwendet, um zu bestimmen, zu welchem SuperBlock ein Block gehört und in welcher Reihenfolge die Aufgaben innerhalb dieses Blocks bearbeitet werden.
|
||||
|
||||
## Umbenennung von Dateien
|
||||
|
||||
Es kann vorkommen, dass du ein Zertifikat, einen Superblock, einen Block oder eine Aufgabe umbenennen musst. In diesem Abschnitt werden die notwendigen Schritte beschrieben, um Fehler bei der Umbenennung zu vermeiden.
|
||||
|
||||
> [!ATTENTION] Das Umbenennen von Dateien innerhalb der Studienplanstruktur führt oft dazu, dass sich der Pfad (oder die URL) des Inhalts auf der Startseite ändert. Dies sollte mit Bedacht geschehen, da für jede Änderung eine Weiterleitung eingerichtet werden muss.
|
||||
|
||||
### Umbenennen eines Zertifikats
|
||||
|
||||
Wenn du eine Zertifizierung umbenennst, willst du wahrscheinlich auch den zugehörigen Superblock umbenennen. Gehe wie folgt vor, um nur das Zertifikat umzubenennen:
|
||||
|
||||
1. Benenne den Ordner `curriculum/challenges/_meta/{superBlock}-certificate` in den neuen Namen um.
|
||||
1. Benenne in der Datei `meta.json` dieses Ordners die Werte in `name`, `dashedName` und `challengeOrder` in den neuen Zertifikatsnamen um.
|
||||
1. Benenne den Ordner `{superBlock}-certificate` und die darin enthaltene YAML-Datei in `curriculum/challenges/english/12-certificate` in den neuen Namen um.
|
||||
1. Ändere den `title` in der YAML-Datei in den neuen Namen um.
|
||||
1. Benenne die Datei und den Ordner aus Schritt 3 für die übrigen Studienplansprachen um.
|
||||
1. Aktualisiere `client/src/redux/index.ts`, um den richtigen `title` zu benutzen.
|
||||
1. Optional aktualisiere den `certSlug` für den superblock in der gleichen Datei. **Beachte**, dass das Umbenennen eines `certSlug` die URL für die Zertifizierung ändern wird und sollte deshalb nur nach sorgfältiger Überlegung durchgeführt werden.
|
||||
1. Aktualisiere den `title` in `client/src/resources/cert-and-project-map.ts` auf den neuen Wert. **Beachte**, dass das Ändern des `title` hier **die SuperBlock-Seite für die zugehörige Zertifizierung unterbricht**. Er ist darauf angewiesen, dass der SuperBlock-Titel mit dem Titel der Zertifizierung übereinstimmt. Wahrscheinlich willst du den SuperBlock gleichzeitig umbenennen.
|
||||
1. Wenn du den `certSlug` in Schritt 7 umbenannt hast, ändere ihn hier für das cert und alle verschachtelten `projects`-Werte.
|
||||
1. Aktualisiere in `config/certification-settings.js` den Wert von `certTypeTitleMap` auf den neuen Namen.
|
||||
1. Wenn du den `certSlug` in Schritt 7 umbenannt hast, aktualisiere den key von`certSlugTypeMap` in derselben Datei.
|
||||
1. Aktualisiere bei Bedarf den Zertifikatsnamen im `legacyCerts`-Array von `client/src/client-only-routes/show-project-links.tsx`.
|
||||
1. Aktualisiere die Hauptdatei `README.md` auf den neuen Namen.
|
||||
|
||||
### Umbenennen eines Superblocks
|
||||
|
||||
> [!NOTE] Wenn du einen SuperBlock umbenennst, wird der neue Ordnername als Pfad verwendet und sollte als "richtiger" Name betrachtet werden. Alle anderen Werte sollten aktualisiert sein, um diese Veränderung widerzuspiegeln.
|
||||
|
||||
Außerdem wirst du wahrscheinlich das Zertifikat und den `{superBlock}-projects`-Block umbenennen wollen, wenn du einen superBlock umbenennst, da sie alle einen gemeinsamen Namen haben. Um nur einen superBlock umzubenennen, musst du:
|
||||
|
||||
1. Benenne den Ordner superBlock im Verzeichnis `curriculum/challenges/english` um.
|
||||
1. Benenne den superBlock Ordner in _allen_ anderen `curriculum/challenges/{language}` Verzeichnissen um.
|
||||
1. Für jeden Block innerhalb dieses Superblocks aktualisierst du den `superBlock`-Wert in der `meta.json`-Datei auf seinen dashedName. Du musst hier keine Ordner umbenennen. Mach das, wenn du einen Block umbenennst.
|
||||
1. Benenne den Superblock-Ordner in `client/src/pages/learn` um.
|
||||
1. Aktualisiere die Datei `index.md` im oben genannten Ordner und ändere die Werte für `title` und `superBlock` auf den neuen Namen.
|
||||
1. Aktualisiere die `index.md` für jeden Blockordner, um den richtigen `superBlock`-Wert zu verwenden.
|
||||
1. In der Datei `client/src/resources/cert-and-project-map.ts` aktualisierst du den Pfad für das Zertifikat(cert) am Anfang der Datei und den `title`-Wert für diesen SuperBlock. **Beachte**, dass das Ändern des `title` hier **die Möglichkeit zerstört,** die eigentliche Zertifizierung für diesen SuperBlock anzuzeigen. Er ist darauf angewiesen, dass der SuperBlock-Titel mit dem Titel der Zertifizierung übereinstimmt. Wahrscheinlich möchtest du die Zertifizierung gleichzeitig umbenennen.
|
||||
1. Aktualisiere den `superBlockCertTypeMap` Schlüssel(key) in `config/certification-settings.js` auf den neuen SuperBlock-Namen.
|
||||
1. Aktualisiere den Pfadwert in `client/src/assets/icons/index.tsx`.
|
||||
1. Aktualisiere für jede Sprache in `client/i18n/locales` die Datei `intro.json`, um den neuen SuperBlock `dashedName` zu verwenden. In der englischen Datei aktualisierst du auch den `title`.
|
||||
1. Überprüfe die Datei `config/i18n/all-langs.js`, um zu sehen, ob der SuperBlock in i18n-Builds aktiviert ist. Aktualisiere alle Werte, in denen er verwendet wird.
|
||||
1. Aktualisiere die Hauptdatei `README.md` auf den neuen Namen.
|
||||
|
||||
### Umbenennen eines Blocks
|
||||
|
||||
Wenn du einen Studienplanblock umbenennen willst, musst du Folgendes tun:
|
||||
|
||||
1. Ändere den Namen des Blockordners im Verzeichnis `curriculum/challenges/english/{superBlock}`.
|
||||
1. Ändere den Namen des gleichen Blockordners in _allen_ der anderen Sprachverzeichnisse, damit er übereinstimmt. Diese müssen alle mit der englischen Struktur übereinstimmen, sonst wird der Build nicht funktionieren.
|
||||
1. Ändere den Namen des Blockordners im `_meta`-Verzeichnis.
|
||||
1. Aktualisiere die Eigenschaften `name` und `dashedName` in der `meta.json`-Datei des Blocks.
|
||||
1. Aktualisiere die `client/utils/help-category-map.json`, um den neuen Blocknamen als Schlüssel(key) zu verwenden.
|
||||
1. Aktualisiere den Blockordner in `client/src/pages/learn/{superBlock}`.
|
||||
1. Aktualisiere in der `index.md`-Datei des obigen Ordners den `block`-Wert im Frontmatter.
|
||||
1. Aktualisiere in den `client/i18n/locales/{language}/intro.json`-Dateien den Blocknamen auf den neuen Namen für alle Sprachen. In der englischen `intro.json`-Datei aktualisierst du auch den `title`.
|
||||
1. Aktualisiere die Hauptdatei `README.md` auf den neuen Namen.
|
||||
|
||||
### Umbenennen einer Aufgabe
|
||||
|
||||
Wenn du eine einzelne Aufgaben-Datei umbenennen willst, musst du Folgendes tun:
|
||||
|
||||
1. Ändere den Namen der Challenge-Datei im Verzeichnis `curriculum/challenges/english`.
|
||||
1. Ändere den Namen des `title` und `dashedName` in dieser Datei.
|
||||
1. Ändere den Namen der Datei und den `dashedName` in diesen Dateien, damit _alle_ der anderen Sprachverzeichnisse übereinstimmen.
|
||||
1. Aktualisiere den Namen der Aufgabe in der entsprechenden `meta.json`-Datei. Die Namen der Aufgaben werden im Build nicht verwendet, aber sie dienen dazu, die Reihenfolge der Aufgaben benutzerfreundlich zu gestalten.
|
||||
1. Wenn es sich bei der Aufgabe um ein Zertifikatsprojekt handelt, aktualisiere die YAML-Datei in `curriculum/english/12-certificates/<superBlock>` auf den neuen Namen.
|
||||
1. Wenn es sich bei der Aufgabe um ein Zertifikatsprojekt handelt, aktualisiere den `title` und `link` in `client/src/resources/cert-and-project-map.ts`
|
||||
1. Wenn es sich bei der Aufgabe um ein Zertifikatsprojekt handelt, aktualisiere die Hauptdatei `README.md` auf den neuen Namen.
|
||||
|
||||
## Die `dashedName`-Eigenschaft
|
||||
|
||||
Die Eigenschaft `dashedName` wird verwendet, um den URL-Pfad für den Superblock, Block oder die Aufgabe zu generieren. Diese sollten in der Regel dem entsprechen, was der `/utils/slugs.js` Helper für den Dateinamen ausgeben würde.
|
||||
962
docs/i18n/german/devops.md
Normal file
962
docs/i18n/german/devops.md
Normal file
@ -0,0 +1,962 @@
|
||||
# Das DevOps Handbuch
|
||||
|
||||
Dieser Leitfaden wird dir helfen zu verstehen, wie unser Infrastruktur-Stack aufgebaut ist und wie wir unsere Plattformen warten. Dieses Handbuch enthält zwar nicht alle Einzelheiten zu allen Vorgängen, aber er kann als Referenz für dein Verständnis der Systeme dienen.
|
||||
|
||||
Lassen es uns wissen, wenn du Feedback oder Fragen hast, dann klären wir das gerne.
|
||||
|
||||
# Handbuch - Bereitstellung von Code
|
||||
|
||||
Dieses Repository wird kontinuierlich entwickelt, getestet und auf **einzelne Infrastrukturen (Server, Datenbanken, CDNs, etc.)** verteilt.
|
||||
|
||||
Dies umfasst drei Schritte, die nacheinander zu durchlaufen sind:
|
||||
|
||||
1. Neue Änderungen (sowohl Fixes als auch Features) werden über Pull-Requests in unseren primären Entwicklungsbranch (`main`) eingebunden.
|
||||
2. Diese Änderungen durchlaufen eine Reihe von automatisierten Tests.
|
||||
3. Sobald die Tests bestanden sind, geben wir die Änderungen frei (oder aktualisieren sie bei Bedarf) und stellen sie in unserer Infrastruktur bereit.
|
||||
|
||||
#### Erstellen der Codebasis - Zuordnen von Git-Branches zu Deployments.
|
||||
|
||||
Normalerweise wird [`main`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main) (der Standard-Entwicklungsbranch) einmal am Tag in den [`prod-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-staging)-Branch zusammengeführt und in einer isolierten Infrastruktur freigegeben.
|
||||
|
||||
Dies ist eine Zwischenversion für unsere Entwickler und freiwillig Mitwirkenden. Sie wird auch als unsere "Staging"- oder "Beta"-Version bezeichnet.
|
||||
|
||||
Sie ist identisch mit unserer Live-Produktionsumgebung auf `freeCodeCamp.org`. Sie verwendet jedoch einen separaten Satz von Datenbanken, Servern, Web-Proxies, etc. Diese Isolation ermöglicht es uns, laufende Entwicklungen und Funktionen in einem "produktionsähnlichen" Szenario zu testen, ohne die regulären Benutzer der Hauptplattformen von freeCodeCamp.org zu beeinträchtigen.
|
||||
|
||||
Sobald das Entwicklerteam [`@freeCodeCamp/dev-team`](https://github.com/orgs/freeCodeCamp/teams/dev-team/members) mit den Änderungen auf der Staging-Plattform zufrieden ist, werden diese Änderungen alle paar Tage auf den [`prod-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-current)-Branch verschoben.
|
||||
|
||||
Dies ist die finale Version, die Änderungen auf unsere Produktionsplattformen auf freeCodeCamp.org überführt.
|
||||
|
||||
#### Test von Änderungen, Integrations- und Benutzerakzeptanztests.
|
||||
|
||||
Wir verwenden verschiedene Stufen von Integrations- und Abnahmetests, um die Qualität des Codes zu überprüfen. Alle unsere Tests werden durch Software wie [GitHub Actions CI](https://github.com/freeCodeCamp/freeCodeCamp/actions) und [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp) durchgeführt.
|
||||
|
||||
Wir nutzen Unit-Tests zum Testen unserer Aufgabenlösungen, Server-APIs und Client-Benutzeroberflächen. Diese helfen uns, die Integration zwischen verschiedenen Komponenten zu testen.
|
||||
|
||||
> [!NOTE] Wir sind auch dabei, Endnutzertests zu schreiben, die dabei helfen werden, reale Szenarien zu erzeugen, wie z. B. das Aktualisieren einer E-Mail oder das Aufrufen der API von Diensten eines Drittanbieters.
|
||||
|
||||
All diese Tests helfen dabei, zu verhindern, dass sich Probleme wiederholen und stellen sicher, dass wir keinen Fehler einführen, während wir an einem anderen Fehler oder einer Funktion arbeiten.
|
||||
|
||||
#### Bereitstellen von Änderungen - Übertragen von Änderungen auf die Server.
|
||||
|
||||
Wir haben eine Continuous-Delivery-Software konfiguriert, um Änderungen auf unsere Entwicklungs- und Produktionsserver zu übertragen.
|
||||
|
||||
Sobald die Änderungen in die geschützten Release-Branches geschoben werden, wird automatisch eine Build-Pipeline für den Branch erstellt. Die Build-Pipelines sind für die Erstellung von Artefakten und deren Aufbewahrung in einem Cold Storage zur späteren Verwendung zuständig.
|
||||
|
||||
Die Build-Pipeline erstellt eine entsprechende Release-Pipeline, wenn sie einen erfolgreichen Lauf absolviert hat. Die Release-Pipelines sind dafür verantwortlich, die Build-Artefakte zu sammeln, sie auf die Server zu verschieben und live zu gehen.
|
||||
|
||||
Status der Builds und Releases sind [hier](#build-test-and-deployment-status) verfügbar.
|
||||
|
||||
## Build, Test und Deploy auslösen
|
||||
|
||||
Derzeit können nur Mitglieder des Entwicklerteams in die Produktionsbranches pushen. Die Änderungen in den `production*`-Branches können nur per Fast-Forward-Merge im [`upstream`](https://github.com/freeCodeCamp/freeCodeCamp) landen.
|
||||
|
||||
> [!NOTE] In der nächsten Zeit wollen wir diesen Ablauf verbessern, indem wir ihn über Pull-Requests abwickeln, um eine bessere Zugriffsverwaltung und Transparenz zu erreichen.
|
||||
|
||||
### Änderungen in die Staging-Anwendungen verschieben.
|
||||
|
||||
1. Den Remotezugriff korrekt konfigurieren.
|
||||
|
||||
```sh
|
||||
git remote -v
|
||||
```
|
||||
|
||||
**Ergebnisse:**
|
||||
|
||||
```
|
||||
origin git@github.com:raisedadead/freeCodeCamp.git (fetch)
|
||||
origin git@github.com:raisedadead/freeCodeCamp.git (push)
|
||||
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (fetch)
|
||||
upstream git@github.com:freeCodeCamp/freeCodeCamp.git (push)
|
||||
```
|
||||
|
||||
2. Stelle sicher, dass dein `main`-Branch fehlerfrei ist und mit dem upstream synchronisiert ist.
|
||||
|
||||
```sh
|
||||
git checkout main
|
||||
git fetch --all --prune
|
||||
git reset --hard upstream/main
|
||||
```
|
||||
|
||||
3. Prüfe ob das GitHub CI den `main`-Branch für den upstream weitergibt.
|
||||
|
||||
Die [Continuous Integration](https://github.com/freeCodeCamp/freeCodeCamp/actions)-Tests sollten für den `main`-Branch grün und BESTANDEN (PASSING) sein. Klicke auf das grüne Häkchen neben dem Commit-Hash, wenn du den Code des `main`-Branch siehst.
|
||||
|
||||
<details> <summary> Überprüfen des Status auf GitHub Actions (Screenshot) </summary>
|
||||
<br>
|
||||
|
||||
</details>
|
||||
|
||||
Wenn dies fehlschlägt, solltest du anhalten und die Fehler untersuchen.
|
||||
|
||||
4. Bestätige dass du in der Lage bist, das Repository lokal zu erstellen.
|
||||
|
||||
```
|
||||
npm run clean-and-develop
|
||||
```
|
||||
|
||||
5. Verschieben von Änderungen von `main` nach `prod-staging` über ein Fast-Forward-Merge
|
||||
|
||||
```
|
||||
git checkout prod-staging
|
||||
git merge main
|
||||
git push upstream
|
||||
```
|
||||
|
||||
> [!NOTE] Du kannst keinen Push erzwingen und wenn du die History in irgendeiner Weise umgeschrieben hast, werden diese Befehle fehlschlagen.
|
||||
>
|
||||
> Wenn dies der Fall ist, hast du möglicherweise etwas falsch gemacht und solltest noch einmal von vorn beginnen.
|
||||
|
||||
Die obigen Schritte lösen automatisch einen Lauf in der Build-Pipeline für den `prod-staging`-Branch aus. Sobald der Build abgeschlossen ist, werden die Artefakte als `.zip`-Dateien in einem Cold Storage gespeichert, um später abgerufen und verwendet werden zu können.
|
||||
|
||||
Die Release-Pipeline wird automatisch ausgelöst, wenn ein neues Artefakt über die angeschlossene Build-Pipeline verfügbar ist. Für Staging-Plattformen erfordert dieser Prozess keine manuelle Freigabe und die Artefakte werden auf den Client CDN und API-Server geschoben.
|
||||
|
||||
### Pushen von Änderungen an Produktionsanwendungen.
|
||||
|
||||
Der Prozess ist meist identisch mit den Staging-Plattformen, wobei einige zusätzliche Kontrollen durchgeführt werden. Dies geschieht nur, um sicherzustellen, dass wir nichts auf freeCodeCamp.org beschädigen, das jederzeit von Hunderten von Benutzern verwendet werden kann.
|
||||
|
||||
| Führe diese Befehle NICHT aus, bevor du nicht sichergestellt hast, dass alles auf der Staging-Plattform funktioniert. Du solltest keine Tests auf Staging umgehen oder überspringen, bevor du weiter fortfährst. |
|
||||
|:---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| |
|
||||
|
||||
1. Stelle sicher, dass dein `prod-staging`-Branch fehlerfrei ist und mit dem upstream synchronisiert ist.
|
||||
|
||||
```sh
|
||||
git checkout prod-staging
|
||||
git fetch --all --prune
|
||||
git reset --hard upstream/prod-staging
|
||||
```
|
||||
|
||||
2. Verschiebe Änderungen von `prod-staging` nach `prod-current` mittels eines fast-forward Merge
|
||||
|
||||
```
|
||||
git checkout prod-current
|
||||
git merge prod-staging
|
||||
git push upstream
|
||||
```
|
||||
|
||||
> [!NOTE] Du kannst keinen Push erzwingen und wenn du die History in irgendeiner Weise umgeschrieben hast, werden diese Befehle fehlschlagen.
|
||||
>
|
||||
> Wenn dies der Fall ist, hast du vielleicht etwas falsch gemacht und solltest noch einmal von vorne beginnen.
|
||||
|
||||
Die obigen Schritte lösen automatisch einen Lauf in der Build-Pipeline für den `prod-current`-Branch aus. Sobald ein Build-Artefakt fertig ist, löst es einen Lauf in der Release-Pipeline aus.
|
||||
|
||||
**Zusätzliche Schritte für Mitarbeiter (Staffs)**
|
||||
|
||||
Wenn ein Release-Lauf ausgelöst wird, erhalten die Mitarbeiter des Entwicklerteams eine automatisierte E-Mail zum manuellen Eingriff. Sie können den Freigabedurchlauf entweder _genehmigen_ oder _ablehnen_.
|
||||
|
||||
Wenn die Änderungen einwandfrei funktionieren und auf der Staging-Plattform getestet wurden, kann die Freigabe erfolgen. Die Genehmigung muss innerhalb von 4 Stunden nach dem Auslösen der Veröffentlichung erteilt werden, bevor sie automatisch abgelehnt wird. Ein Mitarbeiter kann den Freigabelauf für abgelehnte Läufe manuell erneut auslösen oder auf den nächsten Freigabezyklus warten.
|
||||
|
||||
Für Mitarbeiter bestimmt:
|
||||
|
||||
| Prüfe deine E-Mail für einen direkten Link oder [geh zum Release Dashboard](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_release), nachdem der Build-Lauf abgeschlossen ist. |
|
||||
|:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
|
||||
| |
|
||||
|
||||
Sobald einer der Mitarbeiter eine Freigabe genehmigt, schiebt die Pipeline die Änderungen live auf das Produktions-CDN und die API-Server von freeCodeCamp.org.
|
||||
|
||||
## Build, Test and Deployment Status
|
||||
|
||||
Hier ist der aktuelle Test-, Build- und Deployment-Status der Codebasis.
|
||||
|
||||
| Branch | Unit-Tests | Integrations-Tests | Builds & Deployments |
|
||||
|:-------------------------------------------------------------------------------- |:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |:------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |:--------------------------------------------------------------------------------------------------------------------------------- |
|
||||
| [`main`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main) | [](https://github.com/freeCodeCamp/freeCodeCamp/actions?query=workflow%3A%22Node.js+CI%22) | [](https://dashboard.cypress.io/projects/ke77ns/analytics/runs-over-time) | - |
|
||||
| [`prod-staging`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-staging) | [](https://github.com/freeCodeCamp/freeCodeCamp/actions?query=workflow%3A%22Node.js+CI%22+branch%3Aprod-staging) | [](https://dashboard.cypress.io/projects/ke77ns/analytics/runs-over-time) | [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_dashboards/dashboard/d59f36b9-434a-482d-8dbd-d006b71713d4) |
|
||||
| [`prod-current`](https://github.com/freeCodeCamp/freeCodeCamp/tree/prod-staging) | [](https://github.com/freeCodeCamp/freeCodeCamp/actions?query=workflow%3A%22Node.js+CI%22+branch%3Aprod-current) | [](https://dashboard.cypress.io/projects/ke77ns/analytics/runs-over-time) | [Azure Pipelines](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_dashboards/dashboard/d59f36b9-434a-482d-8dbd-d006b71713d4) |
|
||||
| `prod-next` (experimentell, in Vorbereitung) | - | - | - |
|
||||
|
||||
## Früher Zugang (Early access) und Beta-Tests
|
||||
|
||||
Wir laden dich ein, diese Versionen in einem **"public beta testing"** Modus zu testen und frühen Zugriff auf kommende Funktionen der Plattformen zu erhalten. Manchmal werden diese Funktionen/Änderungen als **, Beta, Staging,** usw. bezeichnet.
|
||||
|
||||
Deine Mitwirkung in Form von Feedback und Fehlerberichten helfen uns, die Produktionsplattformen auf `freeCodeCamp.org` für alle **resilient**, **konsistent** und **stabil** zu machen.
|
||||
|
||||
Wir danken dir, dass du uns Fehler meldest, auf die du stößt und uns hilfst, freeCodeCamp.org besser zu machen. Du rockst!
|
||||
|
||||
### Identifizierung der kommenden Version der Plattformen
|
||||
|
||||
Derzeit ist eine öffentliche Beta-Testversion verfügbar:
|
||||
|
||||
| Anwendung | Sprache | URL |
|
||||
|:--------- |:---------- |:---------------------------------------- |
|
||||
| Lernen | Englisch | <https://www.freecodecamp.dev> |
|
||||
| | Spanisch | <https://www.freecodecamp.dev/espanol> |
|
||||
| | Chinesisch | <https://chinese.freecodecamp.dev> |
|
||||
| News | Englisch | <https://www.freecodecamp.dev/news> |
|
||||
| Forum | Englisch | <https://forum.freecodecamp.dev> |
|
||||
| | Chinesisch | <https://chinese.freecodecamp.dev/forum> |
|
||||
| API | - | `https://api.freecodecamp.dev` |
|
||||
|
||||
> [!NOTE] Der Domainname ist anders als **`freeCodeCamp.org`**. Dies ist beabsichtigt, um die Indizierung durch Suchmaschinen zu verhindern und Verwirrung bei regelmäßigen Benutzern der Plattform zu vermeiden.
|
||||
>
|
||||
> Die obige Liste ist nicht abschließend für alle Anwendungen, die wir bereitstellen. Außerdem werden nicht alle Sprachvarianten im Staging bereitgestellt, um Ressourcen zu sparen.
|
||||
|
||||
### Identifizierung der aktuellen Version der Plattformen
|
||||
|
||||
**Die aktuelle Version der Plattform ist immer verfügbar unter [`freeCodeCamp.org`](https://www.freecodecamp.org).**
|
||||
|
||||
Das Entwicklerteam führt Änderungen aus dem `prod-staging`-Branch nach `prod-current` zusammen, wenn sie Änderungen veröffentlichen. Das oberste Commit sollte das sein, was du live auf der Website siehst.
|
||||
|
||||
Du kannst die genaue Version, die eingesetzt wurde, in den Build- und Deployment-Protokollen im Statusbereich nachlesen. Alternativ kannst du uns auch im [Contributors Chat Room](https://chat.freecodecamp.org/channel/contributors) anpingen, um eine Bestätigung zu erhalten.
|
||||
|
||||
### Bekannte Einschränkungen
|
||||
|
||||
Es gibt einige bekannte Einschränkungen und Kompromisse bei der Beta-Version der Plattform.
|
||||
|
||||
- #### Alle Daten / persönliche Fortschritte auf diesen Beta-Plattformen werden NICHT gespeichert oder in die Produktion übernommen.
|
||||
|
||||
**Benutzer der Beta-Version haben ein von der Produktionsversion getrenntes Konto.** Die Beta-Version verwendet eine von der Produktionsversion physisch getrennte Datenbank. So können wir versehentliche Datenverluste oder Änderungen verhindern. Das Entwicklerteam kann die Datenbank dieser Betaversion bei Bedarf löschen.
|
||||
|
||||
- #### Es gibt keine Garantie für die Betriebszeit und Zuverlässigkeit der Beta-Plattformen.
|
||||
|
||||
Es wird erwartet, dass die Deployments häufig und in schnellen Iterationen erfolgen, manchmal mehrmals am Tag. Daher kann es in der Beta-Version manchmal zu unerwarteten Ausfällen oder fehlerhaften Funktionen kommen.
|
||||
|
||||
- #### Schicke keine normalen Nutzer auf diese Seite, um eine Korrektur zu bestätigen.
|
||||
|
||||
Die Beta-Seite ist und war immer dazu da, die lokale Entwicklung und das Testen zu unterstützen, nichts anderes. Es ist kein Versprechen auf das, was kommt, sondern ein Ausblick auf das, woran gearbeitet wird.
|
||||
|
||||
- #### Die Anmeldeseite kann anders aussehen als die Produktionsseite
|
||||
|
||||
Wir verwenden einen Test-Mandanten für freeCodeCamp.dev auf Auth0 und haben daher nicht die Möglichkeit, eine benutzerdefinierte Domain einzustellen. Dies führt dazu, dass alle Weiterleitungsaufrufe und die Anmeldeseite auf einer Standarddomain erscheinen, wie z.B.: `https://freecodecamp-dev.auth0.com/`. Dies hat keinen Einfluss auf die Funktionalität und ist so nah an der Produktion, wie wir es nur bekommen können.
|
||||
|
||||
## Fehler melden und Feedback hinterlassen
|
||||
|
||||
Bitte eröffne neue Issues für Diskussionen und zum Melden von Fehlern.
|
||||
|
||||
Du kannst eine E-Mail an `dev[at]freecodecamp.org` senden, wenn du irgendwelche Fragen hast. Wie immer sollten alle Sicherheitslücken an `security[at]freecodecamp.org` gemeldet werden, anstatt an den öffentlichen Tracker und das Forum.
|
||||
|
||||
# Handbuch- Serverwartung
|
||||
|
||||
> [!WARNING]
|
||||
>
|
||||
> 1. Diese Handbuch gilt nur für die **freeCodeCamp Mitarbeiter**.
|
||||
> 2. Diese Anweisungen sollten nicht als vollständig angesehen werden, bitte sei vorsichtig.
|
||||
|
||||
Als Mitarbeiterin oder Mitarbeiter hast du vielleicht Zugang zu unseren Cloud-Anbietern wie Azure, Digital Ocean usw. erhalten.
|
||||
|
||||
Hier sind einige praktische Befehle, mit denen du an den virtuellen Maschinen (VM) arbeiten kannst, z. B. um Wartungsupdates durchzuführen oder allgemeine Aufgaben zu erledigen.
|
||||
|
||||
## Eine Liste der VMs abrufen
|
||||
|
||||
> [!NOTE] Auch wenn du bereits SSH-Zugriff auf die VMs hast, kannst du damit allein noch nicht VMs auflisten, wenn du nicht auch Zugriff auf die Cloud-Portale hast.
|
||||
|
||||
### Azure
|
||||
|
||||
Installiere Azure CLI `az`: https://docs.microsoft.com/en-us/cli/azure/install-azure-cli
|
||||
|
||||
> **(Einmalig) Installation auf macOS mit [`homebrew`](https://brew.sh):**
|
||||
|
||||
```
|
||||
brew install azure-cli
|
||||
```
|
||||
|
||||
> **(Einmalig) Login:**
|
||||
|
||||
```
|
||||
az login
|
||||
```
|
||||
|
||||
> **Abruf der Liste der VM-Namen und IP-Adressen:**
|
||||
|
||||
```
|
||||
az vm list-ip-addresses --output table
|
||||
```
|
||||
|
||||
### Digital Ocean
|
||||
|
||||
Installiere Digital Ocean CLI `doctl`: https://github.com/digitalocean/doctl#installing-doctl
|
||||
|
||||
> **(Einmalig) Installation unter macOS mit [`homebrew`](https://brew.sh):**
|
||||
|
||||
```
|
||||
brew install doctl
|
||||
```
|
||||
|
||||
> **(Einmalig) Login:**
|
||||
|
||||
Authentifizierung und Kontextwechsel: https://github.com/digitalocean/doctl#Authentifizierung mit-digitalocean
|
||||
|
||||
```
|
||||
doctl auth init
|
||||
```
|
||||
|
||||
> **Liste der VM-Namen und IP-Adressen abrufen:**
|
||||
|
||||
```
|
||||
doctl compute droplet list --format "ID,Name,PublicIPv4"
|
||||
```
|
||||
|
||||
## Neue Ressourcen erzeugen
|
||||
|
||||
Wir arbeiten daran, unser IaC-Setup zu erstellen. Während das in Arbeit ist, kannst du das Azure-Portal oder die Azure CLI nutzen, um neue virtuelle Maschinen und andere Ressourcen zu starten.
|
||||
|
||||
> [!TIP] Unabhängig davon, welche Spinning-Ressourcen du wählst, haben wir ein paar [handliche Cloud-Init-Konfigurationsdateien](https://github.com/freeCodeCamp/infra/tree/main/cloud-init), die dir bei der grundlegenden Einrichtung helfen, z.B. bei der Installation von Docker oder dem Hinzufügen von SSH-Schlüsseln usw.
|
||||
|
||||
## VMs auf dem neuesten Stand halten
|
||||
|
||||
Du solltest die VMs auf dem neuesten Stand halten, indem du Updates und Upgrades durchführst. So wird sichergestellt, dass die virtuelle Maschine mit den neuesten Sicherheitsupdates gepatcht ist.
|
||||
|
||||
> [!WARNING] Bevor du diese Befehle ausführst:
|
||||
>
|
||||
> - Vergewissere dich, dass die VM vollständig provisioniert wurde und keine Post-Installationsschritte laufen.
|
||||
> - Wenn du Pakete auf einer VM aktualisierst, auf der bereits eine Anwendung läuft, stelle sicher, dass die Anwendung gestoppt/gespeichert wurde. Paket-Updates verursachen Netzwerkbandbreite, Speicher- und/oder CPU-Nutzungsspitzen, die zu Ausfällen bei laufenden Anwendungen führen.
|
||||
|
||||
Paketinformationen aktualisieren
|
||||
|
||||
```console
|
||||
sudo apt update
|
||||
```
|
||||
|
||||
Installierte Pakete upgraden
|
||||
|
||||
```console
|
||||
sudo apt upgrade -y
|
||||
```
|
||||
|
||||
Unbenutzte Pakete entfernen
|
||||
|
||||
```console
|
||||
sudo apt autoremove -y
|
||||
```
|
||||
|
||||
## Arbeit an Webservern (Proxy)
|
||||
|
||||
Wir betreiben lastverteilte (Azure Load Balancer) Instanzen für unsere Webserver. Auf diesen Servern läuft NGINX, das den gesamten Datenverkehr von verschiedenen Anwendungen, die auf ihrer eigenen Infrastruktur laufen, zu freeCodeCamp.org umleitet.
|
||||
|
||||
Die NGINX-Konfiguration ist verfügbar in [diesem Repository](https://github.com/freeCodeCamp/nginx-config).
|
||||
|
||||
### Erste Installation
|
||||
|
||||
Provisionieren der VMs mit Code
|
||||
|
||||
1. Installiere NGINX und konfiguriere es aus dem Repository.
|
||||
|
||||
```console
|
||||
sudo su
|
||||
|
||||
cd /var/www/html
|
||||
git clone https://github.com/freeCodeCamp/error-pages
|
||||
|
||||
cd /etc/
|
||||
rm -rf nginx
|
||||
git clone https://github.com/freeCodeCamp/nginx-config nginx
|
||||
|
||||
cd /etc/nginx
|
||||
```
|
||||
|
||||
2. Installiere die Cloudflare-Ursprungszertifikate und die upstream Anwendungskonfiguration.
|
||||
|
||||
Hole die Cloudflare-Ursprungszertifikate aus dem sicheren Speicher und installiere sie an erforderlichen Stellen.
|
||||
|
||||
**oder**
|
||||
|
||||
Übertrage bestehende Zertifikate:
|
||||
|
||||
```console
|
||||
# Local
|
||||
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
|
||||
scp -pr ./ssl username@target-server-public-ip:/tmp/
|
||||
|
||||
# Remote
|
||||
rm -rf ./ssl
|
||||
mv /tmp/ssl ./
|
||||
```
|
||||
|
||||
Aktualisiere die Upstream-Konfigurationen:
|
||||
|
||||
```console
|
||||
vi configs/upstreams.conf
|
||||
```
|
||||
|
||||
Ergänze/aktualisiere die Quell-/Herkunfts-IP-Adressen der Anwendung.
|
||||
|
||||
3. Richte Netzwerke und Firewalls ein.
|
||||
|
||||
Konfiguriere die Azure Firewalls und `ufw` nach Bedarf für die ingress-Ursprungsadressen.
|
||||
|
||||
4. Füge die VM zum Load Balancer Backend Pool hinzu.
|
||||
|
||||
Konfiguriere den Load Balancer und füge ihm Regeln hinzu, falls nötig. Es kann möglicherweise erforderlich sein, auch die VMs zum Load Balancer-Backend-Pool hinzufügen.
|
||||
|
||||
### Logging und Monitoring
|
||||
|
||||
1. Überprüfe den Status des NGINX-Dienstes mit dem folgenden Befehl:
|
||||
|
||||
```console
|
||||
sudo systemctl status nginx
|
||||
```
|
||||
|
||||
2. Logging und Monitoring für die Server sind verfügbar unter:
|
||||
|
||||
NGINX Amplify: [https://amplify.nginx.com]('https://amplify.nginx.com'), unser aktuelles Basis-Monitoring-Dashboard. Wir arbeiten an feineren Metriken für eine bessere Messbarkeit
|
||||
|
||||
### Aktualisieren von Instanzen (Wartung)
|
||||
|
||||
Konfigurationsänderungen an unseren NGINX-Instanzen werden auf GitHub gepflegt, diese sollten auf jeder Instanz wie folgt bereitgestellt werden:
|
||||
|
||||
1. Verbinde dich per SSH mit der Instanz und gib sudo ein
|
||||
|
||||
```console
|
||||
sudo su
|
||||
```
|
||||
|
||||
2. Lade den neuesten Konfigurationscode herunter.
|
||||
|
||||
```console
|
||||
cd /etc/nginx
|
||||
git fetch --all --prune
|
||||
git reset --hard origin/main
|
||||
```
|
||||
|
||||
3. Teste und lade die Konfiguration neu [mit Signals](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
|
||||
|
||||
```console
|
||||
nginx -t
|
||||
nginx -s reload
|
||||
```
|
||||
|
||||
## Arbeiten an API-Instanzen
|
||||
|
||||
1. Installiere Build-Tools für Node-Binaries (`node-gyp`) usw.
|
||||
|
||||
```console
|
||||
sudo apt install build-essential
|
||||
```
|
||||
|
||||
### Erste Installation
|
||||
|
||||
Bereitstellung von VMs mit dem Code
|
||||
|
||||
1. Installiere Node LTS.
|
||||
|
||||
2. Aktualisiere `npm` und installiere PM2 und richte `logrotate` und Start beim Booten ein
|
||||
|
||||
```console
|
||||
npm i -g npm@8
|
||||
npm i -g pm2
|
||||
pm2 install pm2-logrotate
|
||||
pm2 startup
|
||||
```
|
||||
|
||||
3. Klone freeCodeCamp, richte die Umgebungsvariablen (env) und Schlüssel ein.
|
||||
|
||||
```console
|
||||
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
|
||||
cd freeCodeCamp
|
||||
git checkout prod-current # or any other branch to be deployed
|
||||
```
|
||||
|
||||
4. Erstelle die `.env` aus dem geschützten Speicher für Anmeldeinformationen.
|
||||
|
||||
5. Erstelle die `google-credentials.json` aus dem geschützten Speicher für die Anmeldedaten.
|
||||
|
||||
6. Installiere Abhängigkeiten
|
||||
|
||||
```console
|
||||
npm ci
|
||||
```
|
||||
|
||||
7. Errichte den Server.
|
||||
|
||||
```console
|
||||
npm run create:config && npm run build:curriculum && npm run build:server
|
||||
```
|
||||
|
||||
8. Starte Instanzen
|
||||
|
||||
```console
|
||||
cd api-server
|
||||
pm2 start ./lib/production-start.js -i max --max-memory-restart 600M --name org
|
||||
```
|
||||
|
||||
### Logging und Monitoring
|
||||
|
||||
```console
|
||||
pm2 logs
|
||||
```
|
||||
|
||||
```console
|
||||
pm2 monit
|
||||
```
|
||||
|
||||
### Aktualisieren von Instanzen (Wartung)
|
||||
|
||||
Codeänderungen müssen von Zeit zu Zeit auf die API-Instanzen übertragen werden. Es kann ein fortlaufendes Update oder ein manuelles Update sein. Letzteres ist wichtig beim Ändern von Abhängigkeiten oder Hinzufügen von Umgebungsvariablen.
|
||||
|
||||
> [!ATTENTION] Automatisierte Pipelines können derzeit keine Aktualisierungen von Abhängigkeiten vornehmen. Wir müssen eine manuelle Aktualisierung durchführen, bevor die Deployment-Pipeline ausgeführt wird.
|
||||
|
||||
#### 1. Manuelle Updates - Werden für die Aktualisierung von Abhängigkeiten und Umgebungsvariablen verwendet.
|
||||
|
||||
1. Stoppe alle Instanzen
|
||||
|
||||
```console
|
||||
pm2 stop all
|
||||
```
|
||||
|
||||
2. Installiere Abhängigkeiten
|
||||
|
||||
```console
|
||||
npm ci
|
||||
```
|
||||
|
||||
3. Errichte den Server
|
||||
|
||||
```console
|
||||
npm run create:config && npm run build:curriculum && npm run build:server
|
||||
```
|
||||
|
||||
4. Starte Instanzen
|
||||
|
||||
```console
|
||||
pm2 start all --update-env && pm2 logs
|
||||
```
|
||||
|
||||
#### 2. Fortlaufende (Rolling) Updates - Werden für logische Änderungen am Code verwendet.
|
||||
|
||||
```console
|
||||
pm2 reload all --update-env && pm2 logs
|
||||
```
|
||||
|
||||
> [!NOTE] Wir führen fortlaufende Aktualisierungen des Codes, der Logik, mittels Pipelines durch. Du solltest diese Befehle nicht ausführen müssen. Sie dienen nur der Dokumentation.
|
||||
|
||||
## Arbeiten an Client-Instanzen
|
||||
|
||||
1. Installiere Build-Tools für Node-Binaries (`node-gyp`) usw.
|
||||
|
||||
```console
|
||||
sudo apt install build-essential
|
||||
```
|
||||
|
||||
### Erste Installation
|
||||
|
||||
Bereitstellung von VMs mit dem Code
|
||||
|
||||
1. Installiere Node LTS.
|
||||
|
||||
2. Aktualisiere `npm` und installiere PM2 und richte `logrotate` und Start beim Booten ein
|
||||
|
||||
```console
|
||||
npm i -g npm@8
|
||||
npm i -g pm2
|
||||
npm install -g serve
|
||||
pm2 install pm2-logrotate
|
||||
pm2 startup
|
||||
```
|
||||
|
||||
3. Klone die Client-Konfiguration, richte die Umgebungsvariablen und Schlüssel ein.
|
||||
|
||||
```console
|
||||
git clone https://github.com/freeCodeCamp/client-config.git client
|
||||
cd client
|
||||
```
|
||||
|
||||
Starte die Platzhalterinstanzen für den Webclient, diese werden mit Artefakten aus der Azure-Pipeline aktualisiert.
|
||||
|
||||
> Todo: Dieses Setup muss zu S3 oder Azure Blob Storage verschoben werden
|
||||
>
|
||||
> ```console
|
||||
> echo "serve -c ../../serve.json www -p 50505" >> client-start-primary.sh
|
||||
> chmod +x client-start-primary.sh
|
||||
> pm2 delete client-primary
|
||||
> pm2 start ./client-start-primary.sh --name client-primary
|
||||
> echo "serve -c ../../serve.json www -p 52525" >> client-start-secondary.sh
|
||||
> chmod +x client-start-secondary.sh
|
||||
> pm2 delete client-secondary
|
||||
> pm2 start ./client-start-secondary.sh --name client-secondary
|
||||
> ```
|
||||
|
||||
### Logging und Monitoring
|
||||
|
||||
```console
|
||||
pm2 logs
|
||||
```
|
||||
|
||||
```console
|
||||
pm2 monit
|
||||
```
|
||||
|
||||
### Aktualisieren von Instanzen (Wartung)
|
||||
|
||||
Codeänderungen müssen von Zeit zu Zeit auf die API-Instanzen übertragen werden. Es kann ein fortlaufendes Update oder ein manuelles Update sein. Letzteres ist wichtig, wenn du Abhängigkeiten ändern oder Umgebungsvariablen hinzufügen.
|
||||
|
||||
> [!ATTENTION] Automatisierte Pipelines können derzeit keine Aktualisierungen von Abhängigkeiten vornehmen. Wir müssen eine manuelle Aktualisierung durchführen, bevor die Deployment-Pipeline ausgeführt wird.
|
||||
|
||||
#### 1. Manuelle Updates - Werden für die Aktualisierung von Abhängigkeiten und Umgebungsvariablen verwendet.
|
||||
|
||||
1. Stoppe alle Instanzen
|
||||
|
||||
```console
|
||||
pm2 stop all
|
||||
```
|
||||
|
||||
2. Installiere oder aktualisiere Abhängigkeiten
|
||||
|
||||
3. Starte Instanzen
|
||||
|
||||
```console
|
||||
pm2 start all --update-env && pm2 logs
|
||||
```
|
||||
|
||||
#### 2. Fortlaufende (Rolling) Updates - Werden für logische Änderungen am Code verwendet.
|
||||
|
||||
```console
|
||||
pm2 reload all --update-env && pm2 logs
|
||||
```
|
||||
|
||||
> [!NOTE] Wir führen fortlaufende Aktualisierungen des Codes, der Logik, mittels Pipelines durch. Du sollte diese Befehle nicht ausführen müssen. Sie dienen nur der Dokumentation.
|
||||
|
||||
## Arbeiten an Chat-Servern
|
||||
|
||||
Unsere Chatserver sind mit einer HA-Konfiguration verfügbar, die [in den Rocket.Chat-Dokumenten empfohlen wird](https://docs.rocket.chat/installation/docker-containers/high-availability-install). Die Datei `docker-compose` dafür ist [hier](https://github.com/freeCodeCamp/chat-config) verfügbar.
|
||||
|
||||
Wir stellen redundante NGINX-Instanzen bereit, die ihrerseits einen Load Balancing (Azure Load Balancer) vor dem Rocket.Chat-Cluster aufweisen. Die NGINX-Konfigurationsdatei ist [hier](https://github.com/freeCodeCamp/chat-nginx-config) verfügbar.
|
||||
|
||||
### Erstinstallation
|
||||
|
||||
Bereitstellen von VMs mit dem Code
|
||||
|
||||
**NGINX Cluster:**
|
||||
|
||||
1. Installiere NGINX und konfiguriere es aus dem Repository.
|
||||
|
||||
```console
|
||||
sudo su
|
||||
|
||||
cd /var/www/html
|
||||
git clone https://github.com/freeCodeCamp/error-pages
|
||||
|
||||
cd /etc/
|
||||
rm -rf nginx
|
||||
git clone https://github.com/freeCodeCamp/chat-nginx-config nginx
|
||||
|
||||
cd /etc/nginx
|
||||
```
|
||||
|
||||
2. Installiere die Cloudflare-Ursprungszertifikate und die upstream Anwendungskonfiguration.
|
||||
|
||||
Hole die Cloudflare-Ursprungszertifikate aus dem sicheren Speicher und installiere sie an erforderlichen Stellen.
|
||||
|
||||
**oder**
|
||||
|
||||
Übertrage bestehende Zertifikate:
|
||||
|
||||
```console
|
||||
# Local
|
||||
scp -r username@source-server-public-ip:/etc/nginx/ssl ./
|
||||
scp -pr ./ssl username@target-server-public-ip:/tmp/
|
||||
|
||||
# Remote
|
||||
rm -rf ./ssl
|
||||
mv /tmp/ssl ./
|
||||
```
|
||||
|
||||
Aktualisiere die Upstream-Konfigurationen:
|
||||
|
||||
```console
|
||||
vi configs/upstreams.conf
|
||||
```
|
||||
|
||||
Ergänze/aktualisiere die Quell-/Herkunfts-IP-Adressen der Anwendung.
|
||||
|
||||
3. Richte Netzwerke und Firewalls ein.
|
||||
|
||||
Konfiguriere die Azure Firewalls und `ufw` nach Bedarf für die ingress-Ursprungsadressen.
|
||||
|
||||
4. Füge die VM zum Load Balancer Backend Pool hinzu.
|
||||
|
||||
Konfiguriere den Load Balancer und füge ihm Regeln hinzu, falls nötig. Eventuell musst du auch die VMs zum Load Balancer-Backend-Pool hinzufügen, falls erforderlich.
|
||||
|
||||
**Docker Cluster:**
|
||||
|
||||
1. Installiere Docker und konfiguriere aus dem Repository
|
||||
|
||||
```console
|
||||
git clone https://github.com/freeCodeCamp/chat-config.git chat
|
||||
cd chat
|
||||
```
|
||||
|
||||
2. Konfiguriere die erforderlichen Umgebungsvariablen und Instanz-IP-Adressen.
|
||||
|
||||
3. Starte den Rocket-Chat-Server
|
||||
|
||||
```console
|
||||
docker-compose config
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
### Logging und Monitoring
|
||||
|
||||
1. Überprüfe den Status des NGINX-Dienstes mit dem folgenden Befehl:
|
||||
|
||||
```console
|
||||
sudo systemctl status nginx
|
||||
```
|
||||
|
||||
2. Überprüfe den Status für laufende Docker-Instanzen mit:
|
||||
|
||||
```console
|
||||
docker ps
|
||||
```
|
||||
|
||||
### Instanzen aktualisieren (Wartung)
|
||||
|
||||
**NGINX Cluster:**
|
||||
|
||||
Konfigurationsänderungen für unsere NGINX-Instanzen werden auf GitHub gepflegt. Diese sollten auf jeder Instanz wie folgt implementiert werden:
|
||||
|
||||
1. Verbinde dich per SSH mit der Instanz und gib sudo ein
|
||||
|
||||
```console
|
||||
sudo su
|
||||
```
|
||||
|
||||
2. Hol dir den aktuellsten Konfigurationscode.
|
||||
|
||||
```console
|
||||
cd /etc/nginx
|
||||
git fetch --all --prune
|
||||
git reset --hard origin/main
|
||||
```
|
||||
|
||||
3. Teste und lade die Konfiguration neu [mit Signals](https://docs.nginx.com/nginx/admin-guide/basic-functionality/runtime-control/#controlling-nginx).
|
||||
|
||||
```console
|
||||
nginx -t
|
||||
nginx -s reload
|
||||
```
|
||||
|
||||
**Docker Cluster:**
|
||||
|
||||
1. Verbinde dich per SSH mit der Instanz und navigiere zum Chat-Konfigurationspfad
|
||||
|
||||
```console
|
||||
cd ~/chat
|
||||
```
|
||||
|
||||
2. Hol dir den aktuellsten Konfigurationscode.
|
||||
|
||||
```console
|
||||
git fetch --all --prune
|
||||
git reset --hard origin/main
|
||||
```
|
||||
|
||||
3. Lade das neueste Docker-Image für Rocket.Chat herunter
|
||||
|
||||
```console
|
||||
docker-compose pull
|
||||
```
|
||||
|
||||
4. Aktualisiere die laufenden Instanzen
|
||||
|
||||
```console
|
||||
docker-compose up -d
|
||||
```
|
||||
|
||||
5. Überprüfe, ob die Instanzen aktiv sind
|
||||
|
||||
```console
|
||||
docker ps
|
||||
```
|
||||
|
||||
6. Überflüssige Ressourcen bereinigen
|
||||
|
||||
```console
|
||||
docker system prune --volumes
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
```console
|
||||
WARNING! This will remove:
|
||||
- all stopped containers
|
||||
- all networks not used by at least one container
|
||||
- all volumes not used by at least one container
|
||||
- all dangling images
|
||||
- all dangling build cache
|
||||
|
||||
Are you sure you want to continue? [y/N] y
|
||||
```
|
||||
|
||||
Wähle ja (y), um alles zu entfernen, was nicht in Gebrauch ist. Dadurch werden alle gestoppten Container, alle Netzwerke und Volumes, die nicht von mindestens einem Container verwendet werden, sowie alle überflüssigen Images und Build-Caches entfernt.
|
||||
|
||||
## Arbeit an Contributor Tools
|
||||
|
||||
### Updates bereitstellen
|
||||
|
||||
ssh in die VM (gehostet auf Digital Ocean).
|
||||
|
||||
```console
|
||||
cd tools
|
||||
git pull origin master
|
||||
npm ci
|
||||
npm run build
|
||||
pm2 restart contribute-app
|
||||
```
|
||||
|
||||
## Update von Node.js-Versionen auf VMs
|
||||
|
||||
Liste die aktuell installierten node & npm Versionen auf
|
||||
|
||||
```console
|
||||
nvm -v
|
||||
node -v
|
||||
npm -v
|
||||
|
||||
nvm ls
|
||||
```
|
||||
|
||||
Installiere die neueste Node.js LTS, und installiere alle globalen Pakete neu
|
||||
|
||||
```console
|
||||
nvm install --lts --reinstall-packages-from=default
|
||||
```
|
||||
|
||||
Überprüfe installierte Pakete
|
||||
|
||||
```console
|
||||
npm ls -g --depth=0
|
||||
```
|
||||
|
||||
Verändere die `Standard` Node.js Version zur aktuellen LTS (angeheftet an die letzte Hauptversion)
|
||||
|
||||
```console
|
||||
nvm alias default 16
|
||||
```
|
||||
|
||||
(Optional) Deinstalliere alte Versionen
|
||||
|
||||
```console
|
||||
nvm uninstall <version>
|
||||
```
|
||||
|
||||
> [!ATTENTION] In Client-Anwendungen ist es nicht möglich, `pm2 resurrect` zu verwenden, um Shell-Skripte zwischen Node.js-Versionen wieder herzustellen. Setze stattdessen Prozesse von Grund auf neu auf. Dies sollte einfacher werden, wenn wir zu einem Docker-basierten Setup wechseln.
|
||||
>
|
||||
> Wenn du PM2 für Prozesse verwendest, musst du auch die Anwendungen aufrufen und die Prozessliste für die automatische Wiederherstellung bei Neustarts speichern.
|
||||
|
||||
Hole die Anweisungen/Befehle zur Deinstallation mit dem Befehl `unstartup` und verwende die Ausgabe, um die systemctl Dienste zu entfernen
|
||||
|
||||
```console
|
||||
pm2 unstartup
|
||||
```
|
||||
|
||||
Hole dir die Installationsanweisungen/Befehle mit dem `startup` Befehl und benutze die Ausgabe, um die systemctl Dienste hinzuzufügen
|
||||
|
||||
```console
|
||||
pm2 startup
|
||||
```
|
||||
|
||||
Kurzbefehle für PM2, um gespeicherte Prozesse aufzulisten, wiederherzustellen usw.
|
||||
|
||||
```console
|
||||
pm2 ls
|
||||
```
|
||||
|
||||
```console
|
||||
pm2 resurrect
|
||||
```
|
||||
|
||||
```console
|
||||
pm2 save
|
||||
```
|
||||
|
||||
```console
|
||||
pm2 logs
|
||||
```
|
||||
|
||||
## Installieren und Aktualisieren von Azure-Pipeline-Agents
|
||||
|
||||
Siehe: https://docs.microsoft.com/en-us/azure/devops/pipelines/agents/v2-linux?view=azure-devops und befolge die Anweisungen zum Stoppen, Entfernen und Neuinstallieren von Agents. Im Großen und Ganzen kannst du die hier aufgeführten Schritte befolgen.
|
||||
|
||||
Du benötigst einen PAT, den du hier finden kannst: https://dev.azure.com/freeCodeCamp-org/_usersSettings/tokens
|
||||
|
||||
### Installieren eines Agenten auf einem Einsatzziel
|
||||
|
||||
Navigiere zu [Azure Devops](https://dev.azure.com/freeCodeCamp-org) und registriere den Agenten von Grund auf neu in den erforderlichen [Entwicklungsgruppen](https://dev.azure.com/freeCodeCamp-org/freeCodeCamp/_machinegroup).
|
||||
|
||||
> [!NOTE] Du solltest die Skripte im Home-Verzeichnis ausführen und sicherstellen, dass kein anderes `azagent` Verzeichnis existiert.
|
||||
|
||||
### Agents aktualisieren
|
||||
|
||||
Derzeit müssen Agents zum Aktualisieren entfernt und neu konfiguriert werden. Dies ist erforderlich, damit sie die `PATH`-Werte und andere Systemumgebungsvariablen korrekt übernehmen können. Wir müssen dies zum Beispiel tun, um Node.js auf unseren Ziel-VMs zu aktualisieren.
|
||||
|
||||
1. Navigiere zum Dienst und prüfe den Status
|
||||
|
||||
```console
|
||||
cd ~/azagent
|
||||
sudo ./svc.sh status
|
||||
```
|
||||
|
||||
2. Stoppe den Dienst
|
||||
|
||||
```console
|
||||
sudo ./svc.sh stop
|
||||
```
|
||||
|
||||
3. Deinstalliere den Dienst
|
||||
|
||||
```console
|
||||
sudo ./svc.sh uninstall
|
||||
```
|
||||
|
||||
4. Den Agenten aus dem Pipeline-Pool entfernen
|
||||
|
||||
```console
|
||||
./config.sh remove
|
||||
```
|
||||
|
||||
5. Entferne die Konfigurationsdateien
|
||||
|
||||
```console
|
||||
cd ~
|
||||
rm -rf ~/azagent
|
||||
```
|
||||
|
||||
Wenn du die oben genannten Schritte abgeschlossen hast, kannst du die gleichen Schritte wie bei der Installation des Agenten wiederholen.
|
||||
|
||||
# Handbuch - E-Mail Versand
|
||||
|
||||
Wir verwenden [ein CLI-Tool](https://github.com/freecodecamp/sendgrid-email-blast), um den wöchentlichen Newsletter zu versenden. Um dieses in Betrieb zu nehmen und den Prozess zu beginnen:
|
||||
|
||||
1. Melde dich bei DigitalOcean an und erstelle neue Droplets unter dem `Sendgrid`-Projekt. Verwende den Ubuntu Sendgrid-Snapshot mit dem aktuellsten Datum. Dieser wird mit dem CLI-Tool und dem Skript zum Abrufen von E-Mails aus der Datenbank geliefert. Bei dem aktuellen Volumen reichen drei Droplets aus, um die E-Mails rechtzeitig zu versenden.
|
||||
|
||||
2. Richte das Skript zum Abrufen der E-Mail-Liste ein.
|
||||
|
||||
```console
|
||||
cd /home/freecodecamp/scripts/emails
|
||||
cp sample.env .env
|
||||
```
|
||||
|
||||
Du musst die Platzhalterwerte in der `.env`-Datei durch deine Anmeldedaten ersetzen.
|
||||
|
||||
3. Starte das Script
|
||||
|
||||
```console
|
||||
node get-emails.js emails.csv
|
||||
```
|
||||
|
||||
Dadurch wird die E-Mail-Liste in einer `emails.csv`-Datei gespeichert.
|
||||
|
||||
4. Teile die E-Mails in mehrere Dateien auf, je nachdem, wie viele Droplets du brauchst. Das geht am einfachsten, indem du `scp` verwendest, um die E-Mail-Liste lokal zu speichern und sie mit deinem bevorzugten Texteditor in mehrere Dateien aufzuteilen. Jede Datei benötigt den `email,unsubscribeId`-Header.
|
||||
|
||||
5. Wechsle mit `cd /home/sendgrid-email-blast` in das CLI-Verzeichnis und konfiguriere das Tool [gemäß der Dokumentation](https://github.com/freeCodeCamp/sendgrid-email-blast/blob/main/README.md).
|
||||
|
||||
6. Führe das Tool aus, um die E-Mails zu versenden und folge dabei der [Benutzungsdokumentation](https://github.com/freeCodeCamp/sendgrid-email-blast/blob/main/docs/cli-steps.md).
|
||||
|
||||
7. Wenn der E-Mail-Versand abgeschlossen ist, überprüfe, dass keine E-Mails fehlgeschlagen sind, bevor du die Droplets vernichtest.
|
||||
|
||||
# Handbuch - Hinzufügen von Nachrichteninstanzen für neue Sprachen
|
||||
|
||||
### Änderungen des Themes
|
||||
|
||||
Wir verwenden ein eigenes [Theme](https://github.com/freeCodeCamp/news-theme) für unsere Nachrichtenpublikation. Wenn du die folgenden Änderungen am Theme vornimmst, können neue Sprachen hinzugefügt werden.
|
||||
|
||||
1. Füge eine `else if`-Anweisung für den neuen [ISO Sprachcode](https://www.loc.gov/standards/iso639-2/php/code_list.php) in [`setup-locale.js`](https://github.com/freeCodeCamp/news-theme/blob/main/assets/config/setup-locale.js) ein
|
||||
2. Erstelle einen ersten Konfigurationsordner, indem du den [`assets/config/de`](https://github.com/freeCodeCamp/news-theme/tree/main/assets/config/en) Ordner duplizierst und seinen Namen in den neuen Sprachcode änderst. (`de` —> `es` für Spanisch)
|
||||
3. Ändere im neuen Sprachordner die Variablennamen in `main.js` und `footer.js` in die entsprechende Sprachkurzform (`enMain` -> `esMain` für Spanisch)
|
||||
4. Dupliziere den [`locales/de.json`](https://github.com/freeCodeCamp/news-theme/blob/main/locales/en.json) und benenne ihn in den neuen Sprachcode.
|
||||
5. In [`partials/i18n.hbs`](https://github.com/freeCodeCamp/news-theme/blob/main/partials/i18n.hbs) fügst du Skripte für die neu erstellten Konfigurationsdateien hinzu.
|
||||
6. Füge das Skript (`day.js`) der zugehörigen Sprache von [cdnjs](https://cdnjs.com/libraries/dayjs/1.10.4) zum [freeCodeCamp CDN](https://github.com/freeCodeCamp/cdn/tree/main/build/news-assets/dayjs/1.10.4/locale) hinzu
|
||||
|
||||
### Ghost Dashboard Änderungen
|
||||
|
||||
Aktualisiere die Publikations-Assets, indem du zum Ghost Dashboard > Einstellungen > Allgemein gehst und die [Icon](https://github.com/freeCodeCamp/design-style-guide/blob/master/assets/fcc-puck-500-favicon.png), das [Logo](https://github.com/freeCodeCamp/design-style-guide/blob/master/downloads/fcc_primary_large.png) und das [Cover](https://github.com/freeCodeCamp/design-style-guide/blob/master/assets/fcc_ghost_publication_cover.png) der Publikationen hochlädst.
|
||||
77
docs/i18n/german/how-to-add-cypress-tests.md
Normal file
77
docs/i18n/german/how-to-add-cypress-tests.md
Normal file
@ -0,0 +1,77 @@
|
||||
# Wie man Cypress Tests erstellt
|
||||
|
||||
Wenn du Änderungen an JavaScript, CSS oder HTML vornimmst, die die Funktionalität oder das Layout einer Seite verändern könnten, ist es wichtig, entsprechende [Cypress](https://docs.cypress.io)-Integrationstests hinzuzufügen.
|
||||
|
||||
Wie man Cypress-Tests oder "Specs" schreibt, erfährst du in der offiziellen [Dokumentation](https://docs.cypress.io/guides/getting-started/writing-your-first-test.html) von Cypress.
|
||||
|
||||
## Wo du einen Test hinzufügen kannst
|
||||
|
||||
- Cypress-Tests befinden sich im Verzeichnis `./cypress`.
|
||||
|
||||
- Cypress-Tests für ein Studienplanmodul befinden sich im entsprechenden Studienplanverzeichnis, d.h. `cypress/integration/learn/responsive-web-design/basic-css/index.js`.
|
||||
|
||||
## Wie man Tests durchführt
|
||||
|
||||
> [!NOTE] Wenn du GitPod verwendest, lies bitte [Cypress-GitPod Setup](/how-to-add-cypress-tests#cypress-gitpod-setup)
|
||||
|
||||
### 1. Sicherstellen, dass MongoDB und Client-Anwendungen ausgeführt werden
|
||||
|
||||
- [Starte MongoDB und erstelle die Datenbank](/how-to-setup-freecodecamp-locally#step-3-start-mongodb-and-seed-the-database)
|
||||
|
||||
- [Starte die freeCodeCamp Client-Anwendung und den API-Server](/how-to-setup-freecodecamp-locally#step-4-start-the-freecodecamp-client-application-and-api-server)
|
||||
|
||||
### 2. Führe die Cypress-Tests durch
|
||||
|
||||
Um Tests mit Produktions-Builds durchzuführen, ersetze unten `dev` durch `prd`.
|
||||
|
||||
- Um alle Tests im Verzeichnis `./cypress` auszuführen:
|
||||
|
||||
```console
|
||||
npm run cypress:dev:run
|
||||
```
|
||||
|
||||
- Um einen einzelnen Test durchzuführen:
|
||||
|
||||
```console
|
||||
npm run cypress:dev:run -- --spec=cypress/pathToYourSpec/youSpecFileName.js
|
||||
```
|
||||
|
||||
- Um einen Entwicklungs-Build zu erstellen, starte den Entwicklungsserver und führe alle vorhandenen Cypress-End-to-End-Tests aus:
|
||||
|
||||
```console
|
||||
npm run e2e:dev:run
|
||||
```
|
||||
|
||||
## Cypress-GitPod Setup
|
||||
|
||||
### 1. Sicherstellen, dass die Entwicklungsumgebung läuft
|
||||
|
||||
Wenn das Starten der GitPod-Umgebung nicht automatisch die Umgebung aufgebaut hat:
|
||||
|
||||
- Starte die Datenbank
|
||||
|
||||
```console
|
||||
mongod
|
||||
```
|
||||
|
||||
- Richte die Datenbank ein
|
||||
|
||||
```console
|
||||
npm run seed
|
||||
```
|
||||
|
||||
- Entwickle den Server und den Client
|
||||
|
||||
```console
|
||||
npm run develop
|
||||
```
|
||||
|
||||
### 2. Cypress Build Tools installieren
|
||||
|
||||
```console
|
||||
npm run cypress:install-build-tools
|
||||
```
|
||||
|
||||
- Wenn du im Terminal dazu aufgefordert wirst, wähle dein Tastaturlayout nach Sprache/Region aus
|
||||
|
||||
Jetzt kann [Cypress ausgeführt werden](/how-to-add-cypress-tests#_2-run-the-cypress-tests)
|
||||
123
docs/i18n/german/how-to-catch-outgoing-emails-locally.md
Normal file
123
docs/i18n/german/how-to-catch-outgoing-emails-locally.md
Normal file
@ -0,0 +1,123 @@
|
||||
> **Hinweis:** Dies ist ein **optionaler** Schritt und wird nur bei der Arbeit mit E-Mail-Workflows benötigt
|
||||
|
||||
- [Einführung](#introduction)
|
||||
- [MailHog installieren](#installing-mailhog)
|
||||
- [MailHog verwenden](#using-mailhog)
|
||||
- [Nützliche Links](#useful-links)
|
||||
|
||||
## Einführung
|
||||
|
||||
Für einige E-Mail-Workflows, wie z. B. die Aktualisierung der E-Mail eines Nutzers, muss der Backend-Api-Server ausgehende E-Mails versenden. MailHog ist eine Alternative zur Nutzung eines E-Mail-Dienstleisters, um echte E-Mails zu versenden. Es ist ein Entwickler-Tool für E-Mail-Tests, das die von deiner freeCodeCamp-Instanz gesendeten E-Mails abfängt.
|
||||
|
||||
## MailHog installieren
|
||||
|
||||
MailHog kann auf macOS, Windows und Linux installiert oder über Docker verwendet werden
|
||||
|
||||
<details><summary>MailHog mit Docker installieren</summary>
|
||||
|
||||
Wenn du Docker installiert hast, kannst du
|
||||
|
||||
```bash
|
||||
docker run -d --name mailhog --network host --rm mailhog/mailhog
|
||||
```
|
||||
|
||||
eingeben, um MailHog im Hintergrund zu starten und
|
||||
|
||||
```bash
|
||||
docker stop mailhog
|
||||
```
|
||||
|
||||
um es zu stoppen.
|
||||
|
||||
Wenn die Installation abgeschlossen ist, kannst du [MailHog](#using-mailhog) benutzen.
|
||||
|
||||
</details>
|
||||
|
||||
<details><summary>MailHog auf macOS installieren</summary>
|
||||
|
||||
Installiere MailHog auf macOS mit [Homebrew](https://brew.sh/):
|
||||
|
||||
```bash
|
||||
brew install mailhog
|
||||
brew services start mailhog
|
||||
```
|
||||
|
||||
Mit den obigen Befehlen wird ein Mailhog-Dienst im Hintergrund gestartet.
|
||||
|
||||
Wenn die Installation abgeschlossen ist, kannst du [MailHog](#using-mailhog) benutzen.
|
||||
|
||||
</details>
|
||||
|
||||
<details><summary>Installation von MailHog unter Windows</summary>
|
||||
|
||||
Lade die neueste Version von MailHog von [MailHogs offiziellem Repository](https://github.com/mailhog/MailHog/releases) herunter. Klicke auf den Link für deine Windows-Version (32 oder 64 Bit) und es wird eine exe-Datei auf deinen Computer heruntergeladen.
|
||||
|
||||
Wenn der Download abgeschlossen ist, klicke auf die Datei, um sie zu öffnen. Es kann sein, dass eine Benachrichtigung der Windows-Firewall erscheint, die eine Zugriffsberechtigung für MailHog anfordert. Es öffnet sich eine Standard-Windows-Kommandozeile, in der MailHog ausgeführt wird, sobald der Firewall-Zugriff gewährt wurde.
|
||||
|
||||
Beende MailHog, indem du das Fenster der Kommandozeile schließt. Um MailHog erneut zu starten, klicke auf die ausführbare MailHog-Datei (.exe), die du ursprünglich heruntergeladen hast - es ist nicht nötig, eine neue MailHog-Installationsdatei herunterzuladen.
|
||||
|
||||
Starte [mit der Nutzung von MailHog](#using-mailhog).
|
||||
|
||||
</details>
|
||||
|
||||
<details><summary>MailHog unter Linux installieren</summary>
|
||||
|
||||
Installiere zuerst [Go](https://golang.org).
|
||||
|
||||
Führe die folgenden Befehle aus, um GO auf Debian-basierten Systemen wie Ubuntu und Linux Mint zu installieren.
|
||||
|
||||
```bash
|
||||
sudo apt-get install golang
|
||||
```
|
||||
|
||||
Führe die folgenden Befehle aus, um GO auf RPM-basierten Systemen wie CentOS, Fedora, Red Hat Linux, etc. zu installieren.
|
||||
|
||||
```bash
|
||||
sudo dnf install golang
|
||||
```
|
||||
|
||||
Alternativ kannst du GO auch mit den folgenden Befehlen installieren.
|
||||
|
||||
```bash
|
||||
sudo yum install golang
|
||||
```
|
||||
|
||||
Setze nun den Pfad für Go mit den folgenden Befehlen.
|
||||
|
||||
```bash
|
||||
echo "export GOPATH=$HOME/go" >> ~/.profile
|
||||
echo 'export PATH=$PATH:/usr/local/go/bin:$GOPATH/bin' >> ~/.profile
|
||||
source ~/.profile
|
||||
```
|
||||
|
||||
Gib schließlich die folgenden Befehle ein, um MailHog zu installieren und auszuführen.
|
||||
|
||||
```bash
|
||||
go get github.com/mailhog/MailHog
|
||||
sudo cp /home/$(whoami)/go/bin/MailHog /usr/local/bin/mailhog
|
||||
mailhog
|
||||
```
|
||||
|
||||
Starte [mit der Nutzung von MailHog](#using-mailhog).
|
||||
|
||||
</details>
|
||||
|
||||
## MailHog verwenden
|
||||
|
||||
Öffne einen neuen Browser-Tab oder ein neues Fenster und navigiere zu [http://localhost:8025](http://localhost:8025), um deinen MailHog-Posteingang zu öffnen, wenn die MailHog-Installation abgeschlossen ist und MailHog ausgeführt wird. Der Posteingang sieht dann so aus wie auf dem Screenshot unten.
|
||||
|
||||
|
||||
|
||||
Die von deiner freeCodeCamp-Installation gesendeten E-Mails werden wie folgt aussehen
|
||||
|
||||
|
||||
|
||||
Wenn du eine bestimmte E-Mail öffnest, stehen dir zwei Registerkarten zur Verfügung, auf denen du entweder den reinen Text (Plain text) oder den Quelltext (Source) anzeigen kannst. Vergewissere dich, dass die Registerkarte Plain text wie folgt ausgewählt ist.
|
||||
|
||||
|
||||
|
||||
Alle Links in der E-Mail sollten anklickbar sein und auf ihre URL verweisen.
|
||||
|
||||
## Nützliche Links
|
||||
|
||||
- Weitere Informationen zu MailHog findest du im [MailHog](https://github.com/mailhog/MailHog) Repository. Außerdem gibt es zusätzliche Informationen über benutzerdefinierte MailHog-Konfigurationen.
|
||||
198
docs/i18n/german/how-to-help-with-video-challenges.md
Normal file
198
docs/i18n/german/how-to-help-with-video-challenges.md
Normal file
@ -0,0 +1,198 @@
|
||||
# Wie du bei Videoaufgaben helfen kannst
|
||||
|
||||
Videoaufgaben sind eine neue Art von Aufgaben im freeCodeCamp-Studienplan.
|
||||
|
||||
Eine Videoaufgabe ist ein kleiner Abschnitt eines Videokurses in voller Länge zu einem bestimmten Thema. Eine Videoaufgabenseite bettet ein YouTube-Video ein. Jede Aufgabenseite enthält eine Multiple-Choice-Frage zum Video. Der/die Nutzer/in muss die Frage richtig beantworten, bevor er/sie zur nächsten Videoaufgabe des Kurses übergehen kann.
|
||||
|
||||
Die Videoaufgabenseiten werden von Mitgliedern des freeCodeCamp-Teams erstellt. YouTube-Videos werden auch von Mitgliedern des freeCodeCamp-Teams hochgeladen. Viele der Videoaufgaben sind noch nicht mit Fragen verknüpft.
|
||||
|
||||
Du kannst helfen, indem du Multiple-Choice-Fragen zu den Videoabschnitten erstellst und die Fragen zu den Markdown-Dateien für die Videoaufgabe hinzufügst.
|
||||
|
||||
## Vorlage für Aufgaben
|
||||
|
||||
Unten siehst du eine Vorlage, wie die Markdown-Dateien für die Aufgaben aussehen.
|
||||
|
||||
````md
|
||||
---
|
||||
id: Unique identifier (alphanumerical, MongoDB_id)
|
||||
title: Challenge Title
|
||||
challengeType: 11
|
||||
videoId: 'YouTube videoId for video challenge'
|
||||
forumTopicId: 12345
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Challenge description text, in markdown
|
||||
|
||||
```html
|
||||
<div>example code</div>
|
||||
````
|
||||
|
||||
# --question--
|
||||
|
||||
Diese Felder werden derzeit für die Multiple-Choice-Aufgaben in Python verwendet.
|
||||
|
||||
## --text--
|
||||
|
||||
Der Fragetext gehört hierher.
|
||||
|
||||
## --answers--
|
||||
|
||||
Antwort 1
|
||||
|
||||
---
|
||||
|
||||
Antwort 2
|
||||
|
||||
---
|
||||
|
||||
Mehr Antworten
|
||||
|
||||
## --video-solution--
|
||||
|
||||
Die Anzahl der richtigen Antworten gehört hierher.
|
||||
````
|
||||
|
||||
## Erstelle Fragen für Videoaufgaben
|
||||
|
||||
### Zugriff auf die Markdown-Dateien der Videoaufgaben
|
||||
|
||||
Du findest die Markdown-Dateien für die Videoaufgaben auf den folgenden Seiten im Studienplan:
|
||||
|
||||
- [Data Analysis with Python Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/08-data-analysis-with-python/data-analysis-with-python-course)
|
||||
- [TensorFlow 2.0 Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/11-machine-learning-with-python/tensorflow)
|
||||
- [Numpy Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/08-data-analysis-with-python/numpy)
|
||||
- [How Neural Networks Work Course](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/11-machine-learning-with-python/how-neural-networks-work)
|
||||
|
||||
Wähle eine Aufgaben-Markdown-Datei aus den obigen Optionen aus.
|
||||
|
||||
### Überfliege das Video, das mit der Aufgabe verbunden ist, und erstelle eine Multiple-Choice-Frage.
|
||||
|
||||
Finde zunächst die videoId.
|
||||
|
||||
Im folgenden Code aus dem Header einer Videoaufgaben-Markdown-Datei lautet die videoId zum Beispiel "nVAaxZ34khk". Auf GitHub sollten die Informationen in einem Tabellenformat dargestellt werden.
|
||||
|
||||
````
|
||||
---
|
||||
id: 5e9a093a74c4063ca6f7c14d title: Data Analysis Example A challengeType: 11
|
||||
videoId: nVAaxZ34khk
|
||||
---
|
||||
```
|
||||
|
||||
Als Nächstes rufst du das YouTube-Video mit dieser Video-ID auf. Die URL für das Video lautet dann:
|
||||
https://www.youtube.com/watch?v=[videoId] (ersetze `videoId` in der URL durch die ID des Videos - ohne eckige Klammern)
|
||||
|
||||
Im obigen Beispiel lautet die URL https://www.youtube.com/watch?v=nVAaxZ34khk
|
||||
|
||||
Überfliege das YouTube-Video mit dieser videoId und überlege dir eine Multiple-Choice-Frage, die auf dem Inhalt des Videos basiert.
|
||||
|
||||
### Füge die Frage zur Markdown-Datei hinzu.
|
||||
|
||||
Du kannst die Frage lokal oder über die Benutzeroberfläche von GitHub hinzufügen. Um die Frage lokal hinzuzufügen, musst du [freeCodeCamp lokal einrichten](how-to-setup-freecodecamp-locally.md). Du kannst die Datei auch auf GitHub finden und auf den Button "Bearbeiten" klicken, um die Frage direkt in deinem Browser hinzuzufügen.
|
||||
|
||||
Wenn eine Frage noch nicht zu einer bestimmten Videoaufgabe hinzugefügt wurde, wird sie mit der folgenden Standardfrage versehen:
|
||||
|
||||
```md
|
||||
# --question--
|
||||
|
||||
## ``---text--
|
||||
|
||||
Text der Frage
|
||||
|
||||
## --answers--
|
||||
|
||||
Antwort 1
|
||||
|
||||
---
|
||||
|
||||
Antwort 2
|
||||
|
||||
---
|
||||
```
|
||||
|
||||
Füge den Fragetext unter dem angezeigten Teil hinzu bzw. aktualisiere ihn:
|
||||
|
||||
```
|
||||
# --question--
|
||||
|
||||
## --text--
|
||||
```
|
||||
|
||||
Füge Antworten (`Answer 1`, `Answer 2`, und so weiter) unter `## --answers--` hinzu bzw. aktualisiere sie. Achte darauf, dass du die Nummer unter `## --video-solution--` mit der richtigen Antwortnummer aktualisierst. Du kannst weitere mögliche Antworten hinzufügen, indem du das gleiche Format verwendest. Die Fragen und Antworten können in Anführungszeichen gesetzt werden.
|
||||
|
||||
### Fragebeispiele
|
||||
|
||||
````md
|
||||
# --question--
|
||||
|
||||
## --text--
|
||||
|
||||
Was wird mit diesem JavaScript-Code auf der Konsole ausgegeben?
|
||||
|
||||
```js
|
||||
console.log('hello world');
|
||||
````
|
||||
|
||||
## --answers--
|
||||
|
||||
hello _world_
|
||||
|
||||
---
|
||||
|
||||
**hello** world
|
||||
|
||||
---
|
||||
|
||||
hello world
|
||||
|
||||
---
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3
|
||||
````
|
||||
|
||||
````md
|
||||
# --question--
|
||||
|
||||
## --text--
|
||||
|
||||
Was wird nach der Ausführung dieses Codes ausgedruckt:
|
||||
|
||||
|
||||
```py
|
||||
width = 15
|
||||
height = 12.0
|
||||
print(height/3)
|
||||
````
|
||||
|
||||
## --answers--
|
||||
|
||||
39
|
||||
|
||||
---
|
||||
|
||||
4
|
||||
|
||||
---
|
||||
|
||||
4.0
|
||||
|
||||
---
|
||||
|
||||
5.0
|
||||
|
||||
---
|
||||
|
||||
5
|
||||
|
||||
## --video-solution--
|
||||
|
||||
3 ````
|
||||
|
||||
Für weitere Beispiele kannst du dir die Markdown-Dateien für den folgenden Videokurs ansehen. Zu allen Aufgaben gibt es bereits Fragen: [Python für Jedermann Kurs](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges/english/07-scientific-computing-with-python/python-for-everybody)
|
||||
|
||||
## Öffne einen Pull-Request
|
||||
|
||||
Nachdem du eine oder mehrere Fragen erstellt hast, kannst du die Änderungen in einem neuen Branch übertragen und [einen Pull-Request](how-to-open-a-pull-request.md) öffnen.
|
||||
183
docs/i18n/german/how-to-open-a-pull-request.md
Normal file
183
docs/i18n/german/how-to-open-a-pull-request.md
Normal file
@ -0,0 +1,183 @@
|
||||
# Wie man einen Pull-Request (PR) öffnet
|
||||
|
||||
Ein Pull-Request (PR) ermöglicht es dir, Änderungen von deinem Fork auf GitHub an FreeCodeCamp.orgs Hauptrepository zu senden. Wenn du mit den Änderungen am Code fertig bist, kannst du diese Richtlinien befolgen, um einen PR zu eröffnen.
|
||||
|
||||
> [!NOTE] Dein PR sollte in Englisch verfasst sein. Schaue [hier](index.md#translations) nach, wie du Übersetzungen beisteuern kannst.
|
||||
|
||||
## Bereite einen guten PR-Titel vor
|
||||
|
||||
Wir empfehlen, [konventionelle Titel und Nachrichten](https://www.conventionalcommits.org/) für Commits und Pull-Requests zu verwenden. Die Konvention hat das folgende Format:
|
||||
|
||||
> `<type>([optional scope(s)]): <description>`
|
||||
>
|
||||
> Zum Beispiel:
|
||||
>
|
||||
> `fix(learn): tests for the do...while loop challenge`
|
||||
|
||||
Wenn du einen Pull-Request (PR) öffnest, kannst du den Typ, den Geltungsbereich \[scope\] (optional) und die Beschreibung wie folgt festlegen.
|
||||
|
||||
**Typ:**
|
||||
|
||||
| Typ | Wann wählen |
|
||||
|:----- |:------------------------------------------------------------------------------------------------ |
|
||||
| fix | Geänderte oder aktualisierte/verbesserte Funktionalität, Tests, der Wortlaut einer Lektion, usw. |
|
||||
| feat | Nur wenn du neue Funktionen, Tests usw. hinzufügst. |
|
||||
| chore | Änderungen, die sich nicht auf den Code, die Tests oder den Wortlaut einer Lektion beziehen. |
|
||||
| docs | Änderungen im Verzeichnis `/docs` oder in den Mitwirkungsrichtlinien, etc. |
|
||||
|
||||
**Geltungsbereich (Scope):**
|
||||
|
||||
Du kannst einen Geltungsbereich aus [dieser Liste von Labels](https://github.com/freeCodeCamp/freeCodeCamp/labels?q=scope) auswählen.
|
||||
|
||||
**Beschreibung:**
|
||||
|
||||
Halte sie kurz (weniger als 30 Zeichen) und einfach. Du kannst weitere Informationen im PR-Beschreibungsfeld und in den Kommentaren hinzufügen.
|
||||
|
||||
Einige Beispiele für gute PR-Titel wären:
|
||||
|
||||
- `fix(a11y): improved search bar contrast`
|
||||
- `feat: add more tests to HTML and CSS challenges`
|
||||
- `fix(api,client): prevent CORS errors on form submission`
|
||||
- `docs(i18n): Chinese translation of local setup`
|
||||
|
||||
## Einen Pull-Request vorschlagen
|
||||
|
||||
1. Sobald die Änderungen übertragen wurden, wirst du aufgefordert, einen Pull-Request auf der GitHub-Seite deines Forks zu erstellen.
|
||||
|
||||
|
||||
|
||||
2. Grundsätzlich sollten alle Pull-Requests gegen das Haupt-Repository von freeCodeCamp, den `main`-Branch, gerichtet sein.
|
||||
|
||||
Stelle sicher, dass dein Base Fork auf freeCodeCamp/freeCodeCamp eingestellt ist, wenn du einen Pull-Request einreichst.
|
||||
|
||||
|
||||
|
||||
3. Übermittle den Pull-Request von deinem Branch an den `main`-Branch von freeCodeCamp.
|
||||
|
||||
4. Im Hauptteil deines PR fügst du eine ausführlichere Zusammenfassung der Änderungen ein, die du vorgenommen hast und warum.
|
||||
|
||||
- Du erhältst eine Vorlage für einen Pull-Request. Dies ist eine Checkliste, die du befolgen solltest, bevor du den Pull-Request öffnest.
|
||||
|
||||
- Fülle die Details so aus, wie du es für richtig hältst. Diese Informationen werden geprüft und die Prüfer entscheiden, ob dein Pull-Request angenommen wird oder nicht.
|
||||
|
||||
- Wenn der PR ein bestehendes GitHub Problem beheben soll, dann am Ende von der Beschreibungstext deines PR verwenden Sie das Schlüsselwort _Schließt_ mit der Ticketnummer zu [automatisch schließen, wenn der PR akzeptiert und zusammengeführt wird](https://help.github.com/en/articles/closing-issues-using-keywords).
|
||||
|
||||
> Beispiel: `Closes #123` wird Issue 123 schließen
|
||||
|
||||
5. Gib an, ob du auf einer lokalen Kopie der Website getestet hast oder nicht.
|
||||
|
||||
- Das ist sehr wichtig, wenn du Änderungen vornimmst, die nicht nur Textinhalte wie die Dokumentation oder eine Aufgabenbeschreibung betreffen. Beispiele für Änderungen, die lokal getestet werden müssen, sind JavaScript, CSS oder HTML, die die Funktionalität oder das Layout einer Seite verändern könnten.
|
||||
|
||||
- Wenn dein PR das Verhalten einer Seite beeinflusst, sollte er von entsprechenden [Cypress Integrationstests](how-to-add-cypress-tests.md) begleitet werden.
|
||||
|
||||
## Feedback zu Pull-Requests
|
||||
|
||||
> Glückwunsch! :tada: für die Erstellung eines PR und vielen Dank, dass du dir die Zeit genommen haben, einen Beitrag zu leisten.
|
||||
|
||||
Unsere Moderatoren werden jetzt einen Blick darauf werfen und dir ein Feedback hinterlassen. Bitte habe Geduld mit den anderen Moderatoren und respektiere ihre Zeit. Alle Pull-Requests werden zu gegebener Zeit überprüft.
|
||||
|
||||
Und wie immer kannst du Fragen in der [Kategorie 'Contributors' in unserem Forum](https://forum.freecodecamp.org/c/contributors) oder im [Chatraum für Mitwirkende](https://chat.freecodecamp.org/channel/contributors) stellen.
|
||||
|
||||
> [!TIP] Wenn du mehr Pull-Requests beisteuern willst, empfehlen wir dir, die [Richtlinien für Änderungen und Synchronisierung](how-to-setup-freecodecamp-locally.md#making-changes-locally) zu lesen, damit du deinen Fork nicht löschen musst.
|
||||
|
||||
## Konflikte bei Pull-Requests
|
||||
|
||||
Es kann zu Konflikten kommen, weil viele Mitwirkende an dem Repository arbeiten und Änderungen deinen PR zerstören können, der noch auf eine Überprüfung und Zusammenführung wartet.
|
||||
|
||||
In den meisten Fällen brauchst du keinen Rebase, da wir alle Commits vernichten. Wenn jedoch ein Rebase verlangt wird, solltest du wie folgt vorgehen.
|
||||
|
||||
### Für die üblichen Fehlerbehebungen und Funktionen
|
||||
|
||||
Wenn du an regulären Bugs und Features auf unserem Entwicklungszweig `main` arbeitest, kannst du einen einfachen Rebase durchführen:
|
||||
|
||||
1. Rebase deiner lokalen Kopie:
|
||||
|
||||
```console
|
||||
git checkout <pr-branch>
|
||||
git pull --rebase upstream main
|
||||
```
|
||||
|
||||
2. Löse alle Konflikte und füge Commits hinzu / bzw. bearbeite sie
|
||||
|
||||
```console
|
||||
# Either
|
||||
git add .
|
||||
git commit -m "chore: resolve conflicts"
|
||||
|
||||
# Or
|
||||
git add .
|
||||
git commit --amend --no-edit
|
||||
```
|
||||
|
||||
3. Schiebe deine Änderungen in den PR zurück
|
||||
|
||||
```console
|
||||
git push --force origin <pr-branch>
|
||||
```
|
||||
|
||||
### Für anstehende Studienpläne und Features
|
||||
|
||||
Wenn du an Funktionen für unseren kommenden `next-*`-Branch arbeitest, musst du Rosinenpickerei betreiben:
|
||||
|
||||
1. Achte darauf, dass dein Upstream mit deinem Local übereinstimmt:
|
||||
|
||||
```console
|
||||
git checkout main
|
||||
git fetch --all --prune
|
||||
git checkout next-python-projects
|
||||
git reset --hard upstream/next-python-projects
|
||||
```
|
||||
|
||||
2. Backup erstellen
|
||||
|
||||
a. Entweder löschst du deinen lokalen Branch, nachdem du ein Backup gemacht hast (wenn du ihn noch lokal hast):
|
||||
|
||||
```console
|
||||
git checkout <pr-branch-name>
|
||||
|
||||
# Beispiel:
|
||||
# git checkout feat/add-numpy-video-question
|
||||
|
||||
git checkout -b <backup-branch-name>
|
||||
|
||||
# Beispiel:
|
||||
# git checkout -b backup-feat/add-numpy-video-question
|
||||
|
||||
git branch -D <pr-branch-name>
|
||||
```
|
||||
|
||||
b. Oder einfach ein Backup deines PR-Branch (wenn du ihn nicht lokal hast):
|
||||
|
||||
```console
|
||||
git checkout -b <backup-branch-name> origin/<pr-branch-name>
|
||||
|
||||
# Beispiel:
|
||||
# git checkout -b backup-feat/add-numpy-video-question origin/feat/add-numpy-video-question
|
||||
```
|
||||
|
||||
3. Beginne mit einer weißen Weste:
|
||||
|
||||
```console
|
||||
git checkout -b <pr-branch-name> next-python-projects
|
||||
git cherry-pick <commit-hash>
|
||||
```
|
||||
|
||||
4. Beseitige alle Konflikte und räume auf, installiere Tests und führe sie durch
|
||||
|
||||
```console
|
||||
npm run clean
|
||||
|
||||
npm ci
|
||||
npm run test:curriculum --superblock=<superblock-name>
|
||||
|
||||
# Beispiel:
|
||||
|
||||
# npm run test:curriculum --superblock=python-for-everyone
|
||||
|
||||
```
|
||||
|
||||
5. Wenn alles gut aussieht, schickst du es zurück an den PR
|
||||
|
||||
```console
|
||||
git push --force origin <pr-branch-name>
|
||||
```
|
||||
54
docs/i18n/german/how-to-proofread-files.md
Normal file
54
docs/i18n/german/how-to-proofread-files.md
Normal file
@ -0,0 +1,54 @@
|
||||
# Korrekturlesen von Übersetzungen
|
||||
|
||||
Unser Korrekturleseteam ist dafür verantwortlich, dass die Übersetzungen den Ausgangstext genau wiedergeben. Wir vertrauen darauf, dass unsere Korrekturleserinnen und -leser dafür sorgen, dass wir qualitativ hochwertige Übersetzungen erhalten.
|
||||
|
||||
Alle unsere Übersetzungen werden von Hand erstellt, von echten Menschen. Durch das Korrekturlesen wird sichergestellt, dass alle unsere übersetzten Ressourcen wie der Studienplan einen einheitlichen Wortlaut aufweisen.
|
||||
|
||||
Um mit dem Korrekturlesen zu beginnen, besuche [unsere Übersetzungsplattform](https://translate.freecodecamp.org) und logge dich ein. Wähle "Go to console" in der oberen Navigationsleiste, um von der öffentlichen Ansicht zur Ansicht des Arbeitsbereichs zu wechseln.
|
||||
|
||||
## Eine Datei auswählen
|
||||
|
||||
Du solltest die Liste der Projekte sehen, auf die du Zugriff erhalten hast. Wähle das Projekt aus, das du Korrektur lesen möchtest, und wähle dann die Sprache.
|
||||
|
||||
|
||||
|
||||
Du solltest jetzt die Liste der verfügbaren Dateien sehen. Wähle deine Datei aus, indem du auf den Button `Proofread` rechts neben der Datei klickst und dann `Proofreading` aus dem Dropdown-Menü wählst, das erscheint.
|
||||
|
||||
> [!NOTE] Wenn du dich in dieser Arbeitsbereichsansicht befindest, aber anstelle des Korrekturlesens an der [Übersetzung einer Datei](how-to-translate-files.md) arbeiten möchtest, kannst du stattdessen `Crowdsourcing` aus dem Dropdown-Menü auswählen.
|
||||
|
||||
## Korrekturlesen von Übersetzungen
|
||||
|
||||
|
||||
|
||||
<!--Add proofread/crowdsource button to the image-->
|
||||
|
||||
Hier siehst du die Liste der Strings in der ausgewählten Datei mit den dazugehörigen Übersetzungen. Die Übersetzung, die hier angezeigt wird, ist diejenige, die von der Übersetzergemeinschaft die höchste Punktzahl (zwischen Upvotes und Downvotes) erhalten hat.
|
||||
|
||||
Du kannst dir zwar _alle_ vorgeschlagenen Übersetzungen für einen bestimmten String ansehen, aber bei der Entscheidung, welche Übersetzung du genehmigst, solltest du die Community-Bewertungen (die durch die Upvotes und Downvotes bestimmt werden) berücksichtigen. Die Community kann die vorgeschlagenen Übersetzungen überprüfen und empfehlen, welche am genauesten und klarsten ist.
|
||||
|
||||
1. Dies ist der Originaltext (in Englisch).
|
||||
2. Dies ist die passende übersetzte Textstelle. Der beliebteste Übersetzungsvorschlag, basierend auf positiven und negativen Bewertungen, wird hier angezeigt.
|
||||
3. Wenn du auf dieses Häkchen klickst, wird die Übersetzung genehmigt.
|
||||
4. Crowdin zeigt den Status der einzelnen Textstelle an. `Done` bedeutet, dass eine Übersetzung genehmigt wurde und bei unserem nächsten Crowdin-Pull heruntergeladen werden wird. `Todo` bedeutet, dass die Textstelle bisher nicht geprüft wurde. `Hidden` bedeutet, dass der String gesperrt ist und _nicht übersetzt werden sollte_. `Comment` bedeutet, dass der String einen zugehörigen Kommentar hat.
|
||||
5. Übersetzungen können hier mit den Checkboxen ausgewählt und in einer Sammelaktion genehmigt werden.
|
||||
6. Du kannst die von der Community vorgeschlagenen Übersetzungen, ihre Beliebtheitswerte und die von Crowdin vorgeschlagenen Übersetzungen hier einsehen.
|
||||
7. Dieser Button blendet den rechten Anzeigebereich ein/aus, in dem du Übersetzungen, Kommentare, Translation Memory und Glossarbegriffe sehen kannst.
|
||||
8. Crowdin zeigt hier Fehlermeldungen aus den Qualitätssicherungsprüfungen an. Das heißt, wenn etwas in der Übersetzung nicht korrekt erscheint, wird Crowdin dich benachrichtigen. Diese Übersetzungen sollten mit Vorsicht genehmigt werden.
|
||||
|
||||
Nach dem Korrekturlesen einer Datei sind keine weiteren Aktionen erforderlich.
|
||||
|
||||
> [!NOTE] Wenn du einen String in der Korrekturansicht genehmigst, wird er als vollständig markiert und bei unserem nächsten Pull von Crowdin auf GitHub heruntergeladen.
|
||||
|
||||
## Korrekturleser werden
|
||||
|
||||
Wenn du Fragen hast oder daran interessiert bist, Korrekturleser zu werden, kannst du uns in unserem [Contributors Chat Room](https://chat.freecodecamp.org/channel/contributors) kontaktieren. In der Regel gewähren wir dir Zugang zum Korrekturlesen, wenn du schon eine Weile im freeCodeCamp mitarbeitest.
|
||||
|
||||
Unser Mitarbeiterteam und unsere Community-Moderatoren sind immer auf der Suche nach freundlichen Freiwilligen wie dir, die uns dabei helfen, der Welt qualitativ hochwertige Übersetzungen zur Verfügung zu stellen.
|
||||
|
||||
> [!NOTE] Crowdin ermöglicht es dir, deine Übersetzungen zu genehmigen. Im Allgemeinen ist es am besten, wenn du deine vorgeschlagenen Übersetzungen von einem anderen Korrekturleser durchsehen lässt, um sicherzugehen, dass keine Fehler enthalten sind.
|
||||
|
||||
## Einen Kanal im Chat für eine Weltsprache erstellen
|
||||
|
||||
In den meisten Fällen empfehlen wir dir, den [Contributors Chat](https://chat.freecodecamp.org/channel/contributors) für die gesamte Korrespondenz zu nutzen. Wenn jedoch das Team der freiwilligen Übersetzer für eine bestimmte Sprache wächst, können wir in Erwägung ziehen, einen zusätzlichen Break-Out-Channel für diese Sprache einzurichten.
|
||||
|
||||
Wenn du bereits Korrekturleser/in bist und Interesse an einem eigenen Kanal auf unseren Chatservern für eine bestimmte Sprache hast, [fülle dieses Formular aus](https://forms.gle/XU5CyutrYCgDYaVZA).
|
||||
575
docs/i18n/german/how-to-setup-freecodecamp-locally.md
Normal file
575
docs/i18n/german/how-to-setup-freecodecamp-locally.md
Normal file
@ -0,0 +1,575 @@
|
||||
Befolge diese Richtlinien, um freeCodeCamp lokal auf deinem System einzurichten. Das ist sehr empfehlenswert, wenn du regelmäßig einen Beitrag leisten willst.
|
||||
|
||||
Für einige dieser Arbeitsabläufe - wie das Beheben von Fehlern in der Codebasis oder im Studienplan - musst du freeCodeCamp lokal auf deinem Computer ausführen.
|
||||
|
||||
> [!TIP] Wenn du kein Interesse daran hast, das freeCodeCamp lokal einzurichten, kannst du auch Gitpod nutzen, eine kostenlose Online-Entwicklungsumgebung.
|
||||
>
|
||||
> [](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
|
||||
>
|
||||
> (Startet eine Entwicklungsumgebung für freeCodeCamp in deinem Browser.)
|
||||
|
||||
### Wie du deinen lokalen Rechner vorbereitest
|
||||
|
||||
Beginne mit der Installation der erforderlichen Software für dein Betriebssystem.
|
||||
|
||||
Wir unterstützen vor allem die Entwicklung auf Linux- und Unix-basierten Systemen. Unsere Mitarbeiter und Community-Mitglieder arbeiten regelmäßig mit der Codebasis und nutzen dafür Tools, die auf Ubuntu und macOS installiert sind.
|
||||
|
||||
Wir unterstützen auch Windows 10 über WSL2, das du einrichten kannst, indem du [diesen Leitfaden liest](how-to-setup-wsl.md).
|
||||
|
||||
Einige Community-Mitglieder entwickeln auch unter Windows 10 mit Git für Windows (Git Bash) und anderen unter Windows installierten Tools. Zurzeit gibt es keine offizielle Unterstützung für eine solche Konfiguration, wir empfehlen stattdessen die Verwendung von WSL2.
|
||||
|
||||
#### Voraussetzungen:
|
||||
|
||||
| Voraussetzung | Version | Notizen |
|
||||
| --------------------------------------------------------------------------------------------- | ------- | ---------------------------------------------------------------------------------------------------- |
|
||||
| [Node.js](http://nodejs.org) | `16.x` | Wir verwenden die "Active LTS"-Version, siehe [LTS Schedule](https://nodejs.org/en/about/releases/). |
|
||||
| npm (wird mit Node mitgeliefert) | `8.x` | Wir verwenden die Version, die mit Node.js Active LTS ausgeliefert wird. |
|
||||
| [MongoDB Community-Server](https://docs.mongodb.com/manual/administration/install-community/) | `4.0.x` | - |
|
||||
|
||||
> [!ATTENTION] Wenn du eine andere Version hast, installiere bitte die empfohlene Version. Wir können nur Installationsprobleme für empfohlene Versionen unterstützen. Siehe [Problembehebung](#troubleshooting) für Details.
|
||||
|
||||
Wenn Node.js bereits auf deinem Rechner installiert ist, führe die folgenden Befehle aus, um die Versionen zu überprüfen:
|
||||
|
||||
```console
|
||||
node -v
|
||||
npm -v
|
||||
```
|
||||
|
||||
> [!TIP] Wir empfehlen dringend, die neuesten stabilen Versionen der oben aufgeführten Software zu aktualisieren, auch bekannt als Long Term Support (LTS) Releases.
|
||||
|
||||
Sobald du die erforderlichen Ressourcen installiert hast, musst du deine Entwicklungsumgebung vorbereiten. Das ist für viele Entwicklungsworkflows üblich, und du musst das nur einmal machen.
|
||||
|
||||
##### Befolge diese Schritte, um deine Entwicklungsumgebung vorzubereiten:
|
||||
|
||||
1. Installiere [Git](https://git-scm.com/) oder deinen bevorzugten Git-Client, falls du das nicht schon getan hast. Aktualisiere auf die neueste Version; die Version, die mit deinem Betriebssystem mitgeliefert wurde, ist möglicherweise veraltet.
|
||||
|
||||
2. (Optional, aber empfohlen) [Richte einen SSH-Schlüssel](https://help.github.com/articles/generating-an-ssh-key/) für GitHub ein.
|
||||
|
||||
3. Installiere einen Code-Editor deiner Wahl.
|
||||
|
||||
Wir empfehlen die Verwendung von [Visual Studio Code](https://code.visualstudio.com/) oder [Atom](https://atom.io/). Dies sind große, kostenlose Open Source Code-Editoren.
|
||||
|
||||
4. Richte Linting für deinen Code-Editor ein.
|
||||
|
||||
Du solltest [ESLint in deinem Editor laufen lassen](http://eslint.org/docs/user-guide/integrations.html) und es wird alles markieren, was nicht dem [freeCodeCamp's JavaScript Style Guide](http://forum.freecodecamp.org/t/free-code-camp-javascript-style-guide/19121) entspricht.
|
||||
|
||||
> [!TIP] Bitte ignorieren Sie keine Verlinkungsfehler. They are meant to **help** you and to ensure a clean and simple codebase.
|
||||
|
||||
## Forke das Repository auf GitHub
|
||||
|
||||
[Forking](https://help.github.com/articles/about-forks/) ist ein Schritt, bei dem du deine eigene Kopie des freeCodeCamp-Hauptrepository (auch bekannt als _repo_) auf GitHub bekommst.
|
||||
|
||||
Das ist wichtig, denn so kannst du an deiner eigenen Kopie von freeCodeCamp auf GitHub arbeiten oder dein Repository herunterladen (klonen), um lokal daran zu arbeiten. Später kannst du über einen Pull Request (PR) beantragen, dass Änderungen aus deinem Fork in das Haupt-Repository gezogen werden.
|
||||
|
||||
> [!TIP] Das Hauptrepository unter `https://github.com/freeCodeCamp/freeCodeCamp` wird oft als das `Upstream` Repository bezeichnet.
|
||||
>
|
||||
> Dein Fork unter `https://github.com/YOUR_USER_NAME/freeCodeCamp` wird oft als `origin`-Repository bezeichnet. `YOUR_USER_NAME` wird durch deinen GitHub-Benutzernamen ersetzt.
|
||||
|
||||
**Folge diesen Schritten, um das `https://github.com/freeCodeCamp/freeCodeCamp` Repository zu forken:**
|
||||
|
||||
1. Gehe zum freeCodeCamp Repository auf GitHub: <https://github.com/freeCodeCamp/freeCodeCamp>
|
||||
|
||||
2. Klicke auf den "Fork"-Button in der oberen rechten Ecke der Benutzeroberfläche ([Mehr Details hier](https://help.github.com/articles/fork-a-repo/))
|
||||
|
||||
3. Nachdem das Repository geforkt wurde, wirst du zu deiner Kopie des freeCodeCamp Repository unter `https://github.com/YOUR_USER_NAME/freeCodeCamp` weitergeleitet (`YOUR_USER_NAME` wird durch deinen GitHub-Benutzernamen ersetzt).
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
So forkst du freeCodeCamp auf GitHub (Screenshot)
|
||||
</summary>
|
||||
|
||||
<br>
|
||||
<img src="https://raw.githubusercontent.com/freeCodeCamp/freeCodeCamp/main/docs/images/github/how-to-fork-freeCodeCamp.gif" alt="Wie man freeCodeCamp auf GitHub forkt" />
|
||||
</details>
|
||||
|
||||
## Klone deinen Fork von GitHub
|
||||
|
||||
Beim [Klonen](https://help.github.com/articles/cloning-a-repository/) **downloadest ** du eine Kopie eines Repositorys von einem `remote`- Ort, der entweder dir oder einer anderen Person gehört. In deinem Fall ist dieser Remote-Speicherort dein `Fork` des freeCodeCamp-Repositorys, das unter `https://github.com/YOUR_USER_NAME/freeCodeCamp` verfügbar sein sollte. (`YOUR_USER_NAME` wird durch deinen GitHub-Benutzernamen ersetzt).
|
||||
|
||||
> [!WARNING] Wenn du auf einer WSL2 Linux Distribution arbeitest, kann es zu Leistungs- und Stabilitätsproblemen kommen, wenn du dieses Projekt in einem Ordner ausführst, der von Windows und WSL2 gemeinsam genutzt wird (z.B. `/mnt/c/Users/`). Deshalb empfehlen wir dir, dieses Repo in einen Ordner zu klonen, der hauptsächlich von deiner WSL2 Linux Distribution genutzt wird und nicht direkt mit Windows geteilt wird (z.B. `~/PROJECTS/`).
|
||||
>
|
||||
> Siehe [diesen GitHub Issue](https://github.com/freeCodeCamp/freeCodeCamp/issues/40632) für weitere Informationen zu diesem Problem.
|
||||
|
||||
Führe diese Anweisungen auf deinem lokalen Rechner aus:
|
||||
|
||||
1. Öffne ein Terminal / Command Prompt / Shell in deinem Projektverzeichnis
|
||||
|
||||
_z.B.: `/yourprojectsdirectory/`_
|
||||
|
||||
2. Klone deinen Fork von freeCodeCamp und ersetze `YOUR_USER_NAME` durch deinen GitHub Benutzernamen
|
||||
|
||||
```console
|
||||
git clone --depth=1 https://github.com/YOUR_USER_NAME/freeCodeCamp.git
|
||||
```
|
||||
|
||||
Dadurch wird das gesamte freeCodeCamp-Repository in dein Projektverzeichnis heruntergeladen.
|
||||
|
||||
Hinweis: `--depth=1` erstellt einen oberflächlichen Klon deines Forks, der nur den jüngsten Verlauf/Commit enthält.
|
||||
|
||||
## Synchronisation vom Elternteil (parent) konfigurieren
|
||||
|
||||
Jetzt, wo du eine Kopie deines Forks heruntergeladen hast, musst du einen `upstream` zum übergeordneten Repository einrichten.
|
||||
|
||||
[Wie bereits erwähnt](#fork-the-repository-on-github), wird das Haupt-Repository als `upstream`-Repository bezeichnet. Dein Fork wird als `origin`-Repository bezeichnet.
|
||||
|
||||
Du brauchst eine Referenz von deinem lokalen Klon auf das `upstream`-Repository zusätzlich zum `origin`-Repository. So kannst du Änderungen aus dem Haupt-Repository synchronisieren, ohne dass du wiederholt forken und klonen musst.
|
||||
|
||||
1. Wechsle das Verzeichnis auf das neue freeCodeCamp-Verzeichnis:
|
||||
|
||||
```console
|
||||
cd freeCodeCamp
|
||||
```
|
||||
|
||||
2. Füge eine Remote-Referenz zum Haupt-Repository von freeCodeCamp hinzu:
|
||||
|
||||
```console
|
||||
git remote add upstream https://github.com/freeCodeCamp/freeCodeCamp.git
|
||||
```
|
||||
|
||||
3. Stelle sicher, dass die Konfiguration korrekt erscheint:
|
||||
|
||||
```console
|
||||
git remote -v
|
||||
```
|
||||
|
||||
Der Output sollte ungefähr so aussehen wie unten (ersetze `YOUR_USER_NAME` durch deinen GitHub Benutzernamen):
|
||||
|
||||
```console
|
||||
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (fetch)
|
||||
origin https://github.com/YOUR_USER_NAME/freeCodeCamp.git (push)
|
||||
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (fetch)
|
||||
upstream https://github.com/freeCodeCamp/freeCodeCamp.git (push)
|
||||
```
|
||||
|
||||
## FreeCodeCamp lokal ausführen
|
||||
|
||||
Jetzt, wo du eine lokale Kopie von freeCodeCamp besitzt, kannst du diese Anweisungen befolgen, um es lokal auszuführen. Das ermöglicht dir:
|
||||
|
||||
- Vorschau von Änderungen an Seiten, wie sie auf der Lernplattform erscheinen würden.
|
||||
- Arbeite an Problemen und Verbesserungen im Zusammenhang mit der Benutzeroberfläche.
|
||||
- Debugge und behebe Probleme mit den Anwendungsservern und Client-Anwendungen.
|
||||
|
||||
Wenn du auf Probleme stößt, führe zuerst eine Websuche nach deinem Problem durch und schaue nach, ob es bereits beantwortet wurde. Wenn du keine Lösung findest, suche bitte auf unserer [GitHub issues](https://github.com/freeCodeCamp/freeCodeCamp/issues)-Seite nach einer Lösung und melde das Problem, falls es noch nicht gemeldet wurde.
|
||||
|
||||
Und wie immer kannst du Fragen in der [Kategorie 'Contributors' in unserem Forum](https://forum.freecodecamp.org/c/contributors) oder [unserem Chat-Server](https://chat.freecodecamp.org/home) stellen.
|
||||
|
||||
> [!TIP] Du kannst darauf verzichten, freeCodeCamp lokal auszuführen, wenn du nur Dateien bearbeitest. Du kannst zum Beispiel ein `rebase` durchführen oder `merge`-Konflikte beheben.
|
||||
>
|
||||
> Du kannst später jederzeit zu diesem Teil der Anleitung zurückkehren. Du solltest diesen Schritt **nur** überspringen, wenn du die Apps nicht auf deinem Rechner ausführen musst.
|
||||
>
|
||||
> [Überspringen, um Änderungen vorzunehmen](#making-changes-locally).
|
||||
|
||||
### Konfiguriere Abhängigkeiten
|
||||
|
||||
#### Schritt 1: Einrichten der Umgebungsvariablendatei
|
||||
|
||||
Die Standard-API-Schlüssel und Umgebungsvariablen sind in der Datei `sample.env` gespeichert. Diese Datei muss in eine neue Datei namens `.env` kopiert werden, auf die während des Installationsschritts dynamisch zugegriffen wird.
|
||||
|
||||
```console
|
||||
# Erstelle eine Kopie der "sample.env" und nenne sie ".env".
|
||||
# Befülle sie mit den notwendigen API-Schlüsseln und Secrets:
|
||||
```
|
||||
|
||||
<!-- tabs:start -->
|
||||
|
||||
#### **macOS/Linux**
|
||||
|
||||
```console
|
||||
cp sample.env .env
|
||||
```
|
||||
|
||||
#### **Windows**
|
||||
|
||||
```console
|
||||
copy sample.env .env
|
||||
```
|
||||
|
||||
<!-- tabs:end -->
|
||||
|
||||
Die Schlüssel in der `.env` Datei müssen _nicht_ geändert werden, um die App lokal auszuführen. Du kannst die Standardwerte, die du aus `sample.env` kopiert hast, so lassen, wie sie sind.
|
||||
|
||||
> [!TIP] Denk daran, wenn du Dienste wie Auth0 oder Algolia nutzen willst, musst du deine eigenen API-Schlüssel für diese Dienste erwerben und die Einträge in der `.env`-Datei entsprechend bearbeiten.
|
||||
|
||||
#### Schritt 2: Abhängigkeiten installieren
|
||||
|
||||
In diesem Schritt werden die Abhängigkeiten installiert, die erforderlich sind, damit die Anwendung läuft:
|
||||
|
||||
```console
|
||||
npm ci
|
||||
```
|
||||
|
||||
#### Schritt 3: MongoDB starten und die Datenbank initialisieren
|
||||
|
||||
Bevor du die Anwendung lokal ausführen kannst, musst du den MongoDB-Dienst starten.
|
||||
|
||||
> [!NOTE] Wenn du MongoDB nicht in einem anderen Setup als dem Standard-Setup laufen hast, sollte die URL, die als `MONGOHQ_URL`-Wert in der `.env`-Datei gespeichert ist, funktionieren. Wenn du eine benutzerdefinierte Konfiguration verwendest, ändere diesen Wert nach Bedarf.
|
||||
|
||||
Starte den MongoDB-Server in einem separaten Terminal:
|
||||
|
||||
<!-- tabs:start -->
|
||||
|
||||
#### **macOS/Linux**
|
||||
|
||||
```console
|
||||
mongod
|
||||
```
|
||||
|
||||
#### **Windows**
|
||||
|
||||
- Unter Windows musst du den vollständigen Pfad zur `mongod`-Binärdatei angeben
|
||||
|
||||
```console
|
||||
"C:\Program Files\MongoDB\Server\3.6\bin\mongod"
|
||||
```
|
||||
|
||||
<!-- tabs:end -->
|
||||
|
||||
Ersetze `3.6` durch die Version, die du installiert hast.
|
||||
|
||||
> [!TIP] Du kannst vermeiden, dass du MongoDB jedes Mal starten musst, indem du es als Hintergrunddienst installierst. Du kannst [mehr darüber in der Dokumentation für dein Betriebssystem erfahren](https://docs.mongodb.com/manual/administration/install-community/)
|
||||
|
||||
Als Nächstes wollen wir die Datenbank initialisieren (seeden). In diesem Schritt führen wir den folgenden Befehl aus, der den MongoDB-Server mit einigen anfänglichen Datensätzen füllt, die von den Diensten benötigt werden. Dazu gehören unter anderem ein paar Schemata.
|
||||
|
||||
```console
|
||||
npm run seed
|
||||
```
|
||||
|
||||
#### Schritt 4: Starte die freeCodeCamp Client-Anwendung und den API-Server
|
||||
|
||||
Du kannst jetzt den API-Server und die Client-Anwendungen starten.
|
||||
|
||||
```console
|
||||
npm run develop
|
||||
```
|
||||
|
||||
Mit diesem einzigen Befehl werden alle Dienste gestartet, einschließlich des API-Servers und der Client-Anwendungen, an denen du arbeiten kannst.
|
||||
|
||||
> [!NOTE] Sobald du bereit bist, öffne einen Webbrowser und **besuche <http://localhost:8000>**. Wenn die App geladen wird, herzlichen Glückwunsch - du bist bereit! Du hast jetzt eine Kopie der gesamten Lernplattform von freeCodeCamp auf deinem lokalen Rechner laufen.
|
||||
|
||||
> [!TIP] Der API-Server bedient APIs unter `http://localhost:3000`. Die Gatsby-App bedient die Client-Anwendung unter `http://localhost:8000`
|
||||
|
||||
> Wenn du <http://localhost:3000/explorer> besuchst, solltest du die verfügbaren APIs sehen.
|
||||
|
||||
## Mit einem lokalen Benutzer anmelden
|
||||
|
||||
Deine lokale Einrichtung legt automatisch einen lokalen Benutzer in der Datenbank an. Wenn du auf den Button `Sign In` klickst, wirst du automatisch in der lokalen Anwendung authentifiziert.
|
||||
|
||||
Der Zugriff auf die Benutzerportfolio-Seite ist jedoch etwas knifflig. Bei der Entwicklung übernimmt Gatsby das Serving der clientseitigen Seiten und daher bekommst du eine `404`-Seite für das Benutzerportfolio, wenn du lokal arbeitest.
|
||||
|
||||
Wenn du auf den Button **"Preview Custom 404 Page"** klickst, wirst du auf die richtige Seite weitergeleitet.
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
So meldest du dich an, wenn du lokal arbeitest ( Screenshot)
|
||||
</summary>
|
||||
|
||||
<br>
|
||||
<img src="https://user-images.githubusercontent.com/29990697/71541249-f63cdf00-2923-11ea-8a85-cefb6f9c9977.gif" alt="Wie man sich anmeldet, wenn man lokal arbeitet" />
|
||||
</details>
|
||||
|
||||
## Lokale Änderungen vornehmen
|
||||
|
||||
Du kannst jetzt Änderungen an Dateien vornehmen und deine Änderungen an deinen lokalen Klon deines Forks übertragen.
|
||||
|
||||
Befolge diese Schritte:
|
||||
|
||||
1. Überprüfe, ob du dich auf dem `main`-Branch befindest:
|
||||
|
||||
```console
|
||||
git status
|
||||
```
|
||||
|
||||
Du solltest einen Output wie diesen erhalten:
|
||||
|
||||
```console
|
||||
Auf dem main-Branch
|
||||
Your branch is up-to-date with 'origin/main'.
|
||||
|
||||
nothing to commit, working directory clean
|
||||
```
|
||||
|
||||
Wenn du nicht auf main bist oder dein Arbeitsverzeichnis nicht sauber ist, löse alle ausstehenden Dateien/Commits auf und checke `main` aus:
|
||||
|
||||
```console
|
||||
git checkout main
|
||||
```
|
||||
|
||||
2. Synchronisiere die letzten Änderungen aus dem freeCodeCamp upstream-Branch `main` mit deinem lokalen Haupt-Branch:
|
||||
|
||||
> [!WARNING] Wenn du noch ausstehende Pull Requests aus dem `main`-Branch deines Forks hast, verlierst du sie am Ende dieses Schrittes.
|
||||
>
|
||||
> Du solltest sicherstellen, dass dein Pull-Request von einem Moderator zusammengeführt wird, bevor du diesen Schritt ausführst. Um dieses Szenario zu vermeiden, solltest du **immer** auf einem anderen Branch als dem `main` arbeiten.
|
||||
|
||||
Dieser Schritt **synchronisiert die letzten Änderungen** aus dem Haupt-Repository von freeCodeCamp. Es ist wichtig, dass du deinen Branch so oft wie möglich auf den neuesten `upstream/main` zurücksetzt, um spätere Konflikte zu vermeiden.
|
||||
|
||||
Aktualisiere deine lokale Kopie des freeCodeCamp upstream-Repository:
|
||||
|
||||
```console
|
||||
git fetch upstream
|
||||
```
|
||||
|
||||
Führe einen Hard Reset deines Hauptbranch mit dem freeCodeCamp main durch:
|
||||
|
||||
```console
|
||||
git reset --hard upstream/main
|
||||
```
|
||||
|
||||
Schiebe deinen Hauptbranch in deinen origin, um einen sauberen Verlauf deines Forks auf GitHub zu haben:
|
||||
|
||||
```console
|
||||
git push origin main --force
|
||||
```
|
||||
|
||||
Du kannst überprüfen, ob dein aktuelles Main mit dem upstream/main übereinstimmt, indem du einen Diff durchführst:
|
||||
|
||||
```console
|
||||
git diff upstream/main
|
||||
```
|
||||
|
||||
Die resultierende Ausgabe sollte leer sein.
|
||||
|
||||
3. Erstelle einen neuen Branch:
|
||||
|
||||
Die Arbeit an einem separaten Branch für jedes Problem hilft dir, deine lokale Arbeitskopie sauber zu halten. Du solltest niemals am `main` arbeiten. Dadurch wird deine Kopie von freeCodeCamp verunreinigt und du musst eventuell mit einem neuen Klon oder Fork neu beginnen.
|
||||
|
||||
Vergewissere dich, dass du auf `main` bist, wie zuvor erklärt, und zweige von dort ab:
|
||||
|
||||
```console
|
||||
git checkout -b fix/update-guide-for-xyz
|
||||
```
|
||||
|
||||
Dein Branchname sollte mit `fix/`, `feat/`, `docs/` usw. beginnen. Vermeide die Verwendung von Issue-Nummern in Branches. Halte sie kurz, aussagekräftig und einzigartig.
|
||||
|
||||
Einige Beispiele für gute Branchennamen sind:
|
||||
|
||||
```md
|
||||
fix/update-challenges-for-react
|
||||
fix/update-guide-for-html-css
|
||||
fix/platform-bug-sign-in-issues
|
||||
feat/add-guide-article-for-javascript
|
||||
translate/add-spanish-basic-html
|
||||
```
|
||||
|
||||
4. Bearbeite die Seiten und den Code in deinem bevorzugten Texteditor.
|
||||
|
||||
5. Wenn du mit den Änderungen zufrieden bist, solltest du freeCodeCamp optional lokal ausführen, um die Änderungen zu überprüfen.
|
||||
|
||||
6. Stelle sicher, dass du alle Fehler korrigierst und die Formatierung deiner Änderungen überprüfst.
|
||||
|
||||
7. Überprüfe und bestätige die Dateien, die du aktualisierst:
|
||||
|
||||
```console
|
||||
git status
|
||||
```
|
||||
|
||||
Dies sollte eine Liste `unstaged`-Dateien anzeigen, die du verändert hast.
|
||||
|
||||
```console
|
||||
On branch feat/documentation
|
||||
Your branch is up to date with 'upstream/feat/documentation'.
|
||||
|
||||
Changes were not staged for commit:
|
||||
(use "git add/rm <file>..." to update what will be committed)
|
||||
(use "git checkout -- <file>..." to discard changes in the working directory)
|
||||
|
||||
modified: CONTRIBUTING.md
|
||||
modified: docs/README.md
|
||||
modified: docs/how-to-setup-freecodecamp-locally.md
|
||||
modified: docs/how-to-work-on-guide-articles.md
|
||||
...
|
||||
```
|
||||
|
||||
8. Führe die Änderungen durch und mache einen Commit:
|
||||
|
||||
In diesem Schritt solltest du nur Dateien markieren, die du selbst bearbeitet oder hinzugefügt hast. Bei Bedarf kannst du einen Reset durchführen und Dateien lösen, die du nicht ändern wolltest.
|
||||
|
||||
```console
|
||||
git add path/to/my/changed/file.ext
|
||||
```
|
||||
|
||||
Oder du kannst alle `unstaged`-Dateien zum Staging-Bereich hinzufügen:
|
||||
|
||||
```console
|
||||
git add .
|
||||
```
|
||||
|
||||
Nur die Dateien, die in den Staging-Bereich verschoben wurden, werden hinzugefügt, wenn du einen Commit machst.
|
||||
|
||||
```console
|
||||
git status
|
||||
```
|
||||
|
||||
Output:
|
||||
|
||||
```console
|
||||
On branch feat/documentation
|
||||
Your branch is up to date with 'upstream/feat/documentation'.
|
||||
|
||||
Changes to be committed:
|
||||
(use "git reset HEAD <file>..." to unstage)
|
||||
|
||||
modified: CONTRIBUTING.md
|
||||
modified: docs/README.md
|
||||
modified: docs/how-to-setup-freecodecamp-locally.md
|
||||
modified: docs/how-to-work-on-guide-articles.md
|
||||
```
|
||||
|
||||
Jetzt kannst du deine Änderungen mit einer kurzen Nachricht wie dieser übertragen:
|
||||
|
||||
```console
|
||||
git commit -m "fix: meine kurze Commit-Nachricht"
|
||||
```
|
||||
|
||||
Einige Beispiele:
|
||||
|
||||
```md
|
||||
fix: update guide article for Java - for loop
|
||||
feat: add guide article for alexa skills
|
||||
```
|
||||
|
||||
Optional:
|
||||
|
||||
Wir empfehlen dringend eine konventionelle Commit-Nachricht. Das ist eine gute Praxis, die du bei einigen beliebten Open-Source-Repositories sehen wirst. Das ermutigt dich als Entwickler, Standardverfahren zu befolgen.
|
||||
|
||||
Einige Beispiele für konventionelle Commit-Nachrichten sind:
|
||||
|
||||
```md
|
||||
fix: update HTML guide article
|
||||
fix: update build scripts for Travis-CI
|
||||
feat: add article for JavaScript hoisting
|
||||
docs: update contributing guidelines
|
||||
```
|
||||
|
||||
Halte sie kurz, nicht länger als 50 Zeichen. Du kannst jederzeit zusätzliche Informationen in der Beschreibung der Commit-Nachricht hinzufügen.
|
||||
|
||||
Das dauert nicht länger als eine unkonventionelle Meldung wie "update file" oder "add index.md".
|
||||
|
||||
Du kannst [hier](https://www.conventionalcommits.org/en/v1.0.0-beta.2/#why-use-conventional-commits) mehr darüber erfahren, warum du konventionelle Commits verwenden solltest.
|
||||
|
||||
9. Wenn du feststellst, dass du eine Datei bearbeiten oder die Commit-Nachricht aktualisieren musst, nachdem du einen Commit gemacht hast, kannst du das nach der Bearbeitung der Dateien wie folgt tun:
|
||||
|
||||
```console
|
||||
git commit --amend
|
||||
```
|
||||
|
||||
Dadurch öffnet sich ein Standard-Texteditor wie `nano` oder `vi`, in dem du den Titel der Commit-Nachricht bearbeiten und die Beschreibung hinzufügen/bearbeiten kannst.
|
||||
|
||||
10. Als nächstes kannst du deine Änderungen in deinen Fork schieben:
|
||||
|
||||
```console
|
||||
git push origin branch/name-here
|
||||
```
|
||||
|
||||
## Einen Pull Request (PR) vorschlagen
|
||||
|
||||
Nachdem du deine Änderungen übertragen hast, kannst du hier nachlesen, [wie man einen Pull Request erstellt](how-to-open-a-pull-request.md).
|
||||
|
||||
## Schnellreferenz der Befehle
|
||||
|
||||
Eine Schnellreferenz für die Befehle, die du brauchst, wenn du lokal arbeitest.
|
||||
|
||||
| Befehl | Beschreibung |
|
||||
| -------------------------------------------------------------- | --------------------------------------------------------------------------------------------- |
|
||||
| `npm ci` | Installiert / reinstalliert alle Abhängigkeiten und bootet die verschiedenen Dienste. |
|
||||
| `npm run seed` | Analysiert alle Aufgaben-Markdown-Dateien und fügt sie in MongoDB ein. |
|
||||
| `npm run develop` | Startet den freeCodeCamp API Server und die Client-Anwendungen. |
|
||||
| `npm run storybook` | Startet Storybook für die Entwicklung der Komponentenbibliothek. |
|
||||
| `npm test` | Führt alle JS-Tests im System aus, einschließlich Client-, Server-, Lint- und Aufgaben-Tests. |
|
||||
| `npm run test-client` | Führt die Client-Test-Suite aus. |
|
||||
| `npm run test:curriculum` | Führt die Curriculum-Test-Suite aus. |
|
||||
| `npm run test:curriculum --block='Basic HTML and HTML5'` | Testet einen bestimmten Block. |
|
||||
| `npm run test:curriculum --superblock='responsive-web-design'` | Testet einen bestimmten SuperBlock. |
|
||||
| `npm run test-curriculum-full-output` | Führt die Curriculum-Test-Suite aus, ohne nach dem ersten Fehler abzubrechen |
|
||||
| `npm run test-server` | Führt die Server-Test-Suite aus. |
|
||||
| `npm run e2e` | Führt die Cypress End-to-End-Tests durch. |
|
||||
| `npm run clean` | Deinstalliert alle Abhängigkeiten und bereinigt die Caches. |
|
||||
|
||||
## Fehlerbehebung
|
||||
|
||||
### Probleme bei der Installation der empfohlenen Voraussetzungen
|
||||
|
||||
Wir entwickeln regelmäßig auf den neuesten oder beliebtesten Betriebssystemen wie macOS 10.15 oder höher, Ubuntu 18.04 oder höher und Windows 10 (mit WSL2).
|
||||
|
||||
Es wird empfohlen, dein spezifisches Problem auf Ressourcen wie Google, Stack Overflow und Stack Exchange zu recherchieren. Die Wahrscheinlichkeit ist groß, dass jemand mit demselben Problem konfrontiert war und es bereits eine Antwort auf deine spezielle Frage gibt.
|
||||
|
||||
Wenn du ein anderes Betriebssystem verwendest und/oder immer noch Probleme hast, siehe [Hilfe bekommen](#getting-help).
|
||||
|
||||
> [!WARNING]
|
||||
>
|
||||
> Bitte vermeide es, GitHub Issues für Probleme mit den Voraussetzungen zu erstellen. Sie liegen außerhalb des Rahmens dieses Projekts.
|
||||
|
||||
### Probleme mit der Benutzeroberfläche, Schriftarten, Build-Fehler usw.
|
||||
|
||||
Wenn du Probleme mit der Benutzeroberfläche oder den Schriftarten hast oder Build-Fehler siehst, kann eine Bereinigung nützlich sein:
|
||||
|
||||
```console
|
||||
npm run clean
|
||||
npm ci
|
||||
npm run seed
|
||||
npm run develop
|
||||
```
|
||||
|
||||
Oder
|
||||
|
||||
Benutze den Shortcut
|
||||
|
||||
```
|
||||
npm run clean-and-develop
|
||||
```
|
||||
|
||||
Wenn du weiterhin Probleme mit dem Build hast, solltest du den Arbeitsbereich aufräumen.
|
||||
|
||||
Verwende `git clean` im interaktiven Modus:
|
||||
|
||||
```
|
||||
git clean -ifdX
|
||||
```
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
So bereinigst du nicht verfolgte Git-Dateien (Screenshot)
|
||||
</summary>
|
||||
|
||||
<br>
|
||||
<img src="https://user-images.githubusercontent.com/1884376/94270515-ca579400-ff5d-11ea-8ff1-152cade31654.gif" alt="Wie man nicht verfolgte Git-Dateien bereinigt" />
|
||||
</details>
|
||||
|
||||
### Probleme mit der API, dem Login, der Einreichung von Aufgaben, etc.
|
||||
|
||||
Wenn du dich nicht anmelden kannst und stattdessen ein Banner mit einer Fehlermeldung siehst, dass es an freeCodeCamp gemeldet wird, überprüfe bitte, ob dein lokaler Port `3000` nicht von einem anderen Programm verwendet wird.
|
||||
|
||||
<!-- tabs:start -->
|
||||
|
||||
#### **macOS/Linux/WSL unter Windows - Über Terminal:**
|
||||
|
||||
```console
|
||||
netstat -a | grep "3000"
|
||||
|
||||
tcp4 0 0 0.0.0.0:3000 DESKTOP LISTEN
|
||||
```
|
||||
|
||||
#### **Unter Windows - Von der erweiterten PowerShell aus:**
|
||||
|
||||
```powershell
|
||||
netstat -ab | Select-String "3000"
|
||||
|
||||
TCP 0.0.0.0:3000 DESKTOP LISTENING
|
||||
```
|
||||
|
||||
<!-- tabs:end -->
|
||||
|
||||
---
|
||||
|
||||
### Probleme beim Installieren von Abhängigkeiten
|
||||
|
||||
Wenn du bei der Installation der Abhängigkeiten Fehler erhältst, vergewissere dich bitte, dass du dich nicht in einem eingeschränkten Netzwerk befindest oder dass deine Firewall-Einstellungen den Zugriff auf die Ressourcen nicht verhindern.
|
||||
|
||||
Die Ersteinrichtung kann je nach Netzwerkbandbreite eine Weile dauern. Sei geduldig, und wenn du immer noch nicht weiterkommst, empfehlen wir dir, GitPod statt eines Offline-Setups zu verwenden.
|
||||
|
||||
> [!NOTE] Wenn du Apple-Geräte mit M1-Chip verwendest, um die Anwendung lokal auszuführen, wird empfohlen, Node v14.7 oder höher zu verwenden. Du könntest sonst Probleme mit Abhängigkeiten wie Sharp bekommen.
|
||||
|
||||
## Hilfe erhalten
|
||||
|
||||
Wenn du nicht weiterkommst und Hilfe brauchst, kannst du in der [Kategorie "Contributors" in unserem Forum](https://forum.freecodecamp.org/c/contributors) oder im [Contributors Chatraum](https://chat.freecodecamp.org/channel/contributors) Fragen stellen.
|
||||
|
||||
In der Konsole deines Browsers oder in der Bash / Terminal / Kommandozeile kann eine Fehlermeldung erscheinen, die dir hilft, das Problem zu identifizieren. Gib diese Fehlermeldung in deiner Problembeschreibung an, damit andere das Problem leichter identifizieren und dir bei der Suche nach einer Lösung helfen können.
|
||||
133
docs/i18n/german/how-to-setup-wsl.md
Normal file
133
docs/i18n/german/how-to-setup-wsl.md
Normal file
@ -0,0 +1,133 @@
|
||||
# freeCodeCamp auf dem Windows Subsystem für Linux (WSL) einrichten
|
||||
|
||||
> [!HINWEIS] Bevor Sie diesen Anweisungen folgen, stellen Sie sicher, dass Ihr System die Anforderungen erfüllt
|
||||
>
|
||||
> **WSL 2**: Windows 10 64-bit (Version 2004, Build 19041 oder höher) - verfügbar für alle Distributionen einschließlich Windows 10 Home.
|
||||
>
|
||||
> **Docker Desktop für Windows**: Siehe entsprechende Anforderungen für [Windows 10 Pro](https://docs.docker.com/docker-for-windows/install/#system-requirements) und [Windows 10 Home](https://docs.docker.com/docker-for-windows/install-windows-home/#system-requirements)
|
||||
|
||||
Dieser Leitfaden behandelt einige allgemeine Schritte bei der Einrichtung von WSL2. Sobald einige der üblichen Probleme mit WSL2 behoben sind, solltest du in der Lage sein, [diesem Leitfaden zur lokalen Einrichtung](how-to-setup-freecodecamp-locally.md) zu folgen, um mit freeCodeCamp unter Windows und einer WSL-Distribution wie Ubuntu zu arbeiten.
|
||||
|
||||
## WSL aktivieren
|
||||
|
||||
Folge den Anweisungen in der [offiziellen Dokumentation](https://docs.microsoft.com/en-us/windows/wsl/install-win10), um WSL1 zu installieren und anschließend auf WSL2 zu aktualisieren.
|
||||
|
||||
## Ubuntu installieren
|
||||
|
||||
1. Wir empfehlen Ubuntu-18.04 oder höher mit WSL2.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> Du kannst zwar auch andere, nicht auf Debian basierende Distributionen verwenden, aber die haben alle ihre eigenen Tücken und werden in diesem Leitfaden nicht behandelt.
|
||||
|
||||
2. Abhängigkeiten (Dependencies) für das Betriebssystem aktualisieren
|
||||
|
||||
```console
|
||||
sudo apt update
|
||||
sudo apt upgrade -y
|
||||
|
||||
# cleanup
|
||||
sudo apt autoremove -y
|
||||
```
|
||||
|
||||
## Git einrichten
|
||||
|
||||
Git ist bei Ubuntu 18.04 vorinstalliert. Überprüfe deine Git-Version mit `git --version`.
|
||||
|
||||
```output
|
||||
~
|
||||
❯ git --version
|
||||
git version 2.25.1
|
||||
```
|
||||
|
||||
(Optional, aber empfohlen) Du kannst jetzt mit dem [Einrichten deiner SSH-Schlüssel](https://help.github.com/articles/generating-an-ssh-key) bei GitHub fortfahren.
|
||||
|
||||
## Installation eines Code-Editors
|
||||
|
||||
Wir empfehlen wärmstens, [Visual Studio Code](https://code.visualstudio.com) auf Windows 10 zu installieren. Es bietet eine hervorragende Unterstützung für WSL und installiert automatisch alle notwendigen Erweiterungen auf deiner WSL-Distribution.
|
||||
|
||||
Im Wesentlichen bearbeitest und speicherst du deinen Code auf Ubuntu-18.04, während VS Code auf Windows installiert ist.
|
||||
|
||||
Wenn du [IntelliJ Idea](https://www.jetbrains.com/idea/) verwendest, musst du eventuell deinen Node-Interpreter und Npm-Paketmanager auf den Stand deiner WSL-Distribution bringen.
|
||||
|
||||
Du kannst diese Einstellungen überprüfen, indem du zu Einstellungen > Sprachen & Frameworks > Node.js und NPM gehst.
|
||||
|
||||
## Docker Desktop installieren
|
||||
|
||||
**Docker Desktop für Windows** ermöglicht es dir, Datenbanken wie MongoDB und andere Dienste wie NGINX und mehr zu installieren und auszuführen. Dies ist nützlich, um häufige Fallstricke bei der Installation von MongoDB oder anderen Diensten direkt auf Windows oder WSL2 zu vermeiden.
|
||||
|
||||
Folge der Anleitung in der [offiziellen Dokumentation](https://docs.docker.com/docker-for-windows/install) und installiere Docker Desktop für deine Windows-Distribution.
|
||||
|
||||
Es gibt einige Mindestanforderungen an die Hardware für das beste Erlebnis.
|
||||
|
||||
## Docker Desktop für WSL konfigurieren
|
||||
|
||||
Sobald Docker Desktop installiert ist, [folgst du dieser Anleitung](https://docs.docker.com/docker-for-windows/wsl) und konfigurierst es so, dass es die Ubuntu-18.04-Installation als Backend verwendet.
|
||||
|
||||
Dadurch laufen die Container auf der WSL-Seite und nicht unter Windows. Du kannst sowohl unter Windows als auch unter Ubuntu über `http://localhost` auf die Dienste zugreifen.
|
||||
|
||||
## MongoDB vom Docker Hub aus installieren
|
||||
|
||||
Sobald du Docker Desktop für die Zusammenarbeit mit WSL2 konfiguriert hast, befolge diese Schritte, um einen MongoDB-Dienst zu starten:
|
||||
|
||||
1. Starte ein neues Ubuntu-18.04 Terminal
|
||||
|
||||
2. Rufe `MongoDB 4.0.x` von dockerhub ab
|
||||
|
||||
```console
|
||||
docker pull mongo:4.0
|
||||
```
|
||||
|
||||
3. Starte den MongoDB-Dienst an Port `27017` und konfiguriere ihn so, dass er bei Systemneustarts automatisch ausgeführt wird
|
||||
|
||||
```console
|
||||
docker run -it \
|
||||
-v mongodata:/data/db \
|
||||
-p 27017:27017 \
|
||||
--name mongodb \
|
||||
--restart unless-stopped \
|
||||
-d mongo:4.0
|
||||
```
|
||||
|
||||
4. Du kannst jetzt sowohl von Windows als auch von Ubuntu aus auf den Dienst unter `mongodb://localhost:27017` zugreifen.
|
||||
|
||||
## Installiere Node.js und npm
|
||||
|
||||
Wir empfehlen dir, die LTS-Version für Node.js mit einem Node-Versionsmanager zu installieren - [nvm](https://github.com/nvm-sh/nvm#installing-and-updating).
|
||||
|
||||
Nach der Installation kannst du mit den folgenden Befehlen die Node.js-Version installieren und verwenden, falls nötig
|
||||
|
||||
```console
|
||||
nvm install --lts
|
||||
|
||||
# OR
|
||||
# nvm install <version>
|
||||
|
||||
nvm install 14
|
||||
|
||||
# Usage
|
||||
# nvm use <version>
|
||||
|
||||
nvm use 12
|
||||
```
|
||||
|
||||
Node.js wird mit `npm` ausgeliefert. Du kannst wie folgt auf die neuesten Versionen von `npm` aktualisieren:
|
||||
|
||||
```console
|
||||
npm install -g npm@latest
|
||||
```
|
||||
|
||||
## FreeCodeCamp lokal einrichten
|
||||
|
||||
Nachdem du nun die Voraussetzungen erfüllt hast, folge [unserem Leitfaden zur lokalen Einrichtung](how-to-setup-freecodecamp-locally.md), um freeCodeCamp zu klonen, zu installieren und lokal auf deinem Rechner einzurichten.
|
||||
|
||||
> [!WARNING]
|
||||
>
|
||||
> Bitte beachte, dass die Einrichtung der Cypress-Tests (und die damit verbundenen Anforderungen an die Benutzeroberfläche) derzeit noch nicht abgeschlossen ist. Du solltest immer noch in der Lage sein, an den meisten Teilen der Codebasis zu arbeiten.
|
||||
|
||||
## Nützliche Links
|
||||
|
||||
- [Ein WSL2 Dev Setup mit Ubuntu 20.04, Node.js, MongoDB, VS Code und Docker](https://devlog.sh/wsl2-dev-setup-with-ubuntu-nodejs-mongodb-and-docker) - ein Artikel von Mrugesh Mohapatra (Staff Developer bei freeCodeCamp.org)
|
||||
- Häufig gestellte Fragen zu:
|
||||
- [Windows Subsystem für Linux](https://docs.microsoft.com/en-us/windows/wsl/faq)
|
||||
- [Docker Desktop für Windows](https://docs.docker.com/docker-for-windows/faqs)
|
||||
199
docs/i18n/german/how-to-test-translations-locally.md
Normal file
199
docs/i18n/german/how-to-test-translations-locally.md
Normal file
@ -0,0 +1,199 @@
|
||||
# Wie man Übersetzungen lokal testet
|
||||
|
||||
> [!NOTE] Dieser Vorgang ist nicht erforderlich, wird aber dokumentiert, falls du eine Vorschau darauf haben möchtest, wie deine Übersetzungen aussehen werden.
|
||||
|
||||
Wenn du deine Übersetzungen auf einer lokalen Instanz der freeCodeCamp `/learn`-Seite testen möchtest, stelle zuerst sicher, dass du die [Codebasis](how-to-setup-freecodecamp-locally.md) eingerichtet hast.
|
||||
|
||||
## Eine Sprache aktivieren
|
||||
|
||||
Es gibt ein paar Schritte, die du unternehmen musst, damit die Codebasis in deiner gewünschten Sprache erstellt werden kann.
|
||||
|
||||
Gehe zuerst in die Datei `config/i18n/all-langs.ts`, um die Sprache zur Liste der verfügbaren Sprachen hinzuzufügen und die Werte zu konfigurieren. Hier gibt es vier Objekte.
|
||||
|
||||
- `availableLangs`: Füge sowohl für den `client` als auch für das Studienplan(`curriculum`)-Array den Textnamen der Sprache hinzu. Dies ist der Wert, der später in der `.env`-Datei verwendet wird.
|
||||
- `auditedCerts`: Füge den Textnamen der Sprache als _Schlüssel_ und ein Array von `SuperBlocks.{cert}`-Variablen als _Wert_ hinzu. So erfährt der Client, welche Zertifikate vollständig übersetzt sind.
|
||||
- `i18nextCodes`: Das sind die ISO-Sprachcodes für jede Sprache. Du musst den entsprechenden ISO-Code für die Sprache hinzufügen, die du aktivieren willst. Diese müssen für jede Sprache einzigartig sein.
|
||||
- `langDisplayNames`: Dies sind die Anzeigenamen für den Sprachauswahlschalter im Navigationsmenü.
|
||||
- `langCodes`: Dies sind die Sprachcodes, die für die Formatierung von Daten und Zahlen verwendet werden. Dies sollten Unicode CLDR-Codes statt ISO-Codes sein.
|
||||
|
||||
Wenn du zum Beispiel Dothraki als Sprache aktivieren möchtest, sollten deine `all-langs.js`-Objekte wie folgt aussehen:
|
||||
|
||||
```js
|
||||
const availableLangs = {
|
||||
client: ['english', 'espanol', 'chinese', 'chinese-traditional', 'dothraki'],
|
||||
curriculum: [
|
||||
'english',
|
||||
'espanol',
|
||||
'chinese',
|
||||
'chinese-traditional',
|
||||
'dothraki'
|
||||
]
|
||||
};
|
||||
|
||||
export const auditedCerts = {
|
||||
espanol: [
|
||||
SuperBlocks.RespWebDesign,
|
||||
SuperBlocks.JsAlgoDataStruct,
|
||||
SuperBlocks.FrontEndDevLibs,
|
||||
SuperBlocks.DataVis,
|
||||
SuperBlocks.BackEndDevApis
|
||||
],
|
||||
chinese: [
|
||||
SuperBlocks.RespWebDesign,
|
||||
SuperBlocks.JsAlgoDataStruct,
|
||||
SuperBlocks.FrontEndDevLibs,
|
||||
SuperBlocks.DataVis,
|
||||
SuperBlocks.BackEndDevApis,
|
||||
SuperBlocks.QualityAssurance,
|
||||
SuperBlocks.SciCompPy,
|
||||
SuperBlocks.DataAnalysisPy,
|
||||
SuperBlocks.InfoSec,
|
||||
SuperBlocks.MachineLearningPy
|
||||
],
|
||||
'chinese-traditional': [
|
||||
SuperBlocks.RespWebDesign,
|
||||
SuperBlocks.JsAlgoDataStruct,
|
||||
SuperBlocks.FrontEndDevLibs,
|
||||
SuperBlocks.DataVis,
|
||||
SuperBlocks.BackEndDevApis,
|
||||
SuperBlocks.QualityAssurance,
|
||||
SuperBlocks.SciCompPy,
|
||||
SuperBlocks.DataAnalysisPy,
|
||||
SuperBlocks.InfoSec,
|
||||
SuperBlocks.MachineLearningPy
|
||||
],
|
||||
dothraki: [
|
||||
SuperBlocks.RespWebDesign,
|
||||
SuperBlocks.JsAlgoDataStruct,
|
||||
SuperBlocks.FrontEndDevLibs
|
||||
]
|
||||
};
|
||||
|
||||
const i18nextCodes = {
|
||||
english: 'en',
|
||||
espanol: 'es',
|
||||
chinese: 'zh',
|
||||
'chinese-traditional': 'zh-Hant',
|
||||
dothraki: 'mis'
|
||||
};
|
||||
|
||||
const langDisplayNames = {
|
||||
english: 'English',
|
||||
espanol: 'Español',
|
||||
chinese: '中文（简体字）',
|
||||
'chinese-traditional': '中文（繁體字）',
|
||||
dothraki: 'Dothraki'
|
||||
};
|
||||
|
||||
const langCodes = {
|
||||
english: 'en-US',
|
||||
espanol: 'es-419',
|
||||
chinese: 'zh',
|
||||
'chinese-traditional': 'zh-Hant',
|
||||
dothraki: 'mis'
|
||||
};
|
||||
```
|
||||
|
||||
Als nächstes öffnest du die Datei `client/src/utils/algolia-locale-setup.ts`. Diese Daten werden für die Suchleiste verwendet, die `/news `-Artikel lädt. Es ist zwar unwahrscheinlich, dass du diese Funktion testen wirst, aber das Fehlen der Daten für deine Sprache kann zu Fehlern führen, wenn du versuchst, die Codebasis lokal zu erstellen.
|
||||
|
||||
Füge ein Objekt für deine Sprache zum `algoliaIndices`-Objekt hinzu. Du solltest die Werte für das `english`-Objekt für lokale Tests verwenden, indem du den Schlüssel `english` durch den Wert für deine Sprache `availableLangs` ersetzt.
|
||||
|
||||
> [!NOTE] Wenn wir bereits eine Instanz von news in deiner Zielsprache bereitgestellt haben, kannst du die Werte aktualisieren, damit sie die Live-Instanz widerspiegeln. Andernfalls verwendest du die englischen Werte.
|
||||
|
||||
Wenn du Dothraki hinzufügen würdest:
|
||||
|
||||
```js
|
||||
const algoliaIndices = {
|
||||
english: {
|
||||
name: 'news',
|
||||
searchPage: 'https://www.freecodecamp.org/news/search/'
|
||||
},
|
||||
espanol: {
|
||||
name: 'news-es',
|
||||
searchPage: 'https://www.freecodecamp.org/espanol/news/search/'
|
||||
},
|
||||
chinese: {
|
||||
name: 'news-zh',
|
||||
searchPage: 'https://chinese.freecodecamp.org/news/search/'
|
||||
},
|
||||
'chinese-traditional': {
|
||||
name: 'news-zh',
|
||||
searchPage: 'https://chinese.freecodecamp.org/news/search'
|
||||
},
|
||||
dothraki: {
|
||||
name: 'news',
|
||||
searchPage: 'https://www.freecodecamp.org/news/search/'
|
||||
}
|
||||
};
|
||||
```
|
||||
|
||||
Schließlich stellst du in deiner `.env`-Datei `CLIENT_LOCALE` und `CURRICULUM_LOCALE` auf deine neue Sprache ein (verwende den `availableLangs` Wert).
|
||||
|
||||
```txt
|
||||
CLIENT_LOCALE="dothraki"
|
||||
CURRICULUM_LOCALE="dothraki"
|
||||
```
|
||||
|
||||
## Aktivieren von lokalisierten Videos
|
||||
|
||||
Für die Videoaufgaben musst du ein paar Dinge ändern. Zuerst fügst du die neue Sprache (Locale) zur GraphQL-Abfrage in der `client/src/templates/Challenges/video/Show.tsx` Datei hinzu. Füge zum Beispiel Dothraki zur Abfrage hinzu:
|
||||
|
||||
```tsx
|
||||
query VideoChallenge($slug: String!) {
|
||||
challengeNode(fields: { slug: { eq: $slug } }) {
|
||||
videoId
|
||||
videoLocaleIds {
|
||||
espanol
|
||||
italian
|
||||
portuguese
|
||||
dothraki
|
||||
}
|
||||
...
|
||||
```
|
||||
|
||||
Füge dann eine ID für die neue Sprache zu jeder Videoaufgabe in einem auditierten Block hinzu. Wenn zum Beispiel `auditedCerts` in `all-langs.ts` `scientific-computing-with-python` für `dothraki` enthält, dann musst du einen `dothraki`-Eintrag in `videoLocaleIds` hinzufügen. Das Frontmatter sollte dann so aussehen:
|
||||
|
||||
```yml
|
||||
videoLocaleIds:
|
||||
espanol: 3muQV-Im3Z0
|
||||
italian: hiRTRAqNlpE
|
||||
portuguese: AelGAcoMXbI
|
||||
dothraki: new-id-here
|
||||
dashedName: introduction-why-program
|
||||
---
|
||||
```
|
||||
|
||||
Aktualisiere das `VideoLocaleIds` Interface in `client/src/redux/prop-types`, um die neue Sprache aufzunehmen.
|
||||
|
||||
```ts
|
||||
export interface VideoLocaleIds {
|
||||
espanol?: string;
|
||||
italian?: string;
|
||||
portuguese?: string;
|
||||
dothraki?: string;
|
||||
}
|
||||
```
|
||||
|
||||
Und schließlich aktualisiere das Aufgabenschema in `curriculum/schema/challengeSchema.js`.
|
||||
|
||||
```js
|
||||
videoLocaleIds: Joi.when('challengeType', {
|
||||
is: challengeTypes.video,
|
||||
then: Joi.object().keys({
|
||||
espanol: Joi.string(),
|
||||
italian: Joi.string(),
|
||||
portuguese: Joi.string(),
|
||||
dothraki: Joi.string()
|
||||
})
|
||||
}),
|
||||
```
|
||||
|
||||
## Übersetzungen laden
|
||||
|
||||
Da die Sprache noch nicht für die Produktion freigegeben wurde, laden unsere Skripte die Übersetzungen noch nicht automatisch herunter. Nur Mitarbeiter (Staffs) haben den Zugang, um die Übersetzungen direkt herunterzuladen - du kannst uns gerne in unserem [Contributors Chat Room](https://chat.freecodecamp.org/channel/contributors) ansprechen, oder du kannst die englischen Markdown-Dateien zu Testzwecken lokal übersetzen.
|
||||
|
||||
Sobald du die Dateien hast, musst du sie im richtigen Verzeichnis ablegen. Für die Studienplanaufgaben solltest du die Zertifizierungsordner (z.B. `01-responsive-web-design`) in das Verzeichnis `curriculum/challenges/{lang}` ablegen. Für unsere Dothraki-Übersetzungen wäre das `curriculum/challenges/dothraki`. Die Client-Übersetzungsdateien `.json` werden im Verzeichnis `client/i18n/locales/{lang}` abgelegt.
|
||||
|
||||
Sobald du diese Einstellungen vorgenommen hast, solltest du `npm run develop` ausführen können, um deine übersetzte Version von freeCodeCamp anzuzeigen.
|
||||
|
||||
> [!ATTENTION] Du kannst zwar lokal Übersetzungen zu Testzwecken vornehmen, aber wir erinnern alle daran, dass Übersetzungen _nicht_ über GitHub eingereicht werden sollten und nur über Crowdin erfolgen sollten. Achte darauf, dass du deine lokale Codebasis zurücksetzt, wenn du mit dem Testen fertig bist.
|
||||
273
docs/i18n/german/how-to-translate-files.md
Normal file
273
docs/i18n/german/how-to-translate-files.md
Normal file
@ -0,0 +1,273 @@
|
||||
# So übersetzt du die Ressourcen von freeCodeCamp
|
||||
|
||||
Es ist unser Traum, dir die Ressourcen zum Lernen zur Verfügung zu stellen, egal welche Weltsprache du sprichst. Um uns bei diesem massiven Aufwand zu helfen, haben wir unsere Open-Source Code-Basis & Studienpläne mit [Crowdin](https://crowdin.com/) integriert - Ein Tool, das uns hilft, unsere Code-Basis zu lokalisieren.
|
||||
|
||||
Der Übersetzungsworkflow ist in zwei Hauptaktivitäten unterteilt:
|
||||
|
||||
- **Übersetzen** von Studienplandateien, Dokumentation und Elementen der Benutzeroberfläche wie Buttons, Labels, etc.:
|
||||
|
||||
Als Übersetzer kannst du dich auf [unserer Übersetzungsplattform](https://translate.freecodecamp.org) anmelden und Übersetzungen in einer der über 30 Sprachen beisteuern, die dort aktiviert sind.
|
||||
|
||||
- **Korrekturlesen** der Übersetzungen für alle oben genannten Punkte.
|
||||
|
||||
Korrekturleser überprüfen, ob die von der Community beigesteuerten Übersetzungen einen einheitlichen Ton haben und frei von üblichen Problemen wie Tippfehlern usw. sind. Kurzum, sie sorgen für eine hohe Qualität der Übersetzungen. Beachte, dass wir aus einem gutem Grund keine maschinellen Übersetzungen verwenden.
|
||||
|
||||
> [!WARNING] Wir verwenden GitHub nicht mehr, um Dateien direkt zu übersetzen. Wenn du ein zurückgekehrter Helfer bist, gehe stattdessen zu unserer [Übersetzungsplattform](https://translate.freecodecamp.org/).
|
||||
|
||||
## Bereite dich auf die Teilnahme vor
|
||||
|
||||
> Die freeCodeCamp Lokalisierungs-Roadmap - Es gibt keine Geschwindigkeitsbegrenzungen
|
||||
|
||||
Du kannst so viel übersetzen, wie du willst und wann du willst. Es ist nur eine Frage, wie viel Zeit und Energie du bereit bist, als freiwilliger Übersetzer zu investieren.
|
||||
|
||||
Wir bitten nur darum, dass du das Folgende verstehst:
|
||||
|
||||
1. **Übersetzungen sind eine Teamleistung.**
|
||||
|
||||
Das Übersetzen der freeCodeCamp-Ressourcen ist eine der schönsten und lohnendsten Erfahrungen als Helfer, und es funktioniert am besten, wenn du deine Freunde und Kollegen einbeziehst, die die gleiche Weltsprache sprechen wie du.
|
||||
|
||||
Wir empfehlen dir, dich mit deinen Freunden im [Community-Forum](https://forum.freecodecamp.org/c/contributors/3) und im [Contributors Chatroom](https://chat.freecodecamp.org/channel/contributors) anzumelden und dein Interesse zu zeigen, bevor du mit den Übersetzungen beginnst. Crowdin macht es einfach, Übersetzungen beizusteuern, aber es ist immer noch eine Menge Arbeit.
|
||||
|
||||
Wir wollen, dass du Spaß am Mitmachen hast und nicht ausbrennst oder das Interesse verlierst.
|
||||
|
||||
Eine kleine Gruppe von 4-5 Personen ist eine gute Größe, um mit deiner eigenen Weltsprache zu starten. Du kannst dann noch mehr Freunde für dein Team gewinnen.
|
||||
|
||||
2. **Es kostet eine ganze Menge, Server für jede Sprache zu betreiben.**
|
||||
|
||||
Oberflächlich betrachtet mag es nicht so kompliziert erscheinen, wie der technische Stack aufgebaut ist, aber es kostet eine ganze Menge, die Motoren am Laufen zu halten. Dazu gehört auch die Bereitstellung zusätzlicher Server und die Bereitstellung von Personal, das sich um diese kümmert.
|
||||
|
||||
freeCodeCamp.org verpflichtet sich, diese wie immer kostenlos zur Verfügung zu stellen, aber wir müssen die Ressourcen für diejenigen priorisieren, die sie am meisten brauchen. Das Letzte was wir wollen, ist, dass die Server für eine Sprache abgeschaltet werden, wenn die Übersetzungsaktivität nachlässt & die Inhalte veralten.
|
||||
|
||||
Sobald eine Sprache mindestens ein paar Zertifizierungen auf dem Studienplan erreicht hat, können wir damit beginnen, die Sprache live auf [`/learn`](https://www.freecodecamp.org/learn) bereitzustellen, während du weiterhin die verbleibenden Zertifizierungen übersetzt.
|
||||
|
||||
Zum Beispiel würden wir zumindest die gesamte Front-End-Zertifizierungssuite bereitstellen wollen, wenn wir eine neue Weltsprache zum ersten Mal ausliefern.
|
||||
|
||||
3. **Aber was ist mit den Sprachen, die nicht auf der Übersetzungsplattform aufgeführt sind?**
|
||||
|
||||
Wir haben uns unsere Benutzerbasis angesehen und die Liste der aktivierten Sprachen auf der Übersetzungsplattform um mehr als 30 der am häufigsten gesprochenen Sprachen erweitert. Einige Sprachen, wie z. B. Chinesisch und Spanisch, sind zu diesem Zeitpunkt bereits auf **"/learn"** live geschaltet.
|
||||
|
||||
Leider umfasst die Liste nicht alle Sprachen, die es gibt. Wir bekommen jeden Tag dutzende von Anfragen von Unterstützern wie dir, die helfen wollen, die Seite in eine Sprache zu übersetzen, die sie sprechen.
|
||||
|
||||
Wir freuen uns auf jeden Fall darauf, die Liste um weitere Sprachen zu erweitern, aber wie du dir vielleicht schon denken kannst, wäre das nur machbar, wenn wir genug Beteiligung für eine Weltsprache bekommen.
|
||||
|
||||
Wenn du möchtest, dass wir eine neue Weltsprache aufnehmen, empfehlen wir dir, deine Freunde dafür zu begeistern.
|
||||
|
||||
Sobald du eine kleine Gruppe von Leuten hast (mindestens 4-5), die interessiert sind und sich engagieren, können wir einen Versuch starten. Wir erklären dir alle Details und führen dich durch einige der Tools und Prozesse.
|
||||
|
||||
## Erste Schritte
|
||||
|
||||
Als erstes solltest du in unserem [Contributors Chat Room](https://chat.freecodecamp.org/channel/contributors) vorbeischauen und "Hallo" sagen. Wir posten regelmäßig Updates über Übersetzungsressourcen und beantworten dort deine Fragen.
|
||||
|
||||
Als nächstes gehst du zu unserer [Übersetzungsplattform](https://translate.freecodecamp.org/) und loggst dich ein (wenn du noch nie an Übersetzungen mitgewirkt hast, musst du einen Account erstellen).
|
||||
|
||||
Nachfolgend findest du eine ausführliche Anleitung, die dir dabei hilft, die dir zur Verfügung stehenden Übersetzungswerkzeuge und Arbeitsabläufe zu verstehen.
|
||||
|
||||
Viel Spaß beim Übersetzen.
|
||||
|
||||
## Wähle ein Projekt und eine Datei
|
||||
|
||||
Sobald du die Übersetzungsplattform besuchst, solltest du mehrere "Projekte" sehen, die zur Übersetzung verfügbar sind:
|
||||
|
||||
1. [Contributing documentation](https://translate.freecodecamp.org/contributing-docs) - Projekt, das die Dateien für diese Dokumentationsseite enthält.
|
||||
2. [Coding Curriculum](https://translate.freecodecamp.org/curriculum) - Projekt, welches unsere Aufgabendateien für unseren Studienplan enthält.
|
||||
3. [Benutzeroberfläche](https://translate.freecodecamp.org/learn-ui) - Projekt, das Zeichenfolgen für UI-Elemente wie Buttons, Labels, etc. für unsere Lernplattform enthält.
|
||||
|
||||
Wähle ein beliebiges Projekt aus, zu dem du beitragen möchtest, und du wirst eine Liste der verfügbaren Sprachen für die Übersetzung sehen.
|
||||
|
||||
|
||||
|
||||
Wähle die Sprache aus, an der du arbeiten möchtest, und du siehst den kompletten Dateibaum.
|
||||
|
||||
|
||||
|
||||
Für jede Datei und jeden Ordner wird ein Fortschrittsbalken angezeigt. Der **blaue** Teil des Fortschrittsbalkens zeigt an, wie viel Prozent der Datei bereits übersetzt wurde, während der **grüne** Teil des Fortschrittsbalkens anzeigt, wie viel Prozent der Datei vom Korrekturleseteam genehmigt wurde.
|
||||
|
||||
Wähle eine Datei aus, an der du arbeiten möchtest und Crowdin öffnet die Editor-Ansicht.
|
||||
|
||||
> [!NOTE] Wenn sich die Editoransicht öffnet, musst du auf das Einstellungssymbol klicken (dargestellt als Zahnrad) und die Einstellung 'HTML tags displaying' auf 'SHOW' umstellen. Dadurch wird sichergestellt, dass du Tags wie `<code></code>` statt `<0></0>` sehen kannst.
|
||||
|
||||
## Studienpläne übersetzen
|
||||
|
||||
|
||||
|
||||
Crowdin trennt ein Dokument in übersetzbare "Strings", normalerweise Sätze. Jeder String wird einzeln übersetzt. Siehe Bild oben:
|
||||
|
||||
1. Eine grün hervorgehobene Zeichenfolge hat bereits eine vorgeschlagene Übersetzung.
|
||||
2. Eine rot markierte Zeichenfolge hat _keine_ vorgeschlagene Übersetzung.
|
||||
3. Ein String mit ausgegrautem Text kann nicht übersetzt werden. Dies ist der Fall bei Codeblöcken und anderen Inhalten, die nicht übersetzt werden dürfen. Du wirst diese Zeichenfolgen im Editor nicht auswählen können.
|
||||
4. Wenn ein Mitwirkender eine Übersetzung für einen String vorgeschlagen hat, zeigt Crowdin den Vorschlag hier an. Du kannst eine identische Übersetzung nicht speichern - stattdessen solltest du, wenn eine Übersetzung korrekt ist, auf das `+` Symbol klicken, um sie "hochzuvoten". Eine ungenaue Übersetzung kann mit dem `-` Icon "heruntergevoted" werden.
|
||||
5. Crowdin empfiehlt Übersetzungen, die auf Translation Memory (TM) oder Machine Translation (MT) basieren. Translation Memory bezieht sich auf ähnliche oder identische Strings, die wir in anderen Dateien übersetzt/freigegeben haben. Machine Translation bezieht sich auf Übersetzungen, die von der in Crowdin integrierten Bibliothek empfohlen werden.
|
||||
6. Dies ist der Editorbereich, in dem du deinen Übersetzungsvorschlag für den ausgewählten String schreiben kannst.
|
||||
7. Der aktuell im Editor ausgewählte String wird gelb hervorgehoben.
|
||||
8. Hier siehst du Tags, die den Zustand des Strings anzeigen. `Done` bedeutet, dass der String mindestens eine vorgeschlagene Übersetzung hat. `Todo` bedeutet, dass der String keine Übersetzungsvorschläge hat.
|
||||
9. Hier siehst du das Fenster für die Kommentare. Wenn du Fragen oder Bedenken zu einem bestimmten String hast, kannst du hier einen Kommentar zu dem String hinterlassen, den andere Übersetzer sehen können.
|
||||
10. Diese beiden Buttons blenden die linke (Dokument-) und rechte (Kommentar-) Ansicht aus.
|
||||
|
||||
> [!NOTE] Wenn du einen versteckten String siehst, der Übersetzungen enthält, benachrichtige uns bitte im [Contributors Chat Room](https://chat.freecodecamp.org/channel/contributors), damit wir die Übersetzung aus dem Speicher entfernen können.
|
||||
|
||||
Wenn du eine Übersetzung für einen String fertiggestellt hast, wähle den `Save` Button, um deine Übersetzung auf Crowdin zu speichern. Andere Mitwirkende können dann über deine Übersetzung abstimmen und Korrekturleser können sie genehmigen.
|
||||
|
||||
Du kannst so viele Strings übersetzen, wie du möchtest - es sind keine zusätzlichen Schritte erforderlich, wenn du eine vollständige Datei fertigstellst oder eine neue Übersetzung vorschlägst. Ein Klick auf den `Save` Button ist alles, was nötig ist, um eine Übersetzung zu speichern.
|
||||
|
||||
> [!NOTE] Wenn du in der englischen Quelldatei etwas siehst, das ungenau oder falsch ist, korrigiere es bitte nicht im Rahmen des Übersetzungsprozesses. Hinterlasse stattdessen einen Kommentar zu dem String, um uns auf die Unstimmigkeit hinzuweisen, oder erstelle ein Issue auf GitHub.
|
||||
|
||||
## Dokumentation übersetzen
|
||||
|
||||
Die Übersetzung unserer Dokumentation für Helfer ist ein ähnlicher Prozess wie die Übersetzung unserer Studienplan-Dateien.
|
||||
|
||||
> [!NOTE] Unsere Dokumentation wird von `docsify` unterstützt, und wir haben ein spezielles Parsing für Nachrichtenboxen wie diese hier. Wenn du Zeichenfolgen siehst, die mit `[!NOTE]`, `[!WARNING]`, oder `[!TIP]` beginnen, sollten diese Wörter NICHT übersetzt werden.
|
||||
|
||||
## Übersetze das LearnToCode RPG
|
||||
|
||||
Das LearnToCode RPG läuft auf Ren'Py, das eine spezielle Syntax für übersetzte Strings verwendet: (Siehe [Ren'Py Text Dokumentation (englisch)](https://www.renpy.org/doc/html/text.html))
|
||||
|
||||
- Die zu übersetzenden Sätze stehen immer zwischen `""`. Dies sind Dialoge oder Strings der Benutzeroberfläche. Die Schlüsselwörter, die vor oder nach dem Dialog stehen, sind Schlüsselwörter zur Steuerung der Spiel-Engine und werden in den nachfolgenden Regeln genauer erklärt. Beachte, dass diese erste Regel für alle nachfolgenden Regeln gilt.
|
||||
- Im Falle von `new "..."` übersetze nicht das Schlüsselwort `new`.
|
||||
- Präfixe wie `player`, `annika`, `layla`, `marco` (oder Varianten wie `player happy`, `player @ happy`) sollten nicht übersetzt werden. Dies sind Steuerschlüsselwörter, um das Charakter-Sprite im Spiel korrekt anzuzeigen.
|
||||
- Postfixe wie `nointeract` sollten nicht übersetzt werden.
|
||||
- Übersetze keine Dinge zwischen `[]` und `{}`. Dies sind variable Interpolationen und Text-Tags. Diese müssen in halber Breite Klammern `[]` und `{}` bleiben, anstatt ihrer Gegenstücke in voller Breite `【】` und `「」`
|
||||
- Das Schlüsselwort `nointeract` am Ende des Satzes darf nicht übersetzt werden.
|
||||
- Wenn wir versuchen, Klammern in voller Breite `（）` zu verwenden, wird eine QA-Warnung angezeigt. Um die QA-Warnung zu vermeiden, verwende Klammern mit halber Breite `()`
|
||||
|
||||
### Beispiele
|
||||
|
||||
---
|
||||
|
||||
#### Vor der Übersetzung
|
||||
|
||||
```renpy
|
||||
# "[player_name]? What a coincidence! Our VIP team member {a=[vip_profile_url]}[player_name]{/a} will be honored to hear that."
|
||||
"[player_name]? What a coincidence! Our VIP team member {a=[vip_profile_url]}[player_name]{/a} will be honored to hear that." <--- Dies ist die Zeile, die übersetzt werden muss. Siehe Übersetzung unten.
|
||||
```
|
||||
|
||||
#### Nach der Übersetzung
|
||||
|
||||
```renpy
|
||||
# "[player_name]? What a coincidence! Our VIP team member {a=[vip_profile_url]}[player_name]{/a} will be honored to hear that."
|
||||
"[player_name]? Was für ein Zufall! Unser VIP-Teammitglied, {a=[vip_profile_url]}[player_name]{/a} wird sich geehrt fühlen, davon zu hören."
|
||||
```
|
||||
|
||||
Beachte: Die `[]` und `{}` Tags sollten intakt bleiben.
|
||||
|
||||
---
|
||||
|
||||
#### Vor der Übersetzung
|
||||
|
||||
```renpy
|
||||
old "{icon=icon-fast-forward} Skip"
|
||||
new "{icon=icon-fast-forward} Skip" <-- übersetze diese Zeile, siehe unten
|
||||
```
|
||||
|
||||
#### Nach der Übersetzung
|
||||
|
||||
```renpy
|
||||
old "{icon=icon-fast-forward} Skip"
|
||||
new "{icon=icon-fast-forward} Überspringen"
|
||||
```
|
||||
|
||||
Beachte: Auch hier sollten das `new` Präfix und der `{icon=icon-fast-forward}` Tag intakt bleiben.
|
||||
|
||||
---
|
||||
|
||||
#### Vor der Übersetzung
|
||||
|
||||
```renpy
|
||||
# layla @ neutral "Hehe, [player_name], you are a fun one. I'm sure you will enjoy your work as a developer."
|
||||
layla @ neutral "Hehe, [player_name], you are a fun one. I'm sure you will enjoy your work as a developer."
|
||||
```
|
||||
|
||||
#### Nach der Übersetzung
|
||||
|
||||
```renpy
|
||||
# layla @ neutral "Hehe, [player_name], you are a fun one. I'm sure you will enjoy your work as a developer."
|
||||
layla @ neutral "Ha ha, [player_name]，Du bist so witzig. Ich bin sicher, dass dir die Arbeit als Entwickler Spaß machen wird."
|
||||
```
|
||||
|
||||
Beachte: `layla @ neutral` und `[player_name]` bleiben unverändert.
|
||||
|
||||
---
|
||||
|
||||
#### Vor der Übersetzung
|
||||
|
||||
```renpy
|
||||
# player "Maybe this is all a dream?" nointeract
|
||||
player "Maybe this is all a dream?" nointeract
|
||||
```
|
||||
|
||||
#### Nach der Übersetzung
|
||||
|
||||
```renpy
|
||||
# player "Maybe this is all a dream?" nointeract
|
||||
player "Vielleicht ist das alles nur ein Traum?" nointeract
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
### Eine Anmerkung dazu, wie Crowdin einen Satz gliedert
|
||||
|
||||
Achte darauf, wie Crowdin eine Dialogzeile zwischen öffnenden und schließenden Anführungszeichen `""` unterteilt. Bei der Übersetzung des Dialogs müssen wir darauf achten, dass die einleitenden und abschließenden Anführungszeichen beibehalten werden, auch wenn die Anführungszeichen in verschiedenen Segmenten vorkommen.
|
||||
|
||||
Dies ist die zu übersetzende Zeile:
|
||||
|
||||
```renpy
|
||||
player @ surprised "{b}Full-stack{/b}... What is that? I better take notes so I can learn more about it."
|
||||
```
|
||||
|
||||
Crowdin unterteilt es in drei Segmente wie unten:
|
||||
|
||||
<img width="836" alt="Screen Shot 2022-01-23 at 10 36 43" src="https://user-images.githubusercontent.com/35674052/150693962-d3b091e5-2432-44d0-9d24-195ea7d7aeda.png" />
|
||||
|
||||
```renpy
|
||||
# Original
|
||||
player @ surprised "{b}Full-stack{/b}
|
||||
# übersetzt, wobei die einleitenden Anführungszeichen erhalten bleiben `"`
|
||||
player @ surprised "{b}Full-stack{/b}
|
||||
```
|
||||
|
||||
<img width="750" alt="Screen Shot 2022-01-23 at 10 36 49" src="https://user-images.githubusercontent.com/35674052/150693965-15411504-791a-4db3-8b14-bc9177be6375.png" />
|
||||
|
||||
```renpy
|
||||
# Original
|
||||
What is that?
|
||||
# übersetzt, keine Anführungszeichen auf beiden Seiten
|
||||
Was ist das?
|
||||
```
|
||||
|
||||
<img width="857" alt="Screen Shot 2022-01-23 at 10 36 54" src="https://user-images.githubusercontent.com/35674052/150693969-062e3268-580f-4ad2-97db-cab6240b6095.png" />
|
||||
|
||||
```renpy
|
||||
# Original
|
||||
I better take notes so I can learn more about it."
|
||||
# übersetzt, wobei die schließenden Anführungszeichen beibehalten werden `"`
|
||||
Ich mache mir besser Notizen, damit ich mehr darüber lernen kann."
|
||||
```
|
||||
|
||||
## Übersetzungen bewerten
|
||||
|
||||
Crowdin ermöglicht es dir, die vorhandenen Übersetzungsvorschläge zu bewerten. Wenn du versuchst, eine Übersetzung zu speichern, kann es sein, dass du eine Meldung siehst, dass du eine doppelte Übersetzung nicht speichern kannst - das bedeutet, dass ein anderer Mitwirkender die gleiche Übersetzung vorgeschlagen hat. Wenn du mit der Übersetzung einverstanden bist, klicke auf den `+` Button, um die Übersetzung "hochzustufen".
|
||||
|
||||
Wenn du eine Übersetzung siehst, die ungenau ist oder nicht die gleiche Klarheit wie das Original bietet, klicke auf den `-` Button, um die Übersetzung "herabzustufen".
|
||||
|
||||
Crowdin nutzt diese Stimmen, um jeder vorgeschlagenen Übersetzung für einen String eine Punktzahl zu geben, die dem Korrekturleseteam hilft, zu entscheiden, welche Übersetzung für den jeweiligen String am besten geeignet ist.
|
||||
|
||||
## Qualitätssicherungskontrollen
|
||||
|
||||
Wir haben einige Qualitätssicherungsschritte aktiviert, die sicherstellen, dass eine Übersetzung so genau wie möglich ist - das hilft unseren Korrekturlesern, die vorgeschlagenen Übersetzungen zu überprüfen.
|
||||
|
||||
Wenn du versuchst, eine Übersetzung zu speichern, erscheint möglicherweise eine Warnmeldung mit einem Hinweis zu deiner vorgeschlagenen Übersetzung.
|
||||
|
||||
|
||||
|
||||
Diese Meldung erscheint, wenn das QS-System von Crowdin einen möglichen Fehler in der vorgeschlagenen Übersetzung festgestellt hat. In diesem Beispiel haben wir den Text eines `<code>`-Tags geändert und Crowdin hat das erkannt.
|
||||
|
||||
> [!WARNING] Du hast die Möglichkeit, eine Übersetzung trotz Fehlern zu speichern. Wenn du das tust, indem du auf "Save Anyway" klickst, solltest du auch einen Korrekturleser oder Projektmanager markieren und erklären, warum die QA-Meldung in diesem Fall ignoriert werden muss.
|
||||
|
||||
## Bewährte Praktiken bei der Übersetzung
|
||||
|
||||
Befolge diese Richtlinien, um sicherzustellen, dass unsere Übersetzungen so genau wie möglich sind:
|
||||
|
||||
- Übersetze nicht den Inhalt innerhalb der `<code>`-Tags. Diese Tags kennzeichnen Text, der im Code vorkommt und in Englisch belassen werden sollte.
|
||||
- Füge keine zusätzlichen Inhalte hinzu. Wenn du der Meinung bist, dass eine Aufgabe Änderungen am Textinhalt oder zusätzliche Informationen erfordert, solltest du die Änderungen in einem Issue auf GitHub oder in einem Pull Request vorschlagen, der die englische Datei ändert.
|
||||
- Ändere nicht die Reihenfolge des Inhalts.
|
||||
|
||||
Wenn du Fragen hast, kannst du uns gerne in unserem [Contributors Chat Room](https://chat.freecodecamp.org/channel/contributors) ansprechen und wir helfen dir gerne weiter.
|
||||
15
docs/i18n/german/how-to-use-docker-on-windows-home.md
Normal file
15
docs/i18n/german/how-to-use-docker-on-windows-home.md
Normal file
@ -0,0 +1,15 @@
|
||||
# So verwendest du Docker unter Windows Home
|
||||
|
||||
Bei der Einrichtung von Docker unter Windows Home gibt es einige Fallstricke, die du vermeiden solltest. Als erstes musst du die [Docker Toolbox](https://docs.docker.com/toolbox/toolbox_install_windows/) als Administrator verwenden. Leider unterstützt Windows Home kein Docker für Windows Desktop, sodass stattdessen Toolbox verwendet werden muss. Es muss als Administrator ausgeführt werden, da die Installation Symlinks verwendet, die sonst nicht erstellt werden können.
|
||||
|
||||
Sobald du die Toolbox installiert hast, führe das Docker Quickstart Terminal als Administrator aus. Damit wird eine `default` virtuelle Maschine erstellt, wenn sie noch nicht existiert. Wenn das geschehen ist, schließe das Terminal und öffne VirtualBox (wieder als Administrator). Du solltest die `default` Maschine sehen können. Die Website ist ziemlich ressourcenintensiv, also halte die virtuelle Maschine an und erhöhe die Einstellungen so weit wie möglich - vor allem den Arbeitsspeicher. Es wurde bestätigt, dass sie mit 4 GB Arbeitsspeicher funktioniert.
|
||||
|
||||
Wenn du sicher bist, dass Docker funktioniert, klone das freeCodeCamp Repository in ein Verzeichnis innerhalb von `C:\Users`. Diese Verzeichnisse werden gemeinsam genutzt, so dass Docker Zugriff auf die lokalen Verzeichnisse hat, die es während der Installation benötigt.
|
||||
|
||||
Wenn du Meldungen siehst wie
|
||||
|
||||
```shell
|
||||
bash: change_volumes_owner.sh: No such file or directory
|
||||
```
|
||||
|
||||
wenn du `npm run docker:init` ausführst, ist das wahrscheinlich der Grund dafür.
|
||||
497
docs/i18n/german/how-to-work-on-coding-challenges.md
Normal file
497
docs/i18n/german/how-to-work-on-coding-challenges.md
Normal file
@ -0,0 +1,497 @@
|
||||
# Wie man an Programmieraufgaben arbeitet
|
||||
|
||||
Unser Ziel ist es, ein unterhaltsames und voll interaktives Lernerlebnis zu entwickeln.
|
||||
|
||||
Sich interaktive Programmieraufgaben auszudenken ist schwierig. Es wäre viel einfacher, eine ausführliche Erklärung zu schreiben oder ein Video-Tutorial zu erstellen. Aber für unseren Hauptstudienplan bleiben wir bei dem, was für die meisten Menschen am besten funktioniert - ein vollständig interaktives, videospielähnliches Erlebnis.
|
||||
|
||||
Wir wollen, dass die Teilnehmer einen Flow-Zustand erreichen. Wir wollen, dass sie in Schwung kommen und so schnell wie möglich Fortschritte in unserem Studienplan machen. Wir wollen, dass sie mit Selbstvertrauen in die Projekte gehen und einen umfassenden Einblick in Programmierkonzepte bekommen.
|
||||
|
||||
Beachte, dass wir für Version 7.0 des freeCodeCamp-Studienplan zu einem [vollständig projektorientierten Modell mit viel mehr Wiederholungen](https://www.freecodecamp.org/news/python-curriculum-is-live/) übergehen.
|
||||
|
||||
Um diese Aufgaben zu lösen, braucht es viel Kreativität und Liebe zum Detail. Es gibt viele Möglichkeiten, dir zu helfen. Du bekommst Unterstützung von einem ganzen Team von Mitwirkenden, an die du deine Ideen weitergeben und deine Aufgaben demonstrieren kannst.
|
||||
|
||||
Und wie immer kannst du Fragen in der [Kategorie 'Contributors' in unserem Forum](https://forum.freecodecamp.org/c/contributors) oder im [Contributors Chat Room](https://chat.freecodecamp.org/channel/contributors) stellen.
|
||||
|
||||
Mit deiner Hilfe können wir einen interaktiven Studienplan entwickeln, der Millionen von Menschen dabei helfen wird, in den nächsten Jahren das Programmieren zu lernen.
|
||||
|
||||
Der Inhalt jeder Aufgabe wird in einer eigenen Markdown-Datei gespeichert. Diese Markdown-Datei wird später mit unseren Tools in HTML umgewandelt, um interaktive Webseiten zu erstellen.
|
||||
|
||||
Du kannst alle Studienplaninhalte von freeCodeCamp.org im [`/curriculum/challenges`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/curriculum/challenges) Verzeichnis finden.
|
||||
|
||||
## Richte die Hilfsmittel für den Studienplan ein
|
||||
|
||||
Bevor du an dem Studienplan arbeitest, musst du einige Hilfsmittel einrichten, mit denen du deine Änderungen testen kannst. Du kannst jede der unten aufgeführten Optionen verwenden:
|
||||
|
||||
- Du kannst [das freeCodeCamp lokal einrichten](how-to-setup-freecodecamp-locally.md). Das ist **sehr empfehlenswert** für regelmäßige/wiederholte Beiträge. Mit diesem Setup kannst du arbeiten und deine Änderungen testen.
|
||||
- Verwende Gitpod, eine kostenlose Online-Entwicklungsumgebung. Wenn du auf den Button unten klickst, wird eine programmierfertige Entwicklungsumgebung für das freeCodeCamp in deinem Browser gestartet. Es dauert nur wenige Minuten.
|
||||
|
||||
[](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
|
||||
|
||||
- Bearbeite die Dateien in der Benutzeroberfläche von GitHub, indem du auf das Bleistiftsymbol für die entsprechende Datei klickst. Das ist zwar der schnellste Weg, wird aber **nicht empfohlen**, weil du deine Änderungen nicht auf GitHub testen kannst. Wenn unsere Maintainer zu dem Schluss kommen, dass die von dir vorgenommenen Änderungen lokal getestet werden müssen, musst du stattdessen die oben genannten Methoden anwenden.
|
||||
|
||||
### Wie man an Praxisprojekten arbeitet
|
||||
|
||||
Die Praxisprojekte haben einige zusätzliche Werkzeuge, die dir helfen, neue Projekte und Schritte zu erstellen. Näheres dazu findest du in [diesen Dokumenten](how-to-work-on-practice-projects.md).
|
||||
|
||||
## Aufgabenvorlage
|
||||
|
||||
````md
|
||||
---
|
||||
id: Unique identifier (alphanumerical, MongoDB_id)
|
||||
title: 'Challenge Title'
|
||||
challengeType: Integer, defined in `client/utils/challenge-types.js`
|
||||
videoUrl: 'url of video explanation'
|
||||
forumTopicId: 12345
|
||||
---
|
||||
|
||||
# --description--
|
||||
|
||||
Challenge description text, in markdown
|
||||
|
||||
```html
|
||||
<div>example code</div>
|
||||
````
|
||||
|
||||
# --instructions--
|
||||
|
||||
Anweisungstext für die Aufgabe, in Markdown
|
||||
|
||||
# --hints--
|
||||
|
||||
Tests, die gegen Benutzercode laufen, in Paaren von Markdown-Text und Codeblock-Testcode.
|
||||
|
||||
```js
|
||||
Code für den ersten Test
|
||||
```
|
||||
|
||||
Wenn eine dynamische Ausgabe basierend auf dem Code des Benutzers erforderlich ist, werden --fcc-expected-- und --fcc-actual-- durch die erwarteten und tatsächlichen Werte der Testaussagen ersetzt. Sei vorsichtig, wenn du mehrere Aussagen hast, da die erste Aussage, bei der ein Fehler auftritt, die Werte von --fcc-expected-- und --fcc-actual-- bestimmt.
|
||||
|
||||
```js
|
||||
assert.equal(
|
||||
'this will replace --fcc-actual--',
|
||||
'this will replace --fcc-expected--'
|
||||
);
|
||||
```
|
||||
|
||||
# --notes--
|
||||
|
||||
Zusätzliche Informationen für eine Aufgabe, in Markdown
|
||||
|
||||
# --seed--
|
||||
|
||||
## --before-user-code--
|
||||
|
||||
```lang
|
||||
Der Code wird vor dem Code des Nutzers ausgewertet.
|
||||
```
|
||||
|
||||
## --after-user-code--
|
||||
|
||||
```lang
|
||||
Code, der nach dem Code des Nutzers und kurz vor den Tests ausgewertet wird
|
||||
```
|
||||
|
||||
## --seed-contents--
|
||||
|
||||
Boilerplate-Code, der im Editor angezeigt wird. Dieser Abschnitt sollte nur Code innerhalb von Backticks enthalten, wie den folgenden:
|
||||
|
||||
```html
|
||||
<body>
|
||||
<p class="main-text">Hello world!</p>
|
||||
</body>
|
||||
```
|
||||
|
||||
```css
|
||||
body {
|
||||
margin: 0;
|
||||
background-color: #3a3240;
|
||||
}
|
||||
|
||||
.main-text {
|
||||
color: #aea8d3;
|
||||
}
|
||||
```
|
||||
|
||||
```js
|
||||
console.log('freeCodeCamp is awesome!');
|
||||
```
|
||||
|
||||
# --solutions--
|
||||
|
||||
Lösungen werden für die CI-Tests verwendet, um sicherzustellen, dass Änderungen an den Hinweisen (hints) weiterhin wie vorgesehen funktionieren
|
||||
|
||||
```js
|
||||
// erste Lösung - die Sprache(n) sollte(n) mit dem Startwert übereinstimmen.
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
```js
|
||||
// zweite Lösung - also wenn der Startwert in HTML geschrieben ist...
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
```js
|
||||
// dritte Lösung usw. - Ihre Lösungen sollten in HTML geschrieben sein.
|
||||
```
|
||||
|
||||
# --question--
|
||||
|
||||
Diese Felder werden derzeit für die Multiple-Choice-Aufgaben in Python verwendet.
|
||||
|
||||
## --text--
|
||||
|
||||
Der Text der Frage steht hier.
|
||||
|
||||
## --answers--
|
||||
|
||||
Antwort 1
|
||||
|
||||
---
|
||||
|
||||
Antwort 2
|
||||
|
||||
---
|
||||
|
||||
Weitere Antworten
|
||||
|
||||
## --video-solution--
|
||||
|
||||
Die Nummer für die richtige Antwort steht hier.
|
||||
````
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> 1. In den obigen Abschnitten sind Beispiele für `lang`:
|
||||
>
|
||||
> - `html` - HTML/CSS
|
||||
> - `js` - JavaScript
|
||||
> - `jsx` - JSX
|
||||
|
||||
## Nummerierung der Aufgabe
|
||||
|
||||
Jede Aufgabe benötigt eine `id`. Wenn du keine angibst, erstellt MongoDB eine neue, zufällige ID, wenn es die Daten speichert. Das wollen wir aber nicht, denn wir wollen, dass die Aufgaben-IDs in verschiedenen Umgebungen (Staging, Produktion, viele verschiedene Entwickler usw.) konsistent sind.
|
||||
|
||||
Um eine neue in einer Shell zu erstellen (vorausgesetzt, MongoDB wird separat ausgeführt):
|
||||
|
||||
1. Führe den Befehl 'mongo' aus.
|
||||
2. Führe den Befehl `ObjectId()` aus.
|
||||
|
||||
Zum Beispiel:
|
||||
|
||||
```bash
|
||||
$ mongo
|
||||
MongoDB shell version v3.6.1
|
||||
connecting to: mongodb://127.0.0.1:27017
|
||||
MongoDB server version: 3.4.10
|
||||
...
|
||||
$ ObjectId()
|
||||
ObjectId("5a474d78df58bafeb3535d34")
|
||||
````
|
||||
|
||||
Das Ergebnis ist eine neue ID, zum Beispiel `5a474d78df58bafeb3535d34` oben.
|
||||
|
||||
Sobald du deine ID hast, fügst du sie in die Markdown-Datei als `id`-Feld am Anfang ein, z. B.
|
||||
|
||||
```yml
|
||||
---
|
||||
id: 5a474d78df58bafeb3535d34
|
||||
title: Aufgabentitel
|
||||
```
|
||||
|
||||
## Aufgaben benennen
|
||||
|
||||
Dinge zu benennen ist schwer. Wir haben es einfacher gemacht, indem wir ein paar Einschränkungen festgelegt haben.
|
||||
|
||||
Alle Aufgabentitel sollten eindeutig sein und diesem Muster folgen:
|
||||
|
||||
\[Verb\]\[Objektsatz\]
|
||||
|
||||
Hier sind einige Beispielnamen für Aufgaben:
|
||||
|
||||
- Verwende die Uhrzeiger-Notation, um das Padding eines Elements festzulegen
|
||||
- Arrays mit .reduce komprimieren
|
||||
- Verwende die Klammer-Notation, um das erste Zeichen in einem String zu finden
|
||||
|
||||
## Aufgabenbeschreibungen/ Instruktionen
|
||||
|
||||
Die Sätze sollten klar und präzise sein und möglichst wenig Fachjargon enthalten. Wenn Fachjargon verwendet wird, sollte er sofort in einfachem Englisch erklärt werden.
|
||||
|
||||
Halte die Absätze kurz (etwa 1-4 Sätze). Es ist wahrscheinlicher, dass die Leute mehrere kurze Absätze lesen als eine Wand aus Text.
|
||||
|
||||
Der Aufforderungstext sollte in der zweiten Person ("du") verfasst sein, um ihm einen unterhaltenden Ton zu verleihen. Auf diese Weise scheinen der Text und die Instruktionen direkt zu dem/der Teilnehmer/in zu sprechen, der/die die Aufgabe bearbeitet. Versuche, die Verwendung der ersten Person zu vermeiden ("ich", "wir", "lass uns" und "uns").
|
||||
|
||||
Verwende keine ausgehenden Links. Sie unterbrechen den Fluss. Die Teilnehmer/innen sollten bei diesen Aufgaben nie etwas googeln müssen. Wenn du Ressourcen hast, von denen du denkst, dass sie für die Teilnehmer/innen nützlich sind, füge sie zu dem Artikel im Leitfaden für Aufgaben hinzu.
|
||||
|
||||
Du kannst bei Bedarf Grafiken hinzufügen.
|
||||
|
||||
Verwende keine Emojis oder Emoticons in Aufgaben. freeCodeCamp hat eine globale Community und die kulturelle Bedeutung eines Emojis oder Emoticons kann auf der ganzen Welt unterschiedlich sein. Außerdem können Emojis auf verschiedenen Systemen unterschiedlich dargestellt werden.
|
||||
|
||||
Eigennamen sollten, wenn möglich, in korrekter Großschreibung verwendet werden. Im Folgenden findest du eine Liste der Wörter, wie sie in den Aufgaben vorkommen sollten.
|
||||
|
||||
- JavaScript (Großbuchstaben bei "J" und "S" und keine Abkürzungen)
|
||||
- Node.js
|
||||
- Obwohl sie manchmal ungenau sind, sollten die nicht mit Bindestrichen versehenen Formen von "Back-End" und "Front-End" verwendet werden, da sie weiter verbreitet sind.
|
||||
|
||||
### Die 2-Minuten-Regel
|
||||
|
||||
Jede Aufgabe sollte von einem englischen Muttersprachler, der die vorangegangenen Aufgaben gelöst hat, innerhalb von 120 Sekunden gelöst werden können. Dazu gehört auch die Zeit, die du brauchst, um die Instruktionen zu lesen, den vorgegebenen Code zu verstehen, deinen Code zu schreiben und alle Tests zu bestehen.
|
||||
|
||||
Wenn du länger als zwei Minuten brauchst, um die Aufgabe zu lösen, hast du zwei Möglichkeiten:
|
||||
|
||||
- vereinfache die Aufgabe, oder
|
||||
- Teile die Aufgabe in zwei Aufgaben auf.
|
||||
|
||||
Die 2-Minuten-Regel zwingt dich, als Aufgabenersteller, deine Anweisungen kurz und präzise zu formulieren, deinen Startcode klar zu formulieren und deine Tests eindeutig zu gestalten.
|
||||
|
||||
Wir verfolgen, wie lange die Teilnehmer/innen brauchen, um die Aufgaben zu lösen und nutzen diese Informationen, um Aufgaben zu identifizieren, die vereinfacht oder aufgeteilt werden müssen.
|
||||
|
||||
### Modularität
|
||||
|
||||
Jede Aufgabe sollte genau ein Konzept lehren, und dieses Konzept sollte aus dem Namen der Aufgabe ersichtlich sein.
|
||||
|
||||
Wir können bereits behandelte Konzepte durch Wiederholungen und Variationen festigen - zum Beispiel h1-Elemente in einer Aufgabe und h3-Elemente ein paar Aufgaben später.
|
||||
|
||||
Unser Ziel ist es, tausende von 2-minütigen Aufgaben zu haben. Diese können ineinander übergehen und bereits gelernte Konzepte wiederholen.
|
||||
|
||||
### Aufgabentext formatieren
|
||||
|
||||
Hier findest du spezielle Formatierungsrichtlinien für Aufgabentexte und einige Beispiele:
|
||||
|
||||
- Sprachliche Schlüsselwörter stehen in `` \` `` Backticks. Zum Beispiel HTML-Tag-Namen oder CSS-Eigenschaftsnamen.
|
||||
- Verweise auf Codeteile (d. h. Funktions-, Methoden- oder Variablennamen) sollten in `` \` ``-Backticks eingeschlossen werden. Siehe untenstehendes Beispiel:
|
||||
|
||||
```md
|
||||
Verwende `parseInt`, um die Variable `realNumber` in eine Integerzahl umzuwandeln.
|
||||
```
|
||||
|
||||
- Verweise auf Dateinamen und Pfadverzeichnisse (z. B. `package.json`, `src/components`) sollten in `` \` ``-Backticks eingeschlossen werden.
|
||||
- Mehrzeiligen Codeblöcken **muss eine Leerzeile vorangestellt werden**. Die nächste Zeile muss mit drei Backticks beginnen, unmittelbar gefolgt von einer der [unterstützten Sprachen](https://prismjs.com/#supported-languages). Um den Codeblock zu vervollständigen, musst du eine neue Zeile beginnen, die nur drei Backticks und **eine weitere Leerzeile** enthält. Siehe untenstehendes Beispiel:
|
||||
- Whitespace ist in Markdown wichtig, deshalb empfehlen wir, ihn in deinem Editor sichtbar zu machen.
|
||||
|
||||
**Hinweis:** Wenn du einen Beispielcode in YAML verwendest, benutze `yaml` anstelle von `yml` für die Sprache rechts von den Backticks.
|
||||
|
||||
Im Folgenden findest du ein Codebeispiel:
|
||||
|
||||
````md
|
||||
```{Sprache}
|
||||
|
||||
[HIER DEIN CODE]
|
||||
|
||||
````
|
||||
````
|
||||
|
||||
- Zusätzliche Informationen in Form einer Anmerkung sollten von Leerzeilen umgeben sein und wie folgt formatiert werden: "**Note:** Rest des Anmerkungstextes...".
|
||||
- Wenn mehrere Notizen erforderlich sind, listest du alle Notizen in separaten Sätzen auf und verwendest das Format: **Notes:** Erster Text der Notiz. Zweiter Notiztext.`
|
||||
- Verwende einfache Anführungszeichen, wo dies möglich ist.
|
||||
|
||||
**Note:** Das Äquivalent _Markdown_ sollte anstelle von _HTML_ Tags verwendet werden.
|
||||
|
||||
## Tests schreiben
|
||||
|
||||
Aufgaben sollten so viele Tests enthalten, wie nötig sind, um zu überprüfen, ob ein Teilnehmer ein Konzept verstanden hat.
|
||||
|
||||
Unser Ziel ist es, den einzelnen Aspekt der Aufgabe zu vermitteln und zu prüfen, ob die Teilnehmer/innen diesen Aspekt verstanden haben.
|
||||
|
||||
Aufgabentests können die Assertion-Bibliotheken von Node.js und Chai.js nutzen. Außerdem kann bei Bedarf auf den vom Benutzer erstellten Code in der Variable `code` zugegriffen werden. Zusätzlich stellt das Objekt `__helpers` mehrere Funktionen zur Verfügung, die das Schreiben von Tests vereinfachen. Die verfügbaren Funktionen sind in _client/src/utils/curriculum-helpers.ts_ definiert.
|
||||
|
||||
## Formatierung des Startcodes
|
||||
|
||||
Im Folgenden findest du bestimmte Formatierungsrichtlinien für den Startcode der Aufgabe:
|
||||
|
||||
- Verwende zwei Leerzeichen zum Einrücken
|
||||
- JavaScript-Anweisungen enden mit einem Semikolon
|
||||
- Verwende doppelte Anführungszeichen, wo dies möglich ist
|
||||
|
||||
### Kommentare zum Startcode
|
||||
|
||||
Wir haben ein [comment dictionary](/curriculum/dictionaries/english/comments.js), das die einzigen Kommentare enthält, die im Startcode verwendet werden können. Die Groß- und Kleinschreibung und die Abstände des Kommentarwörterbuchs müssen eingehalten werden. Das Kommentarwörterbuch sollte nicht ohne vorherige Absprache mit dem Entwicklungsteam erweitert werden.
|
||||
|
||||
Die verwendeten Kommentare sollten ein Leerzeichen zwischen den Kommentarzeichen und dem eigentlichen Kommentar enthalten. Im Allgemeinen sollten Kommentare sparsam verwendet werden. Überlege dir immer, ob du die Beschreibung oder die Instruktionen einer Aufgabe umschreiben kannst, wenn du dadurch einen Kommentar im Startcode vermeiden kannst.
|
||||
|
||||
Beispiel für einen gültigen einzeiligen JavaScript-Kommentar:
|
||||
|
||||
```js
|
||||
// Ändere nur den Code unterhalb dieser Zeile
|
||||
````
|
||||
|
||||
Beispiel für einen gültigen CSS-Kommentar:
|
||||
|
||||
```css
|
||||
/* Only change code above this line */
|
||||
```
|
||||
|
||||
Wenn eine Aufgabe nur eine einzige Stelle hat, an der Codeänderungen erforderlich sind, verwende bitte die Kommentare im folgenden Beispiel, um dem Teilnehmer mitzuteilen, wo die Änderungen vorgenommen werden sollen.
|
||||
|
||||
```js
|
||||
var a = 3;
|
||||
var b = 17;
|
||||
var c = 12;
|
||||
|
||||
// Only change code below this line
|
||||
a = a + 12;
|
||||
b = 9 + b;
|
||||
c = c + 7;
|
||||
```
|
||||
|
||||
Wenn eine Aufgabe mehrere Stellen hat, an denen der Benutzer den Code ändern soll (z. B. die React-Aufgaben)
|
||||
|
||||
```jsx
|
||||
class MyComponent extends React.Component {
|
||||
constructor(props) {
|
||||
super(props);
|
||||
this.state = {
|
||||
text: 'Hello'
|
||||
};
|
||||
// Change code below this line
|
||||
|
||||
// Change code above this line
|
||||
}
|
||||
handleClick() {
|
||||
this.setState({
|
||||
text: 'You clicked!'
|
||||
});
|
||||
}
|
||||
render() {
|
||||
return (
|
||||
<div>
|
||||
{/* Change code below this line */}
|
||||
<button>Click Me</button>
|
||||
{/* Change code above this line */}
|
||||
<h1>{this.state.text}</h1>
|
||||
</div>
|
||||
);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### Übersetzung der Kommentare im Startcode
|
||||
|
||||
Für jede Sprache gibt es ein eigenes Kommentarwörterbuch. Die [englische Version des Kommentarwörterbuchs](/curriculum/dictionaries/english/comments.js) ist die Grundlage für die Übersetzungen in den entsprechenden nicht-englischen Versionen der Dateien. Die nicht-englische Version des chinesischen Kommentarwörterbuchs befindet sich unter `/curriculum/dictionaries/chinese/comments.js`. Jedes Wörterbuch besteht aus einem Array von Objekten mit einer eindeutigen `id`-Eigenschaft und einer `text`-Eigenschaft. Nur der `text` sollte geändert werden, damit er die Übersetzung des entsprechenden englischen Kommentars enthält.
|
||||
|
||||
Einige Kommentare können ein Wort/einen Satz enthalten, das/der nicht übersetzt werden sollte. Zum Beispiel sollten Variablennamen oder Bibliotheksnamen wie "React" nicht übersetzt werden. Schau dir den Kommentar unten als Beispiel an. Das Wort `myGlobal` sollte nicht übersetzt werden.
|
||||
|
||||
```text
|
||||
Deklariere die Variable myGlobal unterhalb dieser Zeile
|
||||
```
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> Wir arbeiten an einer Integration, die die Arbeit an i18n für das Kommentarwörterbuch ermöglicht.
|
||||
|
||||
## Hinweise und Lösungen
|
||||
|
||||
Jede Aufgabe hat einen `Erhalte einen Tipp` Button, so dass ein Teilnehmer alle Tipps/Lösungen, die für die Aufgabe erstellt wurden, abrufen kann. Tipps und Lösungen für den Studienplan findest du in [unserem Forum](https://forum.freecodecamp.org/c/guide) unter der Kategorie `Guide`.
|
||||
|
||||
Wenn du ein Problem in einem bestehenden Thema für Tipps/Lösungen findest, kannst du in der [Kategorie contributors](https://forum.freecodecamp.org/c/contributors) im Forum Vorschläge machen. Moderatoren und Nutzer mit Vertrauensstufe 3 prüfen die Kommentare und entscheiden, ob die Änderungen in das entsprechende Hinweis-/Lösungsthema aufgenommen werden oder nicht.
|
||||
|
||||
### Neue Aufgabenhinweise/Lösungsthemen hinzufügen
|
||||
|
||||
Führe die folgenden Schritte aus, wenn du ein neues Thema mit Tipps und Lösungen für Aufgaben hinzufügst.
|
||||
|
||||
1. Beginne mit den gleichen Schritten wie beim Erstellen eines neuen Themas, aber schau dir die nächsten Schritte zum Erstellen des Titels an.
|
||||
2. Der Titel des Themas sollte mit `freeCodeCamp Challenge Guide:` beginnen und mit dem eigentlichen Titel der Studienplanaufgabe verkettet werden. Wenn die Aufgabe zum Beispiel "`Chunky Monkey`" heißt, würde der Titel des Themas lauten "`freeCodeCamp Challenge Guide: Chunky Monkey`".
|
||||
3. `camperbot` sollte der Eigentümer dieser Themen/Posts sein. Du musst also einen Admin bitten, den Eigentümer des Hauptposts auf `camperbot` zu ändern.
|
||||
4. Sobald das neue Thema erstellt ist, wird eine Forenthemen-ID erstellt. Sie befindet sich am Ende der URL des Forenthemas. Diese ID muss dem Frontmatter der Studienplanaufgabendatei über den normalen Pull-Request-Prozess hinzugefügt werden, damit der `Erhalte einen Tipp` Button auf das Thema verlinkt.
|
||||
|
||||
### Richtlinien für den Inhalt von Hinweisen und Lösungsthemen
|
||||
|
||||
Wenn du eine Lösung für ein Studienplanaufgabenthema vorschlägst, muss der vollständige Code hinzugefügt werden. Dies beinhaltet den gesamten ursprünglichen Startcode sowie alle Änderungen, die nötig sind, um alle Aufgabentests zu bestehen. Die folgende Vorlage sollte verwendet werden, wenn du neue Hinweise/Lösungen für Themen erstellst:
|
||||
|
||||
````md
|
||||
# Aufgabentitel hier eintragen
|
||||
|
||||
---
|
||||
|
||||
## Problemerläuterung
|
||||
|
||||
Hier wird zusammengefasst, was zu tun ist, ohne die Aufgabenbeschreibung und/oder die Instruktionen einfach zu wiederholen. Dies ist ein optionaler Abschnitt
|
||||
|
||||
#### relevante Links
|
||||
|
||||
- [Linktext](Link_url_hier eintragen)
|
||||
- [Linktext](Link_url_hier eintragen)
|
||||
---
|
||||
|
||||
## Hinweise
|
||||
|
||||
### Hinweis 1
|
||||
|
||||
Hinweis hier eintragen
|
||||
|
||||
### Hinweis 2
|
||||
|
||||
Hinweis hier eintragen
|
||||
|
||||
---
|
||||
|
||||
## Lösungen
|
||||
|
||||
<details><summary>Lösung 1 (Klicken zum Anzeigen/Verbergen)</summary>
|
||||
|
||||
```js
|
||||
function myFunc() {
|
||||
console.log('Hello World!');
|
||||
}
|
||||
````
|
||||
|
||||
#### Erklärung des Codes
|
||||
|
||||
- Erklärung des Codes hier eintragen
|
||||
- Erklärung des Codes hier eintragen
|
||||
|
||||
#### Relevante Links
|
||||
|
||||
- [Linktext](link_url_goes_here)
|
||||
- [Linktext](link_url_goes_here)
|
||||
|
||||
</details>
|
||||
````
|
||||
|
||||
## Testen von Aufgaben
|
||||
|
||||
Bevor du [einen Pull-Request](how-to-open-a-pull-request.md) für deine Änderungen erstellst, musst du überprüfen, ob die von dir vorgenommenen Änderungen nicht versehentlich Probleme mit der Aufgabe verursachen.
|
||||
|
||||
1. Um alle Aufgaben zu testen, führe den folgenden Befehl im Stammverzeichnis aus
|
||||
|
||||
````
|
||||
npm run test:curriculum
|
||||
```
|
||||
|
||||
2. Du kannst auch einen Block oder einen Superblock von Aufgaben mit diesen Befehlen testen
|
||||
|
||||
```
|
||||
npm run test:curriculum --block='Basic HTML and HTML5'
|
||||
```
|
||||
|
||||
```
|
||||
npm run test:curriculum --superblock=responsive-web-design
|
||||
```
|
||||
|
||||
Du kannst eine Aufgabe auch einzeln testen, indem du die folgenden Schritte ausführst:
|
||||
|
||||
1. Wechsle in das Verzeichnis "Curriculum":
|
||||
|
||||
```
|
||||
cd curriculum
|
||||
```
|
||||
|
||||
2. Führe das Folgende für jede Aufgabendatei aus, für die du Änderungen vorgenommen hast (ersetze dabei `Aufgabentitel hier eintragen` durch den vollständigen Titel der Aufgabe):
|
||||
|
||||
```
|
||||
npm run test -- -g Aufgabentitel hier eintragen ```
|
||||
|
||||
Sobald du sichergestellt hast, dass jede Aufgabe, an der du gearbeitet hast, die Tests besteht, [erstelle bitte einen Pull-Request](how-to-open-a-pull-request.md).
|
||||
|
||||
> [!TIP] Du kannst die Umgebungsvariable `LOCALE` in der `.env` auf die Sprache der Aufgabe(n) setzen, die du testen willst.
|
||||
>
|
||||
> Die derzeit akzeptierten Werte sind `englisch` und `chinesisch`, wobei `englisch` standardmäßig eingestellt ist.
|
||||
|
||||
### Nützliche Links
|
||||
|
||||
Aufgaben erstellen und bearbeiten:
|
||||
|
||||
1. [Aufgabentypen](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/client/utils/challenge-types.js#L1-L13) - was die numerischen Aufgabentypenwerte bedeuten (Enum).
|
||||
|
||||
2. [Beitrag zum FreeCodeCamp - ES6 Challenge Tests schreiben](https://www.youtube.com/watch?v=iOdD84OSfAE#t=2h49m55s) - ein Video, das [Ethan Arrowood](https://twitter.com/ArrowoodTech) bei seinem Beitrag zur alten Version des Lehrplans begleitet.
|
||||
267
docs/i18n/german/how-to-work-on-localized-client-webapp.md
Normal file
267
docs/i18n/german/how-to-work-on-localized-client-webapp.md
Normal file
@ -0,0 +1,267 @@
|
||||
# Wie du an einer lokalisierten Client-Webapp arbeitest
|
||||
|
||||
Die React-basierte Client-Web-App, die unsere Lernplattform betreibt, wurde mit Gatsby entwickelt. Sie wird mit [react-i18next](https://react.i18next.com/) und [i18next](https://www.i18next.com/) in verschiedene Weltsprachen übersetzt.
|
||||
|
||||
Du kannst mehr darüber erfahren, wie du die Client-Anwendung lokal für die Entwicklung einrichtest, indem du [unseren Leitfaden zur lokalen Einrichtung](how-to-setup-freecodecamp-locally.md) liest. Standardmäßig ist die Anwendung nur in Englisch verfügbar.
|
||||
|
||||
Sobald du das Projekt lokal eingerichtet hast, solltest du dieser Dokumentation folgen können, um den Client in der Sprache deiner Wahl aus der Liste der verfügbaren Sprachen auszuführen.
|
||||
|
||||
Das kann hilfreich sein, wenn du an einem Feature arbeitest, das speziell auf die Lokalisierung abzielt und du zum Beispiel die Beschriftung eines Buttons in einer anderen Sprache validieren musst.
|
||||
|
||||
> [!TIP] Du musst dieses Dokument nicht befolgen, um den Studienplan von freeCodeCamp zu übersetzen oder etwas zur Dokumentation beizusteuern. Lies stattdessen [diesen Leitfaden hier](how-to-translate-files.md).
|
||||
|
||||
Wir wollen verstehen, wie die i18n-Frameworks und -Werkzeuge funktionieren.
|
||||
|
||||
## Dateistruktur
|
||||
|
||||
Die meisten Dateien für die Übersetzung der Plattform befinden sich im Ordner [`client/i18n`](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/client/i18n). Für jede Sprache gibt es ein Verzeichnis, das JSON-Dateien mit den Übersetzungen enthält.
|
||||
|
||||
```console
|
||||
config/i18n
|
||||
└── all-langs.ts
|
||||
...
|
||||
client/i18n
|
||||
├── configForTests.js
|
||||
├── config.js
|
||||
├── locales
|
||||
│ ├── chinese
|
||||
│ │ ├── intro.json
|
||||
│ │ ├── links.json
|
||||
│ │ ├── meta-tags.json
|
||||
│ │ ├── motivation.json
|
||||
│ │ ├── translations.json
|
||||
│ │ └── trending.json
|
||||
... ...
|
||||
│ ├── dothraki
|
||||
│ │ ├── intro.json
|
||||
│ │ ├── links.json
|
||||
│ │ ├── meta-tags.json
|
||||
│ │ ├── motivation.json
|
||||
│ │ ├── translations.json
|
||||
│ │ └── trending.json
|
||||
... ...
|
||||
│ ├── english
|
||||
│ │ ├── intro.json
|
||||
│ │ ├── links.json
|
||||
│ │ ├── meta-tags.json
|
||||
│ │ ├── motivation.json
|
||||
│ │ ├── translations.json
|
||||
│ │ └── trending.json
|
||||
│ └── espanol
|
||||
│ ├── intro.json
|
||||
│ ├── links.json
|
||||
│ ├── meta-tags.json
|
||||
│ ├── motivation.json
|
||||
│ ├── translations.json
|
||||
│ └── trending.json
|
||||
├── locales.test.js
|
||||
├── schema-validation.js
|
||||
└── validate-keys.ts
|
||||
```
|
||||
|
||||
Einige dieser Dateien werden auf unserer Übersetzungsplattform (Crowdin) übersetzt, andere nicht.
|
||||
|
||||
**Dateien, die auf unserer Übersetzungsplattform übersetzt wurden:**
|
||||
|
||||
- Die Datei `translations.json` enthält den Großteil des Textes, der auf den Elementen der Benutzeroberfläche erscheint. Die Schlüssel werden in der Codebasis verwendet, um den richtigen Text für die eingestellte Sprache zu erhalten. Diese Datei muss in allen Sprachen die exakt gleichen Schlüssel haben.
|
||||
|
||||
- Die Datei `intro.json` enthält die Schlüssel-Werte-Paare für den Einleitungstext auf den Zertifikatseiten.
|
||||
|
||||
Wenn du Übersetzungen für die Schlüssel hinzufügen/aktualisieren willst, lies bitte [diesen Leitfaden hier](how-to-translate-files.md).
|
||||
|
||||
**Dateien, die NICHT auf unserer Übersetzungsplattform übersetzt wurden:**
|
||||
|
||||
- Die `motivation.json` Dateien müssen nicht die gleichen Zitate, Komplimente oder Array-Längen haben. Nur die gleiche JSON-Struktur.
|
||||
|
||||
- Die Datei `trending.json` enthält die Titel und Links für die angesagtesten Nachrichtenartikel in der Fußzeile der Website.
|
||||
|
||||
- Die Datei `meta-tags.json` enthält die Informationen für die Meta-Tag-Informationen unserer Website.
|
||||
|
||||
Änderungen an diesen Dateien werden normalerweise von dem Mitarbeiterteam vorgenommen. Wenn dir etwas Ungewöhnliches auffällt, empfehlen wir dir, uns im [Contributors Chat Room](https://chat.freecodecamp.org/channel/contributors) anzusprechen.
|
||||
|
||||
## Das Testen der Client-App in einer Weltsprache
|
||||
|
||||
Du kannst die Client-App in jeder Sprache testen, die in der [Liste der Sprachen](https://github.com/freeCodeCamp/freeCodeCamp/blob/6b4a6a02568b809fc216ea8566ff5df446d1da4e/config/i18n/all-langs.js#L5) verfügbar ist.
|
||||
|
||||
```js
|
||||
const availableLangs = {
|
||||
client: ['english', 'espanol', 'chinese'],
|
||||
...
|
||||
};
|
||||
```
|
||||
|
||||
Wenn du eine neue Sprache testest, erstelle einen Ordner mit dem Namen der Sprache als Titel neben den anderen Sprachen und kopiere die JSON-Dateien aus einer anderen Sprache in deinen neuen Ordner.
|
||||
|
||||
Füge die Sprache zum `client`-Array hinzu, wie oben in der [`config/i18n/all-langs.js`](https://github.com/freeCodeCamp/freeCodeCamp/blob/main/config/i18n/all-langs.js) Datei zu sehen.
|
||||
|
||||
Befolge dann die Anweisungen in den Kommentaren in derselben Datei, um die restlichen Variablen nach Bedarf hinzuzufügen/zu aktualisieren.
|
||||
|
||||
Zum Schluss stellst du die Variable `CLIENT_LOCALE` in deiner `.env`-Datei auf die Sprache ein, die du verwenden willst, und schon bist du fertig.
|
||||
|
||||
## Wie du Komponenten strukturierst
|
||||
|
||||
Wenn du an einer Funktion oder einem Fehler für die Client-Webanwendung arbeitest, z. B. wenn du neue Elemente auf der Einstellungsseite hinzufügst, solltest du die folgenden Richtlinien befolgen. Sie helfen dir, die Komponenten für die Lokalisierung in alle unterstützten Weltsprachen vorzubereiten.
|
||||
|
||||
### Funktionelle Komponente
|
||||
|
||||
```js
|
||||
import { useTranslation } from 'react-i18next';
|
||||
|
||||
// in der Rendermethode:
|
||||
const { t } = useTranslation();
|
||||
|
||||
// Aufruf der Funktion "t" mit einem Key aus der JSON-Datei:
|
||||
<p>{t('key')}</p> // weitere Details unten
|
||||
```
|
||||
|
||||
### Klassenkomponente
|
||||
|
||||
```js
|
||||
import { withTranslation } from 'react-i18next';
|
||||
|
||||
// withTranslation fügt die Funktion "t" zu props hinzu:
|
||||
const { t } = this.props;
|
||||
|
||||
// Aufruf der Funktion "t" mit einem Key aus der JSON-Datei:
|
||||
<h1>{t('key')}</h1> // weitere Details unten
|
||||
|
||||
// Export ohne redux:
|
||||
export default withTranslation()(Component);
|
||||
|
||||
// oder mit redux:
|
||||
export default connect(...)(withTranslation()(Component));
|
||||
```
|
||||
|
||||
## Übersetzen mit Hilfe der "t"-Funktion
|
||||
|
||||
### Grundlegende Übersetzung
|
||||
|
||||
```js
|
||||
// in der Komponente:
|
||||
<p>{t('p1')}</p>
|
||||
|
||||
// in der JSON Datei:
|
||||
{
|
||||
"p1": "My paragraph"
|
||||
}
|
||||
|
||||
// Output:
|
||||
<p>My paragraph</p>
|
||||
```
|
||||
|
||||
### Mit dynamischen Daten
|
||||
|
||||
```js
|
||||
// in der Komponente:
|
||||
const username = 'moT';
|
||||
|
||||
<p>{t('welcome', { username: username })}</p>
|
||||
|
||||
// in der JSON Datei:
|
||||
{
|
||||
"welcome": "Welcome {{username}}"
|
||||
}
|
||||
|
||||
// Output:
|
||||
<p>Welcome moT</p>
|
||||
```
|
||||
|
||||
Das obige Beispiel übergibt der Funktion `t` ein Objekt mit einer Variablen `username`. Die Variable wird im JSON-Wert verwendet, wo `{{username}}` steht.
|
||||
|
||||
## Übersetzen mit der `Trans`-Komponente
|
||||
|
||||
Generell gilt: Verwende die "t"-Funktion, wenn du kannst. Es gibt aber eine `Trans`-Komponente für den Fall, dass das nicht ausreicht, z. B. wenn du Elemente in den Text eingebettet hast. Du kannst die `Trans`-Komponente mit jeder Art von React-Komponente verwenden.
|
||||
|
||||
### Verschachtelte Grundelemente
|
||||
|
||||
```js
|
||||
// in der Komponente:
|
||||
import { Trans } from 'react-i18next'
|
||||
|
||||
<p>
|
||||
<Trans>fcc.greeting</Trans>
|
||||
</p>
|
||||
|
||||
// in der JSON Datei:
|
||||
{
|
||||
"fcc": {
|
||||
"greeting": "Welcome to <strong>freeCodeCamp</strong>"
|
||||
}
|
||||
}
|
||||
|
||||
// Output:
|
||||
<p>Welcome to <strong>freeCodeCamp</strong></p>
|
||||
```
|
||||
|
||||
Du kannst den Schlüssel wie im obigen Beispiel innerhalb der Komponenten-Tags platzieren, wenn der Text "einfache" Tags ohne Attribute enthält. `br`, `strong`, `i` und `p` sind die Standardwerte, aber diese Liste kann in der i18n-Konfiguration erweitert werden.
|
||||
|
||||
### Verschachtelte komplexe Elemente
|
||||
|
||||
In anderen Fällen möchtest du einen bestimmten Text innerhalb eines anderen Elements platzieren, ein Anker-Tag ist ein gutes Beispiel dafür:
|
||||
|
||||
```js
|
||||
// in der Komponente:
|
||||
<p>
|
||||
<Trans i18nKey='check-forum'>
|
||||
<a href='https://forum.freecodecamp.org/'>placeholder</a>
|
||||
</Trans>
|
||||
</p>
|
||||
|
||||
// in der JSON Datei:
|
||||
{
|
||||
"check-forum": "Check out <0>our forum</0>."
|
||||
}
|
||||
|
||||
// Output:
|
||||
<p>Check out <a href='https://forum.freecodecamp.org/'>our forum</a></p>
|
||||
```
|
||||
|
||||
Im obigen Beispiel wird der Schlüssel in den Attributen der `Trans`-Komponente gesetzt. Die `<0>` und `</0>` im JSON stehen für das erste Kindelement der Komponente, in diesem Fall das Ankerelement. Wenn es mehr Kindelemente gäbe, würden sie einfach von dort aus weiterzählen und dabei dieselbe Syntax verwenden. Du kannst die Kindelemente einer Komponente in den React Dev Tools finden, indem du sie inspizierst. `placeholder` ist einfach da, weil der Linter sich über leere `<a>`-Elemente beschwert.
|
||||
|
||||
### Mit einer Variablen
|
||||
|
||||
```js
|
||||
// in der Komponente:
|
||||
const email = 'team@freecodecamp.org';
|
||||
|
||||
<p>
|
||||
<Trans email={email} i18nKey='fcc.email'>
|
||||
<a href={`mailto:${email}`}>
|
||||
{{ email }}
|
||||
</a>
|
||||
</Trans>
|
||||
</p>
|
||||
|
||||
// in der JSON Datei:
|
||||
{
|
||||
"fcc": {
|
||||
"email": "Send us an email at: <0>{{email}}</0>"
|
||||
}
|
||||
}
|
||||
|
||||
// Output:
|
||||
<p>Send us an email at: <a href='mailto:team@freecodecamp.org'>team@freecodecamp.org</a><p>
|
||||
```
|
||||
|
||||
Im obigen Beispiel werden der Schlüssel und eine Variable in den Attributen der `Trans`-Komponente festgelegt. `{{ email }}` muss auch irgendwo in der `Trans`-Komponente stehen, es ist egal wo.
|
||||
|
||||
## Ändern des Textes
|
||||
|
||||
Um den Text auf der Client-Seite zu ändern, gehst du in die entsprechende `.json`-Datei, suchst den Schlüssel, der in der React-Komponente verwendet wird, und änderst den Wert in den gewünschten neuen Text. Du solltest die Codebasis nach diesem Schlüssel durchsuchen, um sicherzustellen, dass er nicht an anderer Stelle verwendet wird. Oder, falls ja, dass die Änderungen an allen Stellen sinnvoll sind.
|
||||
|
||||
## Hinzufügen von Text
|
||||
|
||||
Wenn der Text, den du dem Client hinzufügen möchtest, bereits in der entsprechenden `.json`-Datei vorhanden ist, verwende den vorhandenen Schlüssel. Andernfalls erstellst du einen neuen Schlüssel.
|
||||
|
||||
Die englische Datei ist die "Quelle der Wahrheit" für alle `.json`-Dateien, die den gleichen Namen haben. Wenn du einen neuen Schlüssel hinzufügen musst, füge ihn dort ein. Dann fügst du den Schlüssel zu **allen** `translations.json`-Dateien hinzu.
|
||||
|
||||
> [!NOTE] Verwende englischen Text für alle Sprachen, wenn die Datei über Crowdin übersetzt wird. Andernfalls werden die Tests fehlschlagen.
|
||||
|
||||
Es wäre auch schön, wenn die Schlüssel in allen Dateien die gleiche Reihenfolge hätten. Versuche außerdem, alle Satzzeichen, Abstände, Anführungszeichen usw. in den JSON-Dateien und nicht in den Komponenten oder Serverdateien zu platzieren.
|
||||
|
||||
> [!NOTE] Der Unterstrich (`_`) ist ein reserviertes Zeichen für Schlüssel in den clientseitigen Dateien. In der [Dokumentation](https://www.i18next.com/translation-function/plurals) erfährst du, wie sie verwendet werden.
|
||||
|
||||
## Hilfreiche Dokumentation
|
||||
|
||||
- [react-i18next Dokumente](https://react.i18next.com/latest/usetranslation-hook)
|
||||
- [i18next Dokumente](https://www.i18next.com/translation-function/essentials)
|
||||
123
docs/i18n/german/how-to-work-on-practice-projects.md
Normal file
123
docs/i18n/german/how-to-work-on-practice-projects.md
Normal file
@ -0,0 +1,123 @@
|
||||
# Wie man an Praxisprojekten arbeitet
|
||||
|
||||
Der Ordner `tools/challenge-helper-scripts` enthält Tools, die die Erstellung und Pflege des projektbasierten Studienplans von freeCodeCamp erleichtern.
|
||||
|
||||
## Erstelle ein neues Projekt
|
||||
|
||||
Führe `npm run create-project` aus. Dadurch öffnet sich eine Kommandozeilenoberfläche, die dich durch den Prozess führt. Wenn das erledigt ist, sollte es eine neue Aufgabe im englischen Studienplan geben, die du für den ersten Schritt des Projekts nutzen kannst. Wenn du zum Beispiel ein Projekt mit dem Namen `test-project` in der Responsive-Webdesign-Zertifizierung erstellt hast, befindet es sich in `curriculum/challenges/english/01-responsive-web-design/test-project`.
|
||||
|
||||
Wenn du neue Schritte erstellen willst, vereinfachen die folgenden Tools diesen Prozess.
|
||||
|
||||
## Nächsten Schritt erstellen
|
||||
|
||||
Ein einmaliges Skript, das automatisch den nächsten Schritt hinzufügt, basierend auf dem letzten Schritt, der als `step-xxx.md` nummeriert ist, wobei `xxx` die dreistellige Schrittnummer des letzten Schritts darstellt. Der Aufgaben-Seed-Code (initialer Startcode im Editor) verwendet den Aufgaben-Seed-Code des vorherigen Schritts, wobei die Editable Region Markers (ERMs) entfernt werden.
|
||||
|
||||
**Hinweis:** Dieses Skript führt auch [reorder-steps](#reorder-steps) aus.
|
||||
|
||||
### So führst du das Skript aus:
|
||||
|
||||
1. Wechsle in das Verzeichnis des Projekts.
|
||||
2. Führe den folgenden npm-Befehl aus:
|
||||
|
||||
```bash
|
||||
npm run create-next-step
|
||||
```
|
||||
|
||||
## leere Schritte erstellen
|
||||
|
||||
Ein einmaliges Skript, das automatisch eine bestimmte Anzahl von Schritten bei einer bestimmten Startschrittnummer hinzufügt. Der Aufgaben-Seed-Code für alle erstellten Schritte wird leer sein.
|
||||
|
||||
**Hinweis:** Dieses Skript führt auch [reorder-steps](#reorder-steps) aus.
|
||||
|
||||
### So führst du das Skript aus:
|
||||
|
||||
1. Wechsle in das Verzeichnis des Projekts.
|
||||
2. Führe den folgenden npm-Befehl aus:
|
||||
|
||||
```bash
|
||||
npm run create-empty-steps start=X num=Y # wobei X die Startschrittnummer und Y die Anzahl der zu erstellenden Schritte ist.
|
||||
```
|
||||
|
||||
## Zwischenschritt erstellen
|
||||
|
||||
Ein einmaliges Skript, das automatisch einen neuen Schritt zwischen zwei bestehenden, aufeinanderfolgenden Schritten einfügt. Der Aufgaben-Seed-Code verwendet den bestehenden Aufgaben-Seed-Code des Startschritts, wobei die ERMs (Editable Region Markers) entfernt werden.
|
||||
|
||||
**Hinweis:** Dieses Skript führt auch [reorder-steps](#reorder-steps) aus.
|
||||
|
||||
### So führst du das Skript aus:
|
||||
|
||||
1. Wechsle in das Verzeichnis des Projekts.
|
||||
2. Führe den folgenden npm-Befehl aus:
|
||||
|
||||
```bash
|
||||
npm run create-step-between start=X # wobei X die Nummer des Anfangsschritts ist
|
||||
```
|
||||
|
||||
## Lösche eine Schritt
|
||||
|
||||
Ein einmaliges Skript, das einen bestehenden Schritt löscht und dann die verbleibenden Schrittdateien im Projektordner neu anordnet sowie das Eigenschaftsarray `challengeOrder` in der `meta.json` des Projekts mit der neuen Reihenfolge der Schritte aktualisiert.
|
||||
|
||||
### So führst du das Skript aus
|
||||
|
||||
1. Wechsle in das Verzeichnis des Projekts.
|
||||
2. Führe den folgenden npm-Befehl aus:
|
||||
|
||||
```bash
|
||||
npm run delete-step num=x # wobei x die Schrittnummer ist, die gelöscht werden soll.
|
||||
```
|
||||
|
||||
## Schritte neu ordnen
|
||||
|
||||
Ein einmaliges Skript, das die Schrittdateien in den Markdown-Dateien eines Projekts automatisch anhand des Dateinamens neu anordnet. Außerdem wird das `challengeOrder` Eigenschaftsarray in der `meta.json` des Projekts mit der neuen Reihenfolge der Schritte aktualisiert.
|
||||
|
||||
### Praxisbeispiel
|
||||
|
||||
Nehmen wir an, du beginnst mit der folgenden Projektstruktur:
|
||||
|
||||
```bash
|
||||
step-001.md
|
||||
step-002.md
|
||||
step-003.md
|
||||
step-004.md
|
||||
step-005.md
|
||||
step-006.md
|
||||
```
|
||||
|
||||
Irgendwann entscheidest du, dass du `Schritt-002.md` löschen musst, weil du diesen Schritt nicht mehr brauchst. Außerdem entscheidest du dich, `Schritt-004.md` in drei Schritte aufzuteilen, statt nur in einen.
|
||||
|
||||
Um diese Umstrukturierung zu erreichen, musst du `step-002.md` löschen und dann eine `step-004a.md` und eine `step-004b.md` hinzufügen. Die neue Ordnerstruktur würde wie folgt aussehen:
|
||||
|
||||
```bash
|
||||
step-001.md
|
||||
step-003.md
|
||||
step-004.md
|
||||
step-004a.md
|
||||
step-004b.md
|
||||
step-005.md
|
||||
step-006.md
|
||||
```
|
||||
|
||||
Die Dateinamen müssen jetzt `step-001.md` bis `step-007.md` lauten, denn du hast eine Datei entfernt, aber zwei weitere hinzugefügt, so dass die Differenz nur eine Datei beträgt. Außerdem muss das Frontmatter jeder Datei unterhalb eines gelöschten oder hinzugefügten Schritts geändert werden, indem der Schlüsselwert `title` an die neue Schrittnummer angepasst wird. Wenn du zum Beispiel `step-3.md` in `step-2.md` umbenannt hast, musst du den Titel von `step-2.md` von `Step 03` in `Step 02` ändern.
|
||||
|
||||
Weiter unten findest du die erforderlichen Änderungen am Projektordner:
|
||||
|
||||
```bash
|
||||
step-001.md
|
||||
step-003.md renamed to step-002.md and title changes to "Step 2"
|
||||
step-004.md renames to step-003.md and title changes to "Step 3"
|
||||
step-004a.md renames to step-004.md and title changes to "Step 4"
|
||||
step-004b.md renames to step-005.md and title changes to "Step 5"
|
||||
step-005.md renames to step-006.md and title changes to "Step 6"
|
||||
step-006.md renames to step-007.md and title changes to "Step 7"
|
||||
```
|
||||
|
||||
Zusammen mit den oben genannten Änderungen muss der Schlüssel `challengeOrder` in der Datei `meta.json` des Projekts die neue Schrittreihenfolge widerspiegeln. Das ist notwendig, weil jeder Schritt, der gelöscht und/oder hinzugefügt wird, den `title` ändert, der mit jeder der betroffenen Schritt-Aufgabe `id` verbunden ist.
|
||||
|
||||
### Wie man das Skript ausführt
|
||||
|
||||
1. Wechsle in das Verzeichnis des Projekts.
|
||||
2. Führe den folgenden npm-Befehl aus:
|
||||
|
||||
```bash
|
||||
npm run reorder-steps
|
||||
```
|
||||
54
docs/i18n/german/how-to-work-on-the-docs-theme.md
Normal file
54
docs/i18n/german/how-to-work-on-the-docs-theme.md
Normal file
@ -0,0 +1,54 @@
|
||||
# So arbeitest du an dem Dokumentations-Theme
|
||||
|
||||
> [!NOTE] Eine kurze Erinnerung daran, dass du für die Arbeit an den Inhalten für die Dokumentationsseite nichts einrichten musst.
|
||||
>
|
||||
> Um an den Mitwirkungsrichtlinien zu arbeiten, kannst du Dateien im `docs`-Verzeichnis [hier verfügbar](https://github.com/freeCodeCamp/freeCodeCamp/tree/main/docs) bearbeiten oder hinzufügen. Wenn deine Änderungen zusammengeführt ("merged") werden, werden sie automatisch auf der Dokumentationsseite zur Verfügung gestellt.
|
||||
|
||||
## Struktur der Dokumentations-Website
|
||||
|
||||
Die Seite wird mit [`docsify`](https://docsify.js.org) erstellt und über GitHub Pages bereitgestellt.
|
||||
|
||||
Normalerweise musst du keine Änderungen an der Konfiguration vornehmen oder die Website lokal erstellen. Falls es dich interessiert, so funktioniert es:
|
||||
|
||||
- Der Quelltext der Homepage ist in [`docs/index.html`](index.html) zu finden.
|
||||
- Wir stellen diese Datei als SPA (Single Page Application) mit `docsify` und GitHub Pages bereit.
|
||||
- Das `docsify`-Skript generiert bei Bedarf den Inhalt der `markdown`-Dateien im `docs`-Verzeichnis.
|
||||
- Die Homepage wird aus der [`_coverpage.md`](_coverpage.md) erstellt.
|
||||
- die Navigation in der Seitenleiste wird aus [`_sidebar.md`](_sidebar.md) generiert.
|
||||
|
||||
## Lokale Bereitstellung der Dokumentations-Website
|
||||
|
||||
FreeCodecamp klonen:
|
||||
|
||||
```console
|
||||
git clone https://github.com/freeCodeCamp/freeCodeCamp.git
|
||||
docsify serve docs
|
||||
```
|
||||
|
||||
`docsify` installieren:
|
||||
|
||||
```console
|
||||
npm install -g docsify
|
||||
```
|
||||
|
||||
und das Verzeichnis `/docs` bereitstellen
|
||||
|
||||
```console
|
||||
docsify serve docs
|
||||
```
|
||||
|
||||
Wenn du freeCodeCamp lokal installiert hast (siehe Anleitung für die lokale Installation), bündeln wir das CLI mit den Entwicklungswerkzeugen, sodass du die unten aufgeführten Befehle bei Bedarf vom Stammverzeichnis des Repos ausführen kannst:
|
||||
|
||||
### Nur die Dokumentationswebsite bereitstellen und starten
|
||||
|
||||
```console
|
||||
npm run docs:serve
|
||||
```
|
||||
|
||||
### Betreibe die Dokumentationswebsite neben dem freeCodeCamp lokal:
|
||||
|
||||
```console
|
||||
npm run develop
|
||||
```
|
||||
|
||||
> Die Dokumentationswebsite sollte unter <http://localhost:3200> zu finden sein
|
||||
100
docs/i18n/german/how-to-work-on-the-news-theme.md
Normal file
100
docs/i18n/german/how-to-work-on-the-news-theme.md
Normal file
@ -0,0 +1,100 @@
|
||||
# Wie man am FreeCodeCamp.orgs Entwickler-News-Theme arbeitet
|
||||
|
||||
Die Entwicklernews, auch bekannt als [`/news`](https://www.freecodecamp.org/news) Seite, wird mit [Ghost](https://ghost.org/) betrieben. Wir verwenden ein individuelles Theme für das Erscheinungsbild der Website. Der Quellcode des Themes ist hier verfügbar: <https://github.com/freeCodeCamp/news-theme>.
|
||||
|
||||
## Das Theme
|
||||
|
||||
Ghost verwendet eine einfache Templating-Sprache namens [Handlebars](http://handlebarsjs.com/) für seine Themes. Das Theme, das auf `/news` verwendet wird, basiert auf dem Standard-Theme [casper](https://github.com/TryGhost/Casper).
|
||||
|
||||
Das Standard-Theme ist ziemlich ausführlich kommentiert, so dass es relativ einfach sein sollte, durch Lesen des Codes und der Kommentare herauszufinden, was vor sich geht. Wenn du dich mit der Funktionsweise vertraut gemacht hast, findest du in Ghost auch eine vollständige [Theme-API-Dokumentation](https://themes.ghost.org), in der alle möglichen Handlebars-Helfer und Vorlagen erklärt werden.
|
||||
|
||||
**Die Hauptdateien sind:**
|
||||
|
||||
- `default.hbs` - Die Hauptvorlagen-Datei
|
||||
- `index.hbs` - Wird für die Startseite verwendet
|
||||
- `post.hbs` - Wird für einzelne Beiträge (posts) verwendet
|
||||
- `page.hbs` - Wird für einzelne Seiten verwendet
|
||||
- `tag.hbs` - Wird für Tag-Archive verwendet
|
||||
- `author.hbs` - Wird für Autorenarchive verwendet
|
||||
|
||||
Ein wirklich toller Trick ist, dass du auch benutzerdefinierte, einmalige Vorlagen erstellen kannst, indem du einfach den Slug einer Seite in eine Vorlagendatei einfügst. Zum Beispiel:
|
||||
|
||||
- `page-about.hbs` - Benutzerdefinierte Vorlage für die `/about/` Seite
|
||||
- `tag-news.hbs` - Benutzerdefinierte Vorlage für `/tag/news/` Archiv
|
||||
- `author-ali.hbs` - Benutzerdefinierte Vorlage für `/author/ali/` Archiv
|
||||
|
||||
## Entwicklung
|
||||
|
||||
1. Installiere Ghost lokal.
|
||||
|
||||
```sh
|
||||
npm install -g ghost-cli@latest
|
||||
mkdir ghost-local-site
|
||||
cd ghost-local-site
|
||||
```
|
||||
|
||||
```sh
|
||||
ghost install local
|
||||
ghost start
|
||||
```
|
||||
|
||||
> Hinweis: Derzeit verwendet freeCodeCamp die Ghost-Version `2.9.0`, also stelle sicher, dass du eine höhere Version verwendest.
|
||||
|
||||
Achte darauf, dass du die `ghost`-Befehle aus dem `ghost-local-site`-Verzeichnis ausführst. Folge den zusätzlichen Anweisungen in [der offiziellen Dokumentation von Ghost](https://docs.ghost.org), wenn du mit der Benutzeroberfläche nicht vertraut bist.
|
||||
|
||||
2. Forke und klone das Repository in deinem Theme-Verzeichnis (ersetze `YOUR_USERNAME` durch deinen GitHub Benutzernamen):
|
||||
|
||||
```sh
|
||||
cd content/themes/
|
||||
git clone https://github.com/YOUR_USERNAME/news-theme.git
|
||||
```
|
||||
|
||||
3. Stelle sicher, dass du alle Voraussetzungen erfüllst.
|
||||
|
||||
Die Stile des Themes werden mit Gulp/PostCSS kompiliert, um zukünftige CSS-Spezifikationen zu erfüllen. Du benötigst [Node.js](https://nodejs.org/). Stelle sicher, dass deine Node.js-Version mit `ghost` kompatibel ist.
|
||||
|
||||
4. Abhängigkeiten (Dependencies) installieren und das Theme entwickeln
|
||||
|
||||
```sh
|
||||
npm ci
|
||||
npm run develop
|
||||
```
|
||||
|
||||
5. Jetzt kannst du `/assets/css/`-Dateien bearbeiten, die automatisch zu `/assets/built/` kompiliert werden.
|
||||
|
||||
6. Zugriff auf die Entwicklungsseite.
|
||||
|
||||
a. Gib `http://localhost:2368/ghost/` in deine Adressleiste ein. Fahre mit dem Setup fort, zu dem du auf der Seite aufgefordert wirst (wenn du Ghost zum ersten Mal ausführst).
|
||||
|
||||
b. _(Einmalig, während des Setups)_ Starte Ghost einmal an einem separaten Terminal neu, um sicherzustellen, dass das Theme verfügbar ist.
|
||||
|
||||
```sh
|
||||
cd ghost-local-site
|
||||
ghost restart
|
||||
```
|
||||
|
||||
c. _(Einmalig, während des Setups)_ Wenn du das getan hast, gehst du auf `http://localhost:2368/ghost/#/settings/design` und scrollst bis zum Ende. Stelle sicher, dass du auf `freecodecamp-news-theme` aktivieren klickst.
|
||||
|
||||
7. Zippe den endgültigen Code und erstelle einen Pull-Request
|
||||
|
||||
Die `zip` Gulp-Aufgabe verpackt die Themedateien in `dist/<theme-name>.zip`, die wir dann auf die Produktionsseite hochladen können.
|
||||
|
||||
Wenn du einen PR erstellst, stelle bitte sicher, dass du das folgende Skript ausgeführt hast, bevor du den Code committest und einen PR sendest.
|
||||
|
||||
```sh
|
||||
npm run zip
|
||||
```
|
||||
|
||||
## Andere Referenzen und Ressourcen
|
||||
|
||||
### Verwendete PostCSS-Funktionen
|
||||
|
||||
- Autoprefixer - Mach dir keine Gedanken über das Schreiben von Browser-Präfixen, das wird alles automatisch erledigt, mit Unterstützung für die letzten 2 Hauptversionen eines jeden Browsers.
|
||||
- Variablen - Einfache reine CSS-Variablen
|
||||
- [Farbfunktion](https://github.com/postcss/postcss-color-function)
|
||||
|
||||
### SVG-Symbole
|
||||
|
||||
Das Theme verwendet Inline-SVG-Symbole, die über Partials von Handlebars eingebunden werden. Du kannst alle Symbole (Icons) innerhalb von `/partials/icons` finden. Um ein Icon zu verwenden, gib einfach den Namen der entsprechenden Datei an, z. B. Um das SVG-Symbol in `/partials/icons/rss.hbs` einzubinden - verwende `{{> "icons/rss"}}`.
|
||||
|
||||
Du kannst deine eigenen SVG-Icons auf dieselbe Art und Weise hinzufügen.
|
||||
138
docs/i18n/german/how-to-work-on-tutorials-that-use-coderoad.md
Normal file
138
docs/i18n/german/how-to-work-on-tutorials-that-use-coderoad.md
Normal file
@ -0,0 +1,138 @@
|
||||
Diese Seite beschreibt, wie du zu den freeCodeCamp-Tutorials und -Projekten beitragen kannst, die mit der CodeRoad VS Code-Erweiterung durchgeführt werden.
|
||||
|
||||
## Wie die Tutorials funktionieren
|
||||
|
||||
Die freeCodeCamp-Tutorials, die CodeRoad verwenden, haben jeweils ihr eigenes Repo unter der freeCodeCamp GitHub-Organisation. Sie beginnen alle mit `learn-`. Zum Beispiel: `https://github.com/freeCodeCamp/learn-bash-by-building-a-boilerplate/`.
|
||||
|
||||
Jedes Tutorial-Repo hat einen `main`-Branch und einen „Version“-Branch, z.B. `v1.0.0`.
|
||||
|
||||
Die beiden wichtigsten Dateien im `main`-Branch sind `TUTORIAL.md` und `coderoad.yaml`. `TUTORIAL.md` enthält alle Anweisungen, Hinweise, Titel und so weiter für das Tutorial. `coderoad.yaml` enthält Anweisungen für CodeRoad, z.B. welche Befehle wann ausgeführt werden sollen, welche Dateien auf Änderungen zu beobachten sind und welcher Versionsbranch für die Schritte zu verwenden ist.
|
||||
|
||||
Der „Version“-Branch enthält die Commits, die bei jedem Schritt eines Tutorials geladen werden. Die Commit-Nachrichten für diesen Branch müssen präzise sein. Der erste Commit benötigt `INIT` für seine Nachricht und enthält alle Dateien, die vor der ersten Lektion geladen werden sollen.
|
||||
|
||||
Nachfolgende Commit-Nachrichten müssen mit der Schrittnummer in `TUTORIAL.md` aus dem `main`-Branch übereinstimmen. Zum Beispiel wird der Commit mit der Nachricht `10.1` geladen, wenn ein Benutzer zum Schritt `10.1` geht.
|
||||
|
||||
Um Änderungen an den Commits in einem Versionsbranch vorzunehmen, musst du die Commits, die du ändern willst, rebasen und bearbeiten. Dadurch wird die Git-Historie umgeschrieben, sodass wir keine PRs für diese Art von Branch akzeptieren können. Sobald ein Versionsbranch im freeCodeCamp-Repository vorhanden ist, sollte er sich nicht mehr ändern.
|
||||
|
||||
> [!WARNING]
|
||||
>
|
||||
> Nimm niemals Änderungen an einem Versionsbranch vor, der sich in einem der freeCodeCamp-Repos befindet. Erstelle immer einen Neuen.
|
||||
|
||||
## Wie du dich beteiligen kannst
|
||||
|
||||
### Voraussetzungen
|
||||
|
||||
Installiere die [CodeRoad CLI Tools](https://www.npmjs.com/package/@coderoad/cli) mit `npm install -g @coderoad/cli`.
|
||||
|
||||
Es gab einige Probleme mit der neuesten Version. Wenn `coderoad --version` nach der Installation nicht funktioniert, mache ein Downgrade auf `0.7.0` mit `npm install -g @coderoad/cli@0.7.0`.
|
||||
|
||||
### Arbeiten an `main`
|
||||
|
||||
Diese Anleitung ist für PRs, die nur kleine Änderungen an `main` zu **bestehenden Lektionen** vornehmen. Dabei handelt es sich hauptsächlich um Änderungen oder Korrekturen von Tippfehlern, Grammatik, Hinweisen und Anleitungen in der Datei `TUTORIAL.md`.
|
||||
|
||||
Für alles andere, einschließlich des Hinzufügens oder Löschens von Lektionen, befolge den [Leitfaden zum Arbeiten an einem Versionsbranch](#working-on-version-branch). Du musst dafür keinen neuen Versionsbranch erstellen - du kannst einen PR erstellen, indem du den Anweisungen unten folgst.
|
||||
|
||||
> [!NOTE]
|
||||
>
|
||||
> Diese Änderungen werden den bestehenden Versionsbranch verwenden. Wenn sie besonders wichtig sind, kannst du sie gerne in die `CHANGELOG.md` aufnehmen. In den meisten Fällen sollte eine gute Commit-Nachricht ausreichen.
|
||||
|
||||
Du musst die Datei `tutorial.json` nie direkt ändern. Diese wird mit den CLI-Tools erstellt.
|
||||
|
||||
Wenn du nur geringfügige Änderungen vornimmst, wie z. B. das Ausbessern eines Schreib- oder Grammatikfehlers, musst du deine Änderungen nicht testen.
|
||||
|
||||
Befolge diese Anweisungen, um einen PR zu erstellen. Beachte dabei, dass die Anweisungen normalerweise die Lektionen um sie herum als Kontext verwenden:
|
||||
|
||||
- Erstelle eine Kopie des neuesten Versionsbranch mit `git branch vX.X.X upstream/vX.X.X` - du musst diesen Branch nicht auschecken, er muss nur existieren.
|
||||
- Erstelle einen neuen Branch von `main` und checke ihn aus.
|
||||
- Mache deine Änderungen und führe einen **Commit** durch. Zur Erinnerung: Du musst nichts in der Datei `tutorial.json` ändern. Wahrscheinlich musst du nur Änderungen an der `TUTORIAL.md` vornehmen
|
||||
- Führe `coderoad build` aus, um die Datei `tutorial.json` neu zu erstellen
|
||||
- Übertrage deine Änderungen mit `update json` als Nachricht
|
||||
- Erstelle einen PR
|
||||
|
||||
### Änderungen an `main` testen
|
||||
|
||||
Wenn du deine Änderungen an `main` nach den obigen Anweisungen testen willst, befolge diese Anweisungen:
|
||||
|
||||
- Befolge die Anweisungen auf dem [rdb-alpha Repo](https://github.com/freeCodeCamp/rdb-alpha), um einen Container zu starten
|
||||
- Starte das Tutorial mit der `tutorial.json` Datei auf dem neuen Branch
|
||||
|
||||
### Überprüfen von PRs für `main`
|
||||
|
||||
Wenn du einen PR überprüfst, der nur `main` ändert und dabei wie oben beschrieben didaktische oder grammatikalische Probleme behandelt, sollten die Änderungen in `TUTORIAL.md` mit den Änderungen in `tutorial.json` übereinstimmen.
|
||||
|
||||
Die Datei `tutorial.json` sollte keine Änderungen an Commit-Hashes oder Step/Level-Ids enthalten. Start- oder Level-Befehle oder Datei-Überwachungen sollten wahrscheinlich auch nicht geändert werden. Es gibt Ausnahmen, wenn es ein Problem mit einer Stufe gibt, aber die sollten mit mehr Vorsicht behandelt werden.
|
||||
|
||||
Denke auch daran, dass die Anleitungen in der Regel die Lektionen um sie herum als Kontext verwenden, also achte darauf, dass sie sinnvoll sind.
|
||||
|
||||
### Arbeiten an einem Versionsbranch
|
||||
|
||||
> [!WARNING]
|
||||
>
|
||||
> Zur Erinnerung: Nimm niemals Änderungen an einem Versionsbranch vor, der sich in einem der freeCodeCamp-Repos befindet. Erstelle immer einen Neuen.
|
||||
|
||||
Es gibt keine einfache Möglichkeit, genau zu sehen, was sich zwischen den Versionsbranches geändert hat, da die Git-Historie neu geschrieben wird. Die Verwendung neuer Versionsbranches muss sorgfältig abgewogen und getestet werden.
|
||||
|
||||
Diese Anweisungen gelten für alle Änderungen in einem "Versions"-Branch, wie z. B. Tests, Testtexte, Zurücksetzen von Dateien, Hinzufügen und Löschen von Schritten und vieles mehr.
|
||||
|
||||
Befolge diese Anweisungen, um eine neue Version zu erstellen:
|
||||
|
||||
- Checke den **letzten** Versionsbranch mit `git checkout -b vX.X.X upstream/vX.X.X` aus
|
||||
- Erstelle einen neuen Branch davon, indem du die Version mit `git checkout -b vX.X.Y` erhöhst
|
||||
- Nimm deine Änderungen an dem Versionsbranch vor. Weitere Informationen zur Arbeit mit Tutorials findest du in der [CodeRoad Dokumentation](https://coderoad.github.io/docs/edit-tutorial)
|
||||
- Schiebe den neuen Branch zu deinem Fork mit `git push -u origin vX.X.Y`
|
||||
- Schau dir den `main`-Branch an
|
||||
- Erstelle einen neuen Branch von `main`. z.B. `feat/version-X.X.Y`
|
||||
- Ändere die `uri` in `coderoad.yaml` zu deinem Fork des Repos. So können du und die Prüfer sie testen, bevor sie in das freeCodeCamp-Repository gestellt wird. Ändere die Version auf den neuen Branch an den beiden Stellen der Datei. Füge deine Änderungen für die neue Version in die `CHANGELOG.md` ein. Nimm alle anderen Änderungen vor, die du benötigst.
|
||||
- Bestätige (Commit) deine Änderungen mit der Nachricht `Feat: Release Version X.X.Y - <optionale Beschreibung>`
|
||||
- Starte `coderoad build`, um eine neue `tutorial.json`-Datei zu erstellen
|
||||
- Füge die Datei hinzu und übertrage sie
|
||||
- Schiebe die Änderungen in deinen Fork
|
||||
- Teste deine Änderungen gemäß der [Testanweisungen unten](#testing-changes-to-a-version-branch). Nimm weitere Änderungen vor und übertrage sie, wie du es soeben getan hast, oder befolge den Rest der Anweisungen, wenn du zufrieden bist
|
||||
- Erstelle einen PR für `main` mit deinem neuen `feat/version-X.X.Y`-Branch. Gib ihm einen Titel wie `Version X.X.Y ready for review`. Dies wird nicht zusammengeführt (merged), sondern dient nur dazu, die Prüfer wissen zu lassen, dass eine neue Version bereitsteht
|
||||
- Danach werden deine Änderungen überprüft
|
||||
|
||||
### Änderungen an einem Versionsbranch testen
|
||||
|
||||
- Befolge die Anweisungen auf dem [rdb-alpha Repo](https://github.com/freeCodeCamp/rdb-alpha), um einen Container zu starten
|
||||
- Starte das Tutorial mit der Datei `tutorial.json` in dem Fork, in dem sich die Änderungen befinden. Achte darauf, dass du die Datei im `feat: Version-X.X.Y`-Branch verwendest und nicht im `main`-Branch
|
||||
|
||||
### Eine neue Version pushen
|
||||
|
||||
Bevor du eine neue Version veröffentlichst, schau dir den neuen `feat/version-vX.X.Y`-Branch (wird mit `main` zusammengeführt) auf dem Fork des Benutzers an. Vergewissere dich, dass die Datei `CHANGELOG.md` um die neuen Änderungen ergänzt wurde und dass die Version an den beiden Stellen der `coderoad.yaml` mit dem neuen Versionsbranch übereinstimmt.
|
||||
|
||||
Wenn du Schreibzugriff auf das freeCodeCamp-Repository hast, die Dateien `CHANGELOG` und `coderoad.yaml` überprüft hast, die Änderungen anhand der obigen Anweisungen getestet hast und eine neue Version eines Tutorials pushen möchtest:
|
||||
|
||||
> [!WARNING]
|
||||
>
|
||||
> Zur Erinnerung: Nimm niemals Änderungen an einem Versionsbranch vor, der sich in einem der freeCodeCamp-Repos befindet. Erstelle immer einen Neuen.
|
||||
|
||||
- Wenn du keinen Remote-Zugang zu dem Ort hast, an dem die neuen Änderungen existieren, erstelle einen Remote-Zugang zum Fork des Benutzers mit `git remote add <users_fork>`
|
||||
- Lösche alle **lokalen** Branches, die den gleichen Namen haben wie die neuen Branches. Wahrscheinlich heißen sie entweder `vX.X.Y` oder `feat/version-X.X.Y`
|
||||
- Checke den neuen Versionsbranch mit `git checkout -b vX.X.Y <remote>/vX.X.Y` aus
|
||||
- Schiebe den neuen Versionszweig mit `git push -u upstream/vX.X.Y` in das freeCodeCamp Repo. Du musst den neuen Branch pushen, bevor du `main` mit der neuen `tutorial.json`-Datei aktualisierst
|
||||
- Checke den Benutzerbranch aus, der mit `main` zusammengeführt werden soll, mit `git checkout -b feat/version-X.X.Y <remote>/feat/version-X.X.Y`
|
||||
- Ändere die `uri` in `coderoad.yaml` zurück auf das freeCodeCamp Repo
|
||||
- Füge die Änderungen hinzu und übertrage sie
|
||||
- Starte `coderoad build`, um die neue `tutorial.json`-Datei zu erstellen
|
||||
- Füge die Datei hinzu und übertrage sie
|
||||
- Schiebe die Änderungen in deinen Fork mit `git push -u origin/feat/version-X.X.Y`
|
||||
- Erstelle einen PR zu `main` auf dem freeCodeCamp Repo
|
||||
- Wenn du zufrieden bist, füge es zusammen oder lass es und bitte um eine Überprüfung von jemandem
|
||||
- Nachdem der PR zusammengeführt wurde, öffne das Tutorial, indem du den Anweisungen im [rdb-alpha repo](https://github.com/freeCodeCamp/rdb-alpha) folgst, um sicherzustellen, dass es richtig geladen wird und du einige Schritte durchlaufen kannst
|
||||
- Wenn es bereits PRs für diese Version gibt, schließe sie
|
||||
|
||||
### Wie du zu einer früheren Version zurückkehrst
|
||||
|
||||
- Erstelle einen neuen Branch vom neuesten `main` mit `git checkout -b revert/to-version-X.X.X`
|
||||
- Mach alle Commits in diesem Branch rückgängig, bis einschließlich des Commits der Version, die auf die Version folgt, zu der du zurückkehren willst. Du könntest zum Beispiel Commits haben, die wie folgt aussehen:
|
||||
|
||||
```
|
||||
fix: typo
|
||||
release: version 1.0.1
|
||||
fix: typo
|
||||
release: version 1.0.0
|
||||
```
|
||||
|
||||
Wenn du zu v1.0.0 zurückkehren willst, nimm alle Commits ab `Release: Version 1.0.1` und danach zurück
|
||||
|
||||
- Erstelle einen PR. Gib ihm einen Titel wie `revert: to version X.X.X`
|
||||
43
docs/i18n/german/index.md
Normal file
43
docs/i18n/german/index.md
Normal file
@ -0,0 +1,43 @@
|
||||
Die [freeCodeCamp.org](https://freecodecamp.org)-Community ist dank tausender freundlicher Freiwilliger wie dir möglich. Wenn Du deine Zeit und dein Fachwissen einbringen möchtest, würden wir uns freuen, dich an Bord begrüßen zu dürfen.
|
||||
|
||||
> [!HINWEIS] Bevor Sie fortfahren, nehmen Sie sich bitte eine kurze 2 Minuten Zeit, um unseren [Code of Conduct](https://www.freecodecamp.org/code-of-conduct) zu lesen. Wir setzen Ihn in unserer Community strikt durch, damit das Mitwirken bei freeCodeCamp.org für alle eine sichere, inklusive Erfahrung ist.
|
||||
|
||||
Du bist herzlich eingeladen, Inhalte für unseren [Studienplan](#curriculum) zu erstellen, zu aktualisieren und Fehler zu beheben. Du kannst uns helfen, Fehler in der [Lernplattform](#learning-platform) von freeCodeCamp.org zu beheben, oder [uns helfen, freeCodeCamp.org in verschiedene Weltsprachen zu übersetzen](#translations).
|
||||
|
||||
Wir beantworten die häufigsten Fragen zum Thema Mithilfe [ in unseren FAQ für Helfer](FAQ.md).
|
||||
|
||||
Fröhliches Mitmachen.
|
||||
|
||||
---
|
||||
|
||||
## Studienplan
|
||||
|
||||
Unser Studienplan wird von der weltweiten freeCodeCamp-Community zusammengestellt. Auf diese Weise können wir das Fachwissen von Freiwilligen wie dir einfließen lassen.
|
||||
|
||||
Du kannst helfen, den Studienplan zu erweitern und zu verbessern. Du kannst auch die User Stories des Projekts aktualisieren, um die Konzepte besser zu erklären. Und du kannst unsere automatisierten Tests verbessern, damit wir den Code der Teilnehmer/innen noch genauer testen können.
|
||||
|
||||
**Wenn du daran interessiert bist, unseren Studienplan zu verbessern, erfährst du hier [wie du zum Studienplan beitragen kannst](how-to-work-on-coding-challenges.md).**
|
||||
|
||||
## Übersetzungen
|
||||
|
||||
Wir lokalisieren freeCodeCamp.org in die wichtigsten Sprachen der Welt.
|
||||
|
||||
Zertifizierungen gibt es bereits in einigen wichtigen Weltsprachen wie [Chinesisch (中文)](https://chinese.freecodecamp.org/learn), [Spanisch (Español)](https://www.freecodecamp.org/espanol/learn/), [Italienisch (Italiano)](https://www.freecodecamp.org/espanol/learn/), [Portugiesisch (Português)](https://www.freecodecamp.org/espanol/learn/). Wir ermutigen dich, die [Ankündigung hier](https://www.freecodecamp.org/news/world-language-translation-effort) zu lesen und sie mit deinen Freunden zu teilen, um sie dafür zu begeistern.
|
||||
|
||||
**Wenn du daran interessiert bist, zu übersetzen, findest du hier [eine Anleitung zum Übersetzen der freeCodeCamp-Ressourcen](how-to-translate-files.md).**
|
||||
|
||||
## Lernplattform
|
||||
|
||||
Unsere Lernplattform läuft auf einem modernen JavaScript-Stack. Es verwendet verschiedene Komponenten, Tools und Bibliotheken. Dazu gehören Node.js, MongoDB, OAuth 2.0, React, Gatsby, Webpack und mehr.
|
||||
|
||||
Im Großen und Ganzen haben wir einen Node.js-basierten API-Server, eine Reihe von React-basierten Client-Anwendungen, Testskripte, um die von Teilnehmer/innen eingereichten Studienplanprojekten zu bewerten, und einiges mehr. Wenn du einen produktiven Beitrag zur Lernplattform leisten willst, empfehlen wir dir, dich mit diesen Tools vertraut zu machen.
|
||||
|
||||
Wenn du uns helfen willst, unsere Codebasis zu verbessern...
|
||||
|
||||
**kannst du entweder Gitpod verwenden, eine kostenlose Online-Entwicklungsumgebung, die eine fertige Entwicklungsumgebung für das freeCodeCamp in deinem Browser startet.**
|
||||
|
||||
[](https://gitpod.io/#https://github.com/freeCodeCamp/freeCodeCamp)
|
||||
|
||||
Oder du kannst...
|
||||
|
||||
**[freeCodeCamp lokal](how-to-setup-freecodecamp-locally.md) auf deinem Rechner einrichten.**
|
||||
539
docs/i18n/german/moderator-handbook.md
Normal file
539
docs/i18n/german/moderator-handbook.md
Normal file
@ -0,0 +1,539 @@
|
||||
# Das offizielle freeCodeCamp Moderator Handbuch
|
||||
|
||||
Dieses Handbuch hilft dir, verschiedene Orte in unserer Community zu moderieren. Dazu gehören Unterhaltungen und Interaktionen in Issues & Pull-Request-Threads auf GitHub, das Community-Forum, die Chatrooms und andere offizielle Communities, die wir pflegen.
|
||||
|
||||
> [!NOTE] Alle freeCodeCamp-Moderatoren sind Community-weite Moderatoren. Das bedeutet, dass wir dir zutrauen, jeden dieser Orte zu beaufsichtigen.
|
||||
|
||||
Du kannst auf jeder der Plattformen, die dich am meisten interessieren, als Moderator/in tätig sein. Einige Moderatoren helfen nur auf GitHub, während andere nur im Forum helfen. Einige Moderatoren sind überall aktiv.
|
||||
|
||||
Unterm Strich wollen wir, dass es dir Spaß macht, Moderator/in zu sein, und dass du deine knappe Zeit in Dinge investierst, die dich interessieren.
|
||||
|
||||
> "Mit großer Macht kommt große Verantwortung" - Uncle Ben
|
||||
|
||||
Als Moderator/in ist das Temperament wichtiger als die technischen Fähigkeiten.
|
||||
|
||||
Hör zu. Sei hilfsbereit. Missbrauche deine Macht nicht.
|
||||
|
||||
Das freeCodeCamp ist eine inklusive Community, und das soll auch so bleiben.
|
||||
|
||||
Wir haben einen einzigen Verhaltenskodex, der für unsere gesamte Community gilt. Je weniger Regeln, desto einfacher ist es, sich sie zu merken. Du kannst die Regeln [hier](https://code-of-conduct.freecodecamp.org) lesen und sie dir einprägen.
|
||||
|
||||
> [!NOTE] Als Moderator/in würden wir dich einem oder mehreren Teams auf GitHub, unseren Community-Foren & Chats hinzufügen. Wenn du keinen Zugang zu einer Plattform hast, die du gerne moderieren würdest, wende dich bitte [an einen unserer Mitarbeiter (Staff)](FAQ.md#additional-assistance).
|
||||
|
||||
## GitHub moderieren
|
||||
|
||||
Auf GitHub haben Moderatoren zwei Hauptaufgaben:
|
||||
|
||||
1. Bearbeitung und Beantwortung von Problemen
|
||||
2. Prüfen und Zusammenführen von Pull-Requests (auch bekannt als QA).
|
||||
|
||||
### GitHub Issues moderieren
|
||||
|
||||
Wir nutzen unser Haupt-Repository [`freeCodeCamp/freeCodeCamp`](https://github.com/freeCodeCamp/freeCodeCamp/issues) als gemeinsamen Issue Tracker für alle unsere Repositories. Jeden Tag bekommen wir neue Issues, die alle bearbeitet, gekennzeichnet und adressiert werden müssen. Das ist auch ein guter Ort, um mit Beiträgen zur Open-Source-Codebasis anzufangen.
|
||||
|
||||
#### Triage von Issues
|
||||
|
||||
[Triaging](https://en.wikipedia.org/wiki/Triage) ist ein Prozess, bei dem die Aufmerksamkeit für jeden neuen Issue Report priorisiert wird. Wir haben eine umfangreiche Liste von Labels, die wir verwenden, um die Priorität, Kategorie, Status und Umfang jedes Problems zu kennzeichnen.
|
||||
|
||||
Du kannst uns helfen, die Issues zu ordnen und einzuteilen, indem du Labels aus [dieser Liste](https://github.com/freeCodeCamp/freeCodeCamp/labels) anwendest. Normalerweise ist neben dem Label eine Beschreibung verfügbar, in der die Bedeutung erläutert wird.
|
||||
|
||||
Bitte achte besonders auf die Label `"help wanted"` und `"first timers only"`. Diese sollen zu Threads hinzugefügt werden, von denen du denkst, dass sie für potenzielle Mitwirkende geöffnet werden können, um einen Pull-Request zu erstellen.
|
||||
|
||||
Das `"first timer only"` Label sollte auf ein triviales Problem (z. B. einen Tippfehler) angewendet werden und zusätzliche Informationen enthalten. Du kannst diese [Antwortvorlage](moderator-handbook.md#first-timer-only-issues) für die Triage verwenden.
|
||||
|
||||
#### Schließen veralteter, inaktiver Issues und Pull-Requests
|
||||
|
||||
- Veraltete Issues oder PRs sind solche, die seit 21 Tagen (3 Wochen nach der letzten Aktivität) keine Aktivität vom Autor erfahren haben, aber erst nachdem ein Moderator weitere Informationen/Änderungen angefordert hat.
|
||||
|
||||
- Aktivität ist definiert als: Kommentare, die eine Aktualisierung der PR und Triages anfordern, wie `status: update needed` Label etc.
|
||||
|
||||
- Wenn der Beitragende um zusätzliche Hilfe oder sogar Zeit bittet, kann das oben Gesagte gelockert und nach einer Antwort erneut überprüft werden. In jedem Fall sollten die Moderatoren nach bestem Wissen und Gewissen den Status der ausstehenden PR klären.
|
||||
|
||||
> [!TIP] Wir empfehlen dir, diese Liste von standardisierten [Antwortvorlagen](moderator-handbook.md#reply-templates) zu verwenden, wenn du Issues bearbeitest.
|
||||
|
||||
### Pull-Requests moderieren
|
||||
|
||||
Pull Requests (PRs) sind die Art und Weise, wie Mitwirkende Änderungen an das freeCodeCamp-Repository übermitteln. Wir müssen eine Qualitätssicherung (QA) für Pull-Requests durchführen, bevor wir entscheiden, ob wir sie zusammenführen, Änderungen beantragen oder schließen.
|
||||
|
||||
#### Arten von Pull Requests
|
||||
|
||||
1. **Bearbeitung der Aufgabeninstruktionen**
|
||||
|
||||
Das sind Änderungen am Text der Aufgaben - der Beschreibung, den Instruktionen oder dem Testtext.
|
||||
|
||||
Du kannst sie auch direkt auf GitHub überprüfen und entscheiden, ob du sie zusammenführen möchtest. Wir müssen hier etwas vorsichtiger sein, denn Millionen von Menschen werden diesem Text begegnen, wenn sie den freeCodeCamp-Studienplan durcharbeiten. Macht der Pull-Request den Text klarer, ohne ihn viel länger zu machen? Sind die Änderungen relevant und nicht übermäßig pedantisch? Denke daran, dass unser Ziel ist, dass die Aufgaben so deutlich und so kurz wie möglich sind. Sie sind nicht der Ort für unklare Details. Die Mitwirkenden könnten versuchen, Links zu Ressourcen zu den Aufgaben hinzuzufügen.
|
||||
|
||||
Mit diesen [Antwortvorlagen](moderator-handbook.md#closing-invalid-pull-requests) kannst du ungültige Pull-Requests schließen und darauf antworten.
|
||||
|
||||
Wenn die Änderung gut aussieht, sorge bitte dafür, dass du eine Genehmigung mit einem "LGTM"-Kommentar hinterlässt. Sobald ein Pull Request mindestens zwei Genehmigungen (einschließlich deiner) von den Moderatoren oder dem Entwicklungsteam erhält, kannst du ihn zusammenführen.
|
||||
|
||||
2. **Bearbeitung des Aufgabencodes**
|
||||
|
||||
Dabei handelt es sich um Änderungen am Code in einer Aufgabe - dem Aufgabenstartcode, der Aufgabenlösung und den Teststrings.
|
||||
|
||||
Diese Pull Requests müssen von GitHub heruntergeladen werden und auf dem eigenen Computer oder Gitpod getestet werden, um sicherzustellen, dass die Tests immer noch mit der aktuellen Lösung bestanden werden können und dass der neue Code keine Fehler einführt.
|
||||
|
||||
Einige Mitwirkende werden versuchen, zusätzliche Tests hinzuzufügen, um spitzfindige Sonderfälle abzudecken. Wir müssen aufpassen, dass wir die Aufgabe nicht zu kompliziert machen. Diese Aufgaben und ihre Tests sollten so einfach und intuitiv wie möglich sein. Abgesehen von den Algorithmusaufgaben und dem Abschnitt zur Interviewvorbereitung sollten die Teilnehmer/innen in der Lage sein, jede Aufgabe innerhalb von etwa 2 Minuten zu lösen.
|
||||
|
||||
Mit diesen [Antwortvorlagen](moderator-handbook.md#closing-invalid-pull-requests) kannst du ungültige Pull-Requests schließen und darauf antworten.
|
||||
|
||||
Wenn die Änderung gut aussieht, sorge bitte dafür, dass du eine Genehmigung mit einem "LGTM"-Kommentar hinterlässt. Sobald ein Pull-Request mindestens zwei Genehmigungen (einschließlich deiner) von den Moderatoren oder dem Entwicklungsteam erhält, kannst du ihn zusammenführen.
|
||||
|
||||
3. **Änderungen der Plattform**
|
||||
|
||||
Diese Code-Bearbeitungen ändern die Funktionalität der freeCodeCamp-Plattform selbst.
|
||||
|
||||
Manchmal versuchen Mitwirkende, Änderungen ohne große Erklärungen vorzunehmen, aber bei Codeänderungen müssen wir sicherstellen, dass es einen echten Bedarf für die Änderung gibt. Diese Pull-Requests sollten auf ein bestehendes GitHub Issue verweisen, in dem die Gründe für die Änderung erläutert werden. Dann kannst du die Pull-Request auf deinem Computer öffnen und sie lokal testen.
|
||||
|
||||
Wenn du das getan hast und die Änderungen gut aussehen, solltest du sie noch nicht zusammenführen. Du kannst den Pull-Request mit "LGTM" kommentieren und dann **"@freeCodeCamp/dev-team"** erwähnen, damit sie einen letzten Blick darauf werfen können.
|
||||
|
||||
4. **Automatisierte PRs (Dependabot)**
|
||||
|
||||
Einige PRs sind automatische Aktualisierungen von Abhängigkeiten, die über eine Integration vorgenommen werden. Du solltest diese PRs nicht zusammenführen oder genehmigen. Ein Mitglied des Entwicklerteams kümmert sich um die Überprüfung und Zusammenführung solcher automatischen PRs.
|
||||
|
||||
#### Wie man Pull-Requests überprüft, zusammenführt oder schließt
|
||||
|
||||
##### Weise dich einem Pull-Request zu:
|
||||
|
||||
Wenn du einen Pull-Request zum Überprüfen auswählst, solltest du dich diesem zunächst selbst zuweisen. Du kannst dies tun, indem du in der rechten Spalte der GitHub-Benutzeroberfläche auf den Link "assign yourself" unter dem Bereich "assignees" klickst.
|
||||
|
||||
Je nachdem, um welche Art von Pull-Request es sich handelt, befolge die entsprechenden Regeln, die zuvor aufgelistet wurden.
|
||||
|
||||
##### Stelle sicher, dass die CI-Prüfungen bestanden werden:
|
||||
|
||||
Vergewissere dich vor dem Zusammenführen eines Pull Requests, dass GitHub alle Prüfungen für die Pull-Requests als bestanden meldet (grüne Häkchen). Wenn du feststellst, dass eine der Prüfungen fehlschlägt, untersuche bitte die Ursache und kläre sie. Führt die Änderung dazu, dass unsere Tests nicht mehr funktionieren? Wird die Seite korrekt aufgebaut, wenn der PR zusammengeführt wird? Diese Kontrollen sind entscheidend für die Stabilität der Plattform.
|
||||
|
||||
> [!WARNING] Das Zusammenführen eines PRs, der die CI/CD-Prüfungen nicht besteht, kann für alle Beteiligten, einschließlich des Entwicklungsteams und der Mitwirkenden, zu Schwierigkeiten führen.
|
||||
|
||||
##### Umgang mit Merge-Konflikten:
|
||||
|
||||
Manchmal kommt es zu einem Merge-Konflikt.
|
||||
|
||||
Das bedeutet, dass ein anderer Pull-Request eine Änderung an demselben Teil der Datei vorgenommen hat. GitHub hat ein Tool, mit dem du diese Merge-Konflikte direkt auf GitHub lösen kannst. Du kannst versuchen, diese Konflikte zu lösen. Benutze einfach dein gutes Urteilsvermögen.
|
||||
|
||||
Die Änderungen des Pull-Requests stehen oben und die des main-Branch unten. Manchmal gibt es dort überflüssige Informationen, die gelöscht werden können. Bevor du fertig bist, stelle sicher, dass du die `<<<<<`, `======` und `>>>>>>` löschst, die Git hinzufügt, um Merge-Konflikte anzuzeigen.
|
||||
|
||||
Wenn du dir unsicher bist, frag bitte einen der anderen Moderatoren oder das Entwicklerteam um Hilfe.
|
||||
|
||||
##### Zusammenführen eines gültigen Pull-Requests:
|
||||
|
||||
Wenn der Pull-Request so aussieht, dass er zusammengeführt werden kann (und keine weiteren Genehmigungen benötigt - denk daran, dass wir mindestens zwei benötigen), kannst du ihn zusammenführen. Achte darauf, dass du die Standardoption **"Squash and Merge"** verwendest. Dadurch werden alle Pull-Request-Commits zu einem einzigen Commit zusammengefasst, wodurch die Git-Historie viel einfacher zu lesen ist.
|
||||
|
||||
> Dann solltest du den Pull-Request kommentieren und dich auf deine persönliche Art und Weise bei dem Mitwirkenden bedanken.
|
||||
|
||||
Wenn der Autor des Pull-Requests zum ersten Mal beiträgt, solltest du ihm auch zu seinem ersten zusammengefassten Pull-Request für das Repository gratulieren. Du kannst in der oberen rechten Ecke des PR-Body nachsehen, ob es sich um einen "first-time" Mitwirkenden handelt. Es wird `First-time contributor` angezeigt, wie unten dargestellt:
|
||||
|
||||
<details>
|
||||
<summary>
|
||||
Badge "First time contributor" für den ersten Beitrag eines Pull-Requests (Screenshot)
|
||||
</summary>
|
||||
|
||||
<br>
|
||||
<img src="https://i.imgur.com/dTQMjGM.png" alt="Abzeichen für den erstmaligen Beitrag zu einem Pull-Requests" />
|
||||
</details>
|
||||
|
||||
Wenn der Pull-Request nicht bereit zum Zusammenführen zu sein scheint, kannst du dem Autor höflich antworten und ihm sagen, was er tun sollte, um ihn fertigzustellen. Wir hoffen, dass sie antworten und ihr Pull-Request bald fertig ist.
|
||||
|
||||
Wenn du eine zweite Meinung zu einem Pull-Request benötigst, hinterlasse deine Kommentare zu dem Pull-Request und füge dann das Label "discussing" zu dem Pull-Request hinzu.
|
||||
|
||||
##### Schließen eines ungültigen Pull-Requests:
|
||||
|
||||
Oft ist ein Pull-Request mit wenig Aufwand verbunden. Das erkennst du in der Regel sofort daran, dass der Mitwirkende sich nicht die Mühe gemacht hat, die Kontrollkästchen in der Pull-Request-Vorlage zu markieren oder einen allgemeinen Pull-Request-Titel wie "made changes" oder "Update index.md" verwendet hat.
|
||||
|
||||
Es gibt auch Situationen, in denen der/die Mitwirkende versucht, einen Link zu seiner/ihrer Website hinzuzufügen, eine von ihm/ihr erstellte Bibliothek einzubinden oder eine unseriöse Bearbeitung vorzunehmen, die niemandem außer ihm/ihr selbst hilft.
|
||||
|
||||
Mit diesen [Antwortvorlagen](moderator-handbook.md#closing-invalid-pull-requests) kannst du ungültige Pull-Requests schließen und darauf antworten.
|
||||
|
||||
#### Weitere Richtlinien für Moderatoren auf GitHub
|
||||
|
||||
Obwohl du Schreibzugriff auf das freeCodeCamp-Repository hast, **solltest du niemals Code direkt in die freeCodeCamp-Repositories pushen**. Der gesamte Code sollte in Form eines Pull-Requests von einem Fork des Repositorys in die Codebasis von freeCodeCamp gelangen.
|
||||
|
||||
Außerdem solltest du niemals deine eigenen PRs akzeptieren. Sie müssen von einem anderen Moderator überprüft werden, genau wie jeder andere PR.
|
||||
|
||||
Wenn du feststellst, dass jemand gegen den [Verhaltenskodex](https://code-of-conduct.freecodecamp.org) auf GitHub verstößt oder Pull-Requests mit bösartigem Inhalt oder Code öffnet, schicke eine E-Mail an `support[at]freecodecamp.org` mit einem Link zu dem betreffenden Pull-Request, damit wir in Erwägung ziehen können, die betreffende Person komplett aus der GitHub-Organisation von freeCodeCamp zu verbannen.
|
||||
|
||||
## Das Forum moderieren
|
||||
|
||||
Als Moderator/in trägst du dazu bei, dass unsere Community ein angenehmer Ort ist, an dem jeder lernen und Hilfe bekommen kann. Du bearbeitest markierte Beiträge und kümmerst dich um Spam, Off-Topic und andere unangemessene Unterhaltungen.
|
||||
|
||||
Sobald du ein Moderator im Forum bist, wirst du blaue Moderatorenhinweise zu Forenmitgliedern sehen, wie z. B. "Dies ist das erste Mal, dass [person] gepostet hat - heißen wir sie in der Community willkommen!" oder "[person] hat schon lange nicht mehr gepostet - heißen wir sie wieder willkommen."
|
||||
|
||||
![Eine blaue Textnachricht mit dem Hinweis "Dies ist das erste Mal, dass [person] gepostet hat - heißen wir sie in der Community willkommen!](https://i.imgur.com/mPmVgzK.png)
|
||||
|
||||
Das sind Gelegenheiten für dich, sie willkommen zu heißen und ihnen das Gefühl zu geben, etwas Besonderes zu sein. Man weiß nie, welche Person, die nur am Rande beteiligt ist, unser nächster Superhelfer wird, der vielen anderen Menschen auf ihrem Weg zum Programmieren hilft. Selbst die kleinste Freundlichkeit kann eine Kaskade von guten Taten auslösen.
|
||||
|
||||
### Lösche Forenbeiträge
|
||||
|
||||
Forum-Moderatoren können Beiträge von Nutzern löschen. Du solltest dies nur in den folgenden Fällen tun:
|
||||
|
||||
1. Jemand hat ein pornografisches oder grafisch gewalttätiges Bild gepostet.
|
||||
2. Jemand hat einen Link oder Code gepostet, der bösartig ist und anderen Teilnehmern, die darauf klicken, schaden könnte.
|
||||
3. Jemand hat einen Thread mit vielen Spam-Nachrichten überflutet.
|
||||
|
||||
### Umgang mit Spam
|
||||
|
||||
Beim ersten Spam-Posting eines Nutzers schickst du ihm eine Nachricht, in der du das Problem erklärst, und entfernst den Link oder das Posting, falls nötig. Hinterlasse eine Notiz im Profil des Nutzers, in der du die von dir ergriffene Maßnahme erklärst. Wenn das Problem weiterhin besteht, sperre den/die Benutzer/in stillschweigend für Beiträge (mit der Stille-Option im Benutzer-Administrationsbereich). Schicke dem Nutzer eine Verwarnung mit dem Verhaltenskodex. Aktiviere das Kästchen in der privaten Nachricht, das angibt, dass deine Nachricht eine "formelle Warnung" ist.
|
||||
|
||||
Als Moderator kannst du im Bereich [staff forum ](https://forum.freecodecamp.org/c/mod-team/4) Fragen stellen und Vorfälle melden.
|
||||
|
||||
### Umgang mit Off-Topic-Gesprächen
|
||||
|
||||
Beiträge oder Themen, die am falschen Ort zu sein scheinen, können neu kategorisiert oder umbenannt werden, was immer angemessen ist.
|
||||
|
||||
In Ausnahmefällen kann es für einen Moderator angemessen sein, eine Diskussion in mehrere Threads aufzuteilen.
|
||||
|
||||
Auch hier gilt: Wenn du Probleme oder Fragen hast, schreibe einen Beitrag mit deinen Aktionen in der Kategorie Staff und markiere einen anderen Moderator, wenn du möchtest, dass er deine Moderationsaktionen überprüft.
|
||||
|
||||
### Minderjährige Nutzer
|
||||
|
||||
Unsere [Nutzungsbedingungen](https://www.freecodecamp.org/terms) verlangen, dass freeCodeCamp-Nutzer mindestens 13 Jahre alt sind. Wenn ein/e Nutzer/in preisgibt, dass er/sie unter 13 Jahre alt ist, schicke ihm/ihr die unten stehende Nachricht und lösche sein/ihr Forumskonto (wenn eine Löschung nicht möglich ist, reicht die Sperrung des Kontos).
|
||||
|
||||
**Schicke eine E-Mail an `support[at]freecodecamp.org`, um auch das freeCodeCamp-Konto des Nutzers zu löschen.**
|
||||
|
||||
```markdown
|
||||
SUBJECT: Users under 13 are not allowed to use the forum per Terms of Service
|
||||
|
||||
It has come to our attention that you are under 13 years of age. Per the [freeCodeCamp terms of service](https://www.freecodecamp.org/news/terms-of-service), you must be at least 13 years old to use the site or the forum. We will be deleting both your freeCodeCamp account and your forum account. This restriction keeps us in compliance with United States laws.
|
||||
|
||||
Please rejoin once you have reached at least 13 years of age.
|
||||
|
||||
Thank you for understanding.
|
||||
```
|
||||
|
||||
## Facebook moderieren
|
||||
|
||||
Wenn du etwas siehst, das gegen unseren [Verhaltenskodex](https://code-of-conduct.freecodecamp.org/) zu verstoßen scheint, solltest du es sofort löschen.
|
||||
|
||||
Manchmal posten Menschen Dinge, die sie für lustig halten. Sie erkennen nicht, dass das, was sie gesagt oder geteilt haben, als beleidigend interpretiert werden könnte. Du solltest solche Beiträge löschen, aber nicht unbedingt die Person verbannen. Hoffentlich begreift der/die NutzerIn, dass das, was er/sie gepostet hat, unangemessen war, denn der Beitrag wurde gelöscht.
|
||||
|
||||
Aber wenn es eine ungeheuerliche Beleidigung ist, welche nicht auf einen kulturellen Unterschied oder einem Missverständnis in der englischen Sprache zurückgeführt werden kann. Dann solltest du in diesem Fall ernsthaft in Erwägung ziehen, das Mitglied aus der Facebook-Gruppe zu sperren.
|
||||
|
||||
## Chat moderieren
|
||||
|
||||
Hier erfährst du, wie die Moderatoren mit Verstößen gegen unseren [Verhaltenskodex](https://code-of-conduct.freecodecamp.org/) auf unserem Chat-Server umgehen:
|
||||
|
||||
1. **Vergewissere dich, dass der/die Nutzer/in die Absicht hatte, gegen den Verhaltenskodex zu verstoßen.**
|
||||
|
||||
Nicht alle Verstöße gegen den Verhaltenskodex waren so beabsichtigt. Ein neuer Teilnehmer könnte eine große Menge an Code posten und um Hilfe bitten, ohne zu wissen, dass dies als Spamming angesehen werden kann. In diesen Fällen kannst du sie einfach bitten, ihren Code mit Diensten wie CodePen oder Pastebin einzufügen.
|
||||
|
||||
2. **Wenn der/die Teilnehmer/in eindeutig und absichtlich gegen den Verhaltenskodex verstößt, wird der/die Moderator/in wie folgt vorgehen:**
|
||||
|
||||
Wirf die beleidigende Person aus dem Chatraum oder schalte sie stumm. Um jemanden hinauszuwerfen oder stumm zu schalten, klickst du mit der linken Maustaste auf sein Profilbild, wählst die drei Punkte und wählst "Remove from room", um ihn hinauszuwerfen, oder "Mute user", um ihn am Senden von Nachrichten zu hindern. Dann berichte eine kurze Zusammenfassung des Ereignisses im Channel #mod-log. Hier ist ein Beispiel dafür, wie eine solche Zusammenfassung aussehen könnte:
|
||||
|
||||
```
|
||||
Kicked: _@username_
|
||||
Reason(s): _Spamming, trolling_
|
||||
Evidence: _One or more links to the offending message(s)_
|
||||
```
|
||||
|
||||
3. **Eine private Diskussion erstellen**
|
||||
|
||||
Es kann Situationen geben, in denen du ein Anliegen mit einem Teilnehmer unter vier Augen besprechen musst. Dies sollte nicht über DMs geschehen, da dies zu Situationen führen kann, in denen du eine Sache behauptest und der Teilnehmer eine andere. Nutze stattdessen die Funktionen des Bots, um eine private Diskussion zu führen:
|
||||
|
||||
- Rufe den Befehl `!fCC private username` auf, wobei `username` der Chat-Benutzername des Teilnehmers ist.
|
||||
- Der Bot erstellt einen neuen Channel und fügt den genannten Camper und alle Moderatoren mit der Rolle `Your Friendly Moderator` hinzu. Obwohl alle Moderatoren zur Transparenz in den Kanal aufgenommen werden, sollte der Moderator, der diesen Befehl aufruft, der einzige sein, der mit dem Teilnehmer interagiert, es sei denn, er bittet um Hilfe.
|
||||
- Wenn die Konversation beendet ist, rufst du den `!fCC close`-Befehl _im privaten Channel_ auf, damit der Bot diesen Channel schließt und löscht.
|
||||
|
||||
4. **Nachrichten löschen**
|
||||
|
||||
Moderatoren können Nachrichten auf unserem Chat-Server löschen. Sie sollten diese Fähigkeit nur in vier ganz bestimmten Situationen nutzen:
|
||||
|
||||
- Jemand hat ein pornografisches oder grafisch gewalttätiges Bild gepostet.
|
||||
|
||||
- Jemand hat einen Link oder Code gepostet, der bösartig ist und anderen Teilnehmern, die darauf klicken, schaden könnte.
|
||||
|
||||
- Jemand hat den Chat mit so vielen Spam-Nachrichten überflutet (meist durch Bots), dass der Chat komplett unbrauchbar ist.
|
||||
|
||||
- Jemand hat eine Werbung und/oder eine selbstdarstellende Nachricht/ein selbstdarstellendes Bild (soziale Medien) gepostet.
|
||||
|
||||
In allen anderen Situationen - auch bei Verstößen gegen den Verhaltenskodex - sollten die Moderatoren die Nachrichten nicht löschen, da sie wichtige historische Aufzeichnungen sind. Wenn du eine Nachricht löschst, solltest du vorher einen Screenshot davon machen! Der Screenshot kann im Channel #mod-log geloggt werden.
|
||||
|
||||
> [!NOTE] Wenn die Nachricht Material enthält, von dem es illegal wäre, einen Screenshot zu machen, kopiere stattdessen den Link der Nachricht und leite ihn an @raisedadead weiter, der ihn an das Team für Vertrauen und Sicherheit von Discord weiterleitet.
|
||||
|
||||
5. **Verwende nicht @all oder @here**
|
||||
|
||||
Verwende unter keinen Umständen @all oder @here! Jede einzelne Person in diesem Chatraum erhält eine Benachrichtigung. In manchen Fällen sind es Zehntausende von Menschen.
|
||||
|
||||
Wenn du möchtest, dass die Leute eine Ankündigung sehen, kannst du sie stattdessen an den Kanal anheften, damit alle sie lesen können.
|
||||
|
||||
6. **Droh nicht mit Maßnahmen**
|
||||
|
||||
Wenn ein/e Teilnehmer/in gegen den Verhaltenskodex verstößt, drohe ihm/ihr nicht mit Maßnahmen des Moderators/der Moderatorin und verwarne ihn/sie nie in der Öffentlichkeit. Sprich stattdessen privat mit ihnen, indem du den Befehl `private` des Bots benutzt. Niemand sonst in diesem Channel muss wissen, dass du die Person gebannt/suspendiert hast. Wenn ein Verstoß eindeutig unbeabsichtigt war und keine Suspendierung oder ein Gespräch unter vier Augen rechtfertigt, solltest du den/die betreffende/n Teilnehmer/in auf sein/ihr Verhalten aufmerksam machen, ohne dass es wie eine Verwarnung wirkt. Zum Beispiel:
|
||||
|
||||
- Der Teilnehmer postet viele Codezeilen und bittet um Hilfe:
|
||||
|
||||
Moderator: @Benutzername Bitte benutze CodePen oder Pastebin, wenn du große Mengen an Code postest.
|
||||
|
||||
- Oder wenn du wirklich erklären musst, warum:
|
||||
|
||||
Moderator: @Benutzername Bitte benutze CodePen oder Pastebin, wenn du große Mengen an Code postest, denn das stört den Chat für alle und könnte laut unserem Verhaltenskodex als Spamming angesehen werden.
|
||||
|
||||
- Für leichte und unbeabsichtigte Verstöße gegen den Verhaltenskodex:
|
||||
|
||||
Moderator: Dies ist eine freundliche Erinnerung an alle, den Verhaltenskodex zu befolgen: https://code-of-conduct.freecodecamp.org/
|
||||
|
||||
7. **Gib nicht damit an, ein Moderator zu sein**
|
||||
|
||||
Sieh dich nicht als über der Community stehend an. Du bist die Community. Und die Community hat dir vertraut, dass du dabei hilfst, etwas Seltenes zu schützen, das wir alle teilen - einen _einladenden_ Ort für neue Entwickler.
|
||||
|
||||
Wenn du damit angibst, Moderator zu sein, fühlen sich die Leute in deiner Nähe vielleicht unwohl, so wie sich die Leute in der Nähe von Polizisten unwohl fühlen, auch wenn sie nichts Unrechtes tun. Das ist einfach die menschliche Natur.
|
||||
|
||||
8. **Widersprich nicht anderen Moderatoren**
|
||||
|
||||
Wenn du mit der Handlung eines Moderators nicht einverstanden bist, sprich mit ihm unter vier Augen oder sprich es im #mod-chat-Kanal an. Setze dich niemals über die Entscheidung eines Moderators hinweg und widerspreche niemals öffentlich den anderen Moderatoren. Führe stattdessen eine sachliche Diskussion im `#mod-chat` und überzeuge den Moderator davon, dass er seinen Bann rückgängig machen oder seinen Standpunkt ändern sollte.
|
||||
|
||||
Denk daran: Wir sind alle im selben Team. Wir wollen die Rolle der Moderatoren würdigen und eine einheitliche Front präsentieren.
|
||||
|
||||
9. **Sprich mit anderen Moderatoren**
|
||||
|
||||
Wir haben einen Raum nur für Moderatoren. Benutze ihn! Wenn du dich mit einer bestimmten Situation unwohl fühlst, bitte andere Moderatoren um Hilfe. Wenn du denkst, dass etwas diskutiert werden sollte, dann tu es. Du bist Teil des Teams, und wir schätzen den Beitrag jedes Teammitglieds! Auch wenn du mit diesen Richtlinien oder dem Verhaltenskodex überhaupt nicht einverstanden bist!
|
||||
|
||||
10. **Vorübergehend inaktiv**
|
||||
|
||||
Wenn du wegen Urlaub, Krankheit oder aus einem anderen Grund eine Weile nicht als Moderator aktiv sein wirst, lass es die anderen im `#mod-chat` Kanal wissen. So wissen wir, ob wir auf dich zählen können, dass du regelmäßig auf dem Server aktiv bist oder nicht.
|
||||
|
||||
## Wie man Moderator wird
|
||||
|
||||
Angenommen, du hilfst den Menschen in deiner Community über einen längeren Zeitraum hinweg. In diesem Fall wird unser Moderatorenteam darauf aufmerksam und einer von ihnen wird dich gegenüber [unseren Mitarbeitern](https://forum.freecodecamp.org/g/Team) als möglichen Moderator erwähnen. Es gibt keine Abkürzungen, um Moderator/in zu werden.
|
||||
|
||||
Wenn du zugelassen wirst, fügen wir dich zu unseren Moderatorenteams auf [GitHub](https://github.com/orgs/freeCodeCamp/teams/moderators), im [Forum](https://forum.freecodecamp.org/g/moderators) und im Chat etc. hinzu.
|
||||
|
||||
> [!NOTE] Für GitHub: Nachdem du als Moderator akzeptiert wurdest, erhältst du eine Einladung zum Github-Repository. Du musst auf [freeCodeCamp GitHub Organisation Invitation](https://github.com/orgs/freeCodeCamp/invitation) gehen, um die Einladung zu akzeptieren.
|
||||
>
|
||||
> Dies ist erforderlich, damit wir dir Schreibzugriff auf einige unserer Repositories geben können.
|
||||
|
||||
## Wie wir inaktive Moderatoren entfernen
|
||||
|
||||
Bitte beachte, dass wir häufig Moderatoren entfernen, von denen wir glauben, dass sie inaktiv sind. Wenn wir das tun, senden wir die folgende Nachricht:
|
||||
|
||||
```markdown
|
||||
This is a standard message notifying you that, since you don't seem to have been an active moderator recently, we're removing you from our Moderator team. We deeply appreciate your help in the past.
|
||||
|
||||
If you think we did this in error, or once you're ready to come back and contribute more, just reply to this message letting me know.
|
||||
```
|
||||
|
||||
## Wie unser Chatraum für Mitwirkende funktioniert
|
||||
|
||||
Jeder ist in dem [Raum für Mitwirkende auf unserem Chat-Server](https://chat.freecodecamp.org/channel/contributors) willkommen. Er ist der Chatraum für Moderatoren und andere Teilnehmer, die auf verschiedene Weise zu unserer Community beitragen, z. B. durch Lerngruppen.
|
||||
|
||||
Wir gehen davon aus, dass Mitwirkende alles in diesem Raum lesen, wo sie direkt mit einem `@Benutzername` erwähnt werden. Alles andere ist freiwillig, aber du kannst gerne alles lesen, was dort gepostet wird, und dich einbringen.
|
||||
|
||||
## Der Umgang mit Anwälten
|
||||
|
||||
Es kann sein, dass du von Organisationen angesprochen wirst, die eine Partnerschaft oder ein Co-Branding mit dem freeCodeCamp anstreben. Sobald du merkst, dass sie das wollen, **hör bitte auf, mit ihnen zu reden** und sag ihnen, sie sollen eine E-Mail an `team[at]freecodecamp.org` schicken.
|
||||
|
||||
Wir bekommen ständig solche Vorschläge, und die Mitarbeiter/innen sind am besten in der Lage zu beurteilen, ob sich eine solche Beziehung für unsere Community lohnt (und das ist sie selten).
|
||||
|
||||
## Umgang mit Anfragen zur (psychischen) Gesundheit
|
||||
|
||||
Es kann sein, dass du auf Situationen triffst, in denen Nutzerinnen und Nutzer medizinischen Rat suchen oder mit psychischen Problemen zu kämpfen haben und nach Unterstützung suchen.
|
||||
|
||||
Grundsätzlich solltest du es vermeiden, über diese Angelegenheiten privat zu sprechen. Sollte die Situation auf das freeCodeCamp zurückfallen, wollen wir das Gespräch bzw. die Gespräche dokumentiert haben. Stelle klar, dass wir keine medizinischen Fachleute sind und dass du die Nutzer/innen ermutigst, sich professionelle Hilfe zu suchen.
|
||||
|
||||
So schwierig es auch manchmal sein kann, vermeide es, irgendwelche Tipps oder Ratschläge zu geben, außer den Nutzer auf professionelle Hilfe zu verweisen!
|
||||
|
||||
Wenn dies auf unserem Chat-Server passiert: Erstelle einen privaten Kanal für den Nutzer und das Mod-Team. Das kannst du mit dem Befehl `private` des Bots machen.
|
||||
|
||||
- Dem Nutzer wird eine gewisse Privatsphäre garantiert
|
||||
- Der öffentliche Chat wir nicht länger unterbrochen
|
||||
- Andere Teammitglieder können einspringen, wenn es dir unangenehm ist, die Situation selbst zu bewältigen
|
||||
|
||||
Hilfreiche URLs:
|
||||
|
||||
http://www.suicide.org/international-suicide-hotlines.html
|
||||
|
||||
## Eine Anmerkung zur Redefreiheit
|
||||
|
||||
Manchmal verteidigen Menschen etwas Beleidigendes oder Hetzerisches, das sie gesagt haben, als "freie Meinungsäußerung".
|
||||
|
||||
Dieser XKCD-Comic fasst die Gedanken der meisten Communities zur Redefreiheit perfekt zusammen. Wenn also jemand etwas im Namen der "Redefreiheit" verteidigt, kannst du es ihm gerne schicken.
|
||||
|
||||
<div align="center"><img src='https://aws1.discourse-cdn.com/freecodecamp/original/3X/4/3/43a8b2eafe4c8622e02838f66f1dc6227de32c70.png' width="400" height="400" /></div>
|
||||
|
||||
Danke, dass du das gelesen hast, und danke, dass du der Entwickler-Community hilfst!
|
||||
|
||||
## Antwortvorlagen
|
||||
|
||||
Dies sind einige der Standard-Antwortvorlagen, die du bei der Überprüfung von Pull-Requests und der Bearbeitung von Issues und Pull-Requests verwenden kannst.
|
||||
|
||||
> Du kannst deine eigenen mit der in GitHub eingebauten [**Saved replies**](https://github.com/settings/replies/) Funktion erstellen oder die untenstehenden verwenden.
|
||||
|
||||
### Dankeschön
|
||||
|
||||
```markdown
|
||||
Thank you for your contribution to the page! 👍
|
||||
We are happy to accept these changes and look forward to future contributions. 🎉
|
||||
```
|
||||
|
||||
### Danke und herzlichen Glückwunsch
|
||||
|
||||
> Für die Danksagung und Ermutigung von erstmalig Mitwirkenden.
|
||||
|
||||
```markdown
|
||||
Hi @username. Congrats on your first pull request (PR)! 🎉
|
||||
|
||||
Thank you for your contribution to the page! 👍
|
||||
We are happy to accept these changes and look forward to future contributions. 📝
|
||||
```
|
||||
|
||||
### Build-Fehler
|
||||
|
||||
```markdown
|
||||
Hey @username
|
||||
|
||||
We would love to be able to merge your changes but it looks like there is an error with the CI build. ⚠️
|
||||
|
||||
Once you resolve these issues, we will be able to review your PR and merge it. 😊
|
||||
|
||||
---
|
||||
|
||||
Feel free to reference the [contributing guidelines](how-to-work-on-coding-challenges.md#testing-challenges) for instructions on running the CI build locally. ✅
|
||||
```
|
||||
|
||||
### Fork synchronisieren
|
||||
|
||||
> Wenn der PR nicht mit dem `main`-Branch auf dem neuesten Stand ist.
|
||||
|
||||
````markdown
|
||||
Hey @username
|
||||
|
||||
We would love to be able to merge your changes, but it looks like the branch is not up to date. ⚠️
|
||||
|
||||
To resolve this error, you will have to sync the latest changes from the `main` branch of the `freeCodeCamp/freeCodeCamp` repo.
|
||||
|
||||
Using the command line, you can do this in three easy steps:
|
||||
|
||||
```bash
|
||||
git remote add upstream git://github.com/freeCodeCamp/freeCodeCamp.git
|
||||
|
||||
git fetch upstream
|
||||
|
||||
git pull upstream main
|
||||
````
|
||||
|
||||
If you're using a GUI, you can simply `Add a new remote...` and use the link `git://github.com/freeCodeCamp/freeCodeCamp.git` from above.
|
||||
|
||||
Once you sync your fork and pass the build, we will be able to review your PR and merge it. 😊
|
||||
|
||||
---
|
||||
|
||||
Feel free to reference the [Syncing a Fork](https://help.github.com/articles/syncing-a-fork/) article on GitHub for more insight on how to keep your fork up-to-date with the upstream repository. 🔄
|
||||
````
|
||||
|
||||
### Merge Conflicts
|
||||
|
||||
> When PR has merge conflicts that need to be resolved.¹
|
||||
|
||||
```markdown
|
||||
Hey @username
|
||||
|
||||
We would love to be able to merge your changes, but it looks like you have some merge conflicts. ⚠️
|
||||
|
||||
Once you resolve these conflicts, we will be able to review your PR and merge it. 😊
|
||||
|
||||
---
|
||||
|
||||
If you're not familiar with the merge conflict process, feel free to look over GitHub's guide on ["Resolving a merge conflict"](https://help.github.com/articles/resolving-a-merge-conflict-on-github/). 🔍️
|
||||
|
||||
Dit is ook goeie praktyk op GitHub om 'n kort beskrywing van jou veranderinge te skryf wanneer jy 'n PR skep. 📝
|
||||
````
|
||||
|
||||
¹ Wenn ein erstmaliger Mitwirkender einen Merge-Konflikt hat, werden die Maintainer den Konflikt für ihn auflösen.
|
||||
|
||||
### Duplikat
|
||||
|
||||
> Wenn eine PR sich wiederholt oder ein Duplikat ist.
|
||||
|
||||
```markdown
|
||||
Hey @username
|
||||
|
||||
This PR seems to make similar changes as the existing PR <#number>. As such, we are going to close this as duplicate.
|
||||
|
||||
If you feel you have additional changes to expand upon this PR, please feel free to push your commits and request this PR be reopened.
|
||||
|
||||
Thanks again! 😊
|
||||
|
||||
---
|
||||
|
||||
If you have any questions, feel free to ask questions on the ['Contributors' category on our forum](https://forum.freecodecamp.org/c/contributors) or [the contributors chat room](https://chat.freecodecamp.org/channel/contributors).
|
||||
```
|
||||
|
||||
### Ungültige Pull-Requests schließen
|
||||
|
||||
> Wenn PR ungültig ist.
|
||||
|
||||
```markdown
|
||||
Hey @username
|
||||
|
||||
Thank you for opening this pull request.
|
||||
|
||||
This is a standard message notifying you that we've reviewed your pull request and have decided not to merge it. We would welcome future pull requests from you.
|
||||
|
||||
Thank you and happy coding.
|
||||
```
|
||||
|
||||
> Wenn ein PR Links zu externen Ressourcen hinzufügt.
|
||||
|
||||
```markdown
|
||||
Thank you for your pull request.
|
||||
|
||||
We are closing this pull request. Please suggest links and other details to add the challenge's corresponding guide post through [a forum topic](https://forum.freecodecamp.org/new-topic?category=Contributors&title=&body=**What%20is%20your%20hint%20or%20solution%20suggestion%3F**%0A%0A%0A%0A%0A**Challenge%3A**%0A%0A%0A**Link%20to%20the%20challenge%3A**) instead.
|
||||
|
||||
If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you, and happy coding.
|
||||
```
|
||||
|
||||
### Ungültige Issues schließen
|
||||
|
||||
> Wenn sich ein Issue auf den Code des Teilnehmers bezieht.
|
||||
|
||||
```markdown
|
||||
Thank you for reporting this issue.
|
||||
|
||||
This is a standard message notifying you that this issue seems to be a request for help. Instead of asking for help here, please click the **"Get Help"** button on the challenge on freeCodeCamp and choose the **"Ask for help"** option, which will help you create a question in the right part of the forum. Volunteers on the forum usually respond to questions within a few hours and can help determine if there is an issue with your code or the challenge's tests.
|
||||
|
||||
If the forum members determine there is nothing wrong with your code, you can request this issue to be reopened.
|
||||
|
||||
Thank you and happy coding.
|
||||
```
|
||||
|
||||
> Wenn eine Issue ein Duplikat eines früheren Issue ist
|
||||
|
||||
```markdown
|
||||
Thank you for reporting this issue.
|
||||
|
||||
This is a standard message notifying you that this issue appears to be very similar to issue #XXXXX, so we are closing it as a duplicate.
|
||||
|
||||
If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.
|
||||
```
|
||||
|
||||
> Wenn ein Problem während des Staging gelöst wird.
|
||||
|
||||
```markdown
|
||||
Thank you for reporting this issue.
|
||||
|
||||
This is a standard message notifying you that the problem you mentioned here is present in production, but that it has already been fixed in staging. This means that the next time we push our staging branch to production, this problem should be fixed. Because of this, we're closing this issue.
|
||||
|
||||
If you think we're wrong in closing this issue, please request for it to be reopened and add further clarification. Thank you and happy coding.
|
||||
```
|
||||
|
||||
### Issue nur für erstmalige Mitwirkende
|
||||
|
||||
> Wenn ein Issue als geeignet für den ersten Codebeitrag eingestuft wird.
|
||||
|
||||
```markdown
|
||||
Thanks for opening this issue.
|
||||
|
||||
This looks like something that can be fixed by "first time" code contributors to this repository. Here are the files that you should be looking at to work on a fix:
|
||||
|
||||
List of files:
|
||||
|
||||
1. ...
|
||||
2. ...
|
||||
3. ...
|
||||
|
||||
Please make sure you read [our guidelines for contributing](https://contribute.freecodecamp.org/#/), we prioritize contributors following the instructions in our guides. Join us in [our chat room](https://chat.freecodecamp.org/channel/contributors) or [the forum](https://forum.freecodecamp.org/c/contributors/3) if you need help contributing, our moderators will guide you through this.
|
||||
|
||||
Sometimes we may get more than one pull request. We typically accept the most quality contribution followed by the one that is made first.
|
||||
|
||||
Happy contributing.
|
||||
```
|
||||
10
docs/i18n/german/security-hall-of-fame.md
Normal file
10
docs/i18n/german/security-hall-of-fame.md
Normal file
@ -0,0 +1,10 @@
|
||||
# Verantwortliche Offenlegung - Hall of Fame
|
||||
|
||||
Wir freuen uns über jede verantwortungsvolle Offenlegung von Schwachstellen, die die Integrität unserer Plattformen und Nutzer/innen beeinträchtigen könnten. Wenn du daran interessiert bist, zur Sicherheit unserer Plattform beizutragen, lies bitte unsere [Sicherheitsrichtlinien](https://contribute.freecodecamp.org/#/security).
|
||||
|
||||
Auch wenn wir im Moment keine Belohnungen oder Swags anbieten, sind wir diesen großartigen Menschen dankbar, dass sie uns helfen, die Plattform für alle sicher zu halten:
|
||||
|
||||
- Mehul Mohan from [codedamn](https://codedamn.com) ([@mehulmpt](https://twitter.com/mehulmpt)) - [Behebung von Sicherheitslücken](https://github.com/freeCodeCamp/freeCodeCamp/blob/bb5a9e815313f1f7c91338e171bfe5acb8f3e346/client/src/components/Flash/index.js)
|
||||
- Peter Samir https://www.linkedin.com/in/peter-samir/
|
||||
|
||||
> ### Danke für eure Beiträge :pray:
|
||||
46
docs/i18n/german/security.md
Normal file
46
docs/i18n/german/security.md
Normal file
@ -0,0 +1,46 @@
|
||||
# Sicherheitsrichtlinie
|
||||
|
||||
Dieses Dokument beschreibt unsere Sicherheitsrichtlinien für die Codebases und Plattformen, die wir betreiben, und wie du Schwachstellen melden kannst.
|
||||
|
||||
## Eine Schwachstelle melden
|
||||
|
||||
Wenn du glaubst, dass du eine Schwachstelle gefunden hast, _bitte melde sie verantwortungsvoll_. Erstelle kein GitHub-Issue für Sicherheitsprobleme. Schicke stattdessen bitte eine E-Mail an `security@freecodecamp.org` und wir werden uns sofort darum kümmern.
|
||||
|
||||
Stelle sicher, dass du die **neueste**, **stabilste (stable)** und **aktuellste** Version des Betriebssystems und des Webbrowsers verwendest, die dir auf deinem Computer zur Verfügung stehen.
|
||||
|
||||
Wir freuen uns über jede verantwortungsvolle Offenlegung von Schwachstellen, die die Integrität unserer Plattformen und Nutzer/innen beeinträchtigen könnten.
|
||||
|
||||
Wenn du eine Schwachstelle meldest, werden wir sie untersuchen und sicherstellen, dass es sich nicht um einen Fehlalarm handelt. Wir werden uns bei dir melden, wenn wir noch Details klären müssen. Du kannst für jedes Problem, das du findest, eine gesonderte Mitteilung machen.
|
||||
|
||||
Im Moment bieten wir zwar keine Belohnungen oder Swags an, aber wir nehmen deinen Namen gerne in unsere [Hall of Fame](https://contribute.freecodecamp.org/#/security-hall-of-fame)-Liste auf, vorausgesetzt, die Meldungen betreffen keine geringfügigen Probleme.
|
||||
|
||||
Wir betrachten die Verwendung von Online-Tools und Hilfsprogrammen zur Meldung von Problemen mit SPF- und DKIM-Einstellungen, SSL-Server-Tests usw. als ["beg bounties"](https://www.troyhunt.com/beg-bounties/) und werden auf diese Meldungen nicht reagieren.
|
||||
|
||||
## Plattformen & Codebasen
|
||||
|
||||
Hier ist eine Liste der Plattformen und Codebasen, für die wir Meldungen annehmen:
|
||||
|
||||
### Lernplattform
|
||||
|
||||
| Version | Branch | wird unterstützt | aktive Website |
|
||||
| ----------- | -------------- | ---------------- | ------------------------ |
|
||||
| production | `prod-current` | Ja | `freecodecamp.org/learn` |
|
||||
| staging | `prod-staging` | Ja | `freecodecamp.dev/learn` |
|
||||
| development | `main` | Nein | |
|
||||
|
||||
### Plattform für Publikationen
|
||||
|
||||
| Version | wird unterstützt | aktive Website |
|
||||
| ---------- | ---------------- | ---------------------------------------- |
|
||||
| production | Ja | `freecodecamp.org/news` |
|
||||
| localized | Ja | `freecodecamp.org/<language>/news` |
|
||||
|
||||
### Mobile App
|
||||
|
||||
| Version | wird unterstützt | aktive Website |
|
||||
| ---------- | ---------------- | ---------------------------------------------------------------- |
|
||||
| production | Ja | `https://play.google.com/store/apps/details?id=org.freecodecamp` |
|
||||
|
||||
Außerdem nehmen wir auch Meldungen für Repositories entgegen, die auf GitHub unter der freeCodeCamp-Organisation gehostet werden.
|
||||
|
||||
Einige unserer Plattformen hosten wir selbst mit Open-Source-Software wie Ghost & Discourse. Wenn du eine Sicherheitslücke meldest, stelle bitte sicher, dass es sich nicht um einen Fehler in der Originalsoftware handelt.
|
||||
Reference in New Issue
Block a user