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:
The following PDF file describes the 5 different architectures for localizing databases in Multilizer: "Multilizer Database Localization Architecture"
When there's a correct connectionstring, this tab shows the tables and fields of the database.
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.
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:
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.
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:
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.