Rav Translate - runtime translation for Clarion ABC applications, on the fly

[AlexShop]

The problem this template solves

If a Clarion application (ABC templates) needs multi-language UI support, there’s essentially no standard way to do it. Either you hand-roll your own translation system and wire it into every window, or you rely on ExtractText from ABUTIL, which gives you no editor, no on-the-fly language switching, and no per-window/per-control overrides.

Rav Translate is a standalone ABC template that adds full runtime translation to an application with almost no work from the developer: no need to manually wrap every control or rewrite existing windows.

What it does

• Automatically translates every window in the application — labels, buttons, list/browse column headers, including the main MDI Frame window (menu) — without a single line of code in the windows themselves.
• Switches the interface language on the fly, no restart needed — already-open windows redraw immediately.
• Provides a built-in translation editor: text search, a “this window only” filter, language selection (languages can be added/removed right from the editor), a “Translations…” button available on any window.
• Supports per-window/per-control overrides — a translation for a specific window and control can override the shared one (example: a label translates as “Name” everywhere, but in one particular column it’s overridden to “Nm.”).
• Translates arbitrary strings and MESSAGE() calls via an explicit call (Translator.TranslateString) — both the title and the body of the message.
• Exports/imports the list of untranslated strings as TSV (2 columns: RecID + text, matched strictly by RecID) — hand it to a translator or run it through machine translation and bring it back.
• Ships with three ready-to-use Python scripts for batch machine translation (Google Cloud Translate, DeepL), all sharing one CLI interface: export from the application → run the script → import back.
• A hotkey to open the translation editor, configured once, globally, for the whole application.

How it works internally

• The template overrides the standard TranslatorClass from ABUTIL (%TranslatorDataSection/%TranslatorCodeSection) — meaning it works through the stock ABC translation mechanism, not around it.
• All the logic (harvesting window text, translation lookup, the editor, export/import) lives in one self-contained MEMBER module (Rav_Translate.CLW), independent of the rest of the application’s code. It’s wired in through a single application-level Global Extension.
• Storage is two TOPSPEED files: the translations themselves (language + window + control + original + translation, including per-window overrides) and a language lookup table. The selected language persists between runs via an INI file.
• Window text is harvested via PROP:NextField (the standard way to walk a window’s fields) — works the same way for ordinary windows and for the Frame/APPLICATION window with its menu.

Default language

On the very first run of the application (before RAVLANG.INI exists), the interface language comes from a template setting, not a hardcoded value. It’s set in the properties of the Rav Translate global extension (Application Tree → Global Extensions → Rav Translate → global part):

• The “Default language on first run (before RAVLANG.INI exists)” field — enter the language code (EN, RU, or any other) that should be used the very first time the application runs for an end user.
• The default value (if left unchanged) is EN.
• After the first run, the chosen language is written to RAVLANG.INI, and the application always starts with it from then on — this template setting is no longer used unless RAVLANG.INI is deleted manually.

Author: Rybnikov A., 2026

Clarion10_EN.zip (14,3 КБ)
School_Rav.zip (3,4 МБ)

Three drop-in Python scripts (Google Cloud Translate, DeepL) that batch machine-translate the strings exported by the Rav Translate Clarion template and hand them straight back for re-import — so you can auto-translate your whole ABC application into a new language in one pass instead of typing every string by hand.
scripts_EN.zip (6,2 КБ)

[Daniel1]

something is not working correctly, check the image

[AlexShop]

@Daniel1

something is not working correctly, check the image

Thanks for catching this and for the screenshot - much appreciated.

Turns out I hadn’t packaged everything correctly: the default interface language was hardcoded in the template instead of being configurable, so anyone downloading the example ended up seeing Russian regardless of their own locale.

That’s fixed now - the template has a proper “default language” setting (Global Extension properties), defaulting to EN, and the current build in the repo/attachment reflects it. Sorry for the inconvenience, and thanks again for flagging it.

Update: fixed the files above — default language is now configurable in the template, no longer hardcoded to Russian.

As the screenshots show, the template isn’t limited to a fixed list of strings - it can translate pretty much any text in a Clarion ABC application: window captions, buttons, prompts, checkboxes, list/browse column headers, the main MDI menu, and even arbitrary strings and MESSAGE() dialogs via an explicit call. Nothing has to be wrapped by hand control-by-control - the template harvests every window automatically the first time it opens, and from there it’s all managed through the built-in editor (or the bundled machine-translation scripts, if you’d rather not type every string yourself).

[Daniel1]

Not sure how it should work. Now I run new example and changing language does not make any change, it stays on English all the time.

[AlexShop]

Thanks for the report! To pin down exactly what’s going on, could you clarify a few things:

1. How exactly are you trying to change the language - specifically through what: the combo box in the “Application translations” window (the translation editor), or some other way?
2. What steps are you taking: do you pick a language, then click something else (Save, Close)? Please describe the exact sequence.
3. What result did you expect, and what do you actually see - does the window redraw at all (does anything change), or does literally nothing happen?
4. Have you added a new language and translation for it? If so, how exactly did you do it (through the “App Translations” window or some other way)? And what do you see after switching-no changes at all, or does something change, but not what you expected?

