Version 5.5. Multi-language Projects. Citect Pty Ltd 3 Fitzsimmons Lane Gordon NSW 2072 Australia

Size: px

Start display at page:

Download "Version 5.5. Multi-language Projects. Citect Pty Ltd 3 Fitzsimmons Lane Gordon NSW 2072 Australia"

Doris Briggs
5 years ago
Views:

1 Version 5.5 Multi-language Projects Citect Pty Ltd 3 Fitzsimmons Lane Gordon NSW 2072 Australia

2 DISCLAIMER Citect Pty. Limited makes no representations or warranties with respect to this manual and, to the maximum extent permitted by law, expressly limits its liability for breach of any warranty that may be implied to the replacement of this manual with another. Further, Citect Pty. Limited reserves the right to revise this publication at any time without incurring an obligation to notify any person of the revision. COPYRIGHT Copyright 2003 Citect Pty Limited. All rights reserved. TRADEMARKS Citect Pty Limited has made every effort to supply trademark information about company names, products and services mentioned in this manual. Trademarks shown below were derived from various sources. CitectSCADA, CitectHMI/SCADA, CitectFacilities and CitectSCADA Batch are regisitered trademarks of Citect Pty. Limited. IBM, IBM PC and IBM PC AT are registered trademerks of Internatrional Business Machine Corporation. MS-DOS, Windows, Windows 98, Windows 2000, Windows XP and Excel are trademarks of Microsoft Corporation. dbase is a trademark of Borland Inc. General Notice: Some product names used in this manual are used for identification purposes only and may be trademarks of their respective companies. October 2003 Edition for CitectSCADA Version 5.5 Manual Revision 1.0 Multi-language Projects 2

3 Multi-Language Projects CitectHMI/SCADA s language switching facility allows you to use one language to configure a project, and another for runtime text items such as alarm descriptions, button text, keyboard/alarm logs, graphic text, Cicode strings etc. You can also dynamically change languages during runtime. For example, if your native language is English, you could enter an English alarm description when configuring the project, but specify to display it in the French or German (or any other language) equivalent at runtime. The desired language can be specified before you run the project, or changed dynamically at runtime (using the SetLanguage() function) - without affecting any of the project s normal operations. CitectHMI/SCADA distinguishes between what is termed the Native Language (e.g. the language of the developer), and the Local language (e.g. the language of the end user). Language changes are achieved by means of a language database, which has a field for native text, and a field for the translated local text. When the project is run, any native text will be replaced with the equivalent local text. Alarm and keyboard logs can be processed in both the native and the local language. This means that both native and local users can read the historical logs. The data can be logged to the same device, or to separate devices. Multi-language Projects 3

4 How to Change Languages Marking Text for Language Change During project development, any text which is to be changed to another language at runtime must be marked with a language change indicator, in the following Native Text [,Width [,Justify]]) Where Native Text is the identifying text which will be displayed when configuring. This text will be replaced by the local equivalent at runtime. Note that the brackets are a necessary part of the indicator. They specify the extent of the native language text. The Width and Justify are optional (indicated by the square brackets). For example, if English is the native language, the following alarm description could be entered: Alarm Failure) This indicator serves two purposes: It flags the text as native, and tells CitectHMI/SCADA to change the text from native to local at runtime. By default, the text that you enter here can be in any combination of upper and lower case. In other words, Motor Failure will be considered the same string as motor failure or MOTOR Failure, and they will all have the same local language translation. Case sensitivity can be introduced by setting the [Language]CaseSensitive parameter to 1. The Width field can be assigned any value from 0 to 254. If the local text is longer than specified, it will be truncated and left justified. If a width is not specified, the field will be the length of the local text, and the text will be left justified. The Justify field specifies the text justification and can only be used in conjunction with the Width field. Justify can be one of the following values: l or L Left r or R Right c or C Centre n or N None For example, to limit the local text in the previous case to 20 characters with right justification: Alarm Failure, 20, R) Characters that are normally part of the formatting ( ) - can also be used within the native text. To do this, you must place a caret (^)character before them. For example, to include a comma without ruining the format: Alarm Failure^, thermal overload, 20, R) NOTE: The caret (^)character will not appear at runtime or in the language database (see the following section). Language Databases When the project is compiled, CitectHMI/SCADA creates a language database (dbase III format), consisting of two fields; NATIVE and LOCAL. Any text marked with a language change indicator is automatically entered in the NATIVE field. You can then open the database and enter the translated text in the LOCAL field. Multi-language Projects 4

