Skip to main content
Table of Contents

Checking the project setup with the Info tab

Most localization problems are not about a single translation. They are about the setup around the translations: a data file in a folder nobody expected, runtime language files that are older than the translations, a compiler option that keeps resourcestrings out of the project, or language files that never reach a mobile build. The editor's Info tab collects these project-level facts in one place, so you can check the setup before you start translating and come back to it when the running application does not show what the editor shows. Use the Translations tab for anything that is wrong with one string, such as a status, a missing translation, or an outdated source text. Use the Info tab for the questions "which file am I editing?", "what does my application read at run time?", and "why is nothing from my resourcestrings showing up?".

Availability

The Info tab is part of the VCL and FMX editors:

Framework Info tab
VCL (design time and run time) Available
FMX (design time and run time) Available
TMS WEB Core Not available

There is nothing to switch on in a VCL or FMX project. In a TMS WEB Core application the editor has no Info tab.

The Info tab shows an in-memory diagnostic of the current project that is rebuilt whenever the tab is shown; there is no API to read it from code.

Opening the Info tab

The Info tab is the last tab of the editor, after Translations, Languages, Rules, AI Settings and Exchange. It sits last because you read it when something looks wrong, not while you translate. Open the editor as usual, from the collector in the designer or with Execute at run time, and select Info.

The editor opens on the Info tab by itself in one situation: when the translation data file does not exist yet. That is a project being set up for the first time. On the Translations tab an empty project under a plausible-looking path reads exactly like a project with nothing collected yet, so the editor shows the setup first. Every later run opens on the Translations tab, as before.

Reading the tab

The tab shows a short introduction, a grid with one row per fact, and a detail panel below the grid:

Column Holds
(level) Problem, Warning, or empty for a plain fact.
Subject What the row is about, such as Translation data or Resource strings.
State The fact itself in one line: a path, a count, or a short statement.

Rows are sorted worst first, so problems come before warnings, and warnings before facts. The first row is selected when the tab opens. A grid cell holds only one line, so the advice for a row is shown in full in the detail panel below the grid. Select a row, with the mouse or the keyboard, to read what to do about it. A row with nothing to do says so, and a project without any findings shows Nothing to report.

The tab is rebuilt every time you switch tabs. A fact changes with every save or build, and an outdated summary is worse than none, because it gets believed. So after you change a project option or build, switch away from Info and back to see the new state.

The Info texts are part of the editor's own UI. They follow the editor language (see Editor language), and with AllowCustomTranslation they are collected as Editor.Info* snippets that you translate like the rest of the editor.

What the tab checks

The rows come from two sources. The collector reports what the translation model itself knows, at design time and at run time. When the editor is opened from the IDE, the design-time package adds what only the IDE can see: the project options, the compiler's resourcestring list and the deployment.

Translation data and runtime files

Subject What it tells you
Translation data The full path of the translation data file (translations.json) the editor works on. A Problem when no data file is in use, which happens when the collector is not on a form of a saved project. A note when the file does not exist yet and is written on the first save.
Runtime files The runtime language files folder next to the data file, where Export Runtime Files... writes the separate language files. It states when the folder is empty, how many files were found and when they were written, and gives a Warning when the files are older than the translation data. Export again to bring them up to date.
What the application reads Which storage the application loads at run time: the exported language files, or the project JSON when no language files were found.

These three rows answer the most common support question: the editor shows a translation, but the running application does not. Usually the application reads exported language files that were written before the translation was made. See Exporting language files and the language files guide.

Languages

Subject What it tells you
Languages The number of languages and the source language. A Problem when no language is marked as the source language: every other language is matched against it, so mark one on the Languages tab.

Resource strings

