reworking terms page + replacing pad classes with inner classes.

[rails.git] / README.md

diff --git a/README.md b/README.md
index 4579b9b80b59573b98f9c6eee4ee397e7975dde5..f22e30011b2e7dcfde54aeba76f2e20dfe2820bb 100644 (file)
--- a/README.md
+++ b/README.md
@@ -17,7 +17,8 @@ There are some non-Rails services which the site includes, for
 example; tiles, geocoding, GPX file loading. There are also some
 utilities which provide other services on the OpenStreetMap site,
 or improve its function, but are not integrated with the Rails 
 example; tiles, geocoding, GPX file loading. There are also some
 utilities which provide other services on the OpenStreetMap site,
 or improve its function, but are not integrated with the Rails 

-port, for example; Osmosis, CGImap.
+port, for example; [Osmosis,](http://wiki.openstreetmap.org/wiki/Osmosis) 
+[CGImap.](https://github.com/zerebubuth/openstreetmap-cgimap)

 
 # License
 
 
 # License
 


@@ -63,7 +64,7 @@ helpful as a reference.
 ## Coding style
 
 When writing code it is generally a good idea to try and match your
 ## Coding style
 
 When writing code it is generally a good idea to try and match your

-formatting to hat of any existing code in the same file, or to other
+formatting to that of any existing code in the same file, or to other

 similar files if you are writing new code. Consistency of layout is
 far more important that the layout itself as it makes reading code
 much easier.
 similar files if you are writing new code. Consistency of layout is
 far more important that the layout itself as it makes reading code
 much easier.


@@ -107,7 +108,7 @@ and why it should be the way it is.
 When you submit patches, the project maintainer has to read them and
 understand them. This is difficult enough at the best of times, and
 misunderstanding patches can lead to them being more difficult to
 When you submit patches, the project maintainer has to read them and
 understand them. This is difficult enough at the best of times, and
 misunderstanding patches can lead to them being more difficult to

-merge. To help wit this, when submitting you should:
+merge. To help with this, when submitting you should:

 
 * Split up large patches into smaller units of functionality.
 * Keep your commit messages relevant to the changes in each individual
 
 * Split up large patches into smaller units of functionality.
 * Keep your commit messages relevant to the changes in each individual