HMI: Making the Browser SCADA Multilingual


Thread Starter


Hello Fellow listers,

I have been thinking of making the tiny browser SCADA put up at multilingual, and here is the reason why: I have been planning to migrate to Canada and though the procedure is in
the initial stages, I decided to learn french. Then I met an Indian at a railway station and he, looking at my french books, well, we started
chatting and he informed me that in the french regions of Canada, you need to know french!
I recalled similar things happening in the past in India. I once even wrote a operations manual in Marathi!

Now what if say in a control room, there is a french person and un anglais!

or suppose a giant corporation like shell or chevron wanted to integrate the SCADA or systems working across the globe and ensure some sort of
interoperability from across the globe! Then either the entire globe has to become anglais which again is problematic. the Hindis will stick to hindi, the Arabs to arabic and french to french, japanese to japanese and chinese to chinese and so on. We need a system such that the
interpretation in the various languages is automatic.

I believe that having a new tags in HTML will greatly help in having multilingual support.
The new tag <langcode> will give a twelve digit alphanumeric code. It will be closed by </langcode> When there is no equivalent <nolangcode alt="123456789abc" native="french"> which will mean that there is no langcode for this text. the nearest equivalent code is given and the native language or the language in which the text which has no langcode was written. this can be closed by </nolangcode> numbers inside the texts could be written by <langnumber> closed by

Say the alarm tag is "Converter Temperature High 175.25". In french it may be "Temperature du converter haut (or grand) 175,25" {Note that since i could not get the accent signs in My linux m/c, the text is basically incorrect in french, but does convey the message} And somewhat different in German, spanish, Arabic, Hindi, Marathi and the thousands of languages across the globe.

Now suppose the server or WEB PLC gives a message indicating the langcode say for example

<langcode> abc123456789 <langnumber>175.25</langnumber></langcode>

The browser could have the related messages for the codes stored in the language used in the particular PC and the message could be displayed in the relevant language.

Detailed explaination of the working:
A standards committee like say the W3C makes the langcodes. The body establishes a comprehensive list of codes for common sentences in every
The table has the following columns:
A langcode column as a primary key,
The language which represents the exact meaning for this langcode,
The languages columns which store the meaning for the langcode in that language, like englist(us), english(uk),french, german, hindi, arabic,
persian and so on.

The browser stores the langcode in the machine. The webtraffic is limited to transmitting langcodes. The browser interpretes the langcode
in the native language. The user sees the text in users own native language.

There are of course limitations that not every phrase could be covered, but such messages can be written with code <nolangcode
alt="abc213456789" native="english"> No bhai there is no anglais code for this</langcode>
Where the user sees the message in english "No bhai there is no anglais code for this"
followed by "nearest Equivalent: There is no English equivalent" in native language. The browser now has to play a critical role, of converting whatever the user types to equivalent codes for transmitting. And on reciept to
reconvert the messages back to text.

Visit <> for
Free Tutorials, Source Codes and Other stuff.

LinuxPLC mailing list
[email protected]

Paul H. Gusciora

It might be easier to get everyone to convert to Esparanto.

But seriously, there are more basic problems with variable units.

In North America, almost all petroleum, and most chemical plants present temperatures in deg F, even though deg C has lots of advantages. We even
had some plants that were displaying deg C, and converted everything over to deg F. If I had my way, the temperatures would be displayed in K, and
people would have to learn what the practical temperature scale means.

Pressures are not terribly confusing, except that there are force / area measurements (lb / in2 = PSI, Pascal), and head measures (in H2O, mm Hg, ft
H2O), in addition to the absolute / gage issue at times.

Flows present more of a problem. Large scale petrochemical plants process mass. They may report the flows as volume / time, but it is always quoted at a particular temperature, pressure and state; and therfore implied density. Contracts often include an adjusment in case the density changes due to composition (as does natural gas bills to residences and businesses). So mass flows around the plant, but is reported on the displays as volume units:
gal, bbl, m3, ft3
or mass units:
lb, kg, ton
per time unit:
sec, min, hr, day, year

Within a given plant, tradition rules the set of units used to display a fluid flow. For example, the flows around a boiler are displayed in units
which depending on the fluid. Water in is usually displayed as gal / min, steam out is displayed as lb / hr, Air in is displayed as ft3 / min, and
fuel could be displayed as lb / hr, or ft3 / min.

Just because the flows are reported in mass or volume units does not imply that they are compensated for temperature and/or presssure. One can find flows measured by differential pressure meters which are compensated but reported in volume units, and those that are not compensated, but reported in mass units.

Multipliers are used which result in entering numbers in the range of [0.1, 100], unless history and custom dictate otherwise. Multipliers following electrical/metric tradion are used (k, M), but sometimes other multipliers appear (M = 10**3, MM = 10**6 in some petroleum service).

Don't get me started on concentrations. The next time you see analyzer results on a display, ask people if they are repored as mol %, mass %, or
volume %. Usually people do not know.

BTW: If you have the system convert the units on the fly, you set things up for catastrophic failure. Example: NASA crashed a sattelite because one group worked in km, and the other in nautical miles.

Paul H. Gusciora, Ph.D., P.E.
San Rafael, CA

Process Control: Improving Process operations three ways: Feedback, Feedforward, Optimization

LinuxPLC mailing list
[email protected]

Gilles Allard

Anand a ecrit:
>I believe that having a new tags in HTML will greatly help in having multilingual support.
There is already support for languages in HTTP. My browser preferences are set for French first and then English. If I connect to, then I automatically get a french WEB page.
I'm not sured this mechanism can be used to switch language without opening a new session.

Many softwares support localization (linux and KDE are good examples) but, in most cases, you should restart the application to get the new language.

>Now what if say in a control room, there is a french person and un anglais!

I'm living in the french portion of Canada. Support for bilingual systems may sometimes be required.
I've designed a few MMI applications where you can press a Fkey to switch from french to english (and vice-versa). We were not using OS services; everything was implemented in our software.
Another example is Siemens MMI. Some of them can support up to 5 simultaneous languages (select a language in the menu and every text is translated). There is no magic there; when the application is configured you define texts in 5 different directories. Selecting another language is nothing more than switching to a different (preconfigured) directory.

I have a nice anecdote about this problem.
Many years ago, we designed an operator interface for a large machine to replace pushbuttons, selectors, dials and thumbwheels. The operator interface was unilingual (french). After installation, everybody noticed that the efficiency of a specific operator has decreased with the new interface. He was unilingual (english). We concluded that our operator interface was not user-friendly for this specific person so we went back to the drawing board and redesigned the software to be bilingual. After installation of this new version, the efficiency of the operator was still low. We were very disappointed (user-friendliness was a goal).
A few weeks later, we learned the guy was illiterate. Nobody in his group knowned that.

The Xycom/Pro-Face HMI suport multi-language capability right out of the box. It's a fairly easy implementation.

For example, if English is the primary language, all the words that would need to change on the HMI screens would populate column A on a spreadsheet.

Then, your next language translations would fill in the subsequent columns as needed. This can be done for several languages.

Then you would put a push button on the screen for each language that, when pushed, will set a language varible and all the tags for that language would now key over to that language.
As I understand it, the satellite crashed, not just because they were working in different units, but because neither group was aware that they were working in different units. If there had been a translation process in place (or even communication?), there may not have been a crash.

Bruce S.