Dear all,

I have been tasked with setting up a small server / client setup using RSViewSE CPR9.

The client wants to use language switching and I would like to know if anyone has had any experience of this,
do you have any hot tips or considerations, are there any fields which you cannot do, say, strings within databases etc.

We could just double stack everything and just get the operator to click a flag on startup, but, its messy and duplicates everything.

Any thoughts anyone?

*XxGunnerxX*

OK all,

One further thought, to minimise the use of different languages I have had the idea to use symbols (ie a square, circle, triangle etc) instead of words such as "Start", "Stop", "Hold" etc. This would minimise the work required in providing 2 different translations.

Has anyone come across popups or screens controlled by symbols and can someone point me in the direction of any standards, either UK or USA Based?

Thanks

*XxGunnerxX*

First, one of the Panelview Plus demo's has something kind of slick. Normally you get a traditional spartan user interface screen. There is a small yellow circle with a question mark on it in a corner. When you click on it, circled question marks appear all over the screen. Clicking on each one brings a popup with descriptions on what each function does.

Second, I already dislike your symbolism information. I'm OK with the idea of coming up with a standard for the various buttons which creates a somewhat unified interface because humans are pattern recognizers and if you have a button with a particular shape and symbol and keep things consistent, it does help. We're a manufacturing plant and many settings have to do with timers, machine positions, and speed-type settings. So I make the background of each one a different color. This makes them clearly stand out and there's little question of what each function does, at least at a very fundamental level.

What I don't like about it is that there are no labels at all! This is like the guy who likes to put labels on everything but no units so you are stuck wondering if "Stroke: 5" means 5 inches, 5 centimeters, or 5 seconds. All that you are doing is needlessly slowing down operator training time. Granted that HMI's are much better in terms of graphics compared to say one of those panels with 50 buttons on it with all the labels worn off (we've all encountered these once or twice), but to suggest that you start out that way and plan on dealing with operators that are 100% unfamiliar with your interface...not fun. Plan on carrying a cell phone around PLUS a beeper for the rest of your career.

As to making it any easier to program...I've got news for you. Many languages (not familiar with RS-View's version but it is probably similar) have support for "I18N" which means multilanguage support. To make this work, there are two critical things that they implement. They have to support font sets with lots of international characters and frequently some way to type them in such as the UTF standard. Then, you have to take every one of your labels and assign it a label "ID" which is either a string or a number. They have a translation table stored somewhere which is a table of languages and labels. The table is full of text strings in each language.

So your description may be crude (as in RS-View might not have any I18N support built in), but you are describing exactly what has to be done.

Fortunately, it frequently isn't as bad as it sounds. You only need one label for "Start" and one for "Stop". You might be using these dozens of times throughout the project. The master table contains just two labels and translations to as many languages as you want. And, you can frequently import/export your language table so that once you get all the labels together one time, you can easily copy it into other projects. Some systems even come with some pre-made translation tables.

Ok, The project is now going well and a lot simpler than I thought.

One minor? buglet (oops sorry thats 2!)



1. When I try to use a new line statement in the foreign language column on the excel spreadsheet, when imported it just shows a square and won't do a new line, ive also tried \n to force a new line this doesn't work either. Word Wrap is on on the text on screen, sized to fit is off. I can see the square on the exported English text but if I copy paste this I still see it as a square in runtime, help!!

2. After configuring the alarm event server viewer with the correct font size for the body text, I then access this in runtime, all is well. I then toggle the language and it swops over but drops the font to a smaller font, and then even if I toggle back it stays small. If I come off the alarm summary page and come back on it corrects itself, any clues?

Thanks

*XxgunnerxX*

I don't have a real good answer to your question, but I can provide input. Trying to support Internationalization/localization in a package that doesn't support it is begging for trouble! Particularly so with RSView, which, (correct me if I'm wrong) doesn't even support unicode. (Basically saying the same thing as Paul was with I18N support).

Double stacking everything is a horrible idea for many reasons. Maintaining the project will be easily twice the work, the project is double loading everything in memory, and maintaining consistent changes will be a nightmare. You're setting yourself up for failure with that decision!

If you really need muli-language support AND you're stuck with a package that doesn't support it, consider maintaining 2 separate projects. Complete one in your "main" language before duplicating it and changing the labels. This still requires exactly double the work (bad), but at least you're not creating a *cluster of layered confusion. Don't believe me? Create one moderately complex screen that way, then make a significant change. Bad ju ju.

Bottom line - you may be trying to use a hammer as a wrench. Either find the right tool or do what you can to minimize the pain.

OK, I think I need to outline how i've constructed the project

Im using Factorytalk view studio CPR9 which has the facility to design a project in a default language and assign a secondary one. This can then be exported to an excel spreadsheet which gives you 2 columns one headed en-en one headed pl-pl.

the default language (in this case English) has the actual words as typed in and polish one has lots of **undefined** 's in until you type them in, you then import the finished sheet in. you are NOT double handling pieces of text ie you do NOT have one piece of text in english and one in polish and then do it on visibility that will produce a monster which is unusable and not easy to administer, likewise having 2 seperate projects for the same reason.

The excel spreadsheet values are stored internally within FT View and the language switching seems to employ some sort of lookup table

the software is setup to use multiple laguages out of the box, the only design consideration is that certain Polish words are much longer than English ones and therefore I have had to design boxes to be that bit bigger in order to get the text to fit.

Its an easy system and the carriage return problem is the only one I have otherwise it would work without issues.

Me thinks a call to tech support is in order!

Thanks

*XxgunnerxX*

Oh good - so it does appear that the software supports multiple languages! Why I couldn't find that feature set on their web site, I have no idea!