Zope

With the Plone Conference due to start next week, now is your last chance to register for the event and attend the largest Plone event of the year. The conference is being held in Bristol, UK and the main dates are the 27th-29th October. Tickets cost ... [More] GBP 320+VAT, and you can register now at http://ploneconf2010.org/register Meet up with hundreds of Plone developers and users from across the globe and hear over 50 talks on subjects ranging from case studies of Plone in action to talks on integrating Plone with other systems and what is coming up in future Plone releases. As well as two days of scheduled talks we have an 'unconference' day on the third day in which you the attendees can propose talks for the day. This is an excellent way to expand on any information you picked up from chats over a coffee or beer. ...and speaking of beer... there will be a mini beer and pie festival where you can try some local English beers and eat some local award winning pies and of course chat to other Plonistas - all in the setting of a historic former bank. Also get a chance to hear a guest keynote by Richard Noble, former world land speed record holder and director of the Bloodhound SSC project aiming to get up to 2,400 km/h, and the similarities between approches to their project and Open Source Software development. There is also training happening the two days before the event, and sprints happening the two days after. For full information on the event and schedule of talks go to: http://ploneconf2010.org [Less]

My article from 2007 about i18n, locales and Plone 3.0 is still one of the most popular articles on my website. By now it is three years old, so it is high time for an update. This time I will focus on Plone 3.3 and 4.0. Advice here should be ... [More] valid for the complete Plone 4.x line as I do not expect changes in this area. The findings below are my conclusions from testing with some sample packages on Plone 3.3.5 and Plone 4.0.0. Contents i18n versus locales Headers and name of po file Domains in GenericSetup xml files Combining i18n and locales in your own package i18ndude Gotchas Special case: translate the profile title and description Extra translations for an existing domain Overriding translations Restrict the loaded languages Compiled translation files Conclusions i18n versus locales When you create a new package with its own translation domain, should you create an i18n directory or a locales directory? Basically, it does not matter in Plone 3.3 and 4.0. They both work fine. But the i18n directory is old technology and may not work anymore in Plone 5 and later. I know no downsides to the newer locales directory. So if you have the choice, you should use a locales directory. Register it like this in your configure.zcml: Note that there is nothing magical about the locales name. You could call it Quack and it would also work, as long as you register it: Headers and name of po file Within a locales directory it does not matter too much what the headers look like. Some headers that you may think are vital, have absolutely no influence in practice. For example, you may have these headers: "Language-Code: en\n" "Language-Name: English\n" "Domain: non.existing\n" When those headers are in the locales/nl/LC_MESSAGES/collective.ducks.po file, then the internationalization machinery will regard the language as Dutch (nl for NetherLands as directory name) and collective.ducks as the domain as that is the name of the file minus the .po at the end. For clarity it may still be better to let the information in the headers match the folder name and file name. Update: Hanno Schlichting notes that these headers are not actually part of the gettext standard, but have been invented for the PlacelessTranslationService, so it is best to remove them from the po files, instead of trying to keep them in sync with the file name. I myself will note that i18ndude (at least the most recent 3.2 version) adds these headers by default, making it hard to keep them removed. But at least in locales directories it neither hurts to keep them, nor to remove them. So your po file must match the pattern locales/languagecode/LC_MESSAGES/domainname.po. Note that the domain name is case sensitive. In Products.Poi the domain name is Poi, so I had to name the file Poi.po; with poi.po my translations were not picked up. Note that if you still use an i18n directory the headers are checked. But i18n is old-style so I have not checked this too rigourously. Update: Hanno confirms that this is indeed the case; you can call your file i18n/spam.po and it will still work, as long as the headers are correct. Domains in GenericSetup xml files In your GenericSetup profile you can have several xml files. In some of these it makes sense to do translations. In most of those cases it only helps to use the plone domain. Let's try out most of the xml files, at least the ones contained in CMFPlone itself. actions.xml: use your own domain. Example: Duck Test Action: test a duck ... Note that when you go to the portal_actions tools in the ZMI, you will see an i18n domain specified for each action. catalog.xml: no i18n needed componentregistry.xml: no i18n needed contenttyperegistry.xml: no i18n needed controlpanel.xml: use your own domain. Example: Manage portal cssregistry.xml: no i18n needed diff_tool.xml: no i18n needed factorytool.xml: no i18n needed jsregistry.xml: no i18n needed kssregistry.xml: no i18n needed mailhost.xml: no i18n needed memberdata_properties.xml: no i18n needed metadata.xml: no i18n needed portal_atct.xml: use the plone domain. Note that this has no influence on the Collections panel in Site Setup. It is only used on the edit and criteria pages of a Collection. portlets.xml: use the plone domain. properties.xml: no i18n needed propertiestool.xml: no i18n needed rolemap.xml: no i18n needed skins.xml: no i18n needed toolset.xml: no i18n needed types: use your own domain viewlets.xml: no i18n needed workflows: use the plone domain Combining i18n and locales in your own package You could put some translations of your domain in an i18n directory and some in a locales directory. When you do that, in Plone 3 your i18n translations are ignored. In Plone 4 both are combined; I cannot imagine a sane use case for doing this though. So: for your own domain you should always use either an i18n or a locales directory. If you want to put your own domain in a locales directory and some extra translations for the plone domain in an i18n directory, that is fine. i18ndude I always use i18ndude to find translations in my package and generate and update the po files. I usually copy a script with the name rebuild_i18n.sh from package A to the new package B, and adapt it to the needs of that package. It at least works on Linux and Mac and looks something like this: #! /bin/sh I18NDOMAIN="collective.ducks" # Synchronise the templates and scripts with the .pot. # All on one line normally: i18ndude rebuild-pot --pot locales/${I18NDOMAIN}.pot \ --merge locales/manual.pot \ --create ${I18NDOMAIN} \ . # Synchronise the resulting .pot with all .po files for po in locales/*/LC_MESSAGES/${I18NDOMAIN}.po; do i18ndude sync --pot locales/${I18NDOMAIN}.pot $po done Note the dot at the end of the rebuild-pot call to signal that i18ndude should start searching in the current directory. The merge is optional; adapt to your needs and look in the i18ndude documentation for hints. Gotchas If you use i18ndude to extract msgids (translatable strings) it looks for i18n:translate calls in templates and xml files; it looks for the corresponding i18n:domain specification to check if this msgid belongs to the domain you are interested in (specified in the --create option). In python files i18ndude simply looks for all strings wrapped in an underscore function: _('My translatable string'). This function is usually defined like this: from zope.i18nmessageid import MessageFactory _ = MessageFactory('collective.ducks') The gotcha now is that i18ndude is not smart enough to know which domain the string belongs to. It will report all 'underscored' strings, whether you look for your own domain or the plone domain. Usually you are only interested in your own domain. If you still need to use the plone domain in a python file, it is best to make sure this is not done with an underscore. For example, when customizing the folder_copy.cpy script of standard Plone in an own skin layer, I usually change it from this: from Products.CMFPlone import PloneMessageFactory as _ message = _(u'One or more items not copyable.') to this: from Products.CMFPlone import PloneMessageFactory as PMF message = PMF(u'One or more items not copyable.') That way, i18ndude will not detect that the string 'One or more items not copyable.' is translatable, so it will not end up in your pot and po files, so the existing translation from plone.app.locales is used. Special case: translate the profile title and description Say you have a configure.zcml like this: i18ndude will not pick up the title and description, so you will have to add it manually. Create a locales/manual.po file with something like this: # --- PLEASE EDIT THE LINES BELOW CORRECTLY --- # SOME DESCRIPTIVE TITLE. # FIRST AUTHOR , YEAR. msgid "" msgstr "" "Project-Id-Version: collective.duck 1.0\n" "POT-Creation-Date: 2010-09-01 09:58+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI +ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0\n" "Language-Code: en\n" "Language-Name: English\n" "Preferred-Encodings: utf-8 latin1\n" "Domain: collective.ducks\n" #: Profile title in configure.zcml msgid "Collect All Ducks" msgstr "" #: Profile description in configure.zcml msgid "Ducks of all nations: unite!" msgstr "" Rebuild the pot file and merge the manual pot file in it, something like this: i18ndude rebuild-pot --pot locales/collective.ducks.pot --merge locales/manual.pot --create collective.ducks . Synchronize the pot file with the po files (we will just do the Dutch file here): i18ndude sync --pot locales/collective.ducks.pot locales/nl/LC_MESSAGES/collective.ducks.po Add the translations in your po file, restart your zope instance and the translations should be visible in the Add-ons panel in the Site Setup (and the portal_quickinstaller in the ZMI). Extra translations for an existing domain This section is true for adding extra translations (new msgids) to any domain, but the plone domain is of course the one for which this is most often needed. In Plone 3, the standard plone domain translations are done in an i18n directory. If you create a locales directory with extra plone translations, these will cancel all existing i18n translations for plone, so this is not good. You should create an i18n directory for this. In Plone 4 you should add extra plone domain translations in a locales dir. In general, you should follow the lead of the standard translations for the domain you want to add msgids for. If they are in an i18n directory, you should add yours in an i18n directory. If they are in a locales directory, you should add yours in a locales directory. Note that in Plone 4 it looks like first all locales are loaded for all packages, and then all i18n directories are loaded. This might depend on the order in which the zcml for the packages is loaded though. Overriding translations In Plone 3.3 you can override translations that are in the i18n directory of a package (for example plone.app.locales, which is the successor or Products.PloneTranslations). The best way to make sure your translations are picked over the default ones, is by creating an i18n directory within your zope instance. Easiest is to use collective.recipe.i18noverrides for this. Note that you can not use an i18n directory in the instance to override translations from a locales directory. In Plone 4 the i18n directory of the instance is completely and utterly ignored. What you can do is override some translations of a locales directory. You can create a new plone package and use that only to override some translations, or you add something to an existing package. Let's say you want to override the "You are here:" translation from the bread crumbs (path bar). In Dutch it says "U bent hier:". We now want it to say: "U bent hier naartoegevlogen:". You locate the plone.po file for your translation and copy it to your locales directory. In our case we have created a package called customer.translations so copy this file: plone.app.locales-4.0.0-py2.6.egg/plone/app/locales/locales/nl/LC_MESSAGES/plone.po to this file: customer.translations/customer/translations/locales/nl/LC_MESSAGES/plone.po Then remove whatever translations you do not need to override, and do your change, so you end up with a po file with some headers and this translation: #. Default: "You are here:" #: plone.app.layout/plone/app/layout/viewlets/path_bar.pt:6 msgid "you_are_here" msgstr "U bent hiernaartoe gevlogen:" In your buildout.cfg make sure this package is added to the eggs. The tricky thing now is to make sure that the zcml for this package is loaded before the zcml of other packages; that way our translations win. The way to do this, is to list it as the first (and possibly only) item in the zcml option, so something like this: [instance] ... eggs = Zope2 Plone ${buildout:eggs} customer.translations zcml = customer.translations Warning: this works in Plone 3 too, but it has a problem. In Plone 3 the translations for the plone domain are in an i18n directory. If we add a plone.po file in our locales directory, the effect is that all other translations from the plone domain are lost. In other words: if you override an i18n folder with your own locales folder, all translations for that domain that are not in your po file, are lost. So you would have to copy over the complete original po file. In that case it is probably easier to use the already mentioned collective.recipe.i18noverrides. To be clear: this is true when using Plone 3. To summarize this part: If you want to override translations from an i18n directory: On Plone 3.3: use collective.recipe.i18noverrides. On Plone 4: copy (part of) the po file to the locales directory of your own package. If you want to override translations from a locales directory it is the same on Plone 3.3 and 4: copy the relevant part of the po file to the locales directory of your own package. Copying the entire po file works as well of course, but is not needed. Also you need to make sure the zcml of your package is loaded first. On Plone 3.3 it seemed less reliable, but that may be because I was meanwhile also combining i18n and locales directories for the same domain, which is not a good idea. Restrict the loaded languages (Update: includes info from Hanno about zope_i18n_allowed_languages.) To speed up zope startup time and use less memory, you can set an environment variable to restrict the languages for which po files are loaded. To restrict them to English, Dutch and German, give this a value of en, nl, de. The commas are optional. In buildout.cfg this would be something like this: [instance] ... environment-vars = PTS_LANGUAGES en nl de zope_i18n_allowed_languages en nl de zope_i18n_compile_mo_files true The zope_i18n_compile_mo_files setting is optional, see the next section. But why do we specify the allowed languages twice? Some words from Hanno, who pointed me to zope_i18n_allowed_languages: In Plone 3.3 there is only PTS_LANGUAGES and it affects both i18n and locales folders. In Plone 4 there is also zope_i18n_allowed_languages. The new one now affects locales folders and the old one only affects i18n folders. So to get the full memory saving affect of not loading too many translation files, you need to specify both on Plone 4. Specifying the new one in Plone 3.3 does not hurt, it just does not do anything. Compiled translation files .po files need to be compiled before Plone can do something with them. When you compile a domain.po file, you get a domain.mo file. This is the file that is read by the translation machinery when looking up a translation for a msgid. To compile a file manually, you need the msgfmt program: msgfmt -o domain.mo domain.po If your package contains po files, Plone 3.3 compiles them when starting up your instance. In Plone 4 this is optional. For example, you might want to skip this when you do not need any translations at all in your site. Actually, it is skipped by default. To enable the compile step, add the following to the instance or zeoclient part of your Plone 4 buildout.cfg: environment-vars = zope_i18n_compile_mo_files true Note that the value (true in this case) does not matter: the relevant code in zope.i18n simply looks for the existence of the variable and does not care what its value is. In Plone 3, any existing mo files in an i18n directory of a package are ignored. Instead, when the Zope instance starts up, all po files are compiled automatically and put in a directory like var/instance/pts. Also in Plone 3, any po files in a locales directory are compiled inside that same locales directory: locales/nl/LC_MESSAGES/domain.po is compiled to a file locales/nl/LC_MESSAGES/domain.mo. In Plone 4, the var/instance/pts directory is not used at all. All po files in an i18n or locales directory are compiled inside that same directory. On startup, Zope (actually the PlacelessTranslationService) may see that a po file already has an accompanying mo file in the correct directory. It then compares the last modification date of the two files. If the po file is more recent, then a new mo file is compiled. Note that you should not put the compiled mo files in subversion (or another version control system) as they can just be automatically created. Once you release a package to the public, putting the mo files in the released source could be handy though: if your package without mo files is installed by for example the root user in a directory where user zope has read access but not write access, then user zope will get an error when starting Plone. plone.app.locales does this correctly. I have not done this myself yet (and some of my packages probably still contain mo files in subversion) so I will not further comment on how to do this. I do want to add support for this in zest.releaser or in an optional support package for that. If you want to do it manually, this shell script does the trick (at least when you have proper bash, find and msgfmt commands available): for po in $(find . -path '*/LC_MESSAGES/*.po'); do msgfmt -o ${po/%po/mo} $po; done Plus you will need to make sure mo files are included in the created source distribution by creating a MANIFEST.in file next to your setup.py file; this works for me: recursive-include collective * global-exclude *pyc Update: Okay, I have just created and released http://pypi.python.org/pypi/zest.pocompile for this, for use in combination with zest.releaser or as stand-alone command line tool. Conclusions When you create a package with a new translation domain: use locales. When extending existing translations, follow the lead of the package you are extending to determine whether you should use i18n or locales. When overriding existing translations, also follow the lead of the package you are overriding. Make sure the zcml of your package is loaded before that of the other package. On Plone 3.3 with an i18n dir: use collective.recipe.i18noverrides. When using locales, make sure your po file matches the pattern locales/languagecode/LC_MESSAGES/domainname.po and note that the domain name is case sensitive. In GenericSetup files, use your own domain for: actions.xml controlpanel.xml types In GenericSetup files, use the plone domain for: portal_atct.xml portlets.xml workflows Have fun translating! [Less]