Subject What it tells you
Resource strings How many resourcestrings were imported, in how many units. At design time, a Warning when none were imported because no compiler list was read, or a plain fact when the project's own units declare no resourcestrings.
Resource strings (duplicates) Source texts that more than one resourcestring uses. When the language files carry string-table ids, each resourcestring keeps its own translation and the row is a fact. Without ids, they are matched by text on Windows and the first translation is used for all of them, which is a Warning.
Resource string list (.drc) (IDE only) Whether the compiler writes the .drc file the collector imports resourcestrings from. A Problem when the active configuration does not write it. Switch on Output resource string .drc file, or set Map file to Detailed, under Project > Options > Building > Delphi Compiler > Linker, and build once. Warnings when the output folder is unknown (name the file yourself in the collector's ResourceStringsFile), when the file does not exist yet, or when it is older than the source. A plain fact when LocalizeResourceStrings is False on the collector.

The resourcestring import itself is described in the resourcestrings guide.

Frames

Subject What it tells you
Frames A Warning for every copy of a frame text that was removed from a form, together with translations that existed only on that copy. The frame's own translation now applies on the form. The detail panel lists the translations that were dropped, so you can re-enter them on the frame if you need them.

The editor saves when it closes, so this row is the only trace of the clean-up. Check it after opening an older project that embeds frames.

Project, localizer and deployment (IDE only)

Subject What it tells you
Project The project file. At run time this row says that the project checks are not available in a running application. At design time, a Warning when the design-time part reported nothing, which usually means the design-time and run-time packages are out of step: rebuild and reinstall them together.
Localizer A Warning when no localizer is found among the project's open modules. The application needs one to load the language files at run time. A localizer on a form that is not open is not seen, so the warning can be harmless.
Localizer (IDE) For Windows targets: where an application started from the IDE looks for runtime language files, falling back to the project JSON.
Localizer (standalone) Where a deployed application reads, based on the localizer's LocalizationFolder: the deployed folder, a relative folder, or an absolute path.
Deployment For macOS, iOS and Android targets: whether the language files are in Project > Deployment for the active platform and configuration, and whether their remote path is the folder the localizer reads. A Warning when no language file is deployed, or when they are deployed to another folder. On other targets, such as Windows, the row only reminds you where standalone runs look.

Putting it together: keep the runtime files current

The most frequent warning on the Info tab is the Runtime files row reporting that the exported language files are older than the translation data. An in-house translation tool can prevent it by exporting again every time the editor closes. The handler below opens the editor in German with the language overload of Execute, and the close callback calls the collector's ExportRuntimeFiles, which writes the same files as Export Runtime Files...:

Keep the runtime files current after editingPascalC++
procedure TFormMain.btnTranslateClick(Sender: TObject);
begin
  { Open the editor in German. Its Info tab, the last tab, shows whether the
    runtime language files are older than the translation data. }
  LocalizationEditor.Execute('de', EditorClosed);
end;

procedure TFormMain.EditorClosed(Sender: TObject);
var
  Files, Lines: Integer;
begin
  { The editor saved the translation data when it closed. Export the runtime
    language files again, so the application does not keep reading files
    that are older than the translations (the Info tab's "Runtime files"
    warning). Desktop only. }
  Files := Collector.ExportRuntimeFiles(Lines);
  if Files > 0 then
    lblSetup.Text := Format('Exported %d language file(s), %d lines.', [Files, Lines])
  else
    lblSetup.Text := 'No translation data file to export from: see the Info tab.';
end;

void __fastcall TFormMain::btnTranslateClick(TObject *Sender)
{
  // Open the editor in German. Its Info tab, the last tab, shows whether the
  // runtime language files are older than the translation data.
  LocalizationEditor->Execute("de", EditorClosed);
}

void __fastcall TFormMain::EditorClosed(TObject *Sender)
{
  // The editor saved the translation data when it closed. Export the runtime
  // language files again, so the application does not keep reading files
  // that are older than the translations (the Info tab's "Runtime files"
  // warning). Desktop only.
  int Lines = 0;
  int Files = Collector->ExportRuntimeFiles(Lines);
  if (Files > 0)
    lblSetup->Text = "Exported " + System::UnicodeString(Files) + " language file(s), " +
      System::UnicodeString(Lines) + " lines.";
  else
    lblSetup->Text = "No translation data file to export from: see the Info tab.";
}

ExportRuntimeFiles returns 0 when no translation data file is in use, which is the situation the Translation data row reports as a Problem.

Common pitfalls

  • The Info tab is not available in TMS WEB Core. Only the VCL and FMX editors have it.
  • A run-time editor shows fewer checks. Project options, the .drc file, the localizer's folder and the deployment can only be read by the IDE. Open the editor from the collector in the designer to have them checked.
  • Switch tabs to refresh. The tab is rebuilt when you change tabs, not while you build or edit project options in the IDE.
  • "Older than the translation data" means exported files are stale. The application keeps reading the old language files until you export again with Export Runtime Files....
  • "No localizer found" may be a false alarm. Only open modules can be inspected. Open the form that holds the localizer and switch tabs to check again.

See also