more british….
Schoorbs 1.0.4 is a minimal bugfix release. It only fixes the handling of n-weekly repeatings.
You could upgrade either via the common Schoorbs upgrade process or via replacing schoorbs-includes/database/schoobs_sql.php and edit_entry_handler.php with their new version.
Links:
As already mentioned in “Introducing Schoorbs (1.1) new translation system“, Schoorbs will get a new translation system. Through the use of *.po-files, we are now able to use Launchpad as a WebGUI for translation. Please feel free to contribute the missing strings of your favourite language.As you will see when you click on the link, there are already a lof of strings translated for various languages, but with the upcoming version there are some new which are missing translation in most languages.
A thing that might sound quite stupid to you is that there are now translations for weekdays and months, which are often already provided by the operating system, but not always. For example if you want to provide a Swedish translation of Schoorbs on a server with only German and English system locales installed, the weekdays couldn’t be translated in Swedish, but when adding them to the translation system of Schoorbs, the translation of the weekdays only depend on the available translations of Schoorbs.
Since there will be major changes in the next Schoorbs release, I will introduce a new versioning system for Schoorbs which will be the same as Ubuntu has(<year>.<month>). I want to do this now to confuse as less people as possible since Schoorbs user base is growing at the moment, but still is small. The next release will include changes which really makes a cut and after that there will be a big difference between Schoorbs and MRBS (but for compability reasons we’ll still use the same DB layout since this has be proven as good (but not as perfect)). So the next upcoming release will be either 8.10, 8.11 or 8.12. I can not say at the moment in which month it ships since there are more changes than I expected, but I hope to get it out before Christmas.
Just to show how the new interface looks like and behaves.
Coming up with Schoorbs 1.1 we introduce a new translation system which is object-oriented, more portable and needs less code. One major thing I wanted to have, is to be independent from the operating system’s locales, so that we do not need anymore those large language code conversation arrays and as wished by users the translations of dates will now ne done by Schoorbs itself and not by the OS, so you do not depend anymore that the locale the users needs is installed on your system, e.g. on an fresh linux installation with only English as the one and only available language in Schoorbs 1.0 the dates where only available in English on the web interface, even if there was a translation file available for the user’s language, now dates are translated into the user’s language if they were already translated in Schoorbs and not if the locale is installed on the system. This fact has many positive sides, the Schoorbs user/administrator does not depend anymore on his webmaster/provider that he installed all the needed locales and the webmaster/provider needs not to install a big amount of locales to satisfy all users of a certain Schoorbs installation which keeps the system clean and nobody has to care of the differences of operating system if one wants to install a different locale.
After the theoratical part we now move on the practical usage of this new system. The “endusers” of this new translation system do not really see a change. In Schoorbs 1.0 a string was translated by calling “get_vocab(’string’)“ now this done with “Lang::_(’string’)“. The only outwardly remarkable change is that ’string’ is returned directly as a translation if no suitable translation was found, before nothing was returned which led to empty buttons in some cases. Under the hood the system completely changed. I will explain the new architecture by doing an example call on “Lang::_(’Time’)“: At first Lang::_() fetches the best available language for the user via Lang::getUserLanguage(). Lang::getUserLanguage analyzes the HTTP_ACCEPT_LANGUAGE strings and search based on the priority for the best fitting language for which a translation exists. If it found a suitable language it gets an instance of it via Lang::getLanguage() and returns it to Lang::_(), if no suitable language was found English is used. If a new language instance is created, the translations are read from a XML-file from schoorbs-includes/lang/schoorbs-<langcode>.po-xml, the format of these files is simple and should be self-explaining. I used this format insted of using directly po-files because it didn’t wanted to include a complete po-parser in Schoorbs and on various sites people disadvise from using PHP’s gettext-functions. Still po-files are used as translation storage since its a common format and I included a rake task that automatically converts the po-files to XML ones. Using po-files as storage during the development enabled me to use launchpad.net as a GUI to translate Schoorbs.
Because it’s a complete new class and could be used in other projects too I duallicensed this translation system under the terms of the GPL 2.1 and a MIT/X11-style license.
Links: