multilingual project

[Wiebe@CARYA]

Hi,

To use different string for messageboxes is different... Best would be to
make a lookup vi. I'd choose a enumerated to choose which string you'd like,
and another one to choose between languages. You have to put this VI in the
code before every messagebox. It would be best to make the VI a buffer, so
you can set the language at one place (e.g. with a menu item), so you don't
have to wire the selected language though the entire diagram...

Regards,

Wiebe.


"Urs Bögli" wrote in message news:4136f223@newsgroups....
> Doc-Doc,
> I would be happy with some message boxes, maybe the controls can stay in
> english.
> Your method is perfect, but too much work!
> Urs
>
> Doc-Doc schrieb:
>
> > Hi Urs
> >
> > Yes we do multilingual
softs.
> > I don't know if we have the best method but here is how we do :
> > Define text correspondance in a table
> > Use different column for different country
> > Redefine All caption in the correct language at the initialisation of
> > the VI
> > Hide labels
> >
> > It is a enormous work.
> >
> > I would be interrested to see if anyone else has a better solution.
> >
> > Doc-Doc
>

[Ben]

Is this technique available in a built app?

Ben

[DOC-doc]

Well your idea will be fine for 2 languages. When you make soft modifications, you pay double price.

For more than 2 languages, the work becomes outstanding.

One idea with the text file is that if there is a message or label error (which can happen when there are many languages), you can correct it without making a new build.

Furthermore, some of our customers can implement themselves new tongues by asking translators to do the job only in the text file, which is easier

[Robert A. Morton]

You can import VI strings into VIs in a built app as long as they are not running or run-reserved when you attempt to import. (Run-reserved means that some parent VI in their hierarchy is running, and the run-reserved VI could start executing at any time). Additionally it's important to note that you cannot export VI strings and perform operations such as creating captions, since this modifies the VI and requires a save.

-Robert

[Robert A. Morton]

I absolutely agree, and this was one of the points of discussion about the topic of localization at NI Week this year. With the VI Strings file format you are placing the burden of work on the localization team, which will have difficulty with the obtuse file format; additionally as you mentioned every time the VI changes and you re-export you will have to retranslate.

The alternative mechanism described by others in this thread involved modifying the VI captions, but this does not manage to localize many important parts of the VI:
* boolean text
* default data
* private data (i.e. the strings in a listbox)
* VI titles
* VI or control descriptions
* control tip-strips
* and many more...

So this mechanism results in more work
for the developer, but less for the localization engineer.

A third mechanism that is rarely discussed is the possibility of creating tools to parse and extract the localizable text from the VI Strings format, and place those into an easy-to-localize text file. Parsing and replacing text in the VI Strings format is not easy, but it is doable. In my experience, this is the best mechanism for complete localization coverage in your VIs.

-Robert