Skip to main content
A text snippet consists of a name and a text. The template only references the name, not the text itself. That way the text is changed in one place and the change takes effect everywhere the snippet is used. Typical examples are buttons, notes, error messages, and legal texts. The name is the technical identifier under which the template or a configuration requests the text. The text is what the customer reads in the shop.

​
Languages are the foundation

Text snippets always exist in the context of a language. Three points belong together here:
  • Each language is created once in the shop. It is an independent object in the configuration, not in the text snippet service.
  • Each subshop has exactly one language. Which text a customer sees depends on which subshop they call: the subshop determines the language, the language determines the text.
  • A text snippet has its own version per language. The name is always the same, the text differs.
As long as no language has been created and assigned to a subshop, there are also no texts the shop could output. How languages are created, assigned, and chained together is described under Creating and assigning languages.

​
Text maintenance

The texts are maintained in the Admin Interface under the service Templates und Content -> Textbausteine und Übersetzungen, reachable at:
Permissions are granted per service, under Einstellungen -> Benutzer -> Benutzer bearbeiten. For text snippets there are five of them: An import, for example, requires the “Create” and “Edit” permissions.
The permissions always apply to the entire service and not just to individual languages. Anyone who may read texts sees all languages. Anyone who may edit can change all languages. Restricting access to individual languages, for example for external translators, is currently not possible. For a translation job, the export of a single language is therefore the more suitable way.

​
The overview

Textblocks Lang3

Screenshot as of 25.08.2026

The service shows a table in which each row corresponds to a text snippet and each column to a language. Up to three languages can be compared side by side and edited directly in the table. You can choose which languages appear as columns yourself. They can be reordered via drag & drop. The left language column is the focus language. It is highlighted and the availability filters always refer to it and not to the other visible columns. If you drag a language all the way to the left, it becomes the focus language.

​
The availability status

The availability status indicates the state of a text snippet in a specific language. There are three variants, color-coded in the cells:
  • green = maintained: A text is present.
  • yellow = empty: An entry exists for this language, but without content.
  • red = missing: No entry exists yet for this language.
This makes it easy to see at a glance where gaps still exist in a language.

​
Searching and filtering

Since many text snippets across multiple languages accumulate over time, the overview can be searched and filtered.
  • Search: by name and text.
  • Availability: exactly the three colors from the table. You can therefore specifically display all snippets that are empty or missing in the focus language and work through the gaps of a language. Several states can be combined. Everything that has one of the selected states is then displayed.
  • Type: system text snippets or custom text snippets.
  • Usage: whether the snippet is referenced in a template. The reference can be restricted to a single subshop, because the templates of different subshops can use different snippets. How this state comes about is described under Effect in the shop.
  • Namespace: a tree view over the dot levels of the names. The tree is not predefined but arises from the names that actually exist in the shop: shop.checkout.button.label produces the levels shop, shop.checkout, and shop.checkout.button. How useful this filter is therefore depends on how consistently the names are chosen. If you name new snippets according to a fixed scheme, for example with a prefix per shop area, you can later filter out a specific area.

​
Editing texts

You change a text either directly in the overview in the cell of the respective language or in the detail view of the text snippet, which you open via the context menu with Edit. In both cases, a simple text field is available for each language. The text is saved exactly as you enter it. You therefore enter formatting as HTML markup directly in the text, for example <strong> for bold, <br> for a line break, or <a href="…"> for a link. The shop does not automatically convert paragraphs and line breaks from the text field into HTML.
The former style editor with switching between Use style editor and Edit source code has been removed. If a text needs paragraphs or emphasis, enter the appropriate HTML markup manually.

​
System and custom text snippets

​
System text snippets

System text snippets are generated automatically by the shop. They arise from configuration fields that are predefined by the system and not editable. These are usually error texts. Their name begins with ws.error. Such fields exist not only in the actions, but also in other areas such as checkout, user accounts, and external data sources. In the configuration, the field does not carry the error text itself, only the name of the text snippet. The text is maintained exclusively here in the text snippet service.
With shop updates, new system text snippets are added continuously as soon as new configuration areas or extensions are delivered. These are usually delivered with German text, and only in the main language of the respective subshop. You have to enter texts for further languages yourself.After an update, it is therefore worth taking a look at the availability filter: setting the focus language to the language in question and filtering by missing shows exactly the newly added gaps.
What you may and may not do with system text snippets:
  • The text is freely changeable. This applies in every language and without restriction. You can therefore fully adapt the phrasing of an error message to your own wording.
  • The name is locked. System text snippets can neither be renamed nor deleted, not even per language. The shop references this name at a fixed place. Without it, there would be no text there.

​
Custom text snippets

When a shop is provisioned, an extensive set of custom, freely changeable text snippets is included. The templates themselves contain no texts; all texts reside in the text snippets. This makes it possible to adapt the entire wording of a shop via this service without having to modify the templates themselves. Beyond that, you can create any number of custom text snippets, for example for individual notes or content that is only needed in this shop. These can be fully created, edited, renamed, and deleted again. Allowed characters in the name: letters a to z and A to Z, digits 0 to 9, dot ., and underscore _. Spaces, hyphens, umlauts, and all other special characters are not allowed. The dot is more than a separator: it forms the levels of the namespace filter (see Searching and filtering). The prefix ws. is reserved for system text snippets and cannot be assigned.
It is not enough to create a text snippet for it to appear in the shop. In addition, the name must be inserted at the desired place in the template or in the configuration. The reverse applies to deleting: first remove the snippet from the template and configuration and then delete it. Otherwise, the output location references a name that no longer exists.
How a text snippet is embedded in the template is described under Template engine.

