Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
I wanted to create an application with full localization support and -while developing it- discovered that all information on how to do this was spread over various forum threads and pages on the internet. Furthermore, I wanted an application that not only detects the system language but is also able to set the language via a settings window. This took quite some time to figure out. Not wanting to do that again this application became my template application. Doing so made me realize that there wasn't something like this available yet. Well, I had to gather all information so logically more developers would face this obstacle when developing multi-language applications in Lazarus. So I decided to share this template in good open source tradition. And thus 'TemplateApp' was born.
If you like my work, please buy me a beer (or a carbonated beverage)
TemplateApp is basically a main form with all the basic controls that a common application has. I kept it intensionally simple. I did this for two reasons:
The interface consists of a main form with a standard menu. It is completely multi-language. When you run the application it will default to the system language. When the system language is not supported the application defaults to English. The code behind for the main form is non existent. Everything is built using a layered design. Al non visible components are placed onto a TDataModule 'dmdCentralComponents' . Using a system like this prevents your main form unit from cluttering up with components and it's code behind with code. You can add more TDataModules to suit your needs. I added two extra elements to the main form. Just to show what is possible and to show how easy it is with a TDataModule/TActionList/TAction/EventHandler set-up to switch interface elements. Instead of the standard about box form, I used a panel and I added a side panel with some custom buttons that pop-up a menu.
Preferences within a common application can mount up to a staggering amount of data that needs to be handled. Having the code to handle all this data spead over the entire application can become a real pain to maintain. Especially over time. Here the TDataModule 'dmdCentralData' comes in. The code behind for this element contains all code to handle the centralized data within the application. Also the swithing between languages has a place here. I chose a TDataModule for this to be able to place non-visual components onto it. Again with the goal of having all this centralized. I can imagine that you want to store information in an a database requiring some non-visual components. This way you have them readably available without cluttering your main form.
For maintaining all settings within the preferences dialog I use a field called FBatchSettings. Which is basically a TStringList. This was again done with simplicity in mind. The objects list within the FBatchSettings field contain TBatchSetting instances. These hold a value and an old value. The latter makes it possible to cancel changed settings and to go back to the original values.
This application is fully multi-language. It detects the system language and -when available- sets it on application start. The language can also be set using the settings dialog. When set, the chosen language is saved in an ini file and this value is read on application start instead of the system setting.
The method of storing the various texts within the application is done via PO-files. This is a very open system of storing localization texts, again done with open source in mind, and allows for easy addition of support for extra languages. The file template.po is the default PO-file and contains all English texts. This file is generated a lfm file is saved. All other languages can be added or maintained from this one.
Adding new languages involves two steps.
Create a new PO-file with the filename in the following format and place it in the languages directory.
Edit settings.ini and add under the section languages the new language in the following format.
The language-name is not very important, it is what's presented to the user. The language-id is important as it links the newly added language to the corresponding PO-file.
Some basic tips for solid multi-language and multi-platform application development.