Database
Database localization for application content.
Translate the text your application keeps in Access, SQL Server, or other database tables, through ODBC, reuse earlier translations, check placeholders, and write the translations back into language columns or language rows. Your application keeps the schema and the queries.
- Input
- Tables of Access (
.accdb,.mdb), SQL Server, or another database, through its ODBC driver - Output
- Translations written back into language columns or language rows
- Runtime
- Your queries read the column or the rows of the user's language
- Edition
- Enterprise
On this page
Tutorial
Localize database content with Lingobit, step by step.
Four steps from the English column to translated columns or rows.
Lingobit reads the tables, translates in the project, and writes back.
You tell Lingobit which tables hold user-facing text, which columns are the key, and how translations are stored. It reads the English values into the project, where they are translated and checked. Create Localized Files writes the translations into the language columns, or into the language rows, of the same tables.
Lingobit does
- Reads the text columns of the tables you choose, with an optional rows filter.
- Reuses earlier translations and the translation memory.
- Checks placeholders, empty and too long translations, and more.
- Writes the translations with UPDATE, and adds missing language rows with INSERT.
Your application keeps
- The schema: the language columns, or the language-ID column.
- The queries that read the user's language.
- Which database Lingobit connects to: a copy or a staging database.
- The final test in the running application.
Access, SQL Server, and other databases through ODBC.
Lingobit reaches a database through its ODBC driver. Localizer uses the 32-bit driver, also on 64-bit Windows, so install the 32-bit version. Windows lists the drivers Localizer can use in ODBC Data Sources (32-bit), on the Drivers tab.
| Database | 32-bit ODBC driver | Where it comes from |
|---|---|---|
Microsoft Access .mdb | Microsoft Access Driver (*.mdb) | Built into Windows; nothing to install |
Microsoft Access .accdb and .mdb | Microsoft Access Driver (*.mdb, *.accdb) | Included in 32-bit Microsoft 365. Without Office, install the 32-bit Microsoft 365 Access Runtime from Microsoft |
| Microsoft SQL Server | SQL Server, or ODBC Driver 18 for SQL Server | The SQL Server driver is built into Windows. Microsoft's ODBC Driver 18 installer for x64 adds the 32-bit driver too |
| MySQL, MariaDB | MySQL Connector/ODBC 8.0, or MariaDB Connector/ODBC | From the vendor: MySQL Connector/ODBC 8.0 is the last version with a 32-bit driver; MariaDB offers a 32-bit package |
| PostgreSQL | psqlODBC | The 32-bit installer, psqlodbc_x86.msi, from the PostgreSQL ODBC project |
| Oracle | Oracle Instant Client ODBC | The Instant Client and ODBC packages for Windows 32-bit, from Oracle |
Connection strings
A database file can be named in the connection string; |DataDirectory| is the project folder:
Driver={Microsoft Access Driver (*.mdb, *.accdb)};Dbq=|DataDirectory|\Shop.accdb;For a database server, create a data source in ODBC Data Sources (32-bit) and give its name, such as DSN=Shop, or write the server into the string:
Driver={SQL Server};Server=localhost;Database=Shop;Trusted_Connection=Yes;Access with 64-bit Office
With 64-bit Office, the .accdb driver on that computer is 64-bit, and Microsoft supports the Access driver in only one bitness per computer, so Localizer cannot open .accdb files there. Run Localizer on a computer without 64-bit Office, with the 32-bit Access Runtime, or save a copy of the database as an Access 2002-2003 .mdb file, which opens through the driver built into Windows.
Other databases
The database sample has been run in Access and in SQL Server. For another database, connect Lingobit to a copy first and run Create Localized Files once. Table and column names of letters, digits, and underscores work with every driver.
Reference
Your queries read the user's language.
Lingobit only fills the language columns or rows; the application chooses which one to show. Fall back to English in the query, so a value that is not translated yet still shows text.
Languages in columns
SELECT ID, COALESCE(de, en) AS Title
FROM STRINGSLanguages in rows
SELECT s.ID, COALESCE(t.Text, s.Text) AS Title
FROM STRINGS s
LEFT JOIN STRINGS t ON t.ID = s.ID AND t.Lang = 'de'
WHERE s.Lang = 'en'Table settings.
Each table in the project has its own settings, under the names Add Database shows.
| Setting | What it does | Example |
|---|---|---|
| Connection string | How Lingobit reaches the database through ODBC; a registered data source also works | DSN=Shop |
| Unique key columns | Identify each row; translations are matched by them on every scan. A key column can also group rows into folders | ID |
| Rows filter | A SQL WHERE expression that limits the rows Lingobit reads | Localizable = YES |
| Target column name template | Same row another column: the name of each language column, by template or per language | de, or Title_de set per language |
| Language-ID column and value template | Same column another row: the column that names the language and the value for each language | Lang with a numeric language ID by default, or de set per language |
| Enable SQL monitoring | Lists each SELECT, UPDATE, and INSERT in Output | — |
Do and don't.
Do
- Connect Lingobit to a copy or a staging database, and move the translations on with your release.
- Create the language columns before Create Localized Files: Lingobit writes into them, it does not add them.
- Keep key values stable between releases.
- Use a rows filter to leave out technical rows.
- Set a maximum length for values that must fit a column or a screen.
Don't
- Point Lingobit at the production database.
- Edit translated values in the database by hand: the next Create overwrites them.
- Include IDs, codes, or settings in the columns to localize.
- Give translators access to the database: they work in Lingobit.
Troubleshooting.
| Symptom | Likely cause | What to do |
|---|---|---|
| Lingobit cannot connect | The 32-bit ODBC driver for your database is not installed, or the connection string is wrong | Install the 32-bit driver, test the connection in ODBC Data Sources (32-bit), and try again |
An .accdb file does not open, but .mdb does | The computer has only the 64-bit Access driver, usually from 64-bit Office | See Access with 64-bit Office |
| A SQL Server table is listed but cannot be read | The table is in a schema other than the default schema of the login | Connect with a login whose default schema holds the table |
| Create Localized Files reports an error for a table | A language column does not exist, or the key columns do not identify one row | Add the column, check the unique key columns, and turn on SQL monitoring to see the statement |
| The application still shows English | The query reads the English column or row, or the translations went to another database | Check the query and the connection string of the project |
| Technical rows appear in the project | The table has rows that are not user-facing text | Add a rows filter, such as Localizable = YES |
| German text is cut off in the application | There is no preview of database text, so long text shows only in the running application | Set a maximum length for the values in Lingobit; Validation reports translations that exceed it |
The database sample.
Localizer installs a database sample with its project, so you can try the steps above without your own database.
SampleDB.mdb, an Access database, and the projectDB Localization Demo.loc, in German and French. The sample opens through the Access driver built into Windows, so there is nothing to install.- Six tables show both schemes, a rows filter, and key columns that group rows into folders; SQL monitoring is on, so Output shows every statement.
More about database localization.
What database content to localize
Many applications keep user-facing text in tables instead of resource files: product descriptions, messages, labels, prompts, and help text. Lingobit reads the configured source-language columns or rows of ODBC-compatible databases and writes the translations into language columns or language rows.
Internal IDs, technical fields, audit columns, runtime-only data, stored procedures, and SQL code are not translated.
Prepare the database for localization
- Identify the tables with user-facing text, and keep stable keys for localizable records.
- Separate user-facing text from technical values, and do not build sentences from many database fragments.
- Decide whether translations belong in columns or rows, and use consistent language identifiers.
- Document which fields to translate, back up the content before writing translations, and test it in the application before deployment.
Clear boundaries
- Lingobit does not design the database schema or replace database administration.
- The application decides how localized content is loaded at runtime and what happens when a translation is missing.
- Database permissions, backups, migrations, and deployment stay with your team.
Database localization FAQ
Localized database fields: language columns or a translation table?
Both work. Language columns (Title_de, Title_fr) keep one row per item and simple queries, but need a schema change for every new language. Language rows in a translation table add a language without changing the schema, at the cost of a join. Lingobit writes either: Same row another column, or Same column another row; see Your queries read the user's language.
Do translators need access to the database?
No. The text is read into the Lingobit project, and translators get a translation task: a translator project, XLIFF 1.2, or CSV. Only the developer who reads and writes the tables needs the connection, preferably to a copy or a staging database.
Can I translate an Access application?
Lingobit translates the text in the tables of an .mdb or .accdb file through ODBC. If your forms and reports read their captions from a table, that table is translated like any other; captions typed into the forms themselves are not.
What happens to rows added after the first translation?
Scan for Changes reads the tables again and matches each row by its unique key columns. New rows arrive as new items, changed source text is marked for review, and translated rows keep their translations.
Related paths
- Localization QA — Validation, placeholder checks, and maximum length.
- Translation workflow — Translators work in Lingobit, not in the database.
- Release workflow — Scan for Changes for every release.
- Compare editions — Database localization is part of Enterprise.