Stores & Mehrsprachigkeit

<div class="prose prose-hyva max-w-none"><p>Der Unterschied zwischen Website, Store und Store View – und wie Sie einen neuen Store View anlegen.</p><p>Magento organisiert mehrere Shop-Varianten in drei hierarchischen Ebenen, verwaltet unter <em>Stores &gt; Settings &gt; All Stores</em>:</p> <ul> <li><strong>Website:</strong> die oberste Ebene, meist eine eigene Domain oder ein komplett getrennter Kundenstamm/Katalog. Kundenkonten sind standardmäßig websiteübergreifend geteilt, können aber pro Website isoliert werden.</li> <li><strong>Store:</strong> eine Produktlinie oder Marke innerhalb einer Website, mit eigenem Root-Kategoriebaum – zwei Stores derselben Website können komplett unterschiedliche Kategoriestrukturen haben.</li> <li><strong>Store View:</strong> die konkrete, für Besucher sichtbare Ausprägung, meist für eine Sprache – z. B. "Deutsch" und "English" innerhalb desselben Stores, mit identischem Produktkatalog, aber übersetzten Inhalten.</li> </ul> <h3>Wann brauche ich mehr als eine Ebene?</h3> <p>Für reine Mehrsprachigkeit (ein Katalog, mehrere Sprachen, wie in diesem Projekt) reicht in der Regel EINE Website und EIN Store mit mehreren Store Views. Mehrere Websites lohnen sich erst bei wirklich getrennten Geschäftsmodellen (z. B. B2C- und B2B-Shop mit unterschiedlichen Domains und Kundenstämmen), mehrere Stores bei unterschiedlichen Sortimenten unter derselben Domain (z. B. zwei Marken mit eigenem Kategoriebaum).</p> <h3>Einen neuen Store View anlegen</h3> <p>Über <strong>Create Store View</strong> legen Sie einen neuen an: Store zuordnen, <strong>Name</strong> (im Backend-Dropdown sichtbar) und <strong>Code</strong> (technischer Bezeichner, wird intern u. a. für Store-Switch-URLs und CLI-Befehle verwendet, sollte kurz und ohne Sonderzeichen sein) vergeben, <strong>Status</strong> auf "Enabled" setzen. Danach unter <em>Stores &gt; Configuration</em> im Scope-Dropdown links oben den neuen Store View auswählen, um store-spezifische Werte wie Sprache oder Basis-Währung zu setzen – ohne diesen Schritt bleibt der neue Store View technisch zwar existent, aber inhaltlich identisch zum Ursprung.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/storeview9kategore.png}}" alt="StoreView" /> <h3>Root-Kategorie und Standard-Store-View je Store</h3> <p>Beim Bearbeiten eines <strong>Store</strong> (nicht Store View!) unter <em>Stores &gt; Settings &gt; All Stores</em> – Klick auf die Store-Zeile, nicht auf einen einzelnen Store View – finden Sie zwei zentrale Felder: <strong>Root Category</strong> legt fest, welcher Knoten im Kategoriebaum als Navigationswurzel für alle Store Views dieses Stores dient (Hauptmenü und Kategorieseiten zeigen nur Unterkategorien dieser Root Category). <strong>Default Store View</strong> bestimmt, welcher Store View geladen wird, wenn ein Besucher die Basis-URL des Stores ohne explizite Sprachwahl aufruft. Praxis-Tipp: Legen Sie für jeden Store eine eigene Root Category an, auch wenn der Produktkatalog identisch bleibt – sonst lassen sich Kategorieseiten später nicht store-spezifisch strukturieren.</p> <h3>Sortierreihenfolge im Store-Switcher</h3> <p>Im Bearbeitungsformular eines Store Views gibt es neben Name, Code und Status auch das Feld <strong>Sort Order</strong>. Es bestimmt die Reihenfolge, in der die Store Views im Scope-Dropdown des Backends und im Store-/Sprach-Switcher des Frontends erscheinen – niedrigere Werte werden zuerst angezeigt. Ohne explizite Sortierung erscheinen neue Store Views meist am Ende der Liste, was bei einer wachsenden Zahl an Sprachen schnell unübersichtlich wird.</p> <h3>Store View deaktivieren statt löschen</h3> <p>Ein Store View lässt sich zwar über die Papierkorb-Aktion vollständig löschen, das entfernt aber unwiderruflich alle zugehörigen URL-Rewrites und store-spezifischen Inhalte. Praxis-Tipp: Setzen Sie stattdessen im Bearbeitungsformular <strong>Status</strong> auf "Disabled", wenn eine Sprache temporär oder dauerhaft nicht mehr live sein soll – der Store View bleibt so als Datencontainer erhalten und kann bei Bedarf reaktiviert werden. Nach jeder Statusänderung ist ein vollständiger Cache-Flush sowie ein Reindex nötig, da deaktivierte Store Views z. B. aus der Sitemap und dem Store-Switcher verschwinden müssen.</p></div>

<div class="prose prose-hyva max-w-none"><p>Wie Sie einen zweiten Store View für eine weitere Sprache einrichten und Inhalte übersetzen.</p><p>Nach dem Anlegen eines neuen Store Views (siehe vorheriges Kapitel) sind diese Schritte für eine funktionierende Übersetzung nötig:</p> <ol> <li><strong>Sprachpaket installieren:</strong> Sprachpakete werden per Composer installiert (z. B. <code>en_US</code> ist meist vorinstalliert). Unter <em>Stores &gt; Configuration &gt; General &gt; General &gt; Locale Options</em> im entsprechenden Store-View-Scope die passende Sprache auswählen.</li> <li><strong>Store-spezifische Attribute übersetzen:</strong> Produkt- und Kategoriefelder wie Name, Beschreibung, URL-Key sind bei entsprechendem Attribut-Scope ("Store View") pro Sprache separat pflegbar – im Store-View-Scope öffnen und übersetzen (siehe Kapitel "Attribute und Attributsets").</li> <li><strong>CMS-Inhalte übersetzen:</strong> CMS-Seiten und -Blöcke sind ebenfalls store-spezifisch – für jede Sprache eine eigene Version des Inhalts hinterlegen (Scope oben links wechseln).</li> <li><strong>Theme-Übersetzungen:</strong> feste Textbausteine des Themes (Buttons, Labels, Systemmeldungen) werden über CSV-Übersetzungsdateien im Theme oder per <em>Content &gt; Design &gt; Themes &gt; Translate Inline</em> angepasst – Letzteres blendet im Frontend anklickbare Übersetzungsfelder direkt über den sichtbaren Texten ein.</li> </ol> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/localeoptions9kategorie.png}}" alt="Store-View" /> <h3>URL-Keys pro Sprache</h3> <p>Wichtig: Der URL-Key sollte pro Sprache unterschiedlich und in der jeweiligen Sprache formuliert sein (z. B. <em>/produkte/schuhe.html</em> vs. <em>/products/shoes.html</em>) – das verbessert sowohl die Nutzererfahrung als auch die SEO-Performance in der jeweiligen Sprache erheblich, da Suchmaschinen fremdsprachige URL-Segmente schlechter einordnen können.</p> <h3>Store-Switcher im Frontend</h3> <p>Der Sprachwechsel im Shop-Frontend läuft über Magentos eingebauten Store-Switcher: Beim Klick auf eine andere Sprache im Header wird die passende, übersetzte URL derselben Seite ermittelt (für Produkte und Kategorien automatisch über die hinterlegten Store-View-URL-Keys) und ein Sprach-Cookie gesetzt, das den Besucher bei zukünftigen Aufrufen in der gewählten Sprache belässt.</p> <h3>Theme-Übersetzungsdateien (i18n-CSV) im Detail</h3> <p>Feste Textbausteine des Themes werden in CSV-Dateien unter <code>app/design/frontend/[Vendor]/[Theme]/i18n/[locale].csv</code> hinterlegt, z. B. <code>de_DE.csv</code>. Jede Zeile besteht aus zwei Spalten: dem exakten Original-String aus dem PHTML-/JS-Code (Groß-/Kleinschreibung und Satzzeichen müssen exakt übereinstimmen) und der Übersetzung, jeweils in Anführungszeichen. Nach dem Anlegen oder Ändern einer CSV-Datei ist ein Static-Content-Deploy sowie ein Cache-Flush nötig, damit die Übersetzung im Frontend sichtbar wird – reines Neuladen der Seite reicht nicht.</p> <h3>Inline-Übersetzung aktivieren</h3> <p>Damit die in Schritt 4 erwähnte "Translate Inline"-Funktion überhaupt nutzbar ist, muss sie zuerst unter <em>Stores &gt; Configuration &gt; Advanced &gt; Developer &gt; Translate Inline</em> separat für <strong>Enabled for Frontend</strong> und <strong>Enabled for Admin</strong> aktiviert werden. Praxis-Tipp: Translate Inline funktioniert ausschließlich im Default- oder Developer-Modus – im Production-Modus bleibt die Funktion auch bei aktivierter Konfiguration wirkungslos, was in der Praxis häufig für Verwirrung sorgt, wenn ein Live-Shop im Production-Modus läuft.</p> <h3>E-Mail-Vorlagen je Sprache anpassen</h3> <p>Transaktionale E-Mails (Bestellbestätigung, Rechnung, Passwort-Reset) verwenden standardmäßig die Systemvorlage in der jeweiligen Store-View-Sprache. Für individuell angepasste Inhalte legen Sie unter <em>Marketing &gt; Communications &gt; Email Templates</em> über "Load default template" eine Kopie der gewünschten Standardvorlage an, bearbeiten und speichern sie unter neuem Namen. Anschließend muss die neue Vorlage im jeweiligen Store-View-Scope unter der passenden Konfigurationsstelle (z. B. <em>Stores &gt; Configuration &gt; Sales &gt; Sales Emails</em> für Bestellmails) als zu verwendende Vorlage hinterlegt werden – ohne diese Zuordnung bleibt die neue Vorlage inaktiv.</p></div>

<div class="prose prose-hyva max-w-none"><p>Die wichtigsten Einstellungen unter Stores > Configuration: Land, Währung, Zeitzone und mehr.</p><p>Unter <em>Stores &gt; Configuration</em> liegt praktisch die gesamte Grundkonfiguration von Magento, organisiert in Bereiche links (General, Catalog, Sales, ...). Wichtig zu verstehen ist der <strong>Scope</strong> (Dropdown oben links):</p> <ul> <li><strong>Default Config:</strong> die globale Grundeinstellung, gilt überall dort, wo kein spezifischerer Wert gesetzt ist.</li> <li><strong>Website-Scope:</strong> überschreibt die Default-Werte für eine bestimmte Website.</li> <li><strong>Store-View-Scope:</strong> überschreibt sie nochmal für eine bestimmte Sprache/Store View – hier setzen Sie z. B. die Sprache selbst.</li> </ul> <h3>Besonders relevante Bereiche unter General</h3> <ul> <li><strong>Country Options:</strong> Standardland und erlaubte Länder für Adressen.</li> <li><strong>Locale Options:</strong> Sprache, Zeitzone, Wochenstart.</li> <li><strong>Store Information:</strong> Firmenname, Adresse, Telefonnummer – erscheint u. a. auf Rechnungen und Versandbelegen.</li> <li><strong>Currency Setup:</strong> Basis-Währung, zulässige Währungen und Wechselkursquelle.</li> </ul> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/configuration9kategorie.png}}" alt="configuration" /> <p>Ein hilfreiches Häkchen: das kleine Kästchen <strong>Use Website</strong>/<strong>Use Default</strong> neben jedem Feld zeigt an, ob der Wert noch geerbt wird oder store-spezifisch überschrieben wurde – ein Blick darauf verrät sofort, wo Sie bereits individuell konfiguriert haben.</p> <h3>Base URLs korrekt setzen</h3> <p>Unter <em>Stores &gt; Configuration &gt; General &gt; Web</em> im Bereich <strong>Base URLs</strong> definieren Sie <strong>Base URL</strong> (Haupt-Domain), <strong>Base Link URL</strong>, <strong>Base URL for Static View Files</strong> und <strong>Base URL for User Media Files</strong> – letztere drei stehen standardmäßig auf dem Platzhalter <code>{{base_url}}</code> und übernehmen damit automatisch die Haupt-URL. Im Bereich <strong>Base URLs (Secure)</strong> darunter gelten dieselben Felder für HTTPS, ergänzt um <strong>Use Secure URLs on Storefront</strong> und <strong>Use Secure URLs in Admin</strong>. Praxis-Tipp: Nach jeder Änderung an einer Base URL ist ein vollständiger Cache-Flush zwingend nötig, da falsche oder gecachte URLs sonst zu kaputten Links im gesamten Shop führen.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/baseurl9kategorie.png}}" alt="baseurl" /> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/basesecure9kategorie.png}}" alt="basesecureurl" /> <h3>Standardseiten festlegen</h3> <p>Im Bereich <strong>Default Pages</strong> (ebenfalls unter <em>Stores &gt; Configuration &gt; General &gt; Web</em>) legen Sie die <strong>CMS Home Page</strong> (Startseite), die <strong>CMS No Route Page</strong> (angezeigt bei nicht existierenden URLs, Ersatz für die generische 404-Seite) und die <strong>CMS No Cookies Page</strong> fest. Diese Einstellung ist im Store-View-Scope überschreibbar – für ein mehrsprachiges Projekt bedeutet das, jede Sprache kann eine eigene, übersetzte Startseite und eigene Fehlerseiten haben, statt die deutschen CMS-Seiten auch im englischen Store View anzuzeigen.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/defaultpages9kategorie.png}}" alt="defaultpages" /> <h3>Store Email Addresses für den Absender konfigurieren</h3> <p>Der Bereich <strong>Store Email Addresses</strong> unter <em>Stores &gt; Configuration &gt; General</em> definiert bis zu vier Absenderidentitäten (<strong>General Contact</strong>, <strong>Sales Representative</strong>, <strong>Customer Support</strong>, <strong>Custom Email 2</strong>), jeweils mit den Feldern <strong>Sender Name</strong> und <strong>Sender Email</strong>. Diese Identitäten werden in den jeweiligen E-Mail-Konfigurationen (z. B. Sales Emails, Newsletter, Kontaktformular) als Absender ausgewählt und sollten pro Store View auf eine sprachlich passende Absenderadresse gesetzt werden.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/generalcontact9kategorie.png}}" alt="generalcontact" /> <h3>Single-Store Mode – wann er NICHT greift</h3> <p>Unter <em>Stores &gt; Configuration &gt; General &gt; General</em> findet sich das Feld <strong>Single-Store Mode</strong>, das bei Aktivierung die Website-/Store-Auswahl im Backend-Menü ausblendet und die Admin-Oberfläche vereinfacht. Praxis-Tipp: Für ein mehrsprachiges Projekt mit mehreren Store Views bleibt diese Option ohne Wirkung bzw. sollte deaktiviert bleiben, da sie ausschließlich für Setups mit nur einer einzigen Website, einem Store und einem Store View gedacht ist – bei mehreren Store Views bleiben Scope-Auswahl und Store-Switcher zwingend sichtbar.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/singlestore9kategorie.png}}" alt="singlestore" /> </div>