Localizing Your LabVIEW Application to Different Languages

Publish Date: Nov 26, 2018 | 35 Ratings | 3.60 out of 5 | Print | 8 Customer Reviews | Submit your review

Overview

This article is part of a series on software engineering practices and tools for large application development in LabVIEW.

Click here to view the list of other articles


This document describes the four steps for easily localizing any LabVIEW application into a different language.

Table of Contents

  1. Introduction to Localizing LabVIEW Applications
  2. Step 1. Localize the Front Panel (User Interface) Strings
  3. Step 2. Localize Run-Time Menus (if applicable)
  4. Step 3. Use Localized Bitmaps (if applicable)
  5. Step 4. Use a Localized LabVIEW Environment or Run-Time Engine

1. Introduction to Localizing LabVIEW Applications

You do not need to have a specific language version of LabVIEW, such as French, German, or Japanese, to be able to enter display text in that language. LabVIEW supports single and double byte characters, but it does not support bidirectional scripts (such as Arabic or Hebrew).

If you want to display text in multi-byte character sets (such as Japanese, Chinese, or Korean) in LabVIEW, you only need an operating system of the appropriate language or an MBCS-enabled operating system with an Input Method Editor (IME) for the corresponding language. Also, there are several commercially available language kits that you can add on to the operating system.

Back to Top

2. Step 1. Localize the Front Panel (User Interface) Strings


To localize your front panel, you need to internationalize your code, extract the VI strings into a text file, translate this text file, and import the localized VI strings into the VI.l

Internationalize your code
First, you need to internationalize your code (diagrams). While LabVIEW already provides several locale-sensitive features (including time/date formats, currency symbols, decimal separators, and so on), you may need to internationalize other parts of your code.

In general, you need to transform any hard-coded string constants in the diagram into string controls (with default values) on the front panel. Another useful technique is to move all your string constants (that need to be localized) into global variables. This step should ideally be part of your development process, but you can easily retrofit your application if necessary.

If you are using bitmaps, you should consider using the picture control to load the bitmaps dynamically. This makes it easier to maintain the VI, because you won't have to copy and paste the localized bitmaps each time you modify your application.

Note: You can localize most of the user interface controls and indicators except for enum controls, because the strings that make up the enum list strictly define its data type. Whenever an enum control is not necessary, use a ring control instead.

Note: Pay attention to case structures with a string selector. They can make the internationalization of your application more difficult.

Extract the VI strings into a text file
From the front panel of the VI from which you want to export strings, select the menu item Project>>Export VI Strings. This will generate a text file containing all the VI strings. In LabVIEW 5.x, this text file contains only front panel strings.

