We’re passionate about helping Transifex users make the jump to contributing members of the community, so there are many ways you can help Django’s development:
Well-written bug reports are incredibly helpful. However, there’s a certain amount of overhead involved in working with any bug tracking system, so your help in keeping our ticket tracker as useful as possible is appreciated. In particular:
We’re always grateful for patches to Transifex’s code. Indeed, bug reports with associated patches will get fixed far more quickly than those without patches.
Here are some notes on the common style we use for stuff landing in Transifex.
Code follows the guidelines described in the standard Python Coding Style of PEP-8. Docstrings follow PEP-257.
Use the following style (indented, auto-concat) when writing long strings:
def lorem_ipsum():
description = _(
"Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Maecenas "
"nisl leo, suscipit sed, elementum ac, condimentum eget, augue. "
"Pellentesque consequat posuere metus. Curabitur scelerisque faucibus "
"massa. Vestibulum ut nisl ut leo cursus commodo."
)
Model filtering should be in the form:
Module.query.filter_by(name='foo')
and not:
Module.query.filter(Module.name=='foo')
Commit messages should have a short first line and optionally more information after a blank newline:
Short (50 chars or less) summary of changes (#ticket)
More detailed explanatory text can follow after a blank line, if
necessary. Wrap to about 72 characters or so.
If there is a ticket associated, include it in the summary line. Prefix
line with "bugfix:" and "trivial:" for bugfixes and trivial commits.
- Bullet points are okay, too. Typically a hyphen or asterisk is used
for the bullet, preceded by a single space, with blank lines between
items.
- Use a hanging indent, like above.
To configure vim for editing Transifex code, make sure that it sets up the indentation level to 4 columns when editing Python code, that it expands ASCII TAB (code: 9) characters to spaces, and wraps text at 72 columns.
To enable these options only for *.py files, you can add the following options to your ~/.vimrc file:
if !exists("format_tx_python")
let format_tx_python = 1
" Formatting Python code for Transifex.
autocmd BufNewFile,BufRead *.py set autoindent showmatch
autocmd BufNewFile,BufRead *.py set formatoptions=tcq2l
autocmd BufNewFile,BufRead *.py set textwidth=72 shiftwidth=4
autocmd BufNewFile,BufRead *.py set softtabstop=4 tabstop=8 expandtab
endif
To configure Emacs for editing Transifex code, you can set up a hook function that runs whenever python-mode is enabled. Setting up the column for wrapping text, and the use of only ASCII SPACE characters for indentation is easy. Just add the following Emacs Lisp snippet in your Emacs startup file:
;; Formatting Python code for Transifex.
(defun local/python-mode-options ()
"My local configuration tweaks for `python-mode'."
(setq fill-column 72 ;text wrap column
python-indent 4 ;use 4-column indentation for Python
indent-tabs-mode nil ;use only SPC for indentation
next-line-add-newlines nil)) ;don't add newlines at end-of-file
;; When python-mode loads, call our hook function.
(eval-after-load "python"
'(add-hook 'python-mode 'local/python-mode-options))
Like with all software having a database, changes to Transifex’s models should be handled with care. Production instances of Transifex rely on the stability of the model when upgrading, and a safe upgrade path should be given to everyone currently running a Transifex instance.
For this reason we usually discuss model changes on the mailing list, especially if they’re big ones.
New model fields should follow the style of the current fields and include any help texts attributes to them, if needed.
A commit which changes the models needs to include fixtures that work with the new model. We already have some sample data for folks to try out in txcommon/fixtures/sample_data.json.
When model modifications are introduced, the following steps can be followed to have the fixture updated:
Flush, create tables and load data:
./manage.py flush
./manage.py syncdb
./manage.py loaddata txcommon/fixtures/sample_data.json
Make changes to the models.
If an evolution is required, get a hint for it, and if it looks OK, copy the lines up to and including the ones with dashes to a file like txcommon/evolutions/001_add_X_field.py:
mg evolve --hint
Note that in complex changes the evolution application might not be able to proceed (for example when adding a non-null column). In this case you can delete the column and re-add it, add it as null and change it, etc.
With the new DB schema in place, dump the data again:
./manage.py dumpdata --intend=2 projects txcollections releases vcs \
translations sites > txcommon/fixtures/sample_data.json
Try the new DB fixture:
./manage.py flush --noinput
./manage.py syncdb --noinput
mg loaddata txcommon/fixtures/sample_data.json
mg loaddata txcommon/fixtures/sample_users.json
Open up your browser to check everything looks OK and that your changes have been included as you’d expect.
Update the documentation if needed. Commit all changes together.
Transifex is protected against CSRF attacks by ensuring that GET requests are side-effect free. This means that every action inside Transifex that has an effect on the database, session, etc. are not being done over a GET request. With Django’s CSRF Middleware enabled, attackers are prevented from meddling with a Transifex user’s settings.
Examples of CSRF-vulnerable elements are a link which calls /logout over GET to log the user out, a ‘pt_BR’ link to change the page’s language to Brazilian Portuguese and save this setting to the user’s cookie, a simple AJAX request to lock a file, etc.
Examples not vulnerable actions are searching through the website for a string, pagination, etc.
If you are adding some code in Transifex which has a side-effect, always do it over POST.
Jun 16, 2009