You can help development of the project by contributing translated texts. Tux Commander doesn't use gettext package yet, strings are located in the file with naming scheme UTranslation_XX.pas where XX stands for locale abbreviation. Each language has its own file, standard Pascal unit file. The main disadvantage is the requirement to compile the application if you want to test the translation. However this solution brings the benefit of independency on additional files or external libraries. Locale strings are updated in every stable version, 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 latest translation file from the GIT repository (see below), either the English translation file (UTranslation_EN.pas) if making new translation or existing translation, if you plan to take over maintainership (check the Description page for list of translations and their status). Open the translation file and change all references to EN abbreviations to your new locale abbreviation (including all constants with LANGen names). You have to use UTF-8 compliant text editor (gedit, katoob, ...) and save the file in UTF-8 encoding. If you want to compile tuxcmd to test your translation, you have to add your unit name to 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 may find strings containing underscore characters, which represent keyboard shortcuts. There's no need to keep the shortcuts on the same letter as English source, the GTK toolkit will automatically extract and activate them.

If you are building Tux Commander yourself, use the enclosed Makefile. The only prerequisite is working FreePascal compiler. Further instructions can be found in the 'INSTALL' file.

Please always use latest version of FreePascal compiler, older versions than 2.2.2 contain various bugs, such as the annoying thread limit (0009016: Create Thread Limit).

List of make targets:

- every module contains necessary URIs for checkout and commit
- to get a snapshot without need to clone whole repo, click the "snapshot" link on particular commit line

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). 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 available 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).