Hilfe:Umwandlung von Infoboxen

Dies ist eine Schritt-für-Schritt-Anleitung, wie du schnell und einfach klassische Wikitext-Infoboxen in Portable Infoboxen konvertierst. Es ist zwar nicht möglich, jeden einzelnen Typ von Infobox zu behandeln – einige Infoboxen sind exotischer als andere – diese Schritte sollten aber weitgehend für die meisten Situationen anwendbar sein.

Diese Anleitung ist für alle Benutzer gedacht, unabhängig von ihrem Wissensstand oder Können und sollte nicht nur von Spezialisten für Portable Infoboxen genutzt zu werden. Dies sollte eine gute Hilfe sein, von Anfang an gute Infoboxen zu erstellen. Es sind auch „beste Vorgehensweisen“ und Portabilitäts-Prinzipien, die für weitergehende Einsicht in das Thema gedacht sind, eingestreut.

Grundlegendes

Bevor du loslegst, solltest du folgende Dinge bereits kennen:

• grundlegendes über Wikitext
• Von CSS-Selektoren und Eigenschaften mindestens gehört haben
• die Tatsache, dass die Begriffe klassische Infobox, nicht portable Infobox, und NPI oder nPI alle dasselbe meinen

Da die Syntax von Portablen Infoboxen XML ist, kann es ebenfalls helfen zu wissen, was „wohlgeformtes XML (englisch)“ bedeutet. Da durch die Umwandlung das Ergebnis von Natur aus wohlgeformtes XML ist, ist das aber eher eine beurteilende Fähigkeit als eine, die wirklich zum Umwandeln der Infoboxen gebraucht wird.

Schritt 0: Die Infoboxen finden

Bevor du mit dem Umwandlungsprozess anfängst, musst du erst einmal herausfinden, welche Vorlagen überhaupt konvertiert werden müssen. Das heißt: Vorlagen finden. Wenn du Glück hast, sind die meisten bereits in einer Kategorie gruppiert, oft heißt diese Kategorie:Infoboxen oder Kategorie:Infobox-Vorlagen.

Aber manchmal werden Infoboxen nicht so schön einsortiert. In dem Fall musst du die Vorlagen über die Klassifikation suchen. Wenn du dir unsicher bist, überprüfe, was die Aufgabe der Infobox ist. Der beste Ort zum Starten ist Spezial:Insights/templateswithouttype. Eventuell siehst du manchmal die Kurzschreibweise der Vanguard-Mitglieder für „Unklassifizierte Vorlagen“/„Unorganisierte Vorlagen“, nämlich „UVs“ („UTs“ im Englischen).

• Schau dir jeden Vorlagen-Eintrag bei den Unorganisierten Vorlagen an, der eine Infobox sein könnte. Wenn es eine vollständige Infobox ist, die in einem Stück vorliegt, klassifiziere sie als Infobox. Wenn es nur ein Teil einer Infobox ist, ist es meistens Daten (wenn die Vorlage den eigentlichen Text betrifft) oder Design (wenn sie beeinflusst, wie der Inhalt oder das Element aussieht).
• Ändere die Klassifikation dieser Vorlagen, indem du auf den Link neben „Vorlagentyp:“ klickst (kann in der Nähe des Seitentitels der Vorlage gefunden werden) oder den Tastaturkurzbefehl „k“ nutzt. Ein gesondertes Fenster („Dialogfeld“ genannt) erscheint, in dem du die neue Klassifikation auswählen kannst.
• Wenn du mehrere Vorlagen in einer Kategorie gesammelt vorliegen hast, kannst du das „Massenbearbeitung des Vorlagentyps“-Werkzeug benutzen, um alle zu klassifizieren. Dieses Werkzeug ist auf lokale Admins und einige Freiwilligen-Gruppen wie VSTF oder Vanguard beschränkt.

HINWEIS: Änderungen am Vorlagentyp werden bis zum nächsten Tag nicht in den Insights angezeigt, da sie nur einmal täglich aktualisiert/gecached werden. Nicht-Insights-Spezialseiten, wie Spezial:Vorlagen, werden häufiger aktualisiert (allerdings nicht in Echtzeit).

Schritt 1: Insights

