Jump to content

Changing language German to English


Recommended Posts

Hi,

 

In the last couple of years I have taken over a large amount of LabVIEW code written in German, and I speak, read, write no German.

 

To be honest the language of the IDE was NOT the problem, where the developer knew what he was doing and had written the code with style it was simple to understand and maintain (with a little help from Goggle Translate on the comments), where the 'other developer ' had no idea what he was doing and no concept of LabVIEW style the job was hell (and would have been even in English).

 

The single issue that caught me out in terms of IDE language that I did not foresee or expect was  "localisation issues"  in particular  "use system decimal point (T)" input to certain LabVIEW VI's or default  use of "system decimal point" in others.

 

use system decimal point defines the decimal separator. If TRUE (default), the decimal separator uses the localized decimal separator. If FALSE, the decimal separator is a period.

 

In the past I have always written code on English PC's  and then run the built executable's on English PC's which use "." as the decimal point so I had never really given localisation any thought.

 

I was stumped initially when I had an executable that worked OK in the UK but failed when deployed to Germany.  It turned out that scan from string function and some other VI's  were locale aware and in Germany the decimal separator is "," so my parsing of GPIB output was all wrong.

 

The simple solution to this is place useLocaleDecimalPt=False into the executable's ini file at build time.

 

hope this helps

 

Dannyt

Link to comment
Hi,

 

In the last couple of years I have taken over a large amount of LabVIEW code written in German, and I speak, read, write no German.

 

To be honest the language of the IDE was NOT the problem, where the developer knew what he was doing and had written the code with style it was simple to understand and maintain (with a little help from Goggle Translate on the comments), where the 'other developer ' had no idea what he was doing and no concept of LabVIEW style the job was hell (and would have been even in English).

 

The single issue that caught me out in terms of IDE language that I did not foresee or expect was  "localisation issues"  in particular  "use system decimal point (T)" input to certain LabVIEW VI's or default  use of "system decimal point" in others.

 

use system decimal point defines the decimal separator. If TRUE (default), the decimal separator uses the localized decimal separator. If FALSE, the decimal separator is a period.

 

In the past I have always written code on English PC's  and then run the built executable's on English PC's which use "." as the decimal point so I had never really given localisation any thought.

 

I was stumped initially when I had an executable that worked OK in the UK but failed when deployed to Germany.  It turned out that scan from string function and some other VI's  were locale aware and in Germany the decimal separator is "," so my parsing of GPIB output was all wrong.

 

The simple solution to this is place useLocaleDecimalPt=False into the executable's ini file at build time.

 

hope this helps

 

Dannyt

 

While this is simple it is a brute force approach. Users likely will not like that their user interface suddenly uses the "wrong" decimal point, since this setting changes the decimal sign for everything in the LabVIEW app. The better approach is to think about localization and make the code use explicit formats where necessary and leave the default where things are presented to users.

 

For the legacy string functions you have the mentioned boolean input, for Scan From String and Format into String you have the %.; or %,; prefix to the format string which tells the function to use an explicit decimal sign.

 

Basically anything that goes to the UI would use the system default (and no prefix in the format string), things that communicate with a device or anything similar will likely be done with the %.; prefix. This way the user gets to see the decimal numbers in whatever way he is used to and the communication with GPIB, TCP/IP and whatever devices will work irrespective of the local country settings.

  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.