Stores & Multi-Language

<div class="prose prose-hyva max-w-none"><p>The difference between website, store and store view – and how to create a new store view.</p><p>Magento organizes multiple shop variants across three hierarchical levels, managed under <em>Stores &gt; Settings &gt; All Stores</em>:</p> <ul> <li><strong>Website:</strong> the top level, usually its own domain or a completely separate customer base/catalog. Customer accounts are shared across websites by default, but can be isolated per website.</li> <li><strong>Store:</strong> a product line or brand within a website, with its own root category tree – two stores of the same website can have completely different category structures.</li> <li><strong>Store View:</strong> the concrete, visitor-facing variant, usually per language – e.g. "Deutsch" and "English" within the same store, with an identical product catalog but translated content.</li> </ul> <h3>When do I need more than one level?</h3> <p>For pure multi-language setups (one catalog, multiple languages, as on this project), ONE website and ONE store with multiple store views is usually enough. Multiple websites only make sense for genuinely separate business models (e.g. a B2C and a B2B shop with different domains and customer bases), multiple stores for different assortments under the same domain (e.g. two brands with their own category tree).</p> <h3>Creating a new store view</h3> <p>Use <strong>Create Store View</strong> to create a new one: assign it to a store, give it a <strong>Name</strong> (visible in the backend dropdown) and a <strong>Code</strong> (technical identifier, used internally for store-switch URLs and CLI commands, should be short and free of special characters), set <strong>Status</strong> to "Enabled". Then, under <em>Stores &gt; Configuration</em>, use the scope dropdown in the top left to select the new store view and set store-specific values such as language or base currency – without this step, the new store view technically exists but is content-identical to the original.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/storeview9kategore.png}}" alt="StoreView" /> <h3>Root category and default store view per store</h3> <p>When editing a <strong>Store</strong> (not a Store View!) under <em>Stores &gt; Settings &gt; All Stores</em> – click the store row itself, not one of its store views – you'll find two key fields: <strong>Root Category</strong> defines which node in the category tree serves as the navigation root for all store views belonging to that store (the main menu and category pages only show subcategories of that root category). <strong>Default Store View</strong> determines which store view loads when a visitor opens the store's base URL without explicitly choosing a language. Practical tip: give each store its own root category, even if the product catalog stays identical – otherwise you won't be able to structure category pages per store later on.</p> <h3>Sort order in the store switcher</h3> <p>Alongside Name, Code and Status, the store view edit form also has a <strong>Sort Order</strong> field. It controls the order in which store views appear in the admin's scope dropdown and in the storefront's store/language switcher – lower values are shown first. Without an explicit sort order, new store views typically end up at the end of the list, which quickly gets confusing as the number of languages grows.</p> <h3>Disabling a store view instead of deleting it</h3> <p>A store view can be permanently removed via the delete action, but that irreversibly wipes all associated URL rewrites and store-specific content. Practical tip: set <strong>Status</strong> to "Disabled" in the edit form instead, when a language should be temporarily or permanently taken offline – the store view then survives as a data container and can be reactivated later. Every status change requires a full cache flush and reindex, since disabled store views must disappear from places like the sitemap and the store switcher.</p></div>

<div class="prose prose-hyva max-w-none"><p>How to set up a second store view for another language and translate your content.</p><p>After creating a new store view (see the previous chapter), these steps are needed for a working translation:</p> <ol> <li><strong>Install the language pack:</strong> language packs are installed via Composer (e.g. <code>en_US</code> is usually pre-installed). Under <em>Stores &gt; Configuration &gt; General &gt; General &gt; Locale Options</em>, select the right language within that store view's scope.</li> <li><strong>Translate store-scoped attributes:</strong> product and category fields like name, description, and URL key can be maintained separately per language when their attribute scope is "Store View" – open them in the store view scope and translate (see the "Attributes and Attribute Sets" chapter).</li> <li><strong>Translate CMS content:</strong> CMS pages and blocks are also store-scoped – maintain a separate version of the content for each language (switch the scope in the top left).</li> <li><strong>Theme translations:</strong> fixed theme text (buttons, labels, system messages) is adjusted via CSV translation files in the theme, or via <em>Content &gt; Design &gt; Themes &gt; Translate Inline</em> – the latter overlays clickable translation fields directly on top of the visible text on the storefront.</li> </ol> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/localeoptions9kategorie.png}}" alt="Store-View" /> <h3>URL keys per language</h3> <p>Important: the URL key should be different per language and phrased in that language (e.g. <em>/products/shoes.html</em> vs. <em>/produkte/schuhe.html</em>) – this significantly improves both user experience and SEO performance in that language, since search engines struggle to rank foreign-language URL segments as well.</p> <h3>The storefront store switcher</h3> <p>The language switch on the storefront runs through Magento's built-in store switcher: clicking a different language in the header resolves the matching, translated URL of the same page (for products and categories, automatically via the stored per-store-view URL keys) and sets a language cookie that keeps the visitor in the chosen language on future visits.</p> <h3>Theme translation files (i18n CSV) in detail</h3> <p>Fixed theme text strings are stored in CSV files under <code>app/design/frontend/[Vendor]/[Theme]/i18n/[locale].csv</code>, e.g. <code>de_DE.csv</code>. Each line has two columns: the exact original string from the PHTML/JS code (capitalization and punctuation must match exactly) and its translation, both quoted. After creating or editing a CSV file, a static content deploy and a cache flush are required before the translation shows up on the storefront – simply reloading the page is not enough.</p> <h3>Enabling inline translation</h3> <p>For the "Translate Inline" feature mentioned in step 4 to work at all, it first has to be enabled under <em>Stores &gt; Configuration &gt; Advanced &gt; Developer &gt; Translate Inline</em>, separately for <strong>Enabled for Frontend</strong> and <strong>Enabled for Admin</strong>. Practical tip: Translate Inline only works in default or developer mode – in production mode the feature stays inactive even with the configuration enabled, which often causes confusion when a live shop runs in production mode.</p> <h3>Adjusting email templates per language</h3> <p>Transactional emails (order confirmation, invoice, password reset) use the system template in the respective store view's language by default. For custom content, go to <em>Marketing &gt; Communications &gt; Email Templates</em>, use "Load default template" to create a copy of the desired default template, edit it and save it under a new name. The new template then has to be assigned as the template to use in the relevant store-view-scoped configuration section (e.g. <em>Stores &gt; Configuration &gt; Sales &gt; Sales Emails</em> for order emails) – without that assignment the new template stays inactive.</p></div>

