You can help to develop the project by contributing the translated texts. The application doesn't use gettext package yet, the strings are located in the file with naming scheme UTranslation_XX.pas where XX stands for locale abbreviation. Each language has its own file, the standard Pascal unit file. The main disadvantage is the requirement to compile the application if you want to test the translation. The big advantage of this solution is that it does not need any additional files or links to the external libraries. The locale strings are updated in every stable version, so the development snapshots may contain English texts. These versions are under development and things may change before releasing stable version.

The best way to start is to grab the English translation file (UTranslation_EN.pas) and change all the references to the EN abbreviation to your new locale abbreviation (including all constants with LANGen names). You have to use a text editor with UTF-8 support and the strings have to be written in the UTF-8 encoding (you can use for example gedit or katoob text editors). If you want to compile the project to test the new translation, you have to add the unit name to the ULocale.pas file - there's a line in the implementation section starting with uses and some other locale units. If you don't want to test the translation yourself, send me the file by e-mail, I will clean it and will send you the compiled snapshot with your translation.

You can try build Tux Commander yourself, there is a Makefile which should do all the work. Before you start the make program, make sure you have changed the path pointing to the Kylix complier (dcc) and the prefix where the files will be installed. You also have to download the gtk2forpascal package and extract it to the sources together with tuxcmd. Further instructions about building are located in the 'INSTALL' file.

There are some parameters to make:

VFS (Virtual File System) modules (plugins) are small libraries which include a functionality for access to a remote filesystem or explore the contents of a packed archive. The main goal is to access the virtual filesystem in the same way like it was local filesystem. User should be able to perform basic operations such as directory tree browsing, copying, deleting... The modules have unified API which they communicate with the host application (Tux Commander here) and they could be used also in other file managers (sharing the modules vice versa).

The host application is searching for available modules on program start in these locations: /usr/lib/tuxcmd, /usr/local/lib/tuxcmd, ~/.tuxcmd/plugins and ./plugins and tries to load each module. If the module is successfully loaded, the new submenu will appear under the Plugins menu. At this time, there's only the About item, but in the future, the other items will appear (plugin actions, configuration dialogs). For testing purposes there's also a Test plugin dialog where you can try to open the URI with the selected module and test/debug the functionality.
Each module can provide access to the archives and/or to the remote services. You can use integrated Connection Manager to define new connections, which are using the services of the VFS modules.
If the modules aren't loaded on startup, please run tuxcmd with parameter --debug and watch the debug log, you should see what happened. Additionally you can run ldd on each module to see if there are all required libraries available in your system.

The modules are standard unix shared objects (dynamic libraries) and they're loaded dynamically from the host application. You can write your own modules in any programming language, if they could generate compatible so libraries (e.g. gcc, Kylix, FPC, maybe Mono?). If you are using Pascal or other non-C languages you have to use the cdecl directive or such equivalent. If the module is dependent on some other system libraries not present in the system running in, it will simply display an error message to the debug log and the module will not be present in the application.

There are two modules available in the sources: gnome-vfs and null. You can use the null module to start making your own plugin, there is a skeleton of all functions used in the current version of VFS API. With included Makefile, you can easily compile the module and test the binary version. You can also take a look to the file uVFSprototypes.pas, there are simple comments to each function used in the API. Please note that the API is not fully stable yet, there will be probably some minor changes in the future, mostly for better error handling. I will not describe here detailed comments for each function, maybe when the VSF API v3 will be finished (corrected and working stable VFS API).