PLS Engine is a set of components, classes and functions, that you can include into your application to support localization. Their usage is very simple and in addition, the concrete implementation of PLS Engine for your concrete application is offered in the form of "source code suggestions" within the PLS Editor.
What's included ?
Visual component that is designed for easy implementation of PLS Engine into your applications. To do it, simply place this component into all forms you want to localize. You can control the process of localization via properties and events of the main TplsController (that one in your main form) and also via events of secondary TplsController components (placed in child forms and data modules).
A base class that handles all needed localization operations. If you want to have more control over the localization of your project, or if some parts of your application needs to be displayed in different language, you can use this class instead of (or in cooperation with) TplsController component.
Localization of properties
PLS Engine uses a simple and native Delphi way to localize component properties. It calls routines from TypInfo unit (SetPropValue, SetOrdProp, etc.) to assign new values into selected properties of desired components. This also suggests two additional interesting options:
- You can ommit some components from localization simply by not including them into your language files
- You can localize other than text properties, so there is no problem to change the size and position of components to make the text to fit into them. This could be realized by including such properties into your language files. Please keep in mind, that PLS Editor ignores other than text properties (with some exceptions like TShortcut) during the scan of your form files, but you can freely add any property value into the language file later.
Localization of constants and resource strings
Applications that are ready to localization should separate all text constants into special unit(s). PLS Editor can automatically generate such a unit (ie. LangConsts.pas) for you, based on constants defined in your localization project. Editor will create all the necessary declarations and default text assignments, so everything what you have to do, is using the constant identifiers when you need them in your code.
Localization of general strings (GNU gettext analogy)
This feature of PLS Engine works the similar way like gettext function, known from the GNU project. In language files, there can be defined not only translations based on identifiers, but also translations based on strings. This could be used for localizing error messages, info messages and/or return values from dynamically linked 3rd-party libraries (DLLs, BPLs, ...).
This feature allows you to define translated texts directly in running application by clicking the desired elements and entering new texts (captions, hints, etc.) in currently selected language. This feature is suitable for minor corrections by end-users, as well as for the complex localization by external translators.
Read more about this feature in online help.
Message and input dialogs
Basic system dialogs (messages, input boxes) with localization support are included. You can find them in plsDialogs unit. Unfortunately, this feature is not implemented for FireMonkey framework yet.
Dynamic language switching
Current language of your application can be switched at run-time, without the need of restarting.
Flexible handling of language files
- PLS Engine works with INI based language files (default suffix is .LNG) allowing fast and uncomplicated verification of changes during the development process of your product.
- Compressed binary file format is also available (.LNGZ suffix). You have to define PLS_LNGZ conditional directive in your Delphi/Lazarus project to enable this feature.
- One translation can be separated to more files, so you can differentiate your texts by GUI, reports, error messages, etc.
- Language files can be shared between your projects (products) and you can choose (filter) which files from your project will be loaded during run-time of the given application.
- With the help of so called "user language files" (.LNGU suffix) you can adapt your product to the specific requirements of certain customers, without altering the distribution package of your product.
Supported IDEs, frameworks and OS platforms
Supported development environments:
Embarcadero Delphi 7, 2005, 2006, 2007, 2009, 2010, XE, XE2, XE3, XE4, XE5
FreePascal/Lazarus (tested on 1.0.8/2.6.2)
Supported development frameworks and techniques:
Delphi VCL (properties of VCL components)
Delphi FMX (properties of FireMonkey components)
Delphi Metropolis UI (the same as VCL/FMX)
Delphi strings (named text constants)
Delphi resource strings (localizable constants, MS Windows only)
Lazarus LCL (properties of LCL components)
FreePascal strings (named text constants)
FreePascal resource strings (localizable constants)
Dynamic localization of general strings (GNU gettext analogy)
Supported target OS platforms:
Microsoft Windows (32 and 64-bit, via VCL/FMX/LCL)
MacOSX (via FMX/LCL)
Linux and others, supported by FreePascal compiler (should work, but not tested)
iOS, Android (experimentaly, via FMX)
ANSI vs. Unicode
PLS Engine supports both ANSI and UNICODE encodings (for Delphi from 7 to 2007 only UTF-8 is supported). PLS Editor can also load language files in ANSI and UNICODE encodings, but any modifications are saved in UTF-8 encoding only. Keep in mind, that ANSI means the current code page defined in your OS settings, so you can't read, for example, Japanese ANSI files on PC with default code page set to English.