My article from 2007 about i18n, locales and Plone 3.0 is still one of the most popular articles on my website. By now it is three years old, so it is high time for an update. This time I will focus on Plone 3.3 and 4.0. Advice here should be ... [More] valid for the complete Plone 4.x line as I do not expect changes in this area. The findings below are my conclusions from testing with some sample packages on Plone 3.3.5 and Plone 4.0.0. Contents i18n versus locales Headers and name of po file Domains in GenericSetup xml files Combining i18n and locales in your own package i18ndude Gotchas Special case: translate the profile title and description Extra translations for an existing domain Overriding translations Restrict the loaded languages Compiled translation files Conclusions i18n versus locales When you create a new package with its own translation domain, should you create an i18n directory or a locales directory? Basically, it does not matter in Plone 3.3 and 4.0. They both work fine. But the i18n directory is old technology and may not work anymore in Plone 5 and later. I know no downsides to the newer locales directory. So if you have the choice, you should use a locales directory. Register it like this in your configure.zcml: Note that there is nothing magical about the locales name. You could call it Quack and it would also work, as long as you register it: Headers and name of po file Within a locales directory it does not matter too much what the headers look like. Some headers that you may think are vital, have absolutely no influence in practice. For example, you may have these headers: "Language-Code: en\n" "Language-Name: English\n" "Domain: non.existing\n" When those headers are in the locales/nl/LC_MESSAGES/collective.ducks.po file, then the internationalization machinery will regard the language as Dutch (nl for NetherLands as directory name) and collective.ducks as the domain as that is the name of the file minus the .po at the end. For clarity it may still be better to let the information in the headers match the folder name and file name. So your po file must match the pattern locales/languagecode/LC_MESSAGES/domainname.po. Note that the domain name is case sensitive. In Products.Poi the domain name is Poi, so I had to name the file Poi.po; with poi.po my translations were not picked up. Note that if you still use an i18n directory the headers probably are checked. But i18n is old-style so I have not checked this too rigourously. Domains in GenericSetup xml files In your GenericSetup profile you can have several xml files. In some of these it makes sense to do translations. In most of those cases it only helps to use the plone domain. Let's try out most of the xml files, at least the ones contained in CMFPlone itself. actions.xml: use your own domain. Example: Duck Test Action: test a duck ... Note that when you go to the portal_actions tools in the ZMI, you will see an i18n domain specified for each action. catalog.xml: no i18n needed componentregistry.xml: no i18n needed contenttyperegistry.xml: no i18n needed controlpanel.xml: use your own domain. Example: Manage portal cssregistry.xml: no i18n needed diff_tool.xml: no i18n needed factorytool.xml: no i18n needed jsregistry.xml: no i18n needed kssregistry.xml: no i18n needed mailhost.xml: no i18n needed memberdata_properties.xml: no i18n needed metadata.xml: no i18n needed portal_atct.xml: use the plone domain. Note that this has no influence on the Collections panel in Site Setup. It is only used on the edit and criteria pages of a Collection. portlets.xml: use the plone domain. properties.xml: no i18n needed propertiestool.xml: no i18n needed rolemap.xml: no i18n needed skins.xml: no i18n needed toolset.xml: no i18n needed types: use your own domain viewlets.xml: no i18n needed workflows: use the plone domain Combining i18n and locales in your own package You could put some translations of your domain in an i18n directory and some in a locales directory. When you do that, in Plone 3 your i18n translations are ignored. In Plone 4 both are combined; I cannot imagine a sane use case for doing this though. So: for your own domain you should always use either an i18n or a locales directory. If you want to put your own domain in a locales directory and some extra translations for the plone domain in an i18n directory, that is fine. i18ndude I always use i18ndude to find translations in my package and generate and update the po files. I usually copy a script with the name rebuild_i18n.sh from package A to the new package B, and adapt it to the needs of that package. It at least works on Linux and Mac and looks something like this: #! /bin/sh I18NDOMAIN="collective.ducks" # Synchronise the templates and scripts with the .pot. # All on one line normally: i18ndude rebuild-pot --pot locales/${I18NDOMAIN}.pot \ --merge locales/manual.pot \ --create ${I18NDOMAIN} \ . # Synchronise the resulting .pot with all .po files for po in locales/*/LC_MESSAGES/${I18NDOMAIN}.po; do i18ndude sync --pot locales/${I18NDOMAIN}.pot $po done Note the dot at the end of the rebuild-pot call to signal that i18ndude should start searching in the current directory. The merge is optional; adapt to your needs and look in the i18ndude documentation for hints. Gotchas If you use i18ndude to extract msgids (translatable strings) it looks for i18n:translate calls in templates and xml files; it looks for the corresponding i18n:domain specification to check if this msgid belongs to the domain you are interested in (specified in the --create option). In python files i18ndude simply looks for all strings wrapped in an underscore function: _('My translatable string'). This function is usually defined like this: from zope.i18nmessageid import MessageFactory _ = MessageFactory('collective.ducks') The gotcha now is that i18ndude is not smart enough to know which domain the string belongs to. It will report all 'underscored' strings, whether you look for your own domain or the plone domain. Usually you are only interested in your own domain. If you still need to use the plone domain in a python file, it is best to make sure this is not done with an underscore. For example, when customizing the folder_copy.cpy script of standard Plone in an own skin layer, I usually change it from this: from Products.CMFPlone import PloneMessageFactory as _ message = _(u'One or more items not copyable.') to this: from Products.CMFPlone import PloneMessageFactory as PMF message = PMF(u'One or more items not copyable.') That way, i18ndude will not detect that the string 'One or more items not copyable.' is translatable, so it will not end up in your pot and po files, so the existing translation from plone.app.locales is used. Special case: translate the profile title and description Say you have a configure.zcml like this: i18ndude will not pick up the title and description, so you will have to add it manually. Create a locales/manual.po file with something like this: # --- PLEASE EDIT THE LINES BELOW CORRECTLY --- # SOME DESCRIPTIVE TITLE. # FIRST AUTHOR , YEAR. msgid "" msgstr "" "Project-Id-Version: collective.duck 1.0\n" "POT-Creation-Date: 2010-09-01 09:58+0000\n" "PO-Revision-Date: YEAR-MO-DA HO:MI +ZONE\n" "Last-Translator: FULL NAME \n" "Language-Team: LANGUAGE \n" "MIME-Version: 1.0\n" "Content-Type: text/plain; charset=utf-8\n" "Content-Transfer-Encoding: 8bit\n" "Plural-Forms: nplurals=1; plural=0\n" "Language-Code: en\n" "Language-Name: English\n" "Preferred-Encodings: utf-8 latin1\n" "Domain: collective.ducks\n" #: Profile title in configure.zcml msgid "Collect All Ducks" msgstr "" #: Profile description in configure.zcml msgid "Ducks of all nations: unite!" msgstr "" Rebuild the pot file and merge the manual pot file in it, something like this: i18ndude rebuild-pot --pot locales/collective.ducks.pot --merge locales/manual.pot --create collective.ducks . Synchronize the pot file with the po files (we will just do the Dutch file here): i18ndude sync --pot locales/collective.ducks.pot locales/nl/LC_MESSAGES/collective.ducks.po Add the translations in your po file, restart your zope instance and the translations should be visible in the Add-ons panel in the Site Setup (and the portal_quickinstaller in the ZMI). Extra translations for an existing domain This section is true for adding extra translations (new msgids) to any domain, but the plone domain is of course the one for which this is most often needed. In Plone 3, the standard plone domain translations are done in an i18n directory. If you create a locales directory with extra plone translations, these will cancel all existing i18n translations for plone, so this is not good. You should create an i18n directory for this. In Plone 4 you should add extra plone domain translations in a locales dir. In general, you should follow the lead of the standard translations for the domain you want to add msgids for. If they are in an i18n directory, you should add yours in an i18n directory. If they are in a locales directory, you should add yours in a locales directory. Note that in Plone 4 it looks like first all locales are loaded for all packages, and then all i18n directories are loaded. This might depend on the order in which the zcml for the packages is loaded though. Overriding translations In Plone 3.3 you can override translations that are in the i18n directory of a package (for example plone.app.locales, which is the successor or Products.PloneTranslations). The best way to make sure your translations are picked over the default ones, is by creating an i18n directory within your zope instance. Easiest is to use collective.recipe.i18noverrides for this. Note that you can not use an i18n directory in the instance to override translations from a locales directory. In Plone 4 the i18n directory of the instance is completely and utterly ignored. What you can do is override some translations of a locales directory. You can create a new plone package and use that only to override some translations, or you add something to an existing package. Let's say you want to override the "You are here:" translation from the bread crumbs (path bar). In Dutch it says "U bent hier:". We now want it to say: "U bent hier naartoegevlogen:". You locate the plone.po file for your translation and copy it to your locales directory. In our case we have created a package called customer.translations so copy this file: plone.app.locales-4.0.0-py2.6.egg/plone/app/locales/locales/nl/LC_MESSAGES/plone.po to this file: customer.translations/customer/translations/locales/nl/LC_MESSAGES/plone.po Then remove whatever translations you do not need to override, and do your change, so you end up with a po file with some headers and this translation: #. Default: "You are here:" #: plone.app.layout/plone/app/layout/viewlets/path_bar.pt:6 msgid "you_are_here" msgstr "U bent hiernaartoe gevlogen:" In your buildout.cfg make sure this package is added to the eggs. The tricky thing now is to make sure that the zcml for this package is loaded before the zcml of other packages; that way our translations win. The way to do this, is to list it as the first (and possibly only) item in the zcml option, so something like this: [instance] ... eggs = Zope2 Plone ${buildout:eggs} customer.translations zcml = customer.translations Warning: this works in Plone 3 too, but it has a problem. In Plone 3 the translations for the plone domain are in an i18n directory. If we add a plone.po file in our locales directory, the effect is that all other translations from the plone domain are lost. In other words: if you override an i18n folder with your own locales folder, all translations for that domain that are not in your po file, are lost. So you would have to copy over the complete original po file. In that case it is probably easier to use the already mentioned collective.recipe.i18noverrides. To be clear: this is true when using Plone 3. To summarize this part: If you want to override translations from an i18n directory: On Plone 3.3: use collective.recipe.i18noverrides. On Plone 4: copy (part of) the po file to the locales directory of your own package. If you want to override translations from a locales directory it is the same on Plone 3.3 and 4: copy the relevant part of the po file to the locales directory of your own package. Copying the entire po file works as well of course, but is not needed. Also you need to make sure the zcml of your package is loaded first. On Plone 3.3 it seemed less reliable, but that may be because I was meanwhile also combining i18n and locales directories for the same domain, which is not a good idea. Restrict the loaded languages You can set an environment variable PTS_LANGUAGES. To restrict the languages for which po files are loaded to English, Dutch and German, gives this a value of en, nl, de. The commas are optional. In buildout.cfg this would be something like this: [instance] ... environment-vars = PTS_LANGUAGES en nl de Compiled translation files .po files need to be compiled before Plone can do something with them. When you compile a domain.po file, you get a domain.mo file. This is the file that is read by the translation machinery when looking up a translation for a msgid. To compile a file manually, you need the msgfmt program: msgfmt -o domain.mo domain.po If your package contains po files, Plone 3.3 compiles them when starting up your instance. In Plone 4 this is optional. For example, you might want to skip this when you do not need any translations at all in your site. Actually, it is skipped by default. To enable the compile step, add the following to the instance or zeoclient part of your Plone 4 buildout.cfg: environment-vars = zope_i18n_compile_mo_files true Note that the value (true in this case) does not matter: the relevant code in zope.i18n simply looks for the existence of the variable and does not care what its value is. In Plone 3, any existing mo files in an i18n directory of a package are ignored. Instead, when the Zope instance starts up, all po files are compiled automatically and put in a directory like var/instance/pts. Also in Plone 3, any po files in a locales directory are compiled inside that same locales directory: locales/nl/LC_MESSAGES/domain.po is compiled to a file locales/nl/LC_MESSAGES/domain.mo. In Plone 4, the var/instance/pts directory is not used at all. All po files in an i18n or locales directory are compiled inside that same directory. On startup, Zope (actually the PlacelessTranslationService) may see that a po file already has an accompanying mo file in the correct directory. It then compares the last modification date of the two files. If the po file is more recent, then a new mo file is compiled. Note that you should not put the compiled mo files in subversion (or another version control system) as they can just be automatically created. Once you release a package to the public, putting the mo files in the released source could be handy though: if your package without mo files is installed by for example the root user in a directory where user zope has read access but not write access, then user zope will get an error when starting Plone. plone.app.locales does this correctly. I have not done this myself yet (and some of my packages probably still contain mo files in subversion) so I will not further comment on how to do this. I do want to add support for this in zest.releaser or in an optional support package for that. If you want to do it manually, this shell script does the trick (at least when you have proper bash, find and msgfmt commands available): for po in $(find . -path '*/LC_MESSAGES/*.po'); do msgfmt -o ${po/%po/mo} $po; done Conclusions When you create a package with a new translation domain: use locales. When extending existing translations, follow the lead of the package you are extending to determine whether you should use i18n or locales. When overriding existing translations, also follow the lead of the package you are overriding. Make sure the zcml of your package is loaded before that of the other package. On Plone 3.3 with an i18n dir: use collective.recipe.i18noverrides. When using locales, make sure your po file matches the pattern locales/languagecode/LC_MESSAGES/domainname.po and note that the domain name is case sensitive. In GenericSetup files, use your own domain for: actions.xml controlpanel.xml types In GenericSetup files, use the plone domain for: portal_atct.xml portlets.xml workflows Have fun translating! [Less]

