). It's acceptable to use
+HTML in C calls, especially for bold and emphasis. However, you
+should limit the amount of HTML that translators must keep exactly
+correct, which means avoid including tags that wrap the entire
+translatable string, especially C<< >>.
+
+
<&|/l, $button &>Do not click [_1]
# ok
+
+ <&|/l, $button &>Do not click [_1]
# not ok
+
+In a few places in RT we also pass HTML as parameters to C
+so that translators do not have to reproduce it exactly, and we can
+also change it more freely. For example:
+
+ <&|/l,
+ '',
+ '',
+ &>Distributed under [_1]version 2 of the GNU GPL[_2].
+
+F looks for C and
+C<< <&|/l&>... >> in our source code to pick out translatable
+strings, clean them up, and put them into F files. We use
+our C<.po> files not only to populate L's lexicons,
+but also to sync new translatable strings and translations with
+Launchpad. This Launchpad sync is typically done early during the
+freeze of RC releases to give our volunteer translators time to
+translate all the new strings which, because of the RC freeze, won't
+continue changing.
+
+Because C and C are used to generate strings for human
+eyes, they generally must be used "close to the browser". These are
+directly in Mason templates, or in functions that return text that
+will be passed through Mason. However, in many places in RT we have
+hardcoded strings which need translations. For example, the C<$RIGHTS>
+hash in F maps rights' names (which must be
+translatable) to their descriptions (which also must be translatable).
+However, when we're declaring such structures, we do not want to
+translate them straight away. RT uses English internally, including
+in its web forms, so we do not want to localize rights' names except
+for display, otherwise things might break weirdly when you check
+if a user has the "Superusuario" right. Furthermore, when we're
+declaring such data structures at compile time, there is no current
+user to select which language to use for localization. Thus, we
+cannot call C when declaring C<$RIGHTS> and other similar
+places.
+
+For this reason, F lets you
+denote translatable strings with comments. That's what the C<#loc_pair>
+comments in the C<$RIGHTS> hash in F indicate.
+Since we have those comments, our toolchain will put the rights'
+names and descriptions into F files, which enables
+translation by our lovely volunteers. Later on, when RT displays
+information about rights in the web UI, we'll pass the right's name
+through C, and L will then be able to find
+our "Superusuario". So although we never used a literal
+C, we still get its effects thanks to the
+C<#loc_pair> comments and using C.
+
+C<#loc_pair> is used for declaring that the both the key and value
+of a particular C<< key => value >> pair are translatable. There
+are other markers that you can use.
+
+C<#loc> is used for declaring that a particular string is translatable.
+Its parsing is pretty strict so you can use it to declare that only
+the value of a particular C<< key => value >> pair is translatable.
+
+C<#loc_left_pair> is used for declaring that the I of a
+particular C<< key => value >> pair is translatable. This is of
+very limited usefulness.
+
+C<#loc_right_pair> does NOT exist. C<#loc> works in such cases since
+its parser does not extend beyond the string at the end of a line.
+
+=head1 Development tips
+
+=head2 Setting up a development environment
+
+=head2 Test suite
+
+RT also comes with a fairly complete test suite. To run it, you will
+need to set environment variables to a database user and password which
+can create and drop databases:
+
+ export RT_DBA_USER=root
+ export RT_DBA_PASSWORD=
+
+You'll need to configure RT and make sure you have all the dependencies
+before running tests. To do this in place without installing:
+
+ ./configure.ac --with-my-user-group --enable-layout=inplace --with-devel-mode
+ make testdeps
+ make fixdeps
+
+Adjust the relevant database options as necessary if you want to test on
+Postgres, Oracle, or SQLite. The default is MySQL.
+
+To run the test suite:
+
+ make test
+
+If you have multiple processors, you can run the test suite in parallel,
+which will be significantly faster:
+
+ make test-parallel
+
+The C<*-trunk> and C branches are expected to be passing always
+be passing all tests. While it is acceptable to break tests in an
+intermediate commit, a branch which does not pass tests will not be
+merged. Ideally, commits which fix a bug should also include a testcase
+which fails before the fix and succeeds after.
+
+
+
+=head1 git quickstart
+
+=over
+
+=item 1.
+
+You will first need to obtain a copy of git; this is accomplished via
+C in RedHat and derivatives, or C for Debian or Ubuntu.
+
+=item 2.
+
+Next, obtain a copy of the RT source from git:
+
+ git clone git://github.com/bestpractical/rt.git
+ cd rt
+
+=item 3.
+
+Configure git to know your name and email address; git uses these when
+it makes commits.
+
+ git config user.email your.email@example.com
+ git config user.name Examp L. Name
+
+=item 4.
+
+Switch to the appropriate point to base your work on; this is generally
+C followed by the major version, followed by C<-trunk>. For
+example, if your bug was observed in version 3.8.9, you would choose
+C; if it was in 4.0.0, you would choose
+C. New features should be based on C.
+
+ git checkout --track origin/4.0-trunk
+
+=item 5.
+
+Give your branch a name based on what you are attempting to accomplish.
+We suggest that branch names be lower-case and separate words with
+dashes, but this branch name is purely for your own reference.
+
+ git branch -m gnupg-encryption
+
+=item 6.
+
+Edit the source tree to make your changes. A few commands you may find
+useful in doing so are listed below.
+
+To see what files you have changed:
+
+ git status
+
+To see a line-by-line list of changes:
+
+ git diff
+
+To revert a file to the original version:
+
+ git checkout path/to/file
+
+To revert only individual parts of a file:
+
+ git checkout -p path/to/file
+
+See L for more tips for working with the RT codebase.
+
+=item 7.
+
+Check that you have no extraneous changes using C, then commit
+your changes:
+
+ git commit -a
+
+You will be prompted to type your commit message. The first line should
+be a short (E 80 character) summary of the changes, followed by a
+blank line, followed by a longer description, if necessary. The commit
+message should not simply restate the diff of which lines were added and
+subtracted, but should rather explain B those changes accomplish,
+and B they are desired.
+
+If your changes are easily split into multiple components, you may wish
+to split your changes into more than one commit; simply return to step 6
+and repeat the with the next related change. If your changes are B
+related to each other, you should submit them separately; finish step 9,
+then start over from step 4.
+
+=item 8.
+
+Save your commits to patch files:
+
+ git format-patch @{u}
+
+This will print out the names of the files as it creates them.
+
+=item 9.
+
+Attach these files to an email using your standard email client, and
+send it to C.
+
+=back
+
+If you have another bug or feature to implement, simply restart the
+process at step 4.
+
+=cut