UI Multi-language with Unicode

[DAckermann]

Hello

So far I was lucky to only need language switching for the UI for English, German and Spanish. But this time I really need to add Chinese. The language should be switchable at run time and it should not depend on the windows settings.

So I was starting to read about the possibilities of using unicode for the UI and did some testing (UseUnicode=TRUE). I have a feeling now, that I am facing a time with a lot of headaches..

What I noticed in my tests is:

- There is no 'force unicode' setting for ring controls, tables, list boxes, tab control tabs

- When I set a string control to 'force unicode' and enter "Hello" via the keyboard, it displays as "H e l l o"?!?

There is a lot of old information out there. So I wanted to ask, if it is possible to develop a unicode UI without restrictions in used types of controls and doing time consuming workarounds in LV2020?

Thanks in advance

[paul_cardinale]

The current very limited support for Unicode is clunky, quirky, and basically a headache.  So much so that I've started developing a new Unicode data type for LabVIEW.  But progress is dreadfully slow because it's not an official project so I'm doing it in my personal spare time (of which I have very little).  Under the hood, the data type is a U32 array with each element being one Unicode character.  I've wrapped the data in a .lvclass (done) so it gets its own wire style and color.  The controls and indicators will be XControls (just a non-functioning shell built so far) and the functions will be wrapped in XNodes so that Create Control/Indicator/Constant will work correctly (and some need to be resizable).  So far I've got Concatenate, To Lower Case, To Upper Case, Trim WhiteSpace, and Replace Substring working.  But the BD constant is giving me headaches.

[paul_cardinale]

I also have these working:

[zou]

Take a look this document:

LabVIEW Unicode Programming Tools

https://forums.ni.com/t5/Reference-Design-Content/LabVIEW-Unicode-Programming-Tools/ta-p/3493021

It's all you need.

Ring, and table shouldn't be a problem.  Not using "force unicode", they need a "BOM".

[paul_cardinale]

---

@zou wrote:

Take a look this document:

LabVIEW Unicode Programming Tools

https://forums.ni.com/t5/Reference-Design-Content/LabVIEW-Unicode-Programming-Tools/ta-p/3493021

It's all you need.

Ring, and table shouldn't be a problem.  Not using "force unicode", they need a "BOM".

---

Yeah, I've seen that; and used it.  As far as I'm concerned, it's a messy hodge-podge.  You really need a new datatype for any of these (and other) functions:

[zou]

Or you can use a .Net ctrl.

[paul_cardinale]

---

@zou wrote:

Or you can use a .Net ctrl.

---

Please explain how "you can use a .Net ctrl" to replace the "Match Pattern" function.

[zou]

.Net ctrl is for display.

If you want to manipulate a string in Chinese, use the Chinese version of LabVIEW.

[DAckermann]

Thank you very much for the suggestions.

I did some more reading and testing and decided to not use unicode. My use case can be solved with the MBCS strings. I only need the possibility to switch to English from any other langage on the fly without changing the code page in Windows. As the English character set is available in all other code pages. This should not be a problem. I do not need to switch from Chinese to Russion for example.

[wiebe@CARYA]

Just want to mention that MBSC is unicode, or actually an encoding for unicode. A very old one, it only supports unicode characters included in the current code page (and font).

If you use 'unicode' there are still lots of encodings to choose from. UTF-8, UTF-16, UTF-32 are just a few. Some come in MSB and LSB variants... Plenty to choose from (not a good thing here).

To render properly, you also need a font that actually contains the characters. If a character set contains Chinees, it often has Cyrillic, Greek, etc., as these are so small in comparison. But fonts not always contain traditional Chinees and simplified Chinees, as both are huge.

It's a big mess; the result of everyone trying to solve a difficult problem in parallel.