Spezial:Insights/nonportableinfoboxes ist das Rückgrat der Infoboxen-Portabilitätsarbeit einer Community. Es kann manchmal auch Falschmeldungen anzeigen (oder Vorlagen, die nicht wirklich Infoboxen sind oder in keinem Artikel auftauchen).

Scrolle auf der Spezial:Insights/nonportableinfoboxes-Liste herunter und klassifiziere Vorlagen, die auf 0 Seiten auftauchen, als Nicht-Artikelseite oder was in dem Fall passt. Da auch Vorlagen-Dokumentationsseiten in dieser Liste auftauchen können – per Definition aber nicht für Artikelseiten gedacht sind – ist Nicht-Artikelseite die korrekte Klassifikation. Siehe Schritt 0 für ausführlichere Anweisungen.

Inventar der möglichen Themes und Variationen

Der erste Teil hiervon ist relativ einfach. Schaue für die Infobox, die umgewandelt werden soll, auf die Artikel, auf denen sie benutzt wird. Das kann über Spezial:Linkliste getan werden (kann auf der Insights-Seite unter „wird auf X Artikeln benutzt“ gefunden werden). Untersuche das generelle Aussehen/den Style jeder Vorlage, ob sie alle ein gleiches Aussehen/Schema haben, ob sie nur meistens aussehen wie die anderen Vorlagen (aber vereinheitlicht werden können) oder ob sie sich komplett unterscheiden. Jeder großer Style-Unterschied wird später ein mögliches Theme. Stelle sicher, dass du gesehen hast, welche Teile der meisten Themes gleich sind (zum Beispiel die Farbe oder abgerundete Ecken), damit diese später in das Standard-Theme .portable-infobox eingefügt werden, wenn du es erstellst.

Der zweite Teil ist möglicherweise technisch herausfordernd, aber notwendig, um eine einheitliche Ersetzung der klassischen Infoboxen einer Community zu gewährleisten. Der einfachste Weg, dies zu tun, ist, in den Quelltext der klassischen Infobox zu schauen, wo der Style durch einen Parameter beeinflusst wird, beispielsweise class="{{{roundy|10px}}}" oder style="width: {{{width|250px}}}; background-color: {{{bgcolor|white}}}". Im zweiten Beispiel kann bgcolor höchstwahrscheinlich als Parameter für theme-source dienen.

Schritt 2: Der „Konvertieren!“-Knopf, was er tut und was nicht

Wenn eine Vorlage als Infobox klassifiziert ist, aber nicht die Syntax einer Protablen Infobox verwendet, wird ein „Konvertieren!“-Knopf auf der Insights-Seite neben der Vorlage auftauchen (und in der Seitenleiste der Vorlagenseite). Dieser Knopf startet das Umwandlungs-Werkzeug, das einige Teile der nicht-portablen Infobox in einnn Portable Infobox-Entwurf umwandelt. Das Werkzeug erkennt normalerweise alle Variablen, die in der klassischen Infobox verwendet werden, und wandelt sie in entsprechende Syntax der Portablen Infobox um. Das Werkzeug kennt sich mit den gebräuchlichsten Code-Teilen für Label und Standardwerte aus und versucht, diese zu erkennen und auf Portable Infobox-Benutzung zuzuschneiden.

Auch wenn dieses Werkzeug sehr nützlich ist und einen großen Teil der Migration von sich aus erledigt, gibt es meistens noch Arbeit, die manuell erledigt werden muss. Die meisten der Variablen werden in <data>-Tags umgewandelt, meistens mit einem <label>: Das Umwandlungs-Werkzeug kann nicht immer zwischen Wikitext-Parametern, die für <title> und <data> gedacht sind, unterscheiden und kann auch andere Elemente der Infobox (wie Header, Bildunterschriften, Standardwerte und andere Werte, die keine Variablen benutzen) nicht erkennen.

Komplexere Infoboxen, die Themes, Gruppen, intelligente Gruppen, <navigation>- oder <format>-Tags benötigen, werden vom Umwandlungs-Werkzeug ebenfalls nicht konvertiert – das muss manuell erledigt werden, anhand des Original-Codes, der in der klassischen Infobox verwendet wird. Dieses Werkzeug kann trotzdem ein Weg sein, die Konvertierung der Infobox zu starten, indem er einen Anhaltspunkt für den endgültigen Portable Infobox-Code bietet – auch, wenn vieles manuell getan werden muss.

Schritt 3: Den beigefügten Code kopieren (noinclude und includeonly)

