Posts & articles relating to the “Woltlab Suite” (WSC) (formerly “WoltLab Community Framework”, WFC) and my activities in the scene.
WCF 2.0 comes with built-in internationalization (i18n) or, as some call it, multi-language support. I18n within WCF 2.0 is realied using so called language variables. Those variables can be filled with values in multiple languages and even allow adminitrators to translate their whole board to another language themselves. But how do plugin developers use language variables correctly?
In the last article, where I wrote about creating a simple WCF 2.0 pugin, I presented a template in which the term “Hello, World!” was hard coded into the template in english. This is not only strongly discouraged, but is also dangerous in terms of encoding and escaping. Languages variables ansure the proper ecspaing of HTML entities and much more, therefore one should always use language variables over hard coded text.
Customizing your WBB4 / WCF2 installation is usually done via plugins. Editing files, following bogus installation and hacking instructions, this is all long gone. Since WBB3, which was built on top of WCF1, hacking is obsolete and was replaced by simply installing plugins via mouse-click in the ACP. The general principle is the same for WCF2 as it was for WCF1, but some detailes have changed.
So what is a plugin?
Basically, just a TAR- or TGZ- archive that contains some files in a specific structure. The heart of each plugin is the
package.xml, a configuration file which defines the plugins dependencies and it’s delivered functionality. The
package.xmlfile is placed in the root of the plugin archive.
The release of WBB4 and WCF 2.0 beta gets closer every day, and writing plugins for it becomes more and more interesting, especially since we knowget a good overview about the things that might not be included by default and make a good plugin. To make things easier, i wrote a little shell script that automagically packs WCF 2.0 packages: wmake!