Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature/ns cs translation #5

Open
wants to merge 6 commits into
base: master
Choose a base branch
from
Open

Conversation

Nos-
Copy link
Member

@Nos- Nos- commented Oct 2, 2017

Translated the Git cheat-sheet into german.

@Nos-
Copy link
Member Author

Nos- commented Oct 2, 2017

It would be nice to preserve both translations.

@cknoll
Copy link
Member

cknoll commented Oct 2, 2017

Sieht schon mal ganz gut aus.
folgende Anmerkungen:

  • der Branch sollte auf dem aktuellen master basieren (in den der Cheat-Sheet-Branch ja auch schon gemörcht wurde)
  • Ich finde die Schreibweise "Repositories" nicht schön. Vorschläge: Repos oder Repositorien
  • Vorschläge für Übersetzung von "Get changes from upstream" : "Änderungen von entferntem Repo holen"
  • Frage ausdiskutieren, ob wir vielleicht eine deutsche und englische Version pflegen wollen (wenn wir die englische schon mal haben). Ich bin dafür. @sebastianriese Wie ist Deine Meinung?
  • die PDF-Datei sollte jeweils mit fsfw- beginnen, falls sie dann irgendwo im Netz zirkuliert, das wir auch "sichtbar" sind. (Im aktuellen Master inzwischen umgesetzt)

@Nos-
Copy link
Member Author

Nos- commented Oct 3, 2017

Ich fände es gut, beide Sprachvarianten zu haben und schlage vor die deutsche Git-Spickzettel zu nennen.

@Nos-
Copy link
Member Author

Nos- commented Oct 3, 2017

Die Quellenangabe am Ende, die zwar richtig ist, ist dennoch ein wenig verwirrend, da sie keine wirklich hilfreichen Infos über uns enthält. Ich schlage deshalb vor wenigstens die Url des Repos einzufügen.

@sebastianriese
Copy link
Member

