Managing glossary keys

Edit on GitHub

Glossary keys present two layers of persistence:

  • SQL database storage
  • In-memory key-value storage: Redis

This document shows how to manage the glossary keys of the Back Office user interface and how to manage the glossary keys of the Storefront interface via Twig extensions.

Update, insert and delete operations for glossary keys are exposed in the Glossary module through the GlossaryFacade class.

For update and insert operations, GlossaryFacade exposes saveGlossaryKeyTranslations that can be accessed as follows:


//Delete the translation for a glossary key

Retrieving glossary keys

The support for listing the glossary keys is exposed through GlossaryBusinessContainer:

$grid = $this->getFactory()->createGlossaryKeyTranslationGrid($request);
  • getEnabledLocales() retrieves the list of locales that are contained in the stores.php configuration file.
  • createGlossaryKeyTranslationGrid() queries the database for the list of glossary keys for each of the supported languages.
Removing locales from configuration

If a locale is removed from configuration, the glossary keys for the locale are not retrieved from the database, even if they exist.

Configuring locales

Locales are configured in config/Shared/stores.php as follows:


Using glossary keys

On the Storefront, you can use glossary keys to translate rendered content. The following example shows how to do it using a dedicated extension for the Twig template engine:

<div><label>{{ 'First Name' | trans }}</label>

        <input type="text" name="first_name" value="{{ form.first_name.value }}">
        {#{{ form_row(form.first_name) }}#}


The keyword trans marks an operation exposed by the TwigTranslator extension. This means that the text of the label is either the default value provided in the view or the corresponding translation for it.