coder.dictionary.Entry Class
Namespace: coder.dictionary
Configure Embedded Coder Dictionary definition
Description
An object of the coder.dictionary.Entry
class represents one definition of
an Embedded Coder® Dictionary. In this API, the object is called an entry. The
information that the object represents is a definition. In this
documentation, definition refers to the definition of the entry
object.
A coder.Dictionary
object contains coder.dictionary.Section
objects, which represent the categories of an Embedded
Coder Dictionary. A coder.dictionary.Section
object contains
coder.dictionary.Entry
objects, which represent the definitions stored in
that section of the Embedded Coder Dictionary. The name of the section identifies the type of
code definitions that the section contains. To access the sections of an Embedded Coder
Dictionary, use a coder.Dictionary
object. To access the dictionary entries
within the section, use a coder.dictionary.Section
object.
Creation
The functions addEntry
,
getEntry
,
copyEntry
, and
find
create
coder.dictionary.Entry
objects.
Properties
A coder.dictionary.Entry
object has these properties.
Name of the coder dictionary definition that the entry represents. The name must be unique among the definitions in the section of the dictionary.
The location of the code definition. This property is read-only.
Built-in
— Provided by Simulink®.Model name — Defined in a Simulink model.
Dictionary name — Defined in a Simulink data dictionary.
Package name — Defined in the Simulink package or in a custom package.
To access the properties of the code definition that an entry represents, use the getAvailableProperties
, get
, and
set
methods. Each
type of code definition has available properties listed.
Storage Classes
Name of the storage class. The name must be unique among the storage classes in the dictionary.
For lists of built-in and example storage classes that Simulink provides, see Choose Storage Class for Controlling Data Representation in Generated Code.
Custom text that you can use to describe the purpose and functionality of the storage class.
The location of the code definition. This property is read-only.
Built-in
— Provided by Simulink.Model name — Defined in a Simulink model.
Dictionary name — Defined in a Simulink data dictionary.
Package name — Defined in the Simulink package or in a custom package.
Specification to access data associated with the model. Access the data directly
(Direct
), through customizable get
and
set
functions (Function
), or by using a pointer
(Pointer
). For more information, see Access Data Through Functions by Using Storage Classes in Embedded Coder Dictionary.
Dependencies
Setting this property to
Function
orPointer
:Sets
DataScope
toImported
.Means that you cannot specify multi-instance properties.
Sets the
PreserveDimensions
property tofalse
. To preserve dimensions of multidimensional arrays in the generated code, setDataAccess
toDirect
.
In addition, setting this property to Function
enables these properties:
AccessMode
AllowedAccess
GetFunctionName
SetFunctionName
Specification that the generated code defines the data (Exported
)
or import (Imported
) the data definition from external code. Built-in
storage classes and storage classes in packages such as Simulink can use other scope options, such as File
.
Dependencies
Setting this property to
Imported
:Disables
DefinitionFile
. To include your external source code file in the build process, use model configuration parameters. For an example, see Configure Data Interface.Means that you cannot set
HeaderFile
to$N.h
, though you can use the$N
token.
To set this property to
Exported
, you must use one of the tokens$N
or$R
in the value ofHeaderFile
.
Name of the header file that declares the data, specified as a name or naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Name of associated data element |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
Dependencies
If you set
DataScope
toExported
, you must use one of the tokens$R
or$N
in the value of this property.If you set
DataScope
toImported
, you cannot set the value of this property to$N.h
, but you can use the$N
token.
Name of the source file that defines the data, specified as a name or naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Name of associated data element |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
Dependencies
Setting DataScope
to Imported
disables
DefinitionFile
. To include your external source code file in
the build process, use model configuration parameters. For an example, see Configure Data Interface.
Specification for the storage class to access data associated with the model through
functions by using Value
or Pointer
. For more
information, see Access Data Through Functions by Using Storage Classes in Embedded Coder Dictionary.
Dependencies
This property is enabled only when you set DataAccess
to
Function
.
Specification for the storage class to allow read and write
(ReadWrite
), read-only (ReadOnly
), or write-only
(WriteOnly
) access to the data.
Dependencies
This property is enabled only when you set DataAccess
to
Function
.
Name of the get
function that fetches the associated data,
specified as a name or naming rule. A naming rule includes a combination of text and
tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$N | Name of associated data element (required) |
$R | Name of root model |
$M | Mangle text that ensures uniqueness |
$U | User token text. See Identifier Format Control. |
Dependencies
This property is enabled only when you set DataAccess
to
Function
and AllowedAccess
to
ReadWrite
or ReadOnly
.
Name of the set
function that fetches the modified data,
specified as a name or naming rule. A naming rule includes a combination of text and
tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$N | Name of associated data element (required) |
$R | Name of root model |
$M | Mangle text that ensures uniqueness |
$U | User token text. See Identifier Format Control. |
Dependencies
This property is enabled only when you set DataAccess
to
Function
and AllowedAccess
to
ReadWrite
or WriteOnly
.
Specification for the storage class to use either the storage settings that you specify for single-instance data or the settings that you specify for multi-instance data. When you apply the storage class to a data item, the Embedded Coder Dictionary determines if it is a single-instance storage class or a multi-instance storage class by the type of data and by the context of the model within the model reference hierarchy.
Dependencies
Selecting this property enables the properties
SingleInstanceStorageType
,
MultiInstanceStorageType
, and
MultiInstanceStructureTypeName
,
MultiInstanceStructureInstanceName
.
Specification to aggregate the data that uses the storage class into a structure in
the generated code. Each data element appears in the code as a field of the structure.
To create a structure, use Structured
.
Dependencies
Setting this property to Structured
enables
StructureTypeName
and
StructureInstanceName
.
Name of the structure type in the generated code, specified as a name or a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as step |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Dependencies
Setting StorageType
to Structured
enables
this property.
Name of the structure variable in the generated code, specified as a name or a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as step |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Dependencies
Setting StorageType
to Structured
enables
this property.
Specification to aggregate the single-instance data that uses the storage class into
a structure in the generated code. Each data element appears in the code as a field of
the structure. To create a structure, use Structured
.
Dependencies
Setting the property
UseDifferentPropSettingsForInstanceData
totrue
enables this property.Setting this property to
Structured
enables the propertiesSingleInstanceStructureTypeName
andSingleInstanceStructureInstanceName
.
Name of the structure type in the generated code, specified as a name or a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as step |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Dependencies
Setting SingleInstanceStorageType
to
Structured
enables this property.
Name of the structure variable in the generated code, specified as a name or a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as step |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Dependencies
Setting SingleInstanceStorageType
to
Structured
enables this property.
Specification to aggregate the single-instance data that uses the storage class into a structure in the generated code. Each data element appears in the code as a field of the structure. You cannot change the value of this property.
Dependencies
Setting the property UseDifferentPropSettingsForInstanceData
to true
enables this property.
Name of the structure type in the generated code, specified as a name or a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as step |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Dependencies
Setting the property
UseDifferentPropSettingsForInstanceData
totrue
enables this property.If you set the property
DataAccess
toFunction
, you cannot set this property.
Name of the structure variable in the generated code, specified as a name or a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as step |
$G | Name of storage class |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Dependencies
Setting the property
UseDifferentPropSettingsForInstanceData
totrue
enables this property.If you set the property
DataAccess
toFunction
, you cannot set this property.
Specification that the generated codes initialize the data.
Dynamic
— The generated code initializes the data as part of the model initialization entry-point function.Static
— The generated code initializes the data in the same statement that defines and allocates memory for the data. The assignment statement appears at the top of a.c
or.cpp
source file, outside of a function.None
— The generated code does not initialize the data.
For storage classes used for persistent data, you must set
DataInit
to None
.
Dependencies
If you set
Const
totrue
, you cannot set this property toDynamic
.Setting this property to
Dynamic
sets the propertyConst
tofalse
.
Location in memory to allocate data, specified as a
coder.dictionary.Entry
object that represents a memory section that
exists in the Embedded Coder Dictionary. For information about memory sections, see
Control Data and Function Placement in Memory by Inserting Pragmas.
Specification for the storage class to preserve dimensions of multidimensional arrays in the generated code. For more information, see Preserve Dimensions of Multidimensional Arrays in Generated Code.
Specification to apply the const
qualifier to the data.
Dependencies
If you select this property, you cannot set
DataInit
toDynamic
.Setting
DataInit
toDynamic
sets this property tofalse
.
Specification to apply the volatile
qualifier to the data.
Specification to apply a custom qualifier to the data. For example, some memory
architectures support qualifiers far
and
huge
.
Do not use this property to apply the keyword static
. Instead,
use the built-in storage class FileScope
, which you cannot apply with
the Code Mappings editor. See Choose Storage Class for Controlling Data Representation in Generated Code.
Specification indicating whether to allow usage of the storage class with model parameters.
Dependencies
Setting
DataInit
toStatic
sets this property totrue
.Setting
DataInit
toDynamic
sets this property tofalse
.To set the value of this property, set
DataInit
toNone
.
Specification indicating whether to allow usage of the storage class with model signals.
Dependencies
Setting
DataInit
toDynamic
sets this property totrue
.Setting
DataInit
toStatic
sets this property tofalse
.To set the value of this property, set
DataInit
toNone
.
Function Customization Templates
Name of the template. The name must be unique among the function templates in the dictionary. Embedded Coder provides the built-in templates listed in this table.
Template | Description |
---|---|
ModelFunction | In the Code Mappings editor, use for entry-point functions for initialization, execution, termination, and reset (see Configure Default Code Generation for Functions) |
UtilityFunction | In the Code Mappings editor, use for shared utility functions (see Configure Default Code Generation for Functions) |
Custom text that you can use to describe the purpose and functionality of the function template.
Names of the functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Base name of associated function, such as step |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$C | For shared utility functions, a checksum inserted to avoid name collisions |
$M | Name-mangling text inserted, if necessary, to avoid name collisions |
Location in memory to allocate function, specified as a
coder.dictionary.Entry
object that represents a memory section that
exists in the Embedded Coder Dictionary. For information about memory sections, see
Control Data and Function Placement in Memory by Inserting Pragmas.
Memory Sections
Name of the memory section, specified as a character vector or string scalar. The name must be unique among the memory sections in the dictionary. Embedded Coder provides the built-in memory sections listed in this table.
Memory Section | Description |
---|---|
MemConst | Apply the storage type qualifier const to the
data. |
MemVolatile | Apply the storage type qualifier volatile to the
data. |
MemConstVolatile | Apply the storage type qualifiers const and
volatile to the data. |
Custom text that you can use to describe the purpose and functionality of the memory section.
Code comment that the code generator includes with the pragmas or other decorations
that you specify with PreStatement
and
PostStatement
.
Code, such as pragmas, to insert before the definitions and declarations of the data or functions that are in the memory section.
You can use the token $R
to represent the name of the model that
uses the memory section.
When you set StatementsSurround
to
EachVariable
, you can use the token $N
to
represent the name of each variable or function that uses the memory section.
Code, such as pragmas, to insert after the definitions and declarations of the data or functions that are in the memory section.
You can use the token $R
to represent the name of the model that
uses the memory section.
When you set StatementsSurround
to
EachVariable
, you can use the token $N
to
represent the name of each variable or function that uses the memory section.
Specification to insert code statements (PreStatement
and
PostStatement
):
Around each variable and function that uses the memory section. Select
EachVariable
.Once, around the entire memory section. The generated code aggregates the variable and function definitions into a contiguous code block and surrounds the block with the statements. Select
AllVariables
.
Receiver Service Interfaces
Name of the receiver service, specified as a character vector or string scalar. Embedded Coder provides the example services listed in this table.
Receiver Service | Description |
---|---|
ReceiverExample1 | Favor memory optimization over data freshness. This service has
DataCommunicationMethod set to
OutsideExecution , so the service reads data from another
function before the function starts executing. |
ReceiverExample2 | Favor data freshness over memory optimization. This service has
DataCommunicationMethod set to
DuringExecution , so the service reads data from another
function immediately during execution. |
ReceiverExample3 | Use this option to maximize performance of
component code or if mutual exclusion is inherent in component model design.
This service has DataCommunicationMethod set to
DirectAccess , so the service reads data from generated
function code directly by using memory that platform services manage for the
target execution environment. |
How receiver data transmission is handled between the target platform service and the run-time environment, specified as one of these options:
OutsideExecution
— Read data from another function before the function starts executing. Use this option to favor memory optimization over data freshness.DuringExecution
— Read data from another function immediately during execution. The generated function code that calls the service must use a local buffer to maintain value coherence during execution. Use this option to favor data freshness over memory optimization.DirectAccess
— Read data from generated function code directly by using memory that platform services manage. Use this option to maximize performance of component code or if mutual exclusion is inherent in component model design.
Names of the receiver functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$G | Service name |
$N | Element name |
$X | Current callable function |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted to avoid name collisions |
Dependencies
To specify a function naming rule, you must set
DataCommunicationMethod
to OutsideExecution
or
DuringExecution
.
Storage class definition, specified as one of the definitions in the
StorageClasses
section of the dictionary.
Dependencies
To specify a storage class receiver services, you must set
DataCommunicationMethod
to
DirectAccess
.
Sender Service Interfaces
Name of the sender service, specified as a character vector or string scalar. Embedded Coder provides the example services listed in this table.
Sender Service | Description |
---|---|
SenderExample1 | Favor memory optimization over data freshness. This service has
DataCommunicationMethod set to
OutsideExecution , so the service sends data to another
function after the function executes. |
SenderExample2 | Favor data freshness over memory optimization. This service has
DataCommunicationMethod set to
DuringExecution , so the service reads data from another
function immediately during execution. |
SenderExample3 | Use this option to maximize performance of
component code or if mutual exclusion is inherent in component model design.
This service has DataCommunicationMethod set to
DirectAccess , so the service reads data from generated
function code directly by using memory that platform services manage for the
target execution environment. |
How sender data transmission is handled between the task and the run-time environment, specified as one of these options:
OutsideExecution
— Send data to another function before the function starts executing. Use this option to favor memory optimization over data freshness.DuringExecution
— Send data to another function immediately during execution. The generated function code that calls the service must use a local buffer to maintain value coherence during execution. Use this option to favor data freshness over memory optimization.DirectAccess
— Send data to generated function code directly by using memory that platform services manage. Use this option to maximize performance of component code or if mutual exclusion is inherent in component model design.
Names of the sender functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$G | Service name |
$N | Element name |
$X | Current callable function |
$U | User token text, which you specify for a model as described in Identifier Format Control |
$M | Name-mangling text inserted to avoid name collisions |
Dependencies
To specify a function naming rule, you must set
DataCommunicationMethod
to OutsideExecution
or
DuringExecution
.
Names of the sender functions that send a value by reference in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$G | Service name |
$X | Current callable function |
$U | User token text, which you specify for a model as described in Identifier Format Control |
Dependencies
To specify a function naming rule, the definition must be a data sender service
and you must set DataCommunicationMethod
to
OutsideExecution
or DuringExecution
.
Storage class definition, specified as one of the definitions in the
StorageClasses
section of the dictionary.
Dependencies
To specify a storage class receiver services, you must set
DataCommunicationMethod
to
DirectAccess
.
Data Transfer Service Interfaces
Name of the data transfer service, specified as a character vector or string scalar. Embedded Coder provides the example services listed in this table.
Data Transfer Service | Description |
---|---|
DataTransferExample1 | Favor memory optimization over data freshness. This service has
DataCommunicationMethod set to
OutsideExecution , so the service receives and sends data
from another function outside of function execution. |
DataTransferExample2 | Favor data freshness over memory optimization. This service has
DataCommunicationMethod set to
DuringExecution , so the service reads data from another
function immediately during execution. |
How data transmission is handled between the task and the run-time environment, specified as one of these options:
OutsideExecution
— Communicate data to another function before the function starts executing. Use this option to favor memory optimization over data freshness.DuringExecution
— Communicate data to another function immediately during execution. The generated function code that calls the service must use a local buffer to maintain value coherence during execution. Use this option to favor data freshness over memory optimization.
Names of the receiver functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Element name |
$X | Current callable function |
$M | Name-mangling text inserted to avoid name collisions |
Names of the sender functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$R | Name of root model |
$N | Element name |
$X | Current callable function |
$M | Name-mangling text inserted to avoid name collisions |
Timer Services
Name of the timer service, specified as a character vector or string scalar. Embedded Coder provides the example service listed in this table.
Timer Service | Description |
---|---|
TimerServiceExample1 | The timer service executes outside of function execution. |
How data transmission is handled between the task and the run-time environment, specified as one of these options:
OutsideExecution
— Communicate data to another function before the function starts executing. Use this option to favor memory optimization over data freshness.DuringExecution
— Communicate data to another function immediately during execution. The generated function code that calls the service must use a local buffer to maintain value coherence during execution. Use this option to favor data freshness over memory optimization.
Names of the clock tick functions in the generated code, specified as a naming rule. A naming rule includes a combination of text and tokens. Valid tokens are listed in this table.
Token | Description |
---|---|
$G | Service name |
$X | Current callable function |
$U | User token text, which you specify for a model as described in Identifier Format Control |
Dependencies
If you create multiple timer services, use the
$G
token.If you set
DataCommunicationMethod
toOutsideExecution
, use the$X
token.
Parameter Tuning Interfaces
The name of the parameter tuning service to use with parameters, specified as a
character vector or string scalar. If the parameters do not need to be tuned, this
property has the default value, "Not tunable"
.
Storage class definition, specified as one of the definitions in the
StorageClasses
section of the dictionary.
Parameter Argument Tuning Interfaces
The name of the parameter argument tuning service to use with parameter arguments,
specified as a character vector or string scalar. If the parameter arguments do not need
to be tuned, this property has the default value, "Not
tunable"
.
Storage class definition, specified as one of the definitions in the
StorageClasses
section of the dictionary.
Measurement Service Interfaces
The name of the measurement service to use with signals, states, and internal data
elements, specified as a character vector or string scalar. If the signals, states, and
internal data elements do not need to be measured, this property has the default value,
"Not measured"
.
Since R2025a
Option to store internal states and data store data in nonvolatile memory in the
target environment. Specified as a logical false
or
true
.
When IsPersistent
is true
, only storage
classes with DataInit
set to None
are
supported.
Storage class definition, specified as one of the definitions in the
StorageClasses
section of the dictionary.
Only storage classes with DataInit
set to
None
are available for service interfaces that specify persistent
data.
Methods
get | Get value of code definition property |
set | Set value of code definition property |
getAvailableProperties | Return properties for code definition |
isDictionaryDefault | Determine if entry is default code definition for a category |
deleteEntry | Delete Embedded Coder Dictionary entry |
valid | Determine if coder.dictionary.Entry object represents a valid
code definition |
Examples
Open the model RollAxisAutopilot
and represent the Embedded Coder
Dictionary by using the coder.Dictionary
object
coderDictionary
. Use this object to access the Storage Classes
section of the dictionary, which contains the storage class definitions.
openExample("RollAxisAutopilot") coderDictionary = coder.dictionary.open("RollAxisAutopilot");
Create a coder.dictionary.Section
object that represents the
Storage Classes section of the Embedded Coder Dictionary.
storageClassesSect = getSection(coderDictionary, "StorageClasses");
Add a definition named MyStorageClass
to the Storage Classes
section. The storage class definition uses the default property settings. You can change
these settings by using the set
function.
newEntry = addEntry(storageClassesSect,"MyStorageClass")
newEntry = Entry with properties: Name: 'MyStorageClass' DataSource: 'RollAxisAutopilot'
Version History
Introduced in R2019bSpecify a measurement service interface for persistent data to support state and data store data that is stored in nonvolatile memory in the target environment.
To specify persistent data, use the service interface PermanentRAM
in
the MeasurementInterfaces
section of the coder dictionary. Alternatively,
you can define a new service interface in the MeasurementInterfaces
section, where you set property IsPersistent
to true
for the service and you specify a storage class that has DataInit
set
to None
. A new storage class called PersistentMemory
is provided in the StorageClasses
section of the coder dictionary.
You can now specify "Not measured"
as the default value of the
MeasurementInterfaces
section in the coder dictionary, and you can
specify "Not tunable"
as the default value of the
ParameterTuningInterfaces
and
ParameterArgumentTuningInterfaces
sections in the dictionary. The
"Not measured"
and "Not tunable"
entries are
included in the dictionary, and are preselected as default values in newly created
dictionaries. You can select other entries as dictionary default for these sections, but you
cannot delete these entries from the dictionary.
Access the coder.dictionary.Entry
objects for Embedded Coder Dictionaries that use the service interface configuration. You can still
access the entry objects for Embedded Coder Dictionaries that use the data interface
configuration.
MATLAB Command
You clicked a link that corresponds to this MATLAB command:
Run the command by entering it in the MATLAB Command Window. Web browsers do not support MATLAB commands.
Select a Web Site
Choose a web site to get translated content where available and see local events and offers. Based on your location, we recommend that you select: United States.
You can also select a web site from the following list
How to Get Best Site Performance
Select the China site (in Chinese or English) for best site performance. Other MathWorks country sites are not optimized for visits from your location.
Americas
- América Latina (Español)
- Canada (English)
- United States (English)
Europe
- Belgium (English)
- Denmark (English)
- Deutschland (Deutsch)
- España (Español)
- Finland (English)
- France (Français)
- Ireland (English)
- Italia (Italiano)
- Luxembourg (English)
- Netherlands (English)
- Norway (English)
- Österreich (Deutsch)
- Portugal (English)
- Sweden (English)
- Switzerland
- United Kingdom (English)