Vorlagen funktionieren mit Transklusion – das Einsetzen einer Quelltext-Vorlage in einen Artikel. Oft genug sind einige Teile der Vorlage nicht in allen Fällen sinnvoll, daher benutzen wir Transklusions-Kontrolltags, um das anzugehen:

<noinclude>

versteckt Inhalt innerhalb dieser Tags im Artikel

Oft genug hat eine Vorlage Abschnitte, die in einem Artikel versteckt werden sollten. Dokumentationen, Infobox-Vorschauen und Vorlagen-Kategorien sind gute Beispiele dafür.

<onlyinclude>

versteckt Inhalt außerhalb dieser Tags im Artikel

Dieser Tag wird weniger oft genutzt, aber grenzt die Infobox schnell von anderen Vorlageninhalten ab. Allgemein gilt, dass <includeonly> vorgezogen wird, wenn es um Code-Klarheit und das Verstehen davon geht.

<includeonly>

versteckt Inhalt innerhalb dieser Tags in der Quelltext-Vorlage

Die Infobox selbst, mit ihren Artikel-Kategorien und was-sonst-noch, werden auch gerne auf der Vorlagen-Seite selbst ausgeblendet. Das hilft dabei, Fehler bei der Erkennung von nPIs zu vermeiden.

Den wichtigen Teil der alten Infobox behalten

Die originale, nicht portable Infobox umfasst meistens zwei Teile: die Infobox-Tabelle selbst und die Dokumentation, Kategorisierung, Navigation und andere unterstützende Informaton außerhalb der Tabelle. Oft sieht das so aus:

{|class="infobox"

. . . verschiedene Code-Zeilen

|}

<noinclude>{{Dokumentation}}[[Kategorie:Infoboxen]]</noinclude>

Kopiere alles, was sowohl vor als auch nach dem Hauptinhalt des NPI-Codes kommt. Das heißt, kopiere alles, was über und unter {| und |} steht. Ersetze im Code der neuen PI die automatisch generierte Dokumentation in der PI mit dem, was du gerade aus der alten NPI kopiert hast. Im obigen Beispiel:

<noinclude>{{Dokumentation}}[[Kategorie:Infoboxen]]</noinclude>

sollte die gesamte automatisch generierte Dokumentation der PI ersetzen.

Schritt 4: Übersetze das Layout und die Gruppen der klassischen Infobox

Wegen der Art und Weise, wie einige klassische Vorlagen geschrieben worden sind, werden einige Wikitext-Parameter möglicherweise außerhalb der Reihenfolge interpretiert oder waren nie dafür vorgesehen, überhaupt sichtbar zu sein. Die allgemeine Form und Struktur dieser Infoboxen wird vom Umwandlungs-Werkzeug nicht erkannt. Der beste Weg, das korrekt umzuformen, ist, von oben nach unten durchzugehen und die Teile in die richtige Reihenfolge und Gruppen zu sortieren.

Portbale Infoboxen verstecken Elemente automatsich, wenn für sie kein Wert eingegeben wird, zusätzlicher Code, diese Teile zu verstecken ist also nicht notwendig. Wenn eine <group> einen <header> in ihr besitzt und kein Tag dieser Gruppe Werte hat, wird der Header auch nicht angezeigt.

HINWEIS: Viele Communitys definieren Werte als „Unbekannt“ in ihren Infoboxen, wenn kein Wert gegeben ist. Auch wenn das eine akzeptable Lösung ist, ist das nicht die beste Lösung (und neigt dazu, opitsches Durcheinander zu verursachen), es sei denn, ein präzises horizontales Raster-Layout ist erforderlich, das dann aber die show="incomplete"-Funktion nutzen sollte.

Daten-Typen

Ist es jetzt image, title, data, navigation, header, etc.? Das ist nicht immer eindeutig erkennbar.

