LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Multilanguage user interface

Hi,

 

I want to develope a distributable that allows multi language user interface selection; despite the fact the question has been asked a considerable number of times I haven't found a good solution yet in the community discussion / NI documentation (most likely my fault...).

The approach I did in the past was to create a multi columns ascii file (one column for each language) and dynamically retrieve string and change captions, labels etc. one by one at VI startup (look code image below). It works, but is a good solution for a simple user interface with a limited number of objects to be translated. The application I'm going to devolope is quite big one, and I want to avoid wasting time in handling every single caption the way I did till now.

 

 

Recently I've used some Scada / HMI developing software and it is astonishing simple to realize multi language UI, but maybe I'm missing something in Labview.

I would like to have suggestion on what is the best approach to minimize the impact of multilanguage application development...THANKS!

0 Kudos
Message 1 of 14
(5,844 Views)

NI has a white paper on this, but I honestly didn't find it too helpful when I had to do this myself.  Here's a summary of how I went about it:

 

My application requires unicode support since the user needs to be able to change between various multibyte character sets at runtime.  LabVIEW doesn't actually support unicode (officially) however, so the built-in import/export tool was useless to me (I don't think I would have liked using it anyway).  I had to come up with my own solutions for localizing various types of UI text:

 

 

Captions

 

For any text associated with a control on the front panel, you'll need to use captions rather than labels.  I found it best to make the caption not size with text, but instead allocate a certain amount of space for it and use the desired justification (center, left, right).  If the text ends up being too long it would be cut off and you need to work with your translator to come up with something smaller (or if necessary re-arrange the UI).

 

What I did is make a config file (encoded in UTF-8 without BOM) with a section for each language and under each section a key / value pair for each control to be localized (using the label for the key).  For example:

 

[English]
Emergency Stop Indicator=Emergency Stop
Voltage Indicator=Voltage [V]
Pulse Length Indicator=Pulse Length [μs]

 

[French]
Emergency Stop Indicator=Arrêt d'urgence
Voltage Indicator=Tension [V]
Pulse Length Indicator=Longueur [μs]

 

[German]
Emergency Stop Indicator=Notaus
Voltage Indicator=Spannung [V]
Pulse Length Indicator=Pulslänge [μs]

 

[Korean]
Emergency Stop Indicator=비상 정지
Voltage Indicator=전압 [V]
Pulse Length Indicator=펄스 길이 [μs]

 

[Chinese]
Emergency Stop Indicator=紧急停止
Voltage Indicator=电压 [V]
Pulse Length Indicator=脉冲长度 [μs]

 

 

The nice thing about this is that to add a new language I just copy one of the existing sections and add new translations for the strings.

 

To localize, iterate over each control on your user interface VI(s) and find the corresponding key / value pair from the .ini file.  

 

localize_captions.png

 

 

I believe the unicode VIs came from here.

 

 

Graph Labels (or other text associated with a control)

 

I handled these similarly to above.  I only have a couple of graphs on the UI so I just cased off of the control label name and in those cases looked up different strings from my .ini file (e.g. "X axis label") and used the appropriate property nodes to set them.

 

 

Window Names

 

I ended up calling into user32.dll since it didn't seem possible to set a unicode window name in LabVIEW directly.  You can use FindWindowA or FindWindowW (depending if the window name is ASCII or unicode) to get a hwind reference then use SetWindowTextW to write a unicode name to the window.  This could be a bit tricky if your window can come and go (i.e. a collapsable menu window or something like that), so how you handle this is really going to depend on the application.

 

 

Text Ring Controls

 

This was by far the worst one--unicode text does not display properly in the built-in LabVIEW ring control drop-down.  I considered just keeping the ring controls in English, but in the end I bit the bullet and made my own ring control drop downs (I intercept the mouse click event and launch my own subVI window on top of the ring control where the drop down would be expected).  It was kind of complicated and what I ended up with wasn't very general (i.e. hard-coded font sizes and upper bound on ring length specific to my application) so I'll spare you the details.

 

 

Best Regards,

