Cool breeze for your CiviCRM translation needs: String Freeze!

CiviCRM 2.0 doesn’t only start introducing significant code oriented architecture changes, we’re also using the occasion of having a nice, round release number to introduce some new things in the process. This version is the first one where we want to announce official string freeze stage in our release process. From now on, every beta3 release of an upcoming version (2.0.beta3, 2.1.beta3, 2.2.beta3, etc.) will be officially the point at which translators can be sure that they won’t be “racing” with developers to provide decent translation of new version in their native language. CiviCRM is evolving quite rapidly, there is a lot of community feedback and a lot of new functionality getting in from version to version. We admit – for every version, we’re also improving existing texts, as people find different glitches in them. This makes default language version (American English in CiviCRM’s case) more polished, but in the same time makes translators’ work harder – all the corrected strings need to be at least reviewed, and in many cases translated again. This is usually fine as long as you know when to expect the end of this process – if you’re trying to maintain your translation in a decent shape when changes come in all the time, it’s easy to lose all the good feelings towards the application you’re translating. :-) String freeze moment in release process is intended to remove this problem. Translators can be sure that there is a moment in the development process when they can start translating the new version and their efforts won’t be hampered by additional changes from the developers. After each beta3 we will require a really strong reason (like totally wrong explanations in a help file) to change a string, and every time we’ll try to let our translation community know about specific changes, so they’re easy to track and get fixed. String freeze is hopefully just the start of other positive changes in the way we work with our valued translators community. Piotr recently spent significant amount of time ordering and cleaning up the way we’re tagging strings in our code, especially in help files, to make them more convenient and easier to translate. We continue the trend to make sure there are no problems with converting our UI to multiple language requirements. The current list of other potential actions that we want to discuss with people involved in CiviCRM translation before introducing them, consists of the following items: providing shared space for translation memory, appointing language coordinators, who will ensure that translations have appropriately high quality, perhaps moving our translation server to another tool (Rosetta is one of the options to consider), splitting our .po files into more granular pieces (per module), and a few others. We encourage everyone interested in working on CiviCRM translations to stay in touch with others who share the same interest, and, of course, with us – through the channel of their choice: appropriate board on our forums or through our translators mailing list.