Support Unicode

[JackDunaway]

Support unicode officially for all FP indicators and controls! Captions and string indicators can be "coaxed" into showing Unicode characters (among other controls/indicators), but trees and listboxes (among most others) cannot show Unicode.

Of course, this may have a small audience, but anyone who has developed a UI meant to be distributed to half a dozen language-speakers has probably fought the same Unicode battles and figured out the display "hacks" that we have.

[JoergLee]

For me it would be also important that LabVIEW supports more than one UNICODE page at the same time, like C#. Because we have to print reports in more then one language at the same time, like German, English, Russian and Chinese. English is never a problem, because the standard ASCII code includes all English characters.

[Halden]

We want Unicode support so that our instruments can be more-easily used by technicians at

our customers' sites around the world.   We have a method that reads control captions from a

unicode text file and programmatically loads them via property nodes.  But we can't change

tabs, enums and some other stuff.  And wierd things happen apparently randomly with the

front panel switching to unicode gibberish at unexpected times.  Because of the extent of the

headaches, I don't recommend that people try to do this.  If Unicode were supported, instrument

manufacturers could create multiple language files for one application, and customers could

select their preferred interface language, thus increasing the market for LabVIEW applications.

[S.Minami]

When we get data from Web API, response data is not only XML data.

For example, JASON data, HTML data including CSV data and more.

Then, we use the LabVIEW String function for parsing the data.

However, we get a character garbage because the LabVIEW String function does NOT support Unicode.

We hope that the LabVIEW String function supports Unicode.

Or, we wants JASON and HTML parser function with supporting Unicode.

(LabVIEW XML parser function supports Unicode: UTF-8.) 

[JackDunaway]

S.Minami - if you're interested, it's possible to convert UTF-8 (the canonical web standard for Unicode) to UTF-16 (the LabVIEW supported encoding of Unicode) to display Unicode strings on your front panels. Check out A List of Tips and Tools for using Unicode in LabVIEW for using Unicode in LabVIEW.

But I agree, I wish LabVIEW natively supported UTF-8 rather than UTF-16.

[Andrey_Dmitriev]

And please, add support for Unicode everywhere in LabVIEW.

Windows current location - Germany, with enabled Russian support for non-unicode Apps:

[Broken_Arrow]

This 3.5-year-old Idea is a "hidden gem" - needs way more Kudos.

[Mr.Mike]

@BrokenArrow, I've given all the kudos I can!

[JackDunaway]

>> This 3.5-year-old Idea is a "hidden gem" - needs way more Kudos

Little known fact; a while back, a brief study on the IdEx uncovered this idea as having a peculiarly high votes-per-views ratio, and also a steady long-tail stream of votes; both factors indicate Unicode-hungry devs continually landing here via organic search, intent on solving an acute problem, yet finding the ability does not exist.

[rva]

As a first little step it would be helpful when the currently implemented Unicode functionality would work properly without bugs like:

-"unexpected switching between Unicode or ASCII interpretation in front panel and block diagram"

-"switching the whole LabView environment in a pseudo chinese state"

-"show only first character in a TextRing"

and so on.

(http://forums.ni.com/t5/LabVIEW/Why-does-my-LabVIEW-occasionally-display-in-Chinese/td-p/1175603/pag...

---

@JackDunaway wrote:

Support unicode officially for all FP indicators and controls! Captions and string indicators can be "coaxed" into showing Unicode characters (among other controls/indicators), but trees and listboxes (among most others) cannot show Unicode.

Of course, this may have a small audience, but anyone who has developed a UI meant to be distributed to half a dozen language-speakers has probably fought the same Unicode battles and figured out the display "hacks" that we have.

---

[BastiFantasti]

Because of the lack of a working i18n approach in LabVIEW, I think UTF-8 support is essential to let the developers build their own tools for localisation without those buggy and quirky work arounds. Almost all available major programming languages support UTF-8 (e.g. Python, Java, all .net languages, ...)

I would appreciate it very much if LabVIEW would get the support for UTF-8 in the near future