For Java properties files (used in the application, for example, to define the text strings that appear on client screens), there is no equivalent of the explicit XML declaration. The client generator must assume an encoding for the client properties files. The assumption the generator makes is that Java properties files are encoded in the default system encoding of the machine that the build is running on. This is a reasonable assumption given that the files themselves were likely created on the same machine or a machine of similar type in the same country. On a Microsoft Windows machine in Western Europe, for example, the system encoding is probably Cp1252, the Windows variant of ISO-8859-1. This encoding will handle the accented characters of Western European languages but does not cover, say, Cyrillic or Chinese characters.
If, for some reason, you are building on a machine that does not share its system encoding with the files that are being processed, you must indicate this by setting the ENCODING environment variable. For example, to build a Chinese language web client application on an English language Microsoft Windows machine, you might choose to save your properties files in the UTF-8 encoding, so you would set the ENCODING environment variable to UTF-8. During the build, you can see that the generator overrides its normal default setting:
System encoding is Cp1252. Using encoding UTF-8 to read properties files.
The Java Runtime Environment will always assume that properties files use the ISO-8859-1 encoding. This is not very helpful if you want to create properties files using the UTF-8 encoding for localization to, say, Chinese. To overcome this limitation, the Cúram CDEJ will automatically translate properties files from your preferred encoding (either the system default encoding, or the encoding specified via the ENCODING environment variable) into the encoding required by Java. This is performed automatically during the build process and your original properties files will not be affected.