As a company, we're handling quite a lot of customer data. This involves a lot of different software components: databases (postgres, oracle), jdbc, xml-rpc, django website, a windows server, etcetera. And sometimes one of those ... [More] components falls over, bringing the data import/whatever for one or more customers to a halt. Waiting for the phone to ring ("Hello, this is customer xyz....") isn't the best way of monitoring it. Doing a manual click-through every morning to check it by hand isn't fun (and so it isn't guaranteed to happen). Solution: automatic monitoring. The things we want to monitor are apparently not covered by the standard munin/nagios types of checks (I don't have enough knowledge about that part of our software to know for sure). So a colleague is working on a dashboard in Django. External checks write their data to the django database and django shows it, basically. It keeps historical records (much like munin/nagios does). The dashboard isn't finished yet, however, and Mandatory Menial Manual Morning Checking was about to be scheduled for the IT department. Manual menial tasks is something I abhor, so I asked around a bit and found an existing snippet of code that checks the component that is the cause of 99% of the downtime. Three hours of coding later, we've now got a temporary web page that lists whether that component is up for our various customers. Easily integratable into the real dashboard later on. Note that getting someone to code such an automatic check was exaclty the purpose of asking the IT department to do the manual monitoring. The trick worked :-) This morning we had our first small victory: a colleague looked at the page and noticed three JDBC couplings were down. We restarted them and got them back on-line. Like I said in my Hudson continuous integration article, we've got a laptop + big monitor in our IT room with our hudson on continuous display. I've now opened a second window with the temporary JDBC tester page so that we can't possibly overlook another downtime :-) [Less]

