Lost in Translation: runtime multi-language Access apps

Long before "i18n" was a checkbox in every framework, shipping one application that an operator could flip between languages at runtime was real work. This piece, written for Smart Access in 2004, shows how I did it in Microsoft Access: one compiled file, every language living in a table, and the whole interface re-labeled on the fly when the user changes a setting.

The approach holds up. Instead of compiling a separate build per language, all UI strings live in a tblTranslateInterface table keyed by language code. A small translator class walks the open forms, reports and CommandBars and swaps each control's caption, tooltip and status text. Menus are the hard part, because CommandBar controls have no unique name, so I keyed them on the Tag property and searched recursively. Changing the active language re-labels every open form immediately, and every form opened afterwards picks up the new language as it loads.

What dates the article is the stack: DAO, Access 97 through 2002, VBA. What does not is the idea. Keep translatable text out of the binary, drive the interface from data, switch at runtime. That is exactly what this site does today, two decades later, on .NET 10 and Blazor: the RO/EN toggle re-renders the whole interface from content, with no rebuild and no redeploy.

The full article, with the complete code and the sample database, was republished by Microsoft and is still online:

Read "Lost in Translation" on Microsoft Learn

Originally published in Smart Access, July 2004, Pinnacle Publishing.