5 For example: NATIVE Line Broken Alarm at Line Speed {LineSpeed1} Main Menu page Conveyor Belt Trip LOCAL <Translation of Line Broken Alarm at Line Speed {LineSpeed1}> <Translation of Main Menu page> <Translation of Conveyor Belt Trip> When the project is run, the translation of Line Broken Alarm at Line Speed {LineSpeed1} will display in place of the English text, the translation of Main Menu page will display in place of the English text etc. NOTE: For the language change to occur automatically when the project is run, you must specify the language database which is to be used before you run the project. This is done using the [Language]LocalLanguage parameter. Otherwise, you can change the language yourself at runtime, using the SetLanguage() function. If you do not enter a LOCAL equivalent of the NATIVE text string, the NATIVE text will be displayed by default. You can specify to display "#MESS", instead of the NATIVE text, by setting the [Language]DisplayError parameter to 1 (one) - the default is 0 (zero). NOTE: For single byte languages (such as French), the database can be edited using Microsoft Excel, but for double byte languages (such as Chinese), it is recommended that Visual FoxPro be used. By default, the language database created by the compile is called English.dbf (this can be changed using the [Language]LocalLanguage parameter). It is saved to the project directory. Once the database is created, it will be updated each time you compile. Any text which has been marked since the last compile will be appended to the end of the database - the rest of the database will remain unchanged. Multiple Languages NOTE: When you want to use characters for Baltic, Central European, Cyrillic, Greek, Turkish, and Asian languages, or right-to-left languages (Arabic, Hebrew, Farsi, and Urdu) the operating system must have the corresponding language version of Windows, or have installed system support for that language. Each local language must have its own language database, so that it can be displayed in place of a specified native language at runtime. Also, it must be set as the local language using the [Language]LocalLanguage parameter. With this parameter set before you compile, CitectHMI/SCADA automatically creates/updates the relevant language database. For example, to display text in French at runtime, set the [Language]LocalLanguage parameter to French, flag all necessary native text in the project and compile. After compiling, look in the project directory for French.dbf, open it, enter the required French translations in the LOCAL field, and save the database. When the project is run, all marked native text will be replaced by the appropriate French text. Because you can have any number of databases, you can use as many different languages as you like. NOTE: When you compile, all text marked with a language change indicator is entered in the NATIVE field of whatever database is set as the local language using the [Language]LocalLanguage parameter. Therefore, it is very important that you know what database is set before you compile. Also, if you have a number of language databases with the same native language, you Multi-language Projects 5

6 should remember that newly marked text will only be appended to the current local language database (as specified by the [Language]LocalLanguage parameter). If you want this text to be added to other databases with the same native language, you should change the [Language]LocalLanguage parameter, update pages, and re-compile for each database. Remember that for each database, only the relevant changes made since the last compile will be added. Multiple Projects A language database can contain entries which are not actually included in a project. This means that a single language database can be developed, which is applicable to a whole range of projects. Changing Languages at Runtime The language of runtime display items such as alarm descriptions, button text, keyboard/alarm logs, graphic text, Cicode strings etc. can be changed dynamically at runtime, using the SetLanguage() function. All normal operations of the project will continue unaffected. NOTE: Forms will not automatically update when the language is changed using the SetLanguage() function. They must be closed and re-opened for the change to take place. Any local translations that are missing from the specified language database will be replaced by the native equivalent. You can specify to display "#MESS", instead of the NATIVE text, by setting the [Language]DisplayError parameter to 1 (one) - the default is 0 (zero). Logging Data in Different Languages Alarm and keyboard logs can be processed in both the native and the local language. This means that both native and local users can read the historical logs. The logs can employ the same device, or separate devices. Logs in the local language are produced using the standard field names. For example, if {NAME} {DESC} {COMMENT} is entered in the format field of an alarm category, the alarm name, description and comment of all alarms in that category will be logged in the local language. All fields which support the automatic language change facility can also be logged in the native language. To do so, just precede the field name with NATIVE. For example, to log the name, description and comment of a category of alarms, enter {NATIVE_NAME} {NATIVE_DESCRIPTION} {NATIVE_COMMENT} in the format field for that category. To log both native and local to the same device, just enter the standard fields, and the native fields together in the format field. To log them to different devices, use a Group of two devices, and enter the local fields as the format for one, and the native fields as the format for the other. Multi-language Projects 6

