If you wish to become involved in the development of Recoll, you are very much welcome, please send me an email.

Translation

More translations is good ! If you are a non-english speaker (and understand english, which can probably be assumed, you being reading this), you can take a little time to translate the GUI messages file.

The newest versions of the message files follow. There is an empty one (the xx thing), the others are partially translated, just needing an update for the new messages.

Updating the files can easily be done with the Qt Linguist. Contact me for more directions if needed.

• Blank: recoll_xx.ts
• German: recoll_de.ts
• Italian: recoll_it.ts
• Russian: recoll_ru.ts
• Turkish: recoll_tr.ts
• Ukrainian: recoll_uk.ts

Development

Apart from general development for additional functionality or bug fixes, the following tasks are waiting for you:

• A better GUI design (both the ergonomy and the appearance).
• More support for the more advanced Xapian concepts like relevance feedback.
• More filters for less common or less obviously useful file types.
• Integration with the KDE desktop.
• Integration with some mail user agent. We need a way to jump from a message preview to the message in thread context inside the MUA.
• Etc. :)

Problem reporting

Once in a while it will happen that a Recoll program will crash (either the "recoll" graphical interface or the "recollindex" command line indexing command).

Reporting crashes is very useful. It can help others, and it can get your own problem to be solved.

All reports are useful. But, in order to maximize usefulness, a crash report should include a so-called stack trace, something that indicates what the program was doing when it crashed. Getting a useful stack trace is not very difficult, but it may need a little work on your part (which will then enable me do my part of the work).

If your distribution includes a separate package for Recoll debugging symbols, it probably also has a page on its web site explaining how to use them to get a stack trace. You should follow these instructions. If there is no debugging package, you should follow the instructions below. A little familiarity with the command line will be necessary.

Compiling and installing a debugging version

• Obtain the recoll source for the version you are using (www.recoll.org), and extract the source tree.
• Follow the instructions for building Recoll from source with the following modifications:
  • Before running configure, edit the mk/localdefs.in file and remove the -O2 option(s).
  • When running configure, specify the standard installation location for your system as a prefix (to avoid ending up with two installed versions, which would almost certainly end in confusion). On Linux this would typically be:
    configure --prefix=/usr.
  • When installing, arrange for the installed executables not to be stripped of debugging symbols by specifying a value for the STRIP environment variable (ie: echo or ls):
    sudo make install STRIP=ls

Getting a core dump

You will need to run the operation that caused the crash inside a writable directory, and tell the system that you accept core dumps. The commands need to be run in a shell inside a terminal window. Ie:

cd
ulimit -c unlimited
recoll  #(or recollindex or whatever you want to run).
	  

Hopefully, you will succeed in getting the command to crash, and you will get a core file.

Using gdb to get a stack trace

• Install gdb if it is not already on the system.
• Run gdb on the command that crashed and the core file (depending on the system, the core file may be named "core" or something else, like recollindex.core, or core.pid), ie:
  gdb /usr/bin/recollindex core
• Inside gdb, you need to use different commands to get a stack trace for recoll and recollindex. For recollindex you can use the bt command. For recoll use:
  thread apply all bt full
• Copy/paste the output to your report email :), and quit gdb ("q").