Internationalization Roadmap¶
This is a working document outlining the current level of support for legacy internationalization features in FWD, and the short term roadmap to augment that support.
Already Supported Legacy Features (with Some Limitations)¶
The following features currently are implemented in FWD:- SESSION:DATE-FORMAT attribute
- SESSION:NUMBER-FORMAT attribute
- SESSION:NUMERIC-DECIMAL-POINT attribute
- SESSION:NUMERIC-SEPARATOR
However, there may be some limitations and edge cases that need to be addressed for this support to be fully robust. For example, the date format used by the database currently is set at the database cluster level. If a date string is passed through in a function expression or compared to the formatted date output produced by the database, there can be issues if a session uses a different date format. Also, in some cases, if session settings are changed after certain operations already have occurred (such as a frame definition already having been pushed from application server to client), mismatches are possible.
Higher Priority Legacy Features¶
Support for (or at minimum deeper investigation of) the following Progress features currently are a relatively higher priority:- SESSION:CPSTREAM attributes
- SESSION:CPTERM attribute
- SESSION:CPLOG attribute
- SESSION:CPPRINT attribute
- SESSION:CPCASE attribute
- SESSION:CPCOLL attribute
SESSION:CPINTERNAL is absent from this list, because this attribute represents the code page the AVM uses internally in memory. Since FWD is implemented in Java, it always uses Unicode internally. This may have implications for some of the other attributes listed above as well.
We have done (limited) testing of FWD using different code pages and LANG environments, where these values have been set system-wide (i.e., for the entire FWD server JVM process). This seems to work sufficiently well, though further testing is warranted. Support needs to be added to change these settings at a per-session level, such that an individual FWD session can process external inputs and outputs in other code pages, properly translating them to and from Unicode.
Further research is needed to determine exactly where the appropriate "boundaries" are at which to translate information between various code pages used externally and Unicode used within the FWD JVM. Obvious areas to investigate include file system resources, sockets, and database.
Lower Priority Legacy Features¶
At this time, there is no plan to support the following Progress features/tools, unless there is a specific customer requirement:- Translation Manager
- SESSION:CPRCODEIN (the FWD implementation does not use r-code)
- SESSION:CPRCODEOUT (the FWD implementation does not use r-code)
- Bidi (bidirectional text) support
Database Collation¶
The appropriate sorting of strings in the database may be specific to a particular locale. Currently, FWD provides a basic, Progress-compatible collation for the PostgreSQL database, defined by a custom, Linux locale based on the ISO 8859-1 character set (see here). Additional work in this area is required:- new collation definitions and custom locales will need to be developed for additional locales;
- a solution for databases which do not allow custom locales to be used/installed/defined;
- investigate how to set custom collations at a session level, rather than only at a database cluster level.
Handling of String Literals¶
Most applications which have not been internationalized contain numerous string literals embedded in the source code. The FWD source code analytics tool set or FWD conversion rules can be used to identify every one of these strings. Such strings may be annotated with translation metadata, if tools were used to generate the source code, or if ABL developers added this information manually. Even if this metadata is not present, developers can use the analytics or intermediate conversion artifacts to identify strings that are translatable. This information can be used as a new input to conversion, such that these strings are extracted from the code and replaced with references to Java resource bundles in the converted source code. Java resource bundles can be used at runtime to inject locale-specific strings in place of the original strings.
For every such string identified and replaced with a resource bundle reference, a locale-specific translation would need to be made. This translation is an effort which, while enabled by, is ultimately outside the scope of the FWD automated conversion. Also, there currently is no solution for the potential impact to the layout of an existing user interface when injecting translated strings which may be of substantially different length than the original text used by the application. This would require a manual effort by developers to re-layout the application's user interface to accommodate this variability. Alternatively, we may be able to introduce new layout features into FWD which could adjust for this variability, but with the knowledge that the user interface would no longer match the original.