I'm in love with whiteboards. Look what we got in the mail: Well, "getting in the mail" means "hauling it up three flights of stairs" as a 4x1m whiteboard sure isn't going to fit into our elevator. The right 2/3 of the whiteboard will ... [More] be the place where we manage our agile projects with plain old post-its. Drop in once and we'll explain it to you. We're still experimenting, but we're enthousiastic about it and it is already taking hold. It is fun to get "inspection tours": quite a lot of colleagues are wondering what we're up to with those post-its and that huge whiteboard :-) I must say that the optimum in whiteboards is still my former job at Zest software where we had two walls covered with whiteboards :-) [Less]

Hello. On behalf of the Zope Toolkit release team and the Zope community, I'm happy to announce the release of Zope Toolkit version 1.0! You can read more about the release at http://docs.zope.org/zopetoolkit/releases/overview-1.0.html. The first ... [More] ZTK release supports all of Python 2.4, 2.5 and 2.6. To use the ZTK release, you can use: [buildout] extends = http://download.zope.org/zopetoolkit/index/1.0/ztk-versions.cfg http://download.zope.org/zopetoolkit/index/1.0/zopeapp-versions.cfg This release focuses on cleaning up the ztk and zopeapp package lists by deprecating packages that are not used by any of the frameworks that use the ZTK. It should provide a stable set of libraries that are known to work well together and for the frameworks to expand on. We post our meeting notes at http://docs.zope.org/zopetoolkit/releaseteam/index.html. Feel free to start discussing with us on this mailing list. Kind regards, Jan-Wijbrand Kolman _______________________________________________ Zope-Announce mai [Less]

