Localization Considerations for LabVIEW Applications

Be aware of factors that influence your approach to localizing LabVIEW-based applications.

LabVIEW supports two formats for exporting strings for translation and importing: XLIFF 2.0 files[1]1 LabVIEW 2026 Q3 and later. and VI strings files. These considerations can influence which format is best to use for your application.

Note In general, NI recommends using XLIFF files for new development.
Consideration Description
Run-time translation or build-time translation Run-time translation refers to the ability to switch languages of your application while the application is running. For example, if a single application serves multiple markets, you can enable a language toggle within the application. A single application can therefore support multiple languages.

Build-time translation describes creating language-specific versions of your application. In this situation, you maintain and distribute multiple copies of the application, one for each language.

This choice influences which strings file format to choose for localization.

  • You can import XLIFF files at run time. This capability enables run-time language selection.
  • You cannot import VI string files at run time.
Use a manual translation process or a build pipeline

LabVIEW can support continuous integration and continuous delivery/deployment. If your organization uses a pipeline for LabVIEW development, you can include translation in the pipeline.

Alternatively, if you have not set up automated development pipelines, you can translate content manually.

You can use either strings format for either approach.

For more information on pipelines for LabVIEW development, refer to LabVIEW Development and Continuous Integration and Continuous Delivery/Deployment.
Translate content on your own or use an LSP

Consider whether to translate your content in-house or use a language service provider. A language service provider (LSP) is an entity that provides language-related services. LSPs can range from individual freelancers to full-service agencies.

Factors that influence your choice include the following:

  • Translate content on your own:
    • Lower volume of content
    • Less frequent need to update translations
    • Access to language expertise in-house, or professional quality translation is not a priority
  • Use an LSP:
    • Higher volume of content
    • More frequent need to update translations
    • Limited access to language expertise in-house, or professional quality translation is a priority
    • Avoid duplicated work: typical LSPs and professional translators use a translation memory (TM). A TM is a database of previous approved translations of your content. When you update your application, the LSP translates only new content relative to the contents of the TM—delta. TMs reduce your translation costs and support consistency in translated material over time.

If you do your own translation, you can use either XLIFF or VI string files.

If you use an LSP, use XLIFF files. XLIFF is a standard file format in the translation field that works with the computer-assisted translation tools (CAT tools) that professional translators use. Most LSPs can use XLIFF 2.0 files. Confirm that any LSP you use can use XLIFF 2.0 files. Some CAT tools can also construct TMs from XLIFF files.

Comparison of LabVIEW String Formats for Localization

LabVIEW can export and import multiple formats to facilitate localization of VIs. Understand these file formats and the differences between them.

Characteristic XLIFF VI Strings File
Definition XML Localization Interchange File Format. XML file format that standardizes the exchange of localizable content between computer-assisted translation tools (CAT tools). LabVIEW uses XLIFF 2.0. First supported in LabVIEW 2026 Q3. LabVIEW-specific file format for localizing VIs.
When to use Recommended for new applications. Recommended for existing applications that already use VI string files for localization.
Number of languages Bilingual file: aligns each source string (the string in your own language) with a corresponding target string (the string in the language you are translating into). Monolingual file: each file enables a single language and contains strings in that language only.
Run-time support Supports run-time language switching: you can design VIs where a user can select a language at run time and translate the interface. Supports build-time localization only. When you use VI string files, you can distribute localized copies of a VI in a single, static language.
Error tolerance Better error tolerance: missing tags do not prevent import (LabVIEW logs associated warnings). Tolerant of changes that you make on the VI front panel after export and before import. Limited error tolerance: import fails if the file contains unknown or missing tags. Import can fail if you modify the front panel relative to when you exported the strings.

1 LabVIEW 2026 Q3 and later.