Translate this text file
The text file that you export has a structure close to XML. (LabVIEW currently doesn't provide a parser that would allow you to extract only the translatable strings. This would be useful for automated dictionary lookups.)

When you export your strings, LabVIEW automatically generates captions for each front panel control and indicator. Captions, as opposed to labels, provide only a textual name for a front panel object, and allow you to localize your user interface. The labels are propagated in the diagram through the wires, and are used when referring to a specific terminal in a VI. Therefore, you should not localize the labels.

For more information regarding the structure of the exported text file, please see the related link G Programming Reference Manual.

With this text file, you can localize the following:

  • VI window titles and descriptions
  • Front panel object captions and descriptions
  • Free labels
  • Default data (for various controls/indicators, including strings, tables, path names, and array default data)
  • Private data (list box item names, table row and column headers, graph plot names, and graph cursor names)

Import the localized VI strings into the VI
Once you have translated the text file, from the front panel of the VI to which you want to import strings, select the menu item Project>>Import VI Strings. This operation imports the localized strings into your VIs and displays captions instead of labels on all front panel objects. Remember that if you modify the VI later, the exported strings may also change. Importing an old exported text file on a modified VI can result in errors. The process of importing strings creates a log file with a list of any errors that occurred during the operation.

When you import strings, the alignment of the owned labels with respect to their corresponding front panel objects also affects the resulting position of the caption. If ALL of the following conditions are met, the resulting position of the caption is undetermined after importing strings:

  1. The width of the label or caption before translation is narrower than the width of the front panel object itself.
  2. The label is not aligned to its default position (for example, the position of the label when you first lay down a control or indicator on the front panel).
  3. The translated string, when imported, is wider than the width of the front panel object itself.


Condition 3 occurs commonly when you translate strings from English to French or German. German strings can be anywhere from 50% to 100% longer than English strings. The remedy is to make sure that you align the labels or captions for your controls and indicators to their default positions.

Also, make sure you leave enough room for expansion of captions. As mentioned above, foreign language strings can be longer than the English strings. If you do not account for this, you may see captions overlapping with other objects and captions as a result of importing strings. This could make the captions difficult to read.

Back to Top

3. Step 2. Localize Run-Time Menus (if applicable)


The LabVIEW Export Strings feature does not export strings in run-time menu files, but you can change the association between a VI and its run-time menu (.rtm) file.

To localize an application that uses run-time menus, you can do either of the following:

  • You can build all your menus dynamically, using the Application Control>>Menus functions. You will need to store your strings in a front panel control, such as an array of strings, in order to export them easily.
  • You can create separate .rtm files for each language. When you Export Strings from a VI, one of the pieces of information that is exported is the name of the .rtm file associated with the VI. Therefore, if you have several exported string files, each can refer to the appropriate .rtm file for that language.

Note: You cannot change the names of LabVIEW's built-in menus. For example, you can't change the name of File>>Open to something else. In the Japanese version of LabVIEW, the application menu items will automatically use the localized names of those built-in menu items. However, this does cause a problem if you want to make Spanish menus. You must either use English menus, or create user menu items (which you can translate) and use the VI Server methods to invoke particular operations in LabVIEW.

Back to Top

4. Step 3. Use Localized Bitmaps (if applicable)


If you need to localize bitmaps, you might consider using the picture control to dynamically load the appropriate bitmap at run-time. If not, you will have to paste the localized bitmaps each time you want to modify your original VIs.

Back to Top

5. Step 4. Use a Localized LabVIEW Environment or Run-Time Engine


To have localized menus and LabVIEW resources for your application, you can either:

  • Get a localized version of LabVIEW (English, French, German, or Japanese) and run your application (.LLB) under the localized LabVIEW environment, or
  • Create an executable and use different language versions of the Run-Time Engine. Localized versions of the Run-Time Engine exist in French, German, and Japanese. Starting with LabVIEW version 5.1, the LabVIEW Run-Time Engine (LVRT.DLL) is separated from the executable program itself.


Note: In LabVIEW 8.2 and later, the LabVIEW Run-Time Engine is multilingual, so you do not have to include multiple versions of it with an application, shared library, or installer in order to use localized text.

To switch from an English to a French interface, replace the English LVRT.DLL with the LVRT.DLL for the corresponding language. To create stand-alone application executables, you do not need to buy a specific language version of the LabVIEW Application Builder. You can build your executable with the English version of the LabVIEW Application Builder and install your executable on a French OS machine with the French Run-Time Engine.

Note: For standard dialog boxes, LabVIEW uses strings (such as Open, Close, Save, and so on) that are specific to the operating system. Some dialogs contain LabVIEW specific strings (for example, Select Cur Dir), which LabVIEW displays in French, German, or Japanese, according to the operating system's regional settings, and in English for other countries.

Note: Strings in menus (such as File, Edit, Project, Help, and so on) and pop-up menus depend upon the version of the LabVIEW Run-Time Engine you are using with the executable. If you use the English Run-Time Engine, the menus always appear in English, regardless of the language of your operating system. Localized versions of the Run-Time Engine are available in French, German and Japanese, from the National Instruments Support site.
Related Links:
G Programming Reference Manual
Technical Support site

Back to Top

Customer Reviews
8 Reviews | Submit your review

Arabic Language  - Oct 22, 2015

Hi I would like to ask if there is any solution to use Arabic Language? Appreciate any Help

  - Aug 29, 2011

For unicode languages add this to labview.ini : UseUnicode=TRUE

  - Mar 21, 2011

The Menu Functions palette is under Dialog and User Interface>>Menus functions not under Application Control>>Menus functions (see step 2)

Answer to Honda customer about IME  - Sep 18, 2004

We have improved the IME functionnality in LabVIEW 7.1 at the request of several of our Japanese customers. Please upgrade to the latest version to enjoy an "inline" IME, located on each control for better user experience. As for the string functions, we are aware of difficulty to use them on Asian systems and will address them in a future revision of LabVIEW.

Japanese supported under NT based OS and LV 7.0  - Dec 26, 2003

Hi, since LV 70, I'm now able to display Japanese on my LV UIs on English OS. I just had to switch system locale to Japanese, which still requires a reboot. Good feature, even though I couldn't find documentation for it. Now please fix the IME location problem and provide Japanese support for the string functions and I will be happy!!

Can't display multibyte/unicode fonts  - Jul 14, 2003

The described "tricks" in the document and the comment provided do not solve the multibyte/unicode font display problem. Changing the locale setting does not work for people who works on multiple languages and the method is not easily switchable. Just look at how Microsoft Notepad of the Windows 2000 and XP solve the unicode display problem: the user choose the unicode font and the script in the font dialog box. This is much easier to switch from one language to the other. If the LabVIEW could provide such mechanism (e.g., a Windows native font dialog box) to display unicode fonts, then we can localize and test the LabVIEW vi much easier.

Answer about multibyte/unicode comment  - Jan 26, 2003

I would like to answer the anonymous user comment about multi-byte/Unicode. 1. LabVIEW is a multibyte based application, which means it can support any type of Asian characters using a multibyte encoding (such as Shift-JIS for Japanese), which is transparent for the user. 2. Up to LabVIEW 6.1, you needed to have a Japanese OS to display Japanese (and so on for other CJVK scripts) using Application Font, Dialog Font or System font. However, it was possible to display Japanese by changing the Application font to MS Gothic for example. In LabVIEW 7.0, the behavior will be changed. As soon as your system locale is set to Japanese, LabVIEW will pick the correct font to display any text in Application, Dialog or System font. 3. The fact that LabVIEW does not currently support Unicode does not prevent you from localizing an LV application into any Asian language. The only thing you need to be aware of is that the string functions of LabVIEW are strictly ASCII based, so parsing asian characters can be difficult. There are workarounds however (if you know the encoding you are dealing with, you can build your own parser. You can also use the OS string functions by calling a system DLL. Chekc your OS SDK). LabVIEW R&D is aware of this and is working on a plan to improve the string functions for CJVK languages in the future. Regards, Michel Farhi-Chevillard Localization Group Manager

  - Dec 26, 2002

It should be noted that you CANNOT localize labview into Multibyte/unicode character sets if you are using and American/English OS. All localization needs to be done by using bitmaps or jpegs of the character set

View more reviews

Bookmark & Share


Ratings

Rate this document

Answered Your Question?
Yes No

Submit