• <title> behandelt Titel und diese Titel bieten keine sichtbaren Label an. Es sollte auch alternative Titel abdecken, zum Beispiel solche aus anderen Sprachen, Titel-Übersetzungen oder Untertitel. Im CSS ist es einfach sekundäre Titel mit etwas wie .pi-title ~ .pi-title zu stylen.
  • Viele Infoboxen werden mit <title source="name"><default>{{PAGENAME}}</default></title> autogeneriert. Um den sauberst möglichen Code zu gewährleisten, sollte dies zu <title source="name"><default><includeonly>{{PAGENAME}}</includeonly></default></title> geändert werden, wenn möglich.
  • Titel aus unterschiedlichen Sprachen sollten in einen einzigen Data-Tag zusammengefasst werden, wo sie äquivalent sind, zum Beispiel kanji- / kana- / rōmaji-Schreibweisen desselben Titels. Ein visueller Indikator, der angibt, welche Sprache verwendet wird, ist üblicherweise nicht erforderlich; eine Flagge zu nutzen, um eine Sprache zu repräsentieren, wird als „schlechter Stil“ angesehen. Wenn mehrere Titel-Übersetzungen (über die ursprüngliche und die Wiki-Sprache hinaus) gegeben sind, sollten diese als <data> in einer <group> gesammelt werden.
  • Titel nach Region oder Sprachregion sollten getrennt werden, wie zum Beispiel spanischsprachige Titel, die Unterschiede in Spanien oder Lateinamerika aufweisen. Das macht man, weil es letzten Endes verschiedene Daten-Teile sind.
  • Ein Logo für ein Thema sollte sollte sich der textuellen Repräsentation des Titels unterordnen, also entweder als sekundärer Titel oder als <data> realisiert werden.