7 ASCII, ANSI and OEM Character Sets ASCII and ANSI Character Sets Each screen character is defined by a code (number). Operating systems and applications need to know these codes to attach meaning to individual characters. A character set provides a code for every character. For your operating system/application to interpret a character correctly, you must use the correct character set. NOTE: Character sets are distinct from fonts. A font defines the visual/appearance properties of a character - not its meaning. ASCII (American Standard Code for Information Interchange) is a widely adopted 7-bit code specifying the basic alpha-numeric character set of the English language. For example, the character capital 'A' has the ASCII value of 65, and the character lowercase 'a' has the ASCII value of 97. The ASCII character set contains 96 characters, it is commonly used as a standard for protocols and files. Windows 95 uses ANSI (American National Standards Institute) character sets. ANSI character sets are language based, with each different language version of Windows (French, Korean etc.) requiring a specific ANSI character set. Codes 32 to 127 always contain the standard ASCII characters. NOTE: Windows NT uses Unicode - but still supports ANSI character sets. Unicode avoids the problem of multiple character sets by having one 16 bit - worldwide - character encoding standard. To support both Windows 95 and NT, CitectHMI/SCADA must use ANSI character sets. OEM Character Sets OEM (Original Equipment Manufacturer) character sets are those which are used by MS-DOS or Console applications (they are operating system dependent). Most OEM character sets do not match the ANSI character sets. For example, line drawing characters commonly used in MS-DOS character sets were replaced with language characters in ANSI character sets. Problems can arise when building multiple language projects if inadequate consideration is given to the role that ANSI and OEM character sets play, in the way the language strings are stored and interpreted. Language configuration information is stored in dbase files (a database standard defined primarily for MS-DOS applications) where string information is customarily stored as OEM characters. When using a Windows application (such as Excel) to edit dbase files, the characters on screen are in the ANSI character set. When you save this information to the dbase file, Excel will convert it to an OEM equivalent. For this conversion to work correctly the OEM character set must be compatible with the ANSI character set used in Excel. For example, if you have prepared strings for a project in Russian (using Excel), the OEM character set must support the Russian (Cyrillic) character set. The OEM character set used by Windows is primarily determined by your system setup and cannot easily be changed. This presents a problem for multi-language projects. For example, consider a project to support Russian, French, and English. Excel is used to prepare the language dbase files. When saving information from Excel, it is translated from the respective ANSI character sets to OEM. To display this information, CitectHMI/SCADA will need to convert it from OEM back to ANSI. However, Russian requires a Cyrillic OEM character set and French and English requires a Latin OEM character set. This causes a problem, since Windows can have only one OEM character set at any given time (which cannot be changed dynamically). In this situation Multi-language Projects 7

8 only one language can be correctly supported - not all three at the same time. The only way to support multiple languages with differing character sets within one CitectHMI/SCADA project, is to ensure that the language information you store in dbase files is stored as ANSI (not OEM). The [CtEdit]ANSItoOEM parameter must be set to 0 (zero) to ensure that no conversion takes place. The difficulty for the developer in preparing the project is in saving this information in the first place - because most applications will store the language information in OEM format. NOTE: A multi-language project is included in the samples directory on your installation CD. This project allows you to enter information into the language dbase files in ANSI format. Multi-language Projects 8

Version 5.5. Using Accumulators. Citect Pty Ltd 3 Fitzsimmons Lane Gordon NSW 2072 Australia

Version 5.5. Using Accumulators. Citect Pty Ltd 3 Fitzsimmons Lane Gordon NSW 2072 Australia Version 5.5 Using Accumulators Citect Pty Ltd 3 Fitzsimmons Lane Gordon NSW 2072 Australia www.citect.com DISCLAIMER Citect Pty. Limited makes no representations or warranties with respect to this manual