Copyright © 1995-2011 Opera Software ASA. All rights reserved. This file is part of the Opera web browser. It may not be distributed under any circumstances.
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.
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:
Please refer to the database format documentation for detailed information on how the information is to be formatted.
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.
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.
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.
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.
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.