<div class="prose prose-hyva max-w-none"><p>The most important settings under Stores > Configuration: country, currency, timezone and more.</p><p>Under <em>Stores &gt; Configuration</em> lives practically the entire base configuration of Magento, organized into sections on the left (General, Catalog, Sales, ...). The important concept to understand is the <strong>Scope</strong> (dropdown in the top left):</p> <ul> <li><strong>Default Config:</strong> the global base setting, applies everywhere no more specific value has been set.</li> <li><strong>Website scope:</strong> overrides the default values for a specific website.</li> <li><strong>Store View scope:</strong> overrides them again for a specific language/store view – this is where you set the language itself, for example.</li> </ul> <h3>Particularly relevant areas under General</h3> <ul> <li><strong>Country Options:</strong> default country and allowed countries for addresses.</li> <li><strong>Locale Options:</strong> language, timezone, first day of the week.</li> <li><strong>Store Information:</strong> company name, address, phone number – shows up on invoices and shipping documents, among other places.</li> <li><strong>Currency Setup:</strong> base currency, allowed currencies and exchange rate source.</li> </ul> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/configuration9kategorie.png}}" alt="configuration" /> <p>A helpful detail: the small <strong>Use Website</strong>/<strong>Use Default</strong> checkbox next to every field shows whether the value is still inherited or has been overridden at this scope – a quick glance tells you immediately where you've already configured something individually.</p> <h3>Setting up base URLs correctly</h3> <p>Under <em>Stores &gt; Configuration &gt; General &gt; Web</em>, in the <strong>Base URLs</strong> section, you define <strong>Base URL</strong> (the main domain), <strong>Base Link URL</strong>, <strong>Base URL for Static View Files</strong> and <strong>Base URL for User Media Files</strong> – the latter three default to the placeholder <code>{{base_url}}</code> and therefore automatically inherit the main URL. The <strong>Base URLs (Secure)</strong> section below has the same fields for HTTPS, plus <strong>Use Secure URLs on Storefront</strong> and <strong>Use Secure URLs in Admin</strong>. Practical tip: a full cache flush is required after any change to a base URL, since stale or incorrect cached URLs otherwise break links throughout the entire shop.</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>Defining default pages</h3> <p>In the <strong>Default Pages</strong> section (also under <em>Stores &gt; Configuration &gt; General &gt; Web</em>) you set the <strong>CMS Home Page</strong> (the homepage), the <strong>CMS No Route Page</strong> (shown for URLs that don't exist, replacing the generic 404 page) and the <strong>CMS No Cookies Page</strong>. This setting can be overridden at store view scope – for a multi-language project that means each language can have its own translated homepage and error pages, instead of the German CMS pages also showing up in the English store view.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/defaultpages9kategorie.png}}" alt="defaultpages" /> <h3>Configuring Store Email Addresses as senders</h3> <p>The <strong>Store Email Addresses</strong> section under <em>Stores &gt; Configuration &gt; General</em> defines up to four sender identities (<strong>General Contact</strong>, <strong>Sales Representative</strong>, <strong>Customer Support</strong>, <strong>Custom Email 2</strong>), each with <strong>Sender Name</strong> and <strong>Sender Email</strong> fields. These identities are selected as the sender in the various email-related configuration sections (e.g. Sales Emails, Newsletter, contact form) and should be set to a language-appropriate sender address per store view.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/generalcontact9kategorie.png}}" alt="generalcontact" /> <h3>Single-Store Mode – when it does NOT apply</h3> <p>Under <em>Stores &gt; Configuration &gt; General &gt; General</em> you'll find the <strong>Single-Store Mode</strong> field, which, when enabled, hides the website/store selectors from the admin menu and simplifies the admin interface. Practical tip: for a multi-language project with several store views, this option has no effect and should stay disabled, since it's meant exclusively for setups with a single website, a single store and a single store view – with multiple store views, the scope selector and store switcher stay visible regardless.</p> <img loading="lazy" src="{{media url=wysiwyg/handbuch/1kapitel/singlestore9kategorie.png}}" alt="singlestore" /> </div>