John Passiak
Message 2 of 14
(5,809 Views)

Dear John,

 

Thanks for the detailed explanation.

Your solution is very similar to mine as you can see in the attached image (till now I didn't have any unicode support request, so has been easyer). Me also I found not too helpful the NI white paper and with the import/export tool seems quite impossible to handle VI revisions. 

I used recently an HMI interface editor software and I been really impressed how fast and easy was a multi language user interface development, so I wanted to investigate if an efficient way to translate user interface NOT string by string exists in LabVIEW. Till now seems not, if so I've to maintain my current approach, maybe with the additional hints you gave to me.

 

 

 

0 Kudos
Message 3 of 14
(5,757 Views)

Hi John,

 

I've analyzed a little bit more in detail your solution and I cannot said is similar to mine... all captions text are automatically updated avoiding manual linking between entry in language file (containing multilanguage strings) and control caption text.

As you pointed out Charts labels (but also tables headers, boolean caption text, pop up messages, ...) are to be handled choosing the appropriate property ("my" approach 😉 )

0 Kudos
Message 4 of 14
(5,745 Views)

I know, this is a old post.

 

John_P1 wrote:

 

"Window Names

 

I ended up calling into user32.dll since it didn't seem possible to set a unicode window name in LabVIEW directly.  You can use FindWindowA or FindWindowW (depending if the window name is ASCII or unicode) to get a hwind reference then use SetWindowTextW to write a unicode name to the window.  This could be a bit tricky if your window can come and go (i.e. a collapsable menu window or something like that), so how you handle this is really going to depend on the application."

 

I tried SetWindowTextW but, I always have something else...

 

Unicode title.png

 

 Maybe someone could explain what I am doing wrong.

Jean-Marc
LV2009 and LV2013
Free PDF Report with iTextSharp
0 Kudos
Message 5 of 14
(5,436 Views)

I'm a bit behind on my LV installations (2011) so I can't open your VI.  

 

How are you getting the handle (hWnd) to pass into the .dll?  Using FP.NativeWindow works well for me (it's part of SuperSecretSpecialPrivateStuff).

 

Localize Front Panel Window.png

 

 

 

I made this simple tester for it (I'm not sure at which point the property returns a valid handle so you might need a delay before calling it... this seems to work for me though).

 

Localize Front Panel Window test.png

 

 

Best Regards,

John Passiak
Message 6 of 14
(5,408 Views)

Thanks John!

I am ashamed!

I tested your VI and I received the the same garbage.  Assuming, that your VI is correct on your system and not on mine, I tried to remember what I have done recently:  and bang - yesterday morning I erased "UseUnicode = True" in the ini file...
 
Now, your version and my version give the good title.

Jean-Marc
LV2009 and LV2013
Free PDF Report with iTextSharp
Message 7 of 14
(5,392 Views)

I posted a toolkit for edit-time language switching of LabVIEW projects over at LAVA: https://lavag.org/files/file/249-set-toolkit/

 

Although it doesn't allow run-time language switching, at least it helps me distribute my programs in different languages.

 

Similar to John's solution, I store exported strings in a unicode text file. However, when I apply a language to the project, the strings are mapped to their associated code page. This way I don't have to mess about so much with the LabVIEW's unofficial unicode support.

Message 8 of 14
(5,245 Views)

Hi John,

I know this is an old thread but could You provide the source code for the program displayed on the picture above? I was unable to recreate it because I can't find the function with "Parse tabs only" input.

Thanks in advance.

 

Ondrej Karpis

 

0 Kudos
Message 9 of 14
(4,946 Views)

 

O_K a écrit :

Hi John,

I know this is an old thread but could You provide the source code for the program displayed on the picture above? I was unable to recreate it because I can't find the function with "Parse tabs only" input.

Thanks in advance.

 

Ondrej Karpis

 


Hi O_K,

The picture (png) is a Snippet, convertible to LabVIEW code: http://www.ni.com/tutorial/9330/en/

Reg
0 Kudos
Message 10 of 14
(4,897 Views)