Thanks for the suggestion! I changed the title to focus on the desired outcome, not the implementation.

For technical reasons, it will be quite difficult to implement an actual progress bar (i.e. one that progresses more or less steadily and allows the user to correctly estimate how long it will take), but I see several alternatives:

• Tell the user what the tool is working on ("Collecting sub-categories/topics (N found)", "Searching for articles in need of attention... (N found)" where N can be updated frequently)
• Stop searching for sub-categories (and articles) after a certain threshold has been reached. The problem is that we have no way of knowing how many tagged articles are in a category until we actually retrieve them from the database, and we probably want to eventually retrieve all articles, not just say the top half of the alphabet.
• Stop searching after a certain amount of time has elapsed and return what we found so far.
• Iterative search, i.e. find some sub-categories, search for tagged articles, display what we have, continue finding more sub-categories, ...
• Quick solution: Display an animated symbol to signal that the tool is indeed working

@Jan_Dittrich can you lend your expertise here? Which of the solutions that Cirdan suggested would you prefer?
Or would there be something else?

Quick solution: Display an animated symbol to signal that the tool is indeed working

Indeed. A simple spinner might be already helpful.

For the stopping ideas:

I think, if the user has a large choice it is not important that they get all .

My question would be if there is a pattern to the articles that come in first: breadth first, depth first, alphabetical, random… – to avoid/consider that e.g. only articles with A… get fixed and Z… never.

In general, random might be preferred for our purposes.