Foreign Languages in Labview

[Alf Katz]

Hi,
Looking at producing a localizable (to three or four different languages) user interface in Labview. Has anyone tried any of the following, or know whether they are possible?
a) Having a resource file with user interface labels, etc. in non-English extended ascii displayable languages.
b) Any method of doing the same thing with Asian languages?
c) Displaying Unicode with labview?

A brief glance shows little thought has been given to localization for the world not represented in the world series, but maybe somebody out there has some workarounds.

Thanks

Alf Katz
alfk@cfcl.com.au

[CraigGraham]

Unicode is an M$ thing I think, so if you're willing to use Unicode then
platform independence probably isn't an issue.

Try using some of the MS ActiveX controls; I've just created an ActiveX
control of type "MSForms.IMdcText" on a Labview front panel, chnaged its
effect to "flat", set the background "transparent", changed the sizing
property "IntegralHeight" to false and written some Hebrew text in Word to
paste into it, giving me to all intents and purposes a Hebrew control label
that can be positioned over an existing control whose label has been hidden.
If you group them together then you won't even have problems rearranging
your panel to make it look nicer. To verify it IS the ActiveX control doing
this, I tried pasting the same thing into a standard string
control and got
simply a series of question marks.

The activeX object shows up as a "Microsoft Forms 2.0 TextBox" in the
"Select ActiveX Object" dialog.

I've not tried using this any further though so I don't know what
"challenges" you'll face making localisation files that can be loaded on
startup to set all the texts.

Alf Katz wrote in message
news:101-506500000008000000AA150000-982303670000@quiq.com...
> Hi,
> Looking at producing a localizable (to three or four different
> languages) user interface in Labview. Has anyone tried any of the
> following, or know whether they are possible?
> a) Having a resource file with user interface labels, etc. in
> non-English extended ascii displayable languages.
> b) Any method of doing the same thing with Asian languages?
> c) Displaying Unicode with labview?
>
> A brief glance shows little thought has been given to localization
> for the world not represented in the world series, but maybe somebody
>
out there has some workarounds.
>
> Thanks
>
> Alf Katz
> alfk@cfcl.com.au

[Alf Katz]

Hi Craig,

Platform independence is *not* an issue for us. Your suggestion of using
ActiveX is an excellent one, and I'll follow it up. I'm sure a few locality
files won't prove too difficult using this technique. Thanks heaps for the
idea. Guess we'll need to get to know ActiveX a bit better.

The Unicode Worldwide Character Standard is a character coding system
designed to support the interchange, processing, and display of the written
texts of the diverse languages of the modern world (kind of like ASCII for
non-Americans). In addition, it supports classical and historical texts of
many written languages. While Micro$oft is on the Unicode consortium, so
are Sun, Apple IBM, Oracle and many more. It is an international standard
supported by most operating systems (including Linux and Solaris) and all
Browsers that I can think of (possible exception of Lynx).

--
Regards,
Alf Katz,
alfkatz@removethis.ieee.org


"Craig Graham" wrote in message
news:3a9cd1f5@newsgroups.ni.com...
> Unicode is an M$ thing I think, so if you're willing to use Unicode then
> platform independence probably isn't an issue.
>
> Try using some of the MS ActiveX controls; I've just created an ActiveX
> control of type "MSForms.IMdcText" on a Labview front panel, chnaged its
> effect to "flat", set the background "transparent", changed the sizing
> property "IntegralHeight" to false and written some Hebrew text in Word to
> paste into it, giving me to all intents and purposes a Hebrew control
label
> that can be positioned over an existing control whose label has been
hidden.
> If you group them together then you won't even have problems rearranging
> your panel to make it look nicer. To verify it IS the ActiveX control
doing
> this, I tried pasting the same thing into a standard string control and
got
> simply a series of question marks.
>
> The activeX object shows up as a "Microsoft Forms 2.0 TextBox" in the
> "Select ActiveX Object" dialog.
>
> I've not tried using this any further though so I don't know what
> "challenges" you'll face making localisation files that can be loaded on
> startup to set all the texts.
>
> Alf Katz wrote in message
> news:101-506500000008000000AA150000-982303670000@quiq.com...
> > Hi,
> > Looking at producing a localizable (to three or four different
> > languages) user interface in Labview. Has anyone tried any of the
> > following, or know whether they are possible?
> > a) Having a resource file with user interface labels, etc. in
> > non-English extended ascii displayable languages.
> > b) Any method of doing the same thing with Asian languages?
> > c) Displaying Unicode with labview?
> >
> > A brief glance shows little thought has been given to localization
> > for the world not represented in the world series, but maybe
somebody
> > out there has some workarounds.
> >
> > Thanks
> >
> > Alf Katz
> > alfk@cfcl.com.au
>
>

