National Language Support (Locales and messages) : Q: How are NLS Message Catalog Files (.CAT), NLS Message Pool Dictionaries, and NLS Messages named?

Q: How are NLS Message Catalog Files (.CAT), NLS Message Pool Dictionaries, and NLS Messages named?
There are many catalog files (.CAT) containing translatable message text shipped with VA Smalltalk. They seem to have strange and undecipherable names. How are these names determined? And, related to this, how are the associated Pool Dictionaries and Messages named?
As you might imagine, there is a standardized naming convention for .CAT files. This naming convention is followed about 98% of the time (exceptions to this convention are described at the end of this article). This naming convention also covers the naming of NLS pool dictionaries and NLS messages.
We’ll start with NLS Pool Dictionary naming since the naming convention for Catalog Files and Messages derives from this.
NLS Pool Dictionary Naming Convention
This section describes the naming conventions of NLS Pool Dictionaries. Nls Pool Dictionary names are composed of several parts, some required and some optional, as follows:
The segments of the pool dictionary name following NlsCat is referred to collectively as the POOL-NAME.
A constant prefix for all NLS pools.
The SUBSYSTEM-CODE is based in part on the existing VA Smalltalk subsystem codes (eg. CFS). In some cases new codes were introduced to represent the separation of a subcomponent. For example, AnalysisTools although currently considered ET, has been tagged EAT to indicate that it is a separate component and does not have to be in the image if ET is loaded.
Subsystems (components) can be spread over several applications. For example, AnalysisTools, EsMemoryUsage and EsMemoryTools comprise the system tagged as EAT.
Each application is responsible for a message catalog and its corresponding pool. Typically the main application of a subsystem (the lowest on the prereq chain for a subsystem) uses the main subsystem code and other applications in the subsystem append a single lowercase letter SUFFIX. The first application uses suffix a, then b and so on.
This allows developers in an application to focus on development from the application perspective while at the same time allowing naming to be clearly done along subsystem lines without necessarily having to focus on the problem of identifying the subsystem a method belongs to in order to determine the naming convention for the strings it uses.
For example if all EAT applications and there messages used EAT as the name, this would require developers working in different applications to coordinate the names more closely and would thus be more troublesome to use.
Platform subapplications may need to add additional subcatalogs containing the platform specific messages. To do this they append sPLATFORM-CODE where PLATFORM-CODE can be:
NOTE: Additional values for PLATFORM may be added in the future as needed.
PlatformWidgets and its various subapps define the following.
In the above, PlatformWidgets uses SUBSYSTEM-CODECWc‘ indicating it is part of the CW subsystem, and has suffix 'c' to distinguish it from other applications forming the CW subsystem. The ‘s' indicates a .CAT file associated with subapplications. Finally, the PLATFORM-CODE of ‘PMWin’, ‘Win‘, etc. follows.
In the event there are several subapps for a platform, a single letter subcatalog SUFFIX can be used (as is done for SUBSYSTEM-CODE).
In the above example, EmLibraryInterface uses SUBSYSTEM-CODEEMc’ indicating it is part of the EM subsystem, and has SUFFIX 'c' to distinguish it from other applications forming the EM subsystem. The 's' indicates those pools which are associated with subapplications. The PLATFORM-CODE of ‘ES‘ indicates the pools belong to product-specific subapps. Since there are two product-specific subapps, ‘ES‘ and ‘ESa‘ have been used. If a third product-specific subapp existed for the same SUBSYSTEM-CODE, ‘ESb‘ would have been used for it.
Non-Platform Subapplications
Subapplications which are NOT platform specific can simply use the pool and messages defined in the parent application.
NLS Catalog File (.CAT) Naming Conventions
This section describes the naming conventions of NLS Catalog Files. Catalog file names have been limited to 8 lowercase characters for conformance with DOS file names. A catalog file name is formed from the POOL-NAME described above (i.e., the name of the pool dictionary without the ‘NlsCat’ prefix). In order to keep to the 8 character limit, ‘pmwin’ is abbreviated as ‘pmw’.
CommonGraphics, CommonPrinting, and CommonWidgets have split streams of development. There are 2 versions of each application; one for X/Motif platforms and another for the emulated (E) platforms (e.g. Win). For simplicity and to avoid managing X/Motif files in a separate area, the files have been named cg_e, cg_x, cp (notice the missing ‘_e’ – even the exceptions have exceptions), cp_x, cw_e , and cw_x.
NLS Message Naming Conventions
This section describes the naming conventions used for resident messages within an NLS pool. Message names are composed as follows:
This is a constant prefix for all NLS messages.
See above. This is the part immediately following ‘NlsCat‘.
An integer that is unique within the catalog.
The NLS Enabler Tool assists users by automatically generating this number, and by searching for existing messages in the catalog which contain the same text.