@tymees I changed the placement of the docstrings.

To elaborate on the working of the HideFromArchiveView, it simply does not hide the proposal from the archives consistently. However, I am also confused about which archive we are talking about with this view. From how I understand it there's the private archive, the url name 'archive'. Here I experience inconsistency in whether the proposal shows up at all after conclusion. furthermore, I have not succeeded in hiding a proposal from this page using the HideFromArchiveView. This view redirects to the private archive, when it is called, which I also find confusing.

Then there is the public archive, with the url name 'public_archive'. Here, proposals show up more consistently for me. I also have managed to remove proposals here using the HideFromArchiveView, but only after having added a line, namely:

proposal.in_archive = False

I have also had to reformat the reverse call at the end of the get_redirect_url method of this view, as that was causing a reverse error from me.

I changed it to:

        committee = proposal.reviewing_committee.name
        return reverse('proposals:archive', args=[committee])

So if the point of the HideFromArchiveView is to remove a proposal from the public archive, then the view was not working correctly, but can be with the changes discussed here. I would suggest however, that it would then redirect to the public archive, to avoid confusion for the user.

Now with the private archive, I am experiencing inconsistency in general, which I don't yet fully understand. If the point is to hide a proposal from here, I will need some more explanation on the workings and intention of this page.

Ugh okay I've figured out what the problem is with the archive stuff. It's not that hard to fix, but it's a bit of a head scratcher to describe. The existance of 4(!) different archives is probably the culprit, which causes confusion on what does what.

I'm rapidly approaching my daily work-time-allowence, so I'll write a new issue for this later sometime this week.

For now, this PR can go ahead to develop I think without that fix. We'll just enable the corresponding action once it's fixed.

There is still the issue of the file conflicts; it's the dreaded translation files again. Michael is our resident PO-file conflict expert, so you might want to hit him up when he's back

thank you, Ty ;) I figured there was something strange going on ... Take it easy!

I will write up a quick how-to on on merging translations in the meta repo.

All right, I implemented the suggested changes, but there is still a merge conflict caused by the .mo file. What do I do about this?

The django.mo file is the compiled version of django.po. It gets generated by python manage.py compilemessages, which is automatically run on the server after every deployment. So as long as django.po is in order, you can ignore django.mo safely. You could put it in your local .gitignore so changes to it aren't recorded or staged.

In this case, because changes to it have already been committed, you should resolve the conflict by simply choosing your local (most up-to-date) version as the correct one. I can help you with this if you like.