Fixed typos

Author: frantic

docs/Images.md

@@ -15,7 +15,7 @@ As of 0.14 release, React Native provides a unified way of managing images in yo
 <Image source={require('./my-icon.png')} />
 ```
 
-Image name is resolved the same way JS modules are resolved. In the example above the packager will look for `my-icon.png` in the same folder as the component that requires it. Also if you have `my-icon.ios.png` and `my-icon.android.png`, the packager will pick the file depending on the platform you are running on.
+The image name is resolved the same way JS modules are resolved. In the example above the packager will look for `my-icon.png` in the same folder as the component that requires it. Also if you have `my-icon.ios.png` and `my-icon.android.png`, the packager will pick the file depending on the platform you are running on.
 
 You can also use `@2x`, `@3x`, etc. suffix in the file name to provide images for different screen densities. For example, if you have the following file structure:
 
@@ -33,19 +33,19 @@ And `button.js` code contains
 <Image source={require('./img/check.png')} />
 ```
 
-Packager will bundle and server image corresponding to device's screen density, e.g. on iPhone 5s `[email protected]` will be used, on Nexus 5 – `[email protected]`. If there is no image matching screen density, closest best option will be selected.
+Packager will bundle and serve the image corresponding to device's screen density, e.g. on iPhone 5s `[email protected]` will be used, on Nexus 5 – `[email protected]`. If there is no image matching the screen density, the closest best option will be selected.
 
 Here are some benefits that you get:
 
 1. Same system on iOS and Android
 2. Images live in the same folder as your JS code. Components are self-contained.
 3. No global namespace, i.e. you don't have worry about name collisions.
 4. Only the images that are actually used will be packaged into your app.
-5. Adding and changing images doesn't require app recompilation, just refresh simulator as you normally do.
-6. Packager knows image size, no need to duplicate it in the code.
+5. Adding and changing images doesn't require app recompilation, just refresh the simulator as you normally do.
+6. The packager knows the image dimensions, no need to duplicate it in the code.
 7. Images can be distributed via [npm](https://www.npmjs.com/) packages.
 
-Note that in order for this to work, image name in `require` has to be known statically.
+Note that in order for this to work, the image name in `require` has to be known statically.
 
 ```javascript
 // GOOD
@@ -115,7 +115,7 @@ In React Native, one interesting decision is that the `src` attribute is named `
 <Image source={{uri: 'something.jpg'}} />
 ```
 
-On the infrastructure side, the reason is that it allows us to attach metadata to this object. For example if you are using `require('./my-icon.png')`, then we add information about it's actual location and size (don't rely on this fact, it might change in the future!). This is also future proofing, for example we may want to support sprites at some point, instead of outputting `{uri: ...}`, we can output `{uri: ..., crop: {left: 10, top: 50, width: 20, height: 40}}` and transparently support spriting on all the existing call sites.
+On the infrastructure side, the reason is that it allows us to attach metadata to this object. For example if you are using `require('./my-icon.png')`, then we add information about its actual location and size (don't rely on this fact, it might change in the future!). This is also future proofing, for example we may want to support sprites at some point, instead of outputting `{uri: ...}`, we can output `{uri: ..., crop: {left: 10, top: 50, width: 20, height: 40}}` and transparently support spriting on all the existing call sites.
 
 On the user side, this lets you annotate the object with useful attributes such as the dimension of the image in order to compute the size it's going to be displayed in. Feel free to use it as your data structure to store more information about your image.