[SergKr]

ActiveX is a solution for ActiveX lovers, but there are couple more ways I'd prefer. One is available as a toolkit for translating front panels using import/export strings mechanisms. This is LabVIEW standard feature with some limitations and guidelines of course (search developer zone for "localization" word). This is for platform independent applications as well.
I have an experience of transcoding unicode symbols say from an EXCEL files to ASCII symbols on the fly and this allows unicode symbols to be seen in string controls etc.

There is also a possibility to use unix-like way of localization mechanism using locales and code pages.

Anyway you'll pay with perfomance and stability for ActiveX. Of course online decoding will eat some pe
rfomance as well, so many of LV developers prefer LabVIEW import/export strings to make front panels localized before run or shipping to customer.

ActiveX will be most heavy in code size, stability and perfomance lost for your application.

In LV 6 there is a way of changing labels (saying captions) programmatically before time-critical applications as well as unicode recoding to ASCII on the fly. The key is reference and vi server, making some captions and texts remake before application run.

This was discussed in Info-LabVIEW group some time ago (hopefully end of the 2000). Try to search: http://labview.pica.army.mil

Good Luck.

[CraigGraham]

The issue here is using characters that are specifically not in the standard
ASCII character set, not in using characters that can be represented
natively in Labview string indicators. I was unable to cut and paste Hebrew
text into either a Labview text decoration or into an LV string control.
This indicates to me that you simply cannot make Hebrew strings. I assume
this also extends to other alphabets that differ from our own not just in
the form of the letters but in the number of letters. On-the-fly conversion
from unicode to ASCII isn't an option if you need more than 255 characters
as, for instance, I believe Chinese does.

Unfortunately I can't search the info-labview archive at the mo- seems to be
down. However I don't recall reading
any message that would have told me how
to make Chinese or Japanese labels, which seem to be the most required of
the "tricky" ones.

Sergey Krasnishov wrote in message
news:101-506500000005000000351A0000-982303670000@quiq.com...
> ActiveX is a solution for ActiveX lovers, but there are couple more
> ways I'd prefer. One is available as a toolkit for translating front
> panels using import/export strings mechanisms. This is LabVIEW
> standard feature with some limitations and guidelines of course
> (search developer zone for "localization" word). This is for platform
> independent applications as well.
> I have an experience of transcoding unicode symbols say from an EXCEL
> files to ASCII symbols on the fly and this allows unicode symbols to
> be seen in string controls etc.

[Sergey Krasnishov]

Craig Graham wrote:

> The issue here is using characters that are specifically not in the standard
> ASCII character set, not in using characters that can be represented
> natively in Labview string indicators. I was unable to cut and paste Hebrew
> text into either a Labview text decoration or into an LV string control.
> This indicates to me that you simply cannot make Hebrew strings. I assume
> this also extends to other alphabets that differ from our own not just in
> the form of the letters but in the number of letters. On-the-fly conversion
> from unicode to ASCII isn't an option if you need more than 255 characters
> as, for instance, I believe Chinese does.
>
> Unfortunately I can't search the info-labview archive at the mo- seems to be
> down. However I don't recall reading any message that would have told me how
> to make Chinese or Japanese labels, which seem to be the most required of
> the "tricky" ones.
>
> Sergey Krasnishov wrote in message
> news:101-506500000005000000351A0000-982303670000@quiq.com...
>
>> ActiveX is a solution for ActiveX lovers, but there are couple more
>> ways I'd prefer. One is available as a toolkit for translating front
>> panels using import/export strings mechanisms. This is LabVIEW
>> standard feature with some limitations and guidelines of course
>> (search developer zone for "localization" word). This is for platform
>> independent applications as well.
>> I have an experience of transcoding unicode symbols say from an EXCEL
>> files to ASCII symbols on the fly and this allows unicode symbols to
>> be seen in string controls etc.