• <image> behandelt größenangepasste Bilder und diese Bilder bieten keine sichtbaren Label an.
  • Bilder-Felder kümmern sich nur um Bilder-Daten. Bei Bildern mit Text vermischt wird nur das Bild angezeigt.
  • Bilder-Felder können entweder <tabber> oder <gallery> als Kind haben, um eine Galerie zu erstellen (oder eine Slideshow auf mobilen Geräten). Wegen der Code-Einfachheit wird <gallery> bevorzugt. Je nachdem, wie die Funktion genutzt wird, kann es nötig sein, stattdessen eine {{#tag:gallery}}-Parserfunktion zu nutzen. Nicht alle Galerieeigenschaften, die außerhalb einer Infobox verfügbar sind, sind nicht unbedingt innerhalb verfügbar, wie bspw. Slideshows.
  • Das Kind <caption> kümmert sich um Bildunterschriften. Wenn ein Bilder-Feld <gallery> besitzt, wird das für die Galerie genutzte „caption“ zum Tab-Namen der Tabs.
  • Bilder-Felder verlangen keinen vollständigen Dateipfad oder interne „Datei:“-Links, obwohl sie in den meisten Situationen akzeptiert werden. Alle Größenangaben oder Bildunterschriften, die dem „Datei:“-Link hinzugefügt werden, haben keinen Effekt.
  • Bilder-Felder skalieren Bilder dynamisch (die, die breiter als 130px sind) bis hin zu einem Maximum von 270px - 300px, damit sie auf jeder Plattform bestmöglich passen. Kleinere Bilder, wenn sie das Thema der Infobox wirklich beschreiben, bleiben in ihrer Größe; wenn das kleinere Bild ein Spiel-Icon oder eine ähnlich ergänzende Information ist, sollte es stattdessen besser ein <data>-Feld sein.
• <data> ist der typische Bereich für die meisten anderen Parameter.
• <navigation> ist ein Bereich (keine Unterstützung eines Labels) für beliebigen Wikitext.
  • Icons im oberen „title“-Bereich sollten als Navigation umgesetzt werden, da sie streng genommen weder <title> noch <image> sind.

Gruppen

Typische, senkrechte Gruppen sind leicht zu erkennen. Bei horizontalen Gruppen hast du zwei Möglichkeiten: Traditionelles „horizontales“ Layout und „intelligente“ Gruppen. Jede kann unterschiedlich angepasst werden, wenn es nötig ist, aber es gibt vielleicht Gründe, wann man welche Gruppe nutzt.
Traditionelle horizontale Gruppen sind starr und für eine kleine und vorher bestimmte Anzahl von Inhalten gedacht, bei denen nur wenig Variation herrscht. Als Beispiel sollten Vorherige- & Nächste-Felder horizontale Gruppen nutzen. Sie sollten in logischen Gruppen genutzt werden, bei denen das Layout auf eine Reihe beschränkt ist.
Intelligente Gruppen sind für (möglicherweise noch werdende) größere, verschiedene Inhalte gedacht. Sie passen sich der Anzahl der Inhalte an und schieben jeden Eintrag in eine neue Reihe, wenn das Maximum erreicht ist (in der row-items-Gruppeneigenschaft vordefiniert).

Daten-Label

Daten-Label unterstützen die meisten Wikitext-Funktionen. Sie sollten auch <noinclude> (um ein Label für Bearbeitungszwecke auf eine Weise zu verdeutlichen, die nicht angezeigt wird) und <includeonly> (um Teile des Labels, die nur im Artikel und nicht im Editor auftauchen sollen, anzuzeigen) beachten. Wenn sie zudem noch ein Infoicon enthalten, sollten sie aufpassen, dass sie keine Probleme mit der Barrierefreiheit verursachen. Nur <data> haben sichtbare Label.

Aus der Lesbarkeits- und der Barrierefreiheits-Perspektive gesehen, sollte noch angemerkt werden, dass senkrecht zentrierte Label kein guter Weg sind, ein höheres/größeres Daten-Feld zu erzeugen, da das menschliche Auge dazu neigt, in unerwarteter Weise umherzuspringen. Auch ergeben kurze Label wie „ATK“ und „DEF“ für einen englischen Muttersprachler Sinn, sollten aber <abbr> nutzen, um das Verständnis von anderen, die sich mit dem Thema oder Sprache nicht auskennen, zu unterstützen. Andersherum sollten besonders lange Label ohne Zeilenumbruch besser in kleinere Wörter aufgeteilt werden. Gleich breite Label und Werte (das heißt 50 % Labelbreite) ist ebenfalls schlechter lesbar mit senkrechten Daten-Inhalten, da es den Schwerpunkt vom eigentlichen Wert wegzieht (und meistens gefärbten Leerraum hinzufügt) und daher in neuen Vorlagen vermieden werden sollte. Wenn die Labelbreite erhöht werden muss, ist flex-basis die richtige CSS-Eigenschaft dafür.

Schritt 5: Defaults und Formats

Es ist typischerweise eine gute Idee, die Vorlage nur mit schlichten Daten zu füttern, auf einen einfach Datentyp reduziert (z. B. als Zahl, Text, Links oder Listen davon). Zu diesem Zweck kann der <format>-Tag ungeformte Eingaben in richtig formatierte Ausgaben umformen. Zum Beispiel: Ein Feld mit den Kosten von „10 Gold“ (angenommen, „Gold“ ist die einzige Währung für diesen Gegenstand) hat als Eingabe „10“ und benutzt den <format>-Tag um den sichtbaren Wert als „10 Gold“ anzuzeigen (oder benutzt ein Gold-Infoicon aus dem Spiel etc.). Der <format>-Tag kann in <data>- oder <title>-Tags benutzt werden, nicht aber in <image>- oder <navigation>-Tags.

Standardwerte mit <default> tauchen nur auf, wenn der Artikel keinen Wert für den in source= benannten Parameter bereitstellt. Der <default>-Tag kann im <data>-, <title>- oder <image>-Tag benutzt werden, nicht aber in <navigation>.

Standardwerte sollten „Unbekannt“ oder „-“ oder Ähnliches vermeiden, es sei denn sie werden für das Layout benötigt. Portable Infoboxen sind dafür ausgelegt, unbenutzte Werte nicht anzuzeigen, weitere Logik, diese zu verstecken ist daher nicht notwendig; weiterhin werden die Gruppe und ihr Header nicht angezeigt, wenn keine Data-Felder in der Gruppe benutzt sind, es sei denn das show="incomplete"-Attribut wurde der Gruppe hinzugefügt.

TIPP: Automatisierung ist nicht immer eine gute Idee. Auf den ersten Blick kann das Überspringen vom Namen oder Titel, um dafür das {{PAGENAME}}-Zauberwort zu nutzen, effizient erscheinen, das kann aber problematisch werden, wenn der Seitenname sich ändert oder der Titel Zeichen oder Format enthält, das nicht als Artikelname dupliziert werden kann. Andere Elemente, wie zum Beispiel Bilder, die vom Seitennamen abhängen, machen die Dinge noch komplizierter, wenn ein Benutzer der Community nicht die innere Magie und Logik deiner Vorlage versteht, um etwas einzutragen oder sie warten zu können. Hilfsvorlagen, Lua-Funktionen oder komplex verschachtelte ParserFunktionen tragen alle zum Unverständnis des Benutzers bei, falls die Vorlage einmal überarbeitet oder entwirrt werden muss.

Wenn ein Daten-Feld nicht verarbeitet werden muss (d.h. nur der {{{Parameter}}} wird benutzt und nicht durch Funktionen oder Styling angepasst) müssen die <default>- und <format>-Tags überhaupt nicht eingebunden werden. Allein diese Funktion vereinfacht einige Umwandlungen von klassischen Infoboxen drastisch. Ansonsten ist der effektive Gebrauch von <default> und <format> das Kernelement jeder Infobox-Umwandlung.

TIPP: Wenn du eine Kategorie hinzufügst, die von einem <data>-Wert abhängt, erspart es dir spätere Arbeit, diese Kategorie in einer Switch-Funktion unterzubringen.

Schritt 6: Styling

Das ist ein weiterer Bereich, bei dem klassische Infoboxen während der Umwandlung viel von ihrer Masse verlieren. In PIs werden Anpassungen im globalen CSS vorgenommen. Inline-CSS (mit den style- und class-Attributen) ist so gut es geht zu vermeiden.

Wenn alle Felder desselben Typs individuell angepasst wurden, sollten diese Anpassungen zum standardmäßigen .portable-infobox-CSS oder als Theme hinzugefügt werden.

Wenn ein Wert im Gegensatz zu den anderen seines Typs anders angepasst wurde (z. B. eine kursiv geschriebene Rōmaji-Abschrift neben kanji oder kana), werden Wikitext (z. B. ''') oder ein angemessener HTML-Tag (z. B. <dfn>) benutzt, um sie innerhalb von <format> auszugleichen. Wikitext, der kein CSS nutzt, wird immer als portabel behandelt.

Es ist stark empfohlen, die Breite der Infoboxen mit CSS nicht zu ändern, da Bilder in der Infobox dann die Ränder der Infobox überschreiten können. Durch CSS verkleinerte Bilder werden zwangsläufig verzerrt.

Themes und accent color

CSS-Anpassungen der PI ist ein zu komplexes Thema, als dass man es in dieser Anleitung behandeln könnte, es ist aber in einiger Ausführlichkeit in Hilfe:Infoboxen/CSS erklärt.

Bonus-Schritt: Zentrales CSS erstellen und Entwürfe genehmigen

Das Vanguard-Team hat seine eigenen Vorgaben und Abläufe, auf Communitys zuzugehen, allerdings können Communitys sich entscheiden, viele der gleichen Werkzeuge und als praktisch erwiesene Ideen zu benutzen. Abhhängig von der Komplexität des CSS und dem Code, ist ein seperates Testwiki aber meist nicht nötig. Den Vorlagen-Code in der Hauptcommunity über das Entwurfs-System direkt zu entwickeln ist unkompliziert und macht das Testen neuer Vorlagen gegen bestehende Artikel einfacher, da es genau so gute oder sogar bessere Ergebnisse erzielen wird, als es in einem alleinigen Testwiki der Fall wäre.

Das Entwurf-System ist sehr effektiv, um schnell Test-Vorlagen auf einer Seite zu testen, indem man die Vorschau der Seite, bei angefügtem /Entwurf an den Vorlagen-Namen, nutzt. Das ist ähnlich, wie wenn man /Sandkasten nutzt. Das klappt bei allen Vorlagen, nicht nur Infoboxen.

.portable-infobox und anderes PI-spezifisches CSS in ein seperates Stylesheet (MediaWiki:Themes.css), was durch MediaWiki:Wikia.css importiert wird, zu verschieben, kann auch hilfreich sein. Die Importzeile im Haupt-Stylesheet @import url("/load.php?mode=articles&articles=MediaWiki:Themes.css&only=styles"); lädt das Themes.css in optimierter Form.

Fazit

Klassisches Infoboxen zu PIs zu konvertieren macht sie zukünftig einfacher zu unterhalten und erlaubt umfassende Style-Änderungen, ohne viele Vorlagen umschreiben zu müssen. Die Sprache ist dafür ausgelegt, flexibel und mächtig zu sein. Wenn du auf Probleme beim Umwandeln stößt, suche dir gerne Hilfe im technischen Forum der Community Deutschland, im Portabilitäts-Hub oder sprich ein Vanguard-Mitglied an.