How to deal with numerous immediate bugs in Plone 5

I have been a Plone user for many years. I started with Plone 3 and then used Plone 4 for a long time. Today, I finally installed Plone 5, to which I wanted to migrate my websites.

Unfortunately, my initial experience with Plone 5 was not very positive. I only performed a few initial steps, but already encountered quite a few bugs, mostly with layout and translation to German.

Now I would really like to see these bugs fixed. In principal, I would think that reporting them to the Plone bug tracker would be the way to go. However, my experience with reporting bugs in open-source software is very negative. Typically, nothing was done about the bugs. So I would first like to check whether it is really worth to spend a considerable amount of time to report all these bugs. Will the Plone developers take care to fix easy bugs quickly? Or would layout and translation bugs be considered minor and their elimination be delayed as a consequence?

Furthermore, I would like to know whether it would be better to report all layout-related bugs in a single report and all translation-related bugs in another single report, or if I should file a single bug report for each particular issue (which might result in many reports).

If you don't report the bugs, then no, they're not going to get fixed.

While I can't guarantee that any specific bug is fixed right away, I can say that we do try our best. We have a large number of German users, so that certainly raises the likelihood of a fix.

For bug reports, please report it as one bug per ticket.

For translation corrections, you can submit tickets, but it'd be just as fast to fix them yourself.

1 Like

Thank you for your prompt response.

It is good to hear that the Plone developers will take care of getting bugs fixed. I think I will give it a try.

Thank you for pointing me to the German translations. I indeed think that it is easier to fix pure translation errors myself. How should I proceed with this on a technical level? Create branches and send pull requests?

Yes please, if you are already familiar with the pull request concept of github, update German translations and send them as a pull request.

I am not really familiar with the concept of pull requests, but willing to learn about it. :slight_smile:

1 Like


Working on the translations technically is easy using an external tool,like Poedit.

The problem is finding the right wording for a phrase in a particular context. German translations are often hard and it is often hard to find a wording that brings a functioanlity to the point without blathering.

Instead of blindly,translating untranslated strings it is better to check translations in Plone section by section.

Apaet from that: one bug report per bug


Then these are probably the best starters:

@jeltsch If it come to bugs, do not forget to check wether your issues are fixed in most recent buildout.coredev for the next 5.1 release. Use buildout.coredev 5.1 branch to check.


Unfortunately, my available time is very limited. Writing good bug reports is already time consuming enough, In the case of layout bugs, it also involves making screen shots, cutting them down, and marking the buggy parts. If I am now supposed to additionally install another Plone version, I might just forget about bug reporting.

I am a Plone user who wants things to work. It is already annoying enough that there are so many obvious bugs one year after Plone 5 was initially released. Note that I did not really use Plone 5 so far and did not deliberately look for bugs. The bugs I am talking about were all encountered by me by just creating a Plone site, configuring e-mail, and clicking a bit around. I did not even try to add or change some content.

Ranting about Plone is usually my job. Plone 5 has some internal issues but in general Plone 5.0 is reasonably usable and does not contain major issues with two sites in production. Please be precise and take your time to write bug reports - unreported bugs do not exist. Plone is open-source and a community-driven project. Writing reasonable bug reports is a reasonable way to participate in Plone. There is no obiligation to fix bugs you reports. But quality will not improve if you do not report the issues that you encounter.


I do not think I ranted. And I still plan to write bug reports. I just objected to me also installing a Plone development version.

IMHO, you have a reasonable concern. If we are going to ask to test alpha versions of things, we ought to have some process to release nightly builds that work with unified installer?

Since we do not, I think it should be a fine shortcut to submit translation bugs, if:

  1. You see them in currently released Plone 5.0.6, and...

  2. You compare the .po files to master branches on github, to see if anyone actually tried addressing this in 5.1. That is easy enough in a browser:
    a. Determine package the .po file in question lives in locally (in your eggs directory);
    b. Go to${PACKAGENAME} to browse source, and find the .po file on the same relative path as it exists inside the egg distribution for the same package.


If you use mr.developer in your buildout (I don't know if we have this in the UnifiedInstaller), you can add to auto-checkout to have the latest translation. For Plone 5.0.x, add this:

auto-checkout =

collective = git://
collective_push =

[sources] = git ${remotes:collective}/ pushurl=${remotes:collective_push}/ branch=5.0.x

(pushurl is on the same line as

Or simpler, you can use a more recent version of 5.0.x too, I did a release some days ago that include German translations update, pin in [versions] = 5.0.12

1 Like