LabVIEW for these countries/languages is or should be different one
because of that 255 symbols limitation, I think. But never tried/needed
to develop Hebrew or Chinese. So didn't know/meant and agree of course.

These issues learned for "letter" languages and hope that LabVIEW will
support unicode at some time, when it will be fully finished by the
unicode standard team and supported by most of the popular OS. Not in M$
implementation.

Thanks Craig,

--
Sergey Krasnishov
____________________________________
Automated Control Systems
National Instruments Alliance Member
Moscow, Russia
sergey_acs@levsha.ru
http://acs.levsha.ru

[Greg_McKaskle2]

> The issue here is using characters that are specifically not in the standard
> ASCII character set, not in using characters that can be represented
> natively in Labview string indicators. I was unable to cut and paste Hebrew
> text into either a Labview text decoration or into an LV string control.
> This indicates to me that you simply cannot make Hebrew strings. I assume
> this also extends to other alphabets that differ from our own not just in
> the form of the letters but in the number of letters. On-the-fly conversion
> from unicode to ASCII isn't an option if you need more than 255 characters
> as, for instance, I believe Chinese does.
>
> Unfortunately I can't search the info-labview archive at the mo- seems to be
> down. However I don't recall reading any message that would have told me how
> to make Chinese or Japanese labels, which seem to be the most required of
> the "tricky" ones.
>

LV is currently sold in four languages. Three of these have ASCII alphabets,
but the Japanese version obviously doesn't. It doesn't use Unicode, but
instead uses a multibyte encoding which I don't know how to spell. It sounds
like Shif-Jis. Unicode is well supported on the modern MS Oses, and support
is getting pretty good for others. That means that Unicode support is in
progress and will be available soon. Unicode is just an alphabet, and alone,
it doesn't handle all the display and especially editing issues. You would
be surprised how complex text editing gets just for simple things like double-
click selecting a word of text. The current Oses tend to have high level
objects that handle lots of text issues, but don't allow enough control for
programs like LV. Then they have very low level and very complex interfaces
for dealing with raw text.

The Unicode support will allow for displaying lots of alphabets, but the
scripts that do not run left to right will take quite a bit more work on
top of these low-level interfaces. Until then, the multibyte encoding
works well for Asian alphabets, ASCII for many other, so as long as the
script direction isn't a problem, LV is already able to display many
languages. You will not be able to transfer or display Unicode until
the support is completed.

Greg McKaskle

[josborne]

Checkout the latest issue of LTR:

http://www.ltrpub.com

It contains an article and some software tools for handling localization. It doesn't address Unicode or double-byte character sets, though.

[Babel]

Hi,

There are many ways to localize your interface in LabVIEW. Look at the localization article on developper zone and look at the recent article published in the LTR magazine.

a) Using a resource file is possible, but you will have to program it in LV. For example, at Run time, you will load the strings corresponding to the language you want. A way to do that is to use control references in LV 6i. To get a reference on all controls of your FP, get a reference on the VI, then on its FP and use the Controls[] property. You will have to recurse to get reference on subcontrols of a cluster. The attached VI shows you how to do that.

b) LabVIEW supports single byte and multi-byte encodings. Displaying double bytes characters is supported as long as your OS does. To displa
y Japanese characters, you will need a Japanese OS.

c) Unicode is not supported yet in LabVIEW. Any attempt to display a unicode string will result in question marks shown on the screen.

We are working to improve ways to localize an application written in LabVIEW.

Regards.

Michel Farhi-Chevillard
Localization Group Manager at National Instruments

[pavitrabaxi]

Hi,

Ive read a lot of your articles regarding localization in labview. None seem to help me. I will describe my problem to you, and will be grateful if you could help me out.

I need to display chinese characters on the front panel.

I am using Labview 8 on SUSE Linux 10.1 with KDE 3.5.1. The labview and linux version are german. I have chinese fonts installed on my PC. All applications like kwrite, open office writer, etc, display chinese characters but labview doesnt display chinese characters. I changed the language and regional settings to chinese, still nothing seems to be happening in Labview.

Im attaching 2 screen shots, one with the chinese characters as displayed in open office writer and the other with the display of the same string imported to labview.

Thanks in advance.

Pavitra