Better localization support

[Marc_A]

I know that this idea exists, but it was submitted in 2009 and I haven't seen any progress in this area. The bottom line is that we need a better way to support different languages in built applications. Importing/exporting strings is tedious and there is no good way to work with these files.

My suggestion is another attribute for every control which contains the name of a string in a language file. I've chosen to show it here similar to php, but any other way to denote that it's a localized string could be used, maybe a different color.

In this example, there would be a string with the name "control1" in each language file that gets loaded based on what language is selected.

There should also be a way to add a "free localized label" to the front panel and a "localized string constant" to the block diagram. This way you can use string names in labels and constants that will be replaced with localized strings from the current language file at run time.

The file could be simple xml:

<string name="control1">
  <text>Input Number</text>
</string>
<string name="fileNotFound">
  <text>The file you selected does not exist</text>
</string>
<string name="okButton">
  <text>OK</text>
</string>

An interface to edit language files could be as easy as a dialog box with a 2 column table containing string names and text.

One language file will be the default. The VI should be broken if the string name isn't found in this default file. When changing the language either by the OS default or a property of the application, all localized text is replaced with strings from the new language file. Any that aren't found fall back to the default file.

Most of this is based on the way Android programming handles localization, which makes it incredibly easy to implement.

[David_L]

Are you familiar with the LabVIEW Localization Toolkit.  It is a third party product sold on the LabVIEW Tools Network that does almost exactly what you are requesting.  You define the localization tags at the project level and it allows you to switch between languages in your VI or application.

[Marc_A]

Yes, we're using the trial of that right now to see if it will do what we need. The functionality is mostly there but I can't say it's easy to work with. If it were built into LabVIEW it could be a lot more intuitive. The toolkit is also $1189, that seems excessive to add the ability that other languages have built in.

[Cepera]

I tried the localization toolkit too. It is not very stable, it does not support complicated data types (e.g. clusters of typedefs), it is expensive, and on top of it, they charge deployment fees. Being a global company, NI should have localization and Unicode support built into LabVIEW.

The approach suggested by Marc_A is good, but it needs to extend to pretty much all string type features of UI elements, e.g. axis labels on graphs. Ideally, it should be possible to localize strict typedefs too, but that's a tough call. At least, give us localization of everything else.

[Porter]

I took a crack at this problem and posted my solution on LAVA: https://lavag.org/files/file/249-set-toolkit/

Its currently not meant for run-time language switching but I'd be willing to pick up development again if there was any interest.