This will help pinpoint where the snag actually is - in the template itself, in the example, or in how switching the language is expected to work.

[Daniel1]

Check image below
I run the app and change to RU language - I expect that it translates into RU language.

[AlexShop]

Daniel1, my apologies for the confusion.

I originally wrote this template for my own project, without giving much thought to how it would behave for other developers. When I started porting/localizing it to an English version, several issues surfaced that never showed up in my own environment (default-language architecture, data file paths, the language-switcher combo) - and I made a number of mistakes there. I’ve now fixed all of that and verified it on my own example, but since you already have the old version installed, you’ll need to clean up and reconfigure a few things, otherwise you’ll hit the same bugs.

Here’s what needs to be done:

1. Delete the old translation data files

Delete these files next to your test application’s exe:

• RAVLANG.TPS
• RAVTRAN.TPS

These are accumulated data from the old, not-yet-fixed version of the template - the default-language structure and logic have changed, and the old files are incompatible with the new template version. They’ll be recreated automatically, under the new scheme, the next time the application runs.

A separate note about RAVLANG.INI: the old template version had a path bug - the file could end up not in the application’s own folder, but in the Windows directory (C:\Windows\RAVLANG.INI), or the write could even go straight into the shared WIN.INI (section [Rav_Translate], key Lang). If you had the template installed before, check both of those locations and remove any leftovers. In the current, fixed version, the template always stores RAVLANG.INI right next to the application’s exe, with no exceptions.

2. Reinstall (re-register) the template in the IDE

Copy the fresh Rav_Translate.tpl, Rav_Translate.inc, Rav_Translate.clw from RavTranslate.zip into your accessory\template\win\ and accessory\libsrc\win\ folders (overwrite the old files).

The Clarion IDE needs to re-read the template definition - either through Application Properties → Template, or by simply closing and reopening the project/application so the IDE picks up the updated template. A plain Build isn’t enough - the template definition itself is cached by the IDE separately from the generated code.

3. Verify it works on the ready-made example

Unzip School_Rav.zip and run it as-is - everything in it is already configured correctly, and I specifically ran this exact example with the fixed template: it worked without any issues. I’ve also added a working sample of the RavLanguageSwitcher control template to the example — a (COMBO) that can be dropped onto any window or toolbar in your application to switch the active interface language on the fly, with no restart needed. You can use the example as a working reference - compare how the template settings are filled in there, and how that combo is placed, if something doesn’t come together in your own project.

4. What to fill in on the global template (APPLICATION)

In the School_Rav example, the primary (native) language is already set to EN - that’s the Default language on first run field of the RavTranslateGlobal extension at the APPLICATION level. If you need a different default language, change this value to the code you need (e.g., DE).

The order matters here: change the language in the template settings first, and only afterward delete the RAVLANG.TPS, RAVTRAN.TPS, and RAVLANG.INI files. The template only picks up the new primary language from this setting at the moment the data files don’t exist yet at all.

The easiest way to get comfortable with this is to try it on the School_Rav example first: change the default language there, delete the data files in the right order, and confirm the switch actually behaves the way you expect - then apply the same steps to your own project.

Translation editor hotkey (optional) - a hotkey that opens the built-in translation editor from any window in the application. If left blank, you’ll need to open the editor some other way (e.g., a dedicated button on the windows where you need it).

Sorry again for the inconvenience - and thanks for helping surface these issues on someone else’s setup; on my own, they might not have shown up for a long while yet.

RavTranslate.zip (17,9 КБ)
School_Rav.zip (3,4 МБ)

[Daniel1]

Thank you for your work, I just don’t need it right now so I try to run your compiled school.exe (without installing the template and stuff).
When I want to change the language, thousand gpf dialog’s are displayed:

[AlexShop]

@Daniel1

Thank you for your work, I just don’t need it right now so I try to run your compiled school.exe (without installing the template and stuff).
When I want to change the language, thousand gpf dialog’s are displayed:

Daniel1, thanks for flagging this - it’s a serious error, we’re looking into it.

Could you please clarify a couple of important points: did you definitely delete the old files (RAVLANG.TPS, RAVTRAN.TPS, RAVLANG.INI) and run only the files from the new archive, without mixing them with the old ones?

I also specifically ran it myself in Windows Sandbox, in the same directory shown in your screenshot - with the same files, opened several windows at once, tried switching the language in different combinations - the error doesn’t reproduce for me.

Given that, it might be something specific to your particular environment. If it’s not too much trouble, could you tell me:

• Which exact Windows version/build is running inside your Sandbox (you can check via winver)?
• Is it a standard system, or some non-standard configuration too (a VM, RDP, a different language/regional Windows settings)?
• Have you tried running it outside Sandbox, on a regular system - does it still crash, or only inside the sandbox?

This will help figure out what’s different between our environments - and either reproduce or rule out the error.

[Daniel1]

Hello
yes, I’m using Sandbox and I just copy your files and paste them there. Using Sandbox, old files are not there, for sure
Now I also deleted all tps files manually and now I have only EN language, check image below.
Like said, it is not something I would use for the moment, just wanted to see how it works, that’s all. Thank you anyway for your work.