​
Text snippets in configurations

Not only templates but also configurations reference text snippets. Wherever a configuration contains a text that is displayed in the frontend, the name of a text snippet can be used instead of a fixed value. This is not limited to system text snippets. You can also reference custom snippets there. The advantage: the same configuration can be used in several language versions of a shop without duplicating it per language. Details under Using text snippets in configurations. A text snippet referenced by a configuration cannot be deleted as long as the reference exists. Remove the reference in the configuration first.

​
Cleaning up unused snippets

The unused filter shows text snippets that no longer appear in any template. This is more than cosmetics. After a relaunch, a template rebuild, or larger changes to the shop, superfluous snippets regularly remain behind. As long as they are in the list, they reappear with every new language and get translated along with everything else. If you filter for unused snippets and clean them up before adding a new subshop or a new language, you save this effort. Only the texts that the shop actually outputs are then displayed and translated.
Before deleting, check whether the state is up to date: usage is determined during template compilation (see Effect in the shop). Immediately after a template change without republishing, the display is not yet up to date.
The shop only recognizes text snippets as used if they appear in the template in the notation %%Textbausteinname%%. Snippets that a template outputs exclusively via the translate function therefore appear under unused. Do not delete such snippets, otherwise the translate function will no longer return any text at this point.

​
Creating and assigning languages

This section concerns shop administration. It is not needed for day-to-day editorial work. It explains how the languages that the text snippet service works with come into being.
Languages are not maintained in the text snippet service but in the shop configuration. Three steps are involved, and their order also explains how inheritance works.

​
1. Create the language

Each language is its own configuration node under general.language with a name and an ISO code. Reference and parameters: general - General shop settings.
As soon as a language exists, it is displayed in the text snippet service as a selectable column. Initially, it is marked red everywhere, because no text has been entered yet.

​
2. Assign the language to a subshop

A subshop gets exactly one language. It is entered in two places, and both must name the same language:
The most commonly overlooked point is that there are two places. If only one of them is changed, the error remains inconspicuous, because the shop continues to display texts - just the wrong ones. For example, an Austrian subshop then still appears with German texts even though Austrian language variants are maintained.In this case, first check whether general.subshopView and general.subshop specify the same language.

​
3. Set fallback languages

Textblocks Languagechains

Screenshot as of 25.08.2026

So that not every language variant has to be fully maintained, a language can have an ordered list of fallback languages. If a text is missing or empty in the actual language, the next language in this list takes effect. What matters is where this list is entered. It belongs to the language and not to the subshop, which only brings along its one language. Which fallback languages stand behind it is decided by the language itself. This results in the effective order:
An example for an Austrian subshop:
  1. The subshop gets the language German (AT).
  2. For the language German (AT), German is entered as the fallback language.
  3. Result: if a text is missing in German (AT), the shop displays the German text.
The chain therefore always points from the more specific language to the more general one.
Anyone coming from WEBSALE V8s often expects the opposite pattern: a master language DEU with the variants AT and CH entered as fallback languages. That does not lead to the goal and is the most common reason why a subshop shows the texts of the base language despite a maintained language variant.The correct way is the reverse: AT and CH are separate languages, and for each of them, DEU is entered as the fallback language.
Chains can be multi-stage. A very specific variant first falls back to a more general language and only then to the base language. The rule here: the chain is not inherited further. Each language carries its complete list itself. For de-at-b2b to fall through de-at down to de, both must be entered for de-at-b2b. It is not enough for de-at to reference de itself. The effect for editors: it is not necessary to maintain every text in all language variants. It is enough to fully maintain the base language. More specific variants automatically take over its contents as long as they contain no text of their own. Only when a variant needs a deviating text does it have to be entered there deliberately. It then overrides the inherited version only for this language.
For the output in the shop, empty and missing behave the same: both trigger the fallback to the fallback language. A deliberately empty stored text therefore does not suppress the output. As long as any language in the chain contains a text, that text is displayed. To actually display nothing at a given place, the text must be empty or missing in all languages of the chain.The difference between the two states is therefore mainly an indicator for editors, as it shows whether a language has already been worked on.

​
Effect in the shop

Two points are central for understanding, because they easily lead to confusion:
1

The text snippet must be embedded in the template

A text snippet is only displayed if it is embedded in the template at the appropriate place. Creating or changing a text snippet alone is therefore not enough. The respective shop page must also actually reference this text snippet at the corresponding place. If you change an already embedded text snippet, the change takes effect immediately. A completely new text snippet only appears in the frontend after it has additionally been inserted into the respective template.
2

Changes only become visible after publishing

Until publication, changes remain in the editing state, so customers cannot see them yet. During publishing, the templates are recompiled with the most recently changed texts. This is the same process that also recalculates the usage state.
For the usage filter, this means: it reflects the state of the last compilation, not the current template content. After changes to templates, it is only up to date after republishing. A pure text change without a template change does not change the usage.

​
Import and export

Textblocks Export

Screenshot as of 25.08.2026

Larger amounts of text snippets can be exported and imported again, for example to have them translated externally or to apply changes in bulk. This can be limited to a single language, so that for example only the French texts are exported, translated externally, and then imported again. The export takes the currently set search and the set filters into account. Both processes run in the background and are accompanied by a progress indicator. Imported texts also only become visible in the shop after publication. System text snippets can be updated via import, but not newly created. The ws. prefix remains reserved for the system.
Before larger or destructive actions, an export is recommended as a backup, because an export can be re-imported unchanged.

​
Guide