Plone, an Open Source Content Management System used throughout the world has a massive following and Plone events are held around the globe. The largest of these is the annual Plone Conference and this year will be held in the UK. Plone is used ... [More] for developing websites, intranet and portals for corporations, NGOs and the public sector. This is a one-day standalone event, aimed specifically at end users, managers, analysts, and consultants who are currently using Plone within their organisation. Or those people looking to find out more about Plone with a view to evaluating it for their needs. This event is separate from the main conference and is free to attend. This event starts at 12:30pm at the Thistle Grand Hotel, Bristol, UK (after the Plone Community of Practice in the morning) with a Networking lunch, followed by a number of case studies of Plone in action.  For more details or to register for this free event, go to http://ploneinbusiness.eventbrite.com 12:30 - 13:30 Networking Lunch 13:30 - 14:15 A Comparison of Plone with other CMSs Mike Grafham, Deloitte MCS 14:15 - 15:00 Connexions and Enterprise Rhaptos — A Global Education and Plone Success Story Joel Thierstein, Connexions / Rice University, USA 15:00 - 15:15 Break 15:15 - 16:00 Open Source Content and Document Management in the Public Sector Graham Oakes, Principal, Graham Oakes Ltd 16:00 - 16:45 Citizen Space - Building public engagement and consultation for government in Plone Gez Smith, Delib, UK 16:45 - 17:00 Closing Wrap-Up Geir Bækholt, President, Plone Foundation     [Less]

