# Strings module

## Introduction

The strings module contains all the localizable strings in the Opera core, and most of the user interfaces, these strings are stored in the language database (`english.db`).

When building Opera, the strings relevant for the particular build are gathered and used to generate source code and a list of strings that can be used to build translated versions.

For further information, please refer to the wiki page.

## How to get new strings into the strings module

The string database is owned by the documentation team and all new strings that are to be added to the module must be submitted through the module owner.

If you need one or more new strings added to the string database, you will need to send a full list of these strings to the module owner. The listing should contain the same information that is found in the string database. The preferred method of submitting new strings is by committing the requested changes to a side-branch and following the patch submission procedure. The script `updatedb.pl` can be used to aid adding strings.

This information should be included:

1. Identifier
2. Caption
3. Description
4. Old scope information (translator hints only)

Please refer to the database format documentation for detailed information on how the information is to be formatted.

## How to build translations

When generating a build, the build system generates a list of strings used in the build, `build.strings`. This file is to be retained, as this list is required to build the translated version. The list is fed to the `makelang.pl` script to generate the translated language file.

The translations themselves are stored in the translations module.

Please see the translations module documentation for further information.

## How to reference strings from your module

Module owners that reference strings in their modules must list these strings in a file called `module.strings` that is placed in the top-level directory of the module. The same rule applies for the modules checked out under the `adjunct` subdirectory, as well as those under `platforms`.

The `module.strings` file should basically contain a list of string identifiers, one per line. You can freely use pre-processor directives to ensure that only the relevant strings are included, these will be evaluated when the `build.strings` file is generated. All the preprocessor definitions that are available from including the `core/pch.h` file can be checked against here.

Normal C++ style comments can be added to the `module.strings` file.

## How to build the string list

The build system, through the operasetup script in the hardcode module first builds the `build.strings` file, from the information in the module.strings files described above. This is done as the very first step in the build process for any build of Opera, as the script also sets up some other required subsystems.

After generating the string list, it calls the `makelang.pl` script, which is provided by the strings module, to generate the header files necessary to build the locale module.

This string list file is also used to generate the necessary language files, as described above.

For other uses of `makelang.pl`, please see the translations module documentation.

## How to tag strings you are using with your platform

The only hints translators have when translating a message is the string identifier, its description and the scope information. We use scope as a tag indicating which strings are in use by different platforms.

To add the tags for your platform, the script `updatescope.pl` can be used with the `build.strings` file to tag the relevant strings in the database.

## How to build language files

The scripts in this module can also be used to generate language files for the target products. Please see the translations module documentation for more details.

## References

- Translations module
- Locale module