I'm trying to move some code into packages to simplify things.
So far I had resourcestrings where they "belonged".
Seeing how lclstrconsts is embedded, I moved them into a single unit for the whole package.
Yes, the advantage is that you need less calls to TranslateUnitResourceStrings in your application
What do I need to add to the package to make it use translated strings?
In the package options you find the "i18n" item again. Check "Enable i18n" and enter a path to the translation files within your package folder, check "Create/update .po file when saving a lfm file". Then define strings as resource strings and, ideally, collect them in a "strings" unit of the package (similar to lclstrconsts). Within your package units do not assign strings directly, always assign the resoure strings. Once the package has reached some stable state begin to translate the po files created by the IDE. For this, copy the .pot file (t = template) and give the copy the extension .<lang>.po where <lang> is the abbreviated language code, e.g. de for German; open this .po file in a translation utility such as POEdit and translate the individual strings - it's pretty much self-explanatory. In case of English (or the language in which your resource strings are contained in the "strings" unit), you just copy the original strings into the tranlation column (in case of POEdit you can simply press CTRL+B).
When it comes to application of your translation-aware package you must activate "i18n" in the project options now and specify a path for the translation files within your project, relative to the project binary so that it can be found when the application runs. "i18n" makes the IDE generate po files for the resource strings in your application. In order to access also the strings of the used packages, you must copy the po files of these packages into the languages folder of your project. Then your project must provide code to execute the translation whenever needed: add unit "Translations" to "uses" and call TranslateUnitResourceStrings with the unitname and the path to the po file as parameters. You may add LCLTranslator to the uses clause, it takes care of preparing the strings from the lfm file to the po file system (it may lead to duplicate items, though, which are harmful but annoying since they create additional work for your translators).
See attached demo which can be switched between English and German. Besides the LCL strings, it also uses some strings from the TAChart package. It also uses a component, TAChartCombobox, of that package and displays its strings in the selected language.
Important side-detail: Do not delete the .lrj file, it is needed to generate the po file. If you work with a version control system such as SVN or GIT, put it under version control.
Recent
