EstherM hat geschrieben:Vielleicht kannst du in der jeweils anderen Sprache die vorhandenen Texte auch auftauchen lassen, aber mit [EN] bzw. [DE] als abweichend kennzeichnen.
So ähnlich hab ich das vor - in der Navigation taucht die "fremdsprachige" Überschrift auf, und hinter der Überschrift dann das dazu gehörige Sprachsymbol. Der Link geht dann allerdings auch direkt auf die "fremdsprachige" Seite, d.h. man wechselt in dem Fall (anders als normal) mit der Seitennavigation auch die Sprache.
EstherM hat geschrieben:Ich bin gerade dabei, den Text in sechs Dateien aufzuteilen (Einstieg und 1 Datei für jeden Level), so wie ihr das vorgeschlagen habt. Dann hätte "Brickly" sechs Unterpunkte. Ginge das so?
Die Aufteilung passt super.
EstherM hat geschrieben:Ich hatte jetzt an die Aufbereitung der Dateien für ein Wiki gedacht, aber das ist ja mit dem von dir vorgeschlagenen System hinfällig.
Das muss sich ja nicht unbedingt ausschliessen. Die Markdown-Variante, die für Github Pages verwendet wird, kann allerdings etwas mehr als die im Github-Wiki (oder in der direkten Ansicht auf Github), d.h. wenn man das voll ausnutzt, dann sehen die Seiten im Wiki eventuell nicht mehr so gut aus (ein Beispiel dafür siehst Du z.B. direkt auf der Startseite - vergleich da das Bild mal mit der Darstellung der Seite unter https://github.com/ftCommunity/ftcommun ... e/index.md).
EstherM hat geschrieben:Als Dateinamen habe ich sowas gedacht wie "DE-Brickly-Einstieg" usw.. Ist das recht so? Wie hättest du denn gerne die Verzeichnisstruktur: alles in einem Verzeichnis, auch die Bilder? Oder lieber Unterverzeichnisse? [ ... ] Dann muss man nur noch die Links in den Dateien geradebiegen. Im Github-Markdown sind relative Links (also z.B. nur der Dateiname) möglich, aber das muss ich noch ausprobieren. Noch bin ich da flexibel, aber wenn ich möchte ungern die Struktur mehrfach umstellen, weil das unnötige Arbeit macht.
Die beste Verzeichnisstruktur ist vermutlich ein Unterverzeichnis pro Sprache (also zunächst mal nur "de"), und darunter dann direkt die jeweiligen Dateien. Damit können wir dann einfach zusätzliche Sprachen hinzufügen, und es passt zu der Struktur, mit der ich auf cfw.ftcommunity.de die Umschaltung zwischen den Sprachen mache. Innerhalb eines Sprachverzeichnis noch weitere Unterverzeichnisse anzulegen macht denke ich nur Sinn, wenn da noch deutlich mehr Kapitel dazukommen als ein Einstieg und 5 Level - und dann kann man das immer noch machen.
Wenn Du mir helfen willst, dann nennst Du die Einstiegsdatei "index.md" (das wird dann zu "index.html", und das wiederum wird automatisch angezeigt, wenn jemand das passende "Verzeichnis" unter cfw.ftcommunity.de aufruft). Wie die anderen Seiten heißen ist eigentlich ziemlich egal, ich würde sie - fantasielos wie ich bin - wohl schlicht "level-1.md" bis "level-5.md" nennen 
Was mir wieder helfen würde: Wenn dann später die englischen Seiten dieselben Dateinamen haben (nur halt dann in einem anderen Unterverzeichnis) - darauf baue ich nämlich den Mechanismus auf, der erkennt ob es zu einer Seite eine Übersetzung in einer anderen Sprache gibt oder nicht.
Relative Links sind ideal (auch für die Bilder) - die funktionieren nämlich auch dann, wenn die Seiten später irgendwo anders in einer Seitenhierarchie eingehängt werden.
Wo die Bilder am besten hinkommen hängt davon ab, wie gut die von den zukünftigen Sprachversionen gemeinsam genutzt werden können. Wenn es da viele Überschneidungen gibt, ist es sinnvoll die Bilder in ein gemeinsames Verzeichnis auf demselben Level wie die Sprach-Unterverzeichnisse zu legen. Und wenn es eh keine Überschneidungen gibt, dann können die Bilder auch ins gleiche Verzeichnis wie die Texte (spart dann etwas Tipperei bei den relativen Links). Ich würde im Zweifelsfall aber wohl eher ein eigenes Bilder-Verzeichnis auf der obersten Ebene nehmen.
EstherM hat geschrieben:Wenn wir uns da einig sind, könnte ich die fertigen Dokumente einfach in ein Verzeichnis "brickly" in meinem Repository pushen, und du holst sie von da rüber.
Ein extra "brickly"-Unterverzeichnis brauche ich nicht wirklich. Das würde zwar auch nicht stören, aber wirklich sinnvoll ist es denke ich nur, wenn im gleichen Repository noch was anderes als eine Brickly-Anleitung liegen sollte.
Ich bin noch nicht hundertprozentig sicher ob das so klappt wie ich mir das vorstelle (die Github-Doku ist da ein wenig vage, oder ich bin zu blöd um sie zu verstehen), aber ich will versuchen, Dein Repository als ein Git-"submodule" unter docs/brickly einzubinden - das kann man sich so vorstellen wie eine Anweisung für Git, in diesem Unterverzeichnis dann Dein Projekt in einer bestimmten Version einzublenden (und ein Update auf eine neuere Version ist dann ähnlich einfach wie ein "git pull" im eigentlichen Repository).
Das kann die Jekyll-Installation auf Github anscheinend verstehen (zumindestens dann, wenn das submodule ebenfalls auf ein öffentliches Repository zeigt, und wenn ich die Doku dazu richtig verstanden habe natürlich) und die Seiten dann genauso einbinden als ob ich sie kopieren würde.
Und für die Veröffentlichung kann man dann Jekyll auch noch beibringen, die URLs für die Website systematisch von den Pfadnamen (relativ zu "docs") brickly/de/... auf de/brickly/... umzuschreiben, d.h. auf der fertigen Website sieht das dann so aus, als ob die Brickly-Anleitung in derselben Verzeichnishierarchie liegt wie der Rest der Seite.