It's always tempting to rewrite an existing, popular framework or programming language project in a moderately or entirely backwards incompatible way...

The machine that hosts the Plone community's software repositories (hosted by Oregon State University) will undergo system maintenance this Saturday October 16, 4:00PM - 12:00AM EDT. During this time, it is expected that the Subversion software ... [More] repositories (plone, collective, and archetypes) and corresponding Trac instances may be unavailable for several hours or more. Other services on deus (see: http://admins.plone.org/systems.html#host-deus-plone-org for a list) may go down briefly too, while they are relocated to other hosts. Subversion and Trac will remain on OSU's server and be reinstalled using "modern" techniques, such as mod_wsgi in place of mod_python. No other services (e.g. plone.org, lists.plone.org) will be affected. We appreciate your patience while we improve the Plone community's infrastructure! — The Plone.org team [Less]

Talks Announced for Plone Conference 2010 in Bristol, UK Over 400 attendees are expected to meet at the 8th annual Plone Conference for a week-long programme of training, talks and developer sprints from the 25th to 31st October at the Thistle Grand ... [More] Hotel in Bristol, UK.  Registration is now open.Plone, an Open Source Content Management System used throughout the world has a massive following and Plone events are held around the globe. The largest of these is the annual Plone Conference and this year will be held in the UK. Plone is used for developing websites, intranet and portals for corporations, NGOs and the public sector.Organised by Netsight Internet Solutions, it promises to bring together developers, designers, end users and business people. This year an additional event is being planned as a one-day mini-conference on the 26th October called "Plone in Business" which will be aimed specifically at analysts, advisors, evaluators and information professionals looking to find out more about Plone and see a showcase of successful Plone projects from across the sectors. It will also see the launch of the JBoye Plone Community of Practice.The main part of the conference, from the 27th - 29th October, has over 50 scheduled talks from speakers from 19 countries and includes an 'unconference' day in which talks will be proposed by the attendees.Plone Conference 2010 scheduled talks include:* Easier and faster Plone theming with Deliverance* Design and Development with Dexterity* Enterprise Search in Plone with Solr* Boosting productivity with "Plone-driven Plone development"* Brasil.gov.br: Building a digital nation with PloneFor a full list of talks, visit - http://www.ploneconf2010.org/the-event/talksAlan Runyan, co-founder of Plone and president of Enfold Systems along with Alex Limi, fellow co-founder of Plone and now Firefox User Experience Lead at Mozilla will be delivering a keynote. There will also be a guest keynote by Richard Noble, OBE, project director of the Bloodhound SSC project attempting be build a car to pass the 1,000mph land speed mark.The conference falls at a great time, with the recent release of Plone 4, a product that raises the bar in the Content Management System market with a faster, more user-friendly and more refined version of the product.So far, registrations for the conference have come from over 30 countries around the world. To find out more about the conference and to register, visit http://ploneconf2010.org. Plone Foundation Announces New Members Congratulations to Tom Lazar, Mikko Ohtamaa, Wyn Williams, Ricardo Alves and Erico Andrei.  They are the newest members of the Plone Foundation.The group of five new members were confirmed at the Foundation Board's first meeting in October, chosen from the 11 applications the Membership Committee received for consideration.  The Plone Foundation selects as members individuals who have made significant, enduring contributions that benefit the general Plone community.The Membership Committee is Steve McMahon, Godefroid Chapelle, Chris Calloway, Hanno Schlichting, JoAnna Springsteen & Matthew Wilkes. Plone 4 CMS Unveiled: Advancing Power, Performance & User Experience The Plone community has raised the bar in the Content Management System market with today's release of Plone 4, a faster, more user-friendly and more refined version of a product which has set the pace for CMS innovation for nearly a decade.  Plone 4 delivers big improvements in raw speed, scalability and ease of use, and continues to advance its hallmark strengths of unmatched security, superior user interface, ease of installation and a beautiful out-of-the-box experience."Plone 4 is based on the most-frequently requested features and improvements from Plone's worldwide user and developer community," says Plone co-founder and Firefox User Experience Lead Alexander Limi. "Our developers and users asked for better performance - Plone 4 is much faster, requires less memory, and performs well even when serving up massive files. They also didn't want us to sacrifice what we do well to get there - and we haven't. Plone 4 is not just more powerful - it continues to improve in areas Plone has always been known for: usability, security, and a CMS that is easy to install, upgrade, and looks great right out of the box."Looking back on the nine year evolution of Plone and the community that supports it, Limi is more than pleased. "It's gotten to be a lot bigger than I thought it could be. Sometimes we forget how many people are involved with Plone, and how many people have left behind PHP and Java to create successful businesses based around Plone."Geir Baekholt, President of the Plone Foundation, has a similar reaction. "I'm impressed with how professional, mature and focused the Plone community is. It's rare in open source to see so many companies operating to such high standards, treating their customers and employees well and running their businesses in a sustainable manner.  The best thing about Plone is that we have so many mature, stable companies using it who are consummate professionals at what they do."For all its technical and visual improvements, one of Plone 4's most important roles is to build the under-the-hood foundation even more exciting improvements in Plone 5.  It gives developers and users innovations they can use today, while allowing them to develop products and websites that will be ready to take full advantage of future Plone releases.The list of notable changes in Plone 4 includes:  Significant performance improvements New theme Search and indexing improvements Group Dashboards for a Customized User Experience Massively improved handling of large files & media New, faster folder implementation More powerful management of users and groups Dynamic forms framework based on jQuery Tools Improved first-run experience Smooth upgrade experience Reduced memory footprint Upgraded infrastructure You can find out more about these new features than you would ever want to by visiting http://plone.org/4. Plone Deployment Workshop 2010 Returns to Indianapolis November 11-12  Six Feet Up has announced the return of its Plone Deployment Workshop this Fall at the Omni Severin. The workshop offers the opportunity to delve into the details of how to follow egg-based release practices for successful deployments.The workshop will offer two tracks for different audiences.  Both tracks will cover how to successfully deploy Plone, with one as a more hands-on experience for system administrators who would like to gain a more in-depth understanding of Plone management.  The second track will offer a higher-level understanding of how to manage a successful deployment.Some of the talks will include:* Buildout for the Future by Clayton Parker* Caching by Ricardo Newbery* Supervisor  by Chris McDonough* Scaling and system management  by Elizabeth Leddy* We will also have talks by our own staff on ldap integration, relStorage, Zenoss, memmon and more.GUEST SPEAKERSElizabeth Leddy, Plone enthusiast, will focus on scalability and performance during her presentation at the Plone Deployment Workshop.  With over seven years of development and deployment of applications with Python platforms, she has been instrumental in the expansion of Plone as a leading Content Management System.   Her passion for scaling and system management comes from her own experience in a variety of industries.  She currently is a consultant in San Francisco.Chris McDonough is the primary author of the repoze.bfg web application framework and the author of the book "The repoze.bfg Web Application Framework". He is a Python developer and consultant for Agendaless Consulting, a company based in Fredericksburg, VA, USA. His other major projects include Supervisor, a Python process management system.Ricardo Newbery is a former physics researcher and instructor who now spends much of the time developing applications and troubleshooting issues for people who need robust high performance web content management solutions. Mr. Newbery is a contributor to the Plone CMS project and the release manager for plone.app., plone., z3c., plone.cachepurging, plone.recipe.squid, and the CacheFu collection of products.For more information or to sign up, visit - http://www.sixfeetup.com/news/plone-deployment-workshop-2010 Plone 3.3 Site Administration This book for administrators was written by Alex Clark, a member of the plone.org infrastructure team, Plone Foundation Member and leader of the Washington DC Zope/Python Users Group.  It provides a solid introduction to administering Plone-based websites and covers the subject in an easy to follow, step by step manner.What this book covers: The basics of Plone site administrationInstalling Python, Distribute, Buildout, PIP, Plone, and moreChanging the appearance of your Plone site with freely available, professional-looking themesAutomating maintenance tasks to keep your site running smoothly with less effortSecuring, backing up, and monitoring your Plone siteMaximizing the performance of your Plone site by applying various site optimization techniques This book is designed for site administrators, webmasters, or content editors managing a site with Plone who have some Plone background, but are new to site administration. The reader is also expected to know basic Python programming. Plone 3.3 Site Administration is available in both print and electronic forms from Packt Publishing.   A User's Guide to Plone The latest edition, for Plone 4, is 246 pages, has undergone a major rewrite and includes new material on topics such as: using the TinyMCE editor, using Plone for wikis and making content easy to find.  This volume focuses on how to use "out of the box" features preinstalled with any default Plone installation. It is written especially for those who use Plone on a daily basis to write and approve content.Available on Amazon in Print: http://www.amazon.com/dp/0615404626Available as PDF download: http://www.enfoldsystems.com/assets/user-guide/a-users-guide-to-plone-4Also available from Amazon.co.uk and Amazon.de within 1-2 weeks.Free PDF versions of the User Guide for the Plone 2/3 series are available athttp://www.enfoldsystems.com/support/a-users-guide-to-plone.html Introducing Plone.org's New "Downloads" Section: Comments, Ratings, Screenshots and More! Plone.org's "downloads" section has gotten a major facelift, and now includes community product ratings, comments on products, screenshots and many other improvements.The Plone.org team is proud to unveil a long-awaited overhaul to Plone.org's "downloads" section which houses Plone's many add-on products.  Thanks to some fantastic work from Elizabeth Leddy, Alec Mitchell, Alex Clark and participants at the recent LA Plone Sprint, Plone.org now features:Community ratings of add-on products. Plone.org users can now rate add-on products, and search listings are now sortable by product ratings.  This will help users quickly find the products that the Plone community likes best.  Product authors will also benefit from the quick and easy feedback mechanism. Comments on products. Plone.org now enables comments on products from logged-in users.  This enables another channel for community feedback on a product.   Please use it to review the product.   Bug reports should continue to go to the product issue trackers and support questions should generally go to the plone-users list. Screenshots with lightbox popups = a theme gallery! Plone.org now displays front-and-center screenshots in product listings when the product author provides them.  Screenshots have slick lightbox-style popups which is especially useful for getting a preview of theme products.  Downloads organized by product, rather than by release. The Plone.org downloads section is now organized by add-on product, rather than by individual product releases.  This produces much more intuitively-organized product listings, especially for products that are making frequent releases.Plone version compatibility is front-and-center. Plone product listings now show Plone version compatibility right up front, this makes finding add-on products for your version of Plone quick and easy.At-a-glance compatibility and status matrix for all product releases. Each product detail page now includes a new compatibility and status matrix that summarizes the status (alpha, beta, final) version compatibility and summary information for each product release.Please take a few moments to explore the new http://plone.org/products, rate your favorite products, leave a comment or two and of course let us know if you run into any problems with the new downloads section.  Big thanks to Elizabeth, Alec, Alex, and the LA Plone Sprinters for some fantastic work that will touch everyone who uses Plone. Demo Site Lets Users Preview Plone 4 Features online A demonstration site has been set up to allow users to preview Plone 4. The demonstration site lets users experience the look and feel of Plone 4 as well as check out its ease of  use and new features. Its a great tool for demonstrating Plone 4 without needing to do a local installation and for folks to look at the changes since Plone 3.  The site lets users log in using a variety of roles so they can see the difference between what users, editor and administrators see when working in Plone 4.You can access the demo site at http://demo.plone.org . New Site Spotlight Library of Bergen, Norway's Second Largest Library recently launched a brand new Plone-based website created by Jarn.  In addition to an awesome visual design, the site also serves as a showcase of Plone's newest technologies and Web 2.0 / Social Media integration.The Bergen site was themed with XDV, as opposed to regular old style Plone themes. Using XDV made us also able to integrate/theme the library's existing library-management-system without touching the system itself.  So even when users are using the existing PHP infrastructure they don't notice that they are viewing a different system at all. Al library operations like reserving books, extending loans, searching for books, etc seem to be going through one website.  A good example of this is the XDV-themed search, which can be seen here.  You can visit the site at http://bergenbibliotek.no/ [Less]