start

# Contributing

We could use your help. If you are interesting in contributing then please join us on IRC on #pootle and on the translate-devel mailing list.

Here are some idea of how you can contribute

1. Test - help us test new candidate releases before they are released
2. Debug - check bug reports, create tests to highlight problems
3. Develop - add your Python developer skills to the mix
4. Document - help make our docs readable, useful and complete

Below we give you more detail on these:

## Testing

Before we release new versions of the Toolkit we need people to check that they still work correctly. If you are a frequent user you might want to start using the release candidate on your current work and report any errors before we release them.

Compile and install the software to see if we have any platform issues

    ./setup.py install

Check for any files that are missing, tools that were not installed, etc

Run unit tests to see if there are any issues. You’ll need the py.test unit test software which you can download from http://code2.codespeak.net/download/py/

To run the tests you do

    py.test

from the translate src directory, or

    py.test storage/test_dtd.py

to run a specific set of tests.

Report any failures.

Note: If your Pootle tests fail with an error along the lines of:

    URLError: <urlopen error (-2, 'Name or service not known')>

Check your http_proxy environment variable. Usually it helps just to unset it:

    unset http_proxy

Finally, simply work with the software. Checking all your current usage patterns and report problems.

## Debugging

1. Make sure your familiar with the bug reporing guidelines.
2. Create a login for yourself at bugs.wordforege.org
3. Then choose a bug

Now you need to try and validate the bug. Your aim is to confirm that the bug is either fixed, is invalid or still exists.

If its fixed please close the bug and give details of how when it was fixed or what version you used to validate it as corrected.

If you find that the bug reporter has made the incorrect assumptions or their suggestion cannot work. Then mark the bug as invalid and give reasons why.

The last case, an existing bug is the most interesting. Check through the bug and do the following:

1. Fix up the summary to make it clear what the bug is
2. Create new bugs for seperate issues
3. Set severty level and classifications correctly
4. Add examples to reproduce the bug, or make the supplied files simpler
5. If you can identify the bug but not fix it then explain what needs fixing
6. Move on to the next bug

## Developing

Don’t ignore this area if you feel like your not a hotshot coder!

You will need some Python skills, this is a great way to learn.

Here are some ideas to get you going:

- Write a test to expose some bug
- Try to fix the actual code to fix your bug
- Add a small piece of functionality that helps you
- Document the methods in especially the base class and derived classes
- Add a format type and convertors: eg PDF, ODF, .doc
- Add more features to help our formats conform to the standards

You will definately need to be on the Development and probably on the CVS checkin lists.

You can use anonymous SVN to start with but once you’ve done some work please ask for a subversion account and commit directly.

Now is the time to familiarise yourself with the developers guide.

## Documenting

This is the easy one. Login to the wiki and start!

The key areas that need to be looked at are:

1. Do the guides to each tool cover all command line options
2. Are the examples clear for the general cases
3. Is the tools use clear
4. In the Use cases, can we add more, do they need updating. Has upstream changed its approach

After that and always:

- Grammar
- Spelling
- Layout