Release workflow
Localize every new build without starting over.
Scan for Changes compares the new build with your project, keeps the translations that still fit, and marks what is new or changed. Translators get only the difference, and Create Localized Files writes the localized files, by hand or from your build script.
- Each release
- Scan for Changes keeps the translations that still fit
- Work
- Only new and changed strings, found by filter
- Ready
- Translation Readiness for each language
- Automation
- Command line: Professional and higher
Scan for Changes: the new build in, the translations kept.
Put the new build where the original files are and choose Project > Scan for Changes. Localizer reads the new files, keeps every translation that still fits, and lists the difference in Output: New, Updated, and Removed, with their counts.
- New. The item is new in the build.
- String changed. The source text changed; review the translation.
- Matched by value. The item moved; its translation was found by the source text.
- Fuzzy match. The translation comes from a similar source text; review it carefully.
- Bounds changed. Only the size or position of the control changed.
Translations of removed items go to the translation memory of the project, in case the text comes back.
Moved and reworded strings keep their translation.
When a dialog is split in two, Localizer finds each string by its source text. A slightly different text gets the old translation as a fuzzy match, from 90% similarity by default, marked for review.
Work only on what changed.
The filter Any Merge Changes shows only the items Scan for Changes touched; Needs Translation and Needs Review show what is left. Accept what still fits, translate what is new, then choose Clear Merge Status.
Prepare Translation Task sends translators only that part: its filter takes what is not Complete, plus what Scan for Changes marked new or changed.
See which language is ready to ship.
The Statistics pane shows Translation Readiness for each target language: what still needs translation, what needs review, and what is complete. The Ready for Release filter shows the items behind the number.
Project > Generate Project Report saves statistics and progress, remaining work, and the impact of Scan for Changes for the languages you choose. Locked and read-only items are not counted as work.
Create Localized Files writes the localized build.
Localizer writes the localized files itself. For a Win32 or .NET build, that means the localized EXE and DLL files or the satellite assemblies, ready to run and test. By default they go next to the originals, in a folder for each language.
| File | For German (Germany) |
|---|---|
| Win32 localized file | de-DE\MyApp.exe |
| MFC resource-only DLL | MyAppDEU.dll |
| .NET resource file | Form1.de-DE.resx |
| PO file | de_DE\messages.po |
Each format has its output pattern, for the project or for a single file. Set an output folder such as $(ProjectDir)\Localized to keep the localized files apart from the build.
Before the files are written, validation can stop them while a format string is broken; Run Localized Application starts the result in the target language.
The same steps in one line of your build script.
Professional and higher
localizer.com runs the same operations without the window: scan the new build, validate every language, create the localized files, save the project. The exit code is not zero when validation finds issues or an operation fails, so the build stops there.
- Translation tasks.
-sendltp,-sendkit,-sendxliff, and-sendcsvcreate the task with the settings saved in the project; the-receiveswitches import the results. - Memory and terminology.
-importtmx,-translate, and-duplicatefill what can be filled;-terminologyin Enterprise. - A fixed order. The switches run in one order, whatever their order on the line. To validate after an import, run it twice.
- No dialogs. A question gets a preset answer, reported as a warning unless you add
-silent. - Settings from a file.
-settingsapplies project settings from a JSON file.
The Command Line License is included with Professional and higher, with no separate automation license to buy. Not in Standard. In the trial, the command line runs in Enterprise mode with the trial limitations, so you can test your build. Syntax: command-line reference in Help.
One application under several names: Brands.
Enterprise
Brands add a second dimension to languages: the same application under several product, device, or customer names, each in several languages. A terminology list holds the terms that differ between brands, such as product names, and a target brand can show only the items whose original text it changes.
What Release workflow does and does not promise.
Lingobit updates the project and writes the localized files; your build, installer, and release stay yours.
What Lingobit helps with
- Updating the project from each new build
- Keeping the translations that still fit, also for moved and reworded strings
- Finding new and changed items by filter
- Translation Readiness for each language
- Writing the localized files
- The same steps from a build script
What remains project-side
- Building the application and the installer
- Toolchain steps such as Qt
lreleaseor gettextmsgfmt - Loading the language at run time
- Testing the localized application and signing off the release
Matching depends on the format: in HTML and CHM files, changed text comes back as Removed and New.
Related
- MigrationStart the project from the localized files you already have.
- Translation workflowSend translators and proofreaders only the changes, and bring their work back by status.
- Translation assistanceTranslation memory, terminology, and machine translation for the new strings.
- Localization QAValidation before the files are written, and Crash Finder.
- Compare editionsCommand line, Brands, and the formats in each edition.
Localize the next build without starting over.
Scan for Changes, the filters, Translation Readiness, Create Localized Files, and the command line: the same steps for every release.