Database Scanner 

Database scanner options allow user to specify how Multilizer localizes database contents, such as tables in a SQL Server database for example. Connection to database is defined as a connection string, so the basic use is the same Microsoft Access and SQL Server for example.

Multilizer needs to connect to the database only when scanning, building, or specifying localization options. All other work can be done offline. So the localization work can be organized in a way that translator doesn't need connection to the database.

The most important settings are the following:

  • Database; the connectionstring to the database.
  • Destination of localization (Output tab); choose how to localize the database content.
  • Import existing translations... (Input tab); allows importing of translations (if any) from the database.
  • Database type (Input tab) affects how the scanner communicates with the database. Ensure this setting is correct.

The following PDF file describes the 5 different architectures for localizing databases in Multilizer: "Multilizer Database Localization Architecture"


Tables and Fields

When there's a correct connectionstring, this tab shows the tables and fields of the database.

  • Left pane shows all tables and fields containing text data of the database.
  • Right pane shows the tables and fields that will be localized.


Native language field lets you specify what's the language of the database content being localized.

Default language is a fallback language; if there's no translation in target language, the text of default language is used instead.

Native encoding allows the user to specify, what's the encoding of the native strings. This field can be left empty.

Language list shows the project languages.

  • In Encoding column the user can choose a specific character encoding to the translated text. If this is left empty the same enoding will be used as for native text.
  • In Code column the user can customize the language code. This code will be used in table and field names for localized content. For instance in field localization Multilizer assumes that localized Finnish content goes to data_fi column, but the user can override the code to fin and Multilizer would write content to data_fin consequently. The usage of the Code depends on the localization architecture.


On this table the user can specify how to work with the existing database content.

Check Import existing translations from database to project, if you want to import translations from an existing database. This option should be checked when creating a new localization project with Multilizer, so that any existing translations are added to Multilizer project. After this it is recommended that this checkbox is not checked, because Multilizer takes care of producing translations to the database.

Limit processing option allows the user to limit processing (scanning/building) to a specific schema. This feature -- especially developed for Oracle database localization -- increases the Multilizer performance significantly on big databases.

Database type is affects the queries that Multilizer uses for communicating with the database. This setting is a prerequisite for the scanner to work properly.


On this tab you define how to localize the database.

Destination of localization

According to the chosen database localization architecture (See PDF: Multilizer Database Localization Architecture) the user selects the corresponding destination of localization:

  • Replace Localization (Replace original fields) will overwrite existing content in database with the localized.
  • Single Table Localization (In same tables in records...) writes the translations in the same table and fields as the original strings. The language of each record in the table is specified by a Language ID that is compulstory.
  • Field Localization (Set in fields of localization). Translations will be written to fields that are specific for the target language. The fields must be created by the database administrator.
  • Table Localization (Set in table of localization). Translations will be written to tables that are specific for the target language. The result will be a table that contains all the same data as orginal table, but texts are localized.
  • Database cloning allows user to create a completely new database file for the localized information. The result will be a new database file with localized texts.

Cloning Options define where localized database will be written. Database cloning (MS Access only) copies the entire database file; therefore output directory and filename needs to be defined.

Build action for missing translations tell what to do in such cases where the Multilizer project does not contain a translation.

Lang ID

The Language ID is used in Single Table Localization only, where it is required. Always check Use Language ID in this database localization architecture.

On this tab the user specifies the field that is used as language identifier in the record. The field is a text field that should contain enough of space for a fully qualified language identifier. By default Multilizer uses language identifiers that are 2-5 characters. We recommened, however, that you reserve 8-16 characters for this field.

The language id must be specified for all tables that you localize. The syntax is:
... where:

  • is the name of the table being localized
  • is the name of the field that is used as language identifier.

Context ID

The Context ID is used to form the context (ID) of strings that are scanned from the database to Multilizer project.

By default the scanner uses the key fields of the table to form the context. For example, if the MyTable table contains keyfields id and kind and localizable context in MyText field, then the context has the following format,:
, where and contain the data found in these fields respectively.

Specifying context ID manually

If user specifies an index (context) for a table manually, it overrides any auto-detected indexes for the particular table.

The notation for specifying fields manually is the following: tablename=indexfield1;indexfield2;…;indexfieldN

When scanning, the context follows the order of the user-specified fields.

The user should choose the fields with care, in order to ensure that the contexts will be unique.