Der "Fehler mit deprecated \tt" ist mit dem commit nicht repariert, wenn dann müsste in der ersetzung \texttt{#1} stehen. So verändert das das Kompilat.

@sebastianriese
Copy link
Member

sebastianriese commented Oct 3, 2017

Beide Sprachvarianten beizubehalten finde ich auch besser. Dann muss man nur einen Prozess etablieren, der sicherstellt, dass Änderungen immer Parallel an beiden stattfinden. Vorschlag:
Einen Quelltext mit "sprachschalter" a la \ende{English text}{Deutscher Text}. (Die Struktur und die git Kommandos sind ja identisch).

Anmerkung: Man sollte den "Inhalt" in zwei Dokumente importieren, die das \ende Kommando entsprechend implementieren und das korrekte babel importieren (just in case, eigentlich sollte es keine Zeilenumbrüche geben, da kein Blocksatz auf den Folien ist). Der Rest der Präambel sollte im eingefügten Dokument sein (Pakete für die farbigen Blöcke, etc.), so dass die Code-Duplikation minimiert ist.

Aufwändigere Alternative: Einen "Translation"-Marker verwenden und mit einem externen Tool die Übersetzungen generieren (so wie das in GUI Toolkits/mit gettext gemacht wird), das skaliert besser, wenn wir mal mehr Sprachen unterstützen wollen. Fertiges tooling dafür: getTeXt.

@Nos- Nos- changed the base branch from feature/cheat-sheet to master October 3, 2017 13:26
Copy link
Member

@horazont horazont left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Abgesehen von den Bereits angemerkten Punkten, dass es ganz nett wäre beide Sprachen parallel zu pflegen habe ich noch die untenstehenden Anmerkungen.

Mindestens der auskommentierte Teil sollte auf keinen Fall im Hauptbranch landen.

\documentclass[a4paper,fontsize=7.5pt]{scrreprt}
%\documentclass[a4paper,fontsize=7.5pt, ngerman]{scrreprt}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Das auskommentierte Zeug gehört da nicht hin.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ja, das ist ein Überbleibsel vom Debuging des behobenen \tt Errors


% Packages
\usepackage[utf8]{inputenc}
%\usepackage[ngerman]{babel}
%\usepackage[]{babel}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Siehe oben.

Und warum weder ngerman noch english?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sind beide wieder drin.

@@ -66,7 +69,7 @@
% set own shortcuts
\newcommand{\sourcetext}[1] {
\begin{tabularx}{\hsize}{X}
{\tt #1}
{\texttt{} #1}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

\texttt{} tut garnichts, warum steht das da?

\cmdline{git config [-{}-global] [option]}
\annotation{with \texttt{-{}-global} it is stored in \texttt{$\tilde{\ }$/.gitconfig}}
\subsection{Information about the user}
\annotation{mit \texttt{-{}-global}: wird es gespeichert in \texttt{$\tilde{\ }$/.gitconfig}}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"mit […] wird es in […] gespeichert" liest sich flüssiger als "mit […] wird es gespeichert in […]".

\sourcetext{color.ui auto}
\subsection{Improve interactive user-experience}
\subsection{Verbesserung der interaktiven Nutzererfahrung}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Versteht das unser Zielpublikum?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wäre "Verbesserung der interaktiven Bedienbarkeit" besser?

\cmdline{git add path/to/add}
\subsection{Interactively select changes for addition/committing}
\subsection{Wähle interaktiv alle Änderungen zum Hinzufügen/ Committen aus}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Kein Leerzeichen nach dem Schrägstrich.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Erledigt

\cmdline{git commit -m "<message>"}
}

%% How to handle branches
\colouredbox{orange}{
\begin{center}\section{Working with Branches}\end{center}
\subsection{List all branches}
\begin{center}\section{Arbeiten mit Branches (dt.: Äste)}\end{center}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Zweige" anstatt "Äste" vielleicht? Das ergibt mehr Sinn, weil "Zweig" auch in sowas wie "Abzweigung" drin steckt.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

+1 für Zweig. Wir haben das Wort Zweig auch als deutsches Synonym zu Branch im Workshop eingeführt.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Die Argumentation finde ich nachvollziehbar auch wenn ich eigentlich "Zweig" mit "twig" übersetzen würde.

\cmdline{git checkout <branch>}
\subsection{Merge Branch B1 into B2}
\subsection{Branch B1 in B2 mergen (dt. mischen)}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Zusammenführen" ist finde ich eine bessere Übersetzung als "Mischen". Zusammenführen drückt mehr aus, dass das mit System passiert, und nicht chaotisch.

\annotation{generates commit even if fast-forwarding is possible}
\subsection{Create Branch based on HEAD and checkout}
\annotation{Erstelle einen Commit auch wenn fast-forwarding möglich ist}
\subsection{Erstellen eines Branches basierend auf HEAD und checkout}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"und wechselt zu diesem" anstatt "und checkout"

\cmdline{git push [origin] [branch]}
\subsection{Create tags}
\subsection{Einen tag (dt.: ???) erstellen}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Einfach bei "Tag" belassen, deutsche Übersetzung weglassen. "Tag" ist ja ein relativ eingedeutschter Begriff heutzutage. #thankstwitter

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ich bin für das Genus Neuter für "Tag" (unter anderem um es von "der Tag" zu unterscheiden), der Duden ist meiner Meinung.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Grummelgrummel, jaja… Damit werde ich mich nicht anfreunden können ;-).

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ich bin dafür es mir Fragezeichen zu belassen. Schließlich ist es work-in-progress und Mitmachen erwünscht.

@Nos-
Copy link
Member Author

Nos- commented Oct 3, 2017

So, ich habe den Pullrequest auf den Masterbranch umgestellt. Bitte umsichtig mergen, damit nichts verlorengeht!

Bitte für die Zukunft: Es wäre hilfreich, wenn erst alle Pullrequests von Unterbranches durchgeschaut (geschweige denn gemerged) würden, bevor mit Master oder so gemerget wird.

@horazont
Copy link
Member

horazont commented Oct 3, 2017

Bitte für die Zukunft: Es wäre hilfreich, wenn erst alle Pullrequests von Unterbranches durchgeschaut (geschweige denn gemerged) würden, bevor mit Master oder so gemerget wird.

Halte ich nicht unbedingt für sinnvoll. Wenn es extrem wichtig ist, sollte man das vielleicht eher am PR für den Targetbranch anmerken, für Sichtbarkeit (und vielleicht durch ein Request Changes review deutlich markieren).

Ansonsten spricht doch garnichts gegen Ändern vom Zielbranch im Zweifelsfall?

(Ein anderes Vorgehen was ich sonst noch kenne, ist, den PR immer gegen master aufzumachen und anzusagen, dass die Änderungen von PR #soundso abhängen und vorher nicht gemergt werden sollte.)

Copy link
Member Author

@Nos- Nos- left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So, schaut mal was ihr hiervon haltet.

\documentclass[a4paper,fontsize=7.5pt]{scrreprt}
%\documentclass[a4paper,fontsize=7.5pt, ngerman]{scrreprt}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ja, das ist ein Überbleibsel vom Debuging des behobenen \tt Errors


% Packages
\usepackage[utf8]{inputenc}
%\usepackage[ngerman]{babel}
%\usepackage[]{babel}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sind beide wieder drin.

\cmdline{git add path/to/add}
\subsection{Interactively select changes for addition/committing}
\subsection{Wähle interaktiv alle Änderungen zum Hinzufügen/ Committen aus}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Erledigt

@sebastianriese
Copy link
Member

Gebaute PDF im git ist eine sehr schlechte Idee: Das macht das Repo unnötig groß und muss bei jeder Änderung angepasst werden und ist daher anfällig für Inkonsistenz, wenn wir eine gebaute Version verbreiten wollen, dann über's Wiki (da sollte man dann natürlich auch jeweils die neuste Version hochladen, wenn man was ändert, aber wenigstens ist es dann nicht innerhalb des Repositories Inkonsistent). Delta-Conpression funktioniert auch wirklich nicht gut für PDF.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants