diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index c01cb7efb3..913c95399b 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -4,7 +4,7 @@ We are open to, and grateful for, any contributions made by the community. By co
 
 ## Reporting Issues and Asking Questions
 
-Before opening an issue, please search the [issue tracker](https://github.com/reactjs/redux/issues) to make sure your issue hasn’t already been reported.
+Before opening an issue, please search the [issue tracker](https://github.com/reactjs/redux/issues) to make sure your issue hasn't already been reported.
 
 ### Bugs and Improvements
 
@@ -12,11 +12,11 @@ We use the issue tracker to keep track of bugs and improvements to Redux itself,
 
 ### Getting Help
 
-**For support or usage questions like “how do I do X with Redux” and “my code doesn’t work”, please search and ask on [StackOverflow with a Redux tag](http://stackoverflow.com/questions/tagged/redux?sort=votes&pageSize=50) first.**
+**For support or usage questions like “how do I do X with Redux” and “my code doesn't work”, please search and ask on [StackOverflow with a Redux tag](http://stackoverflow.com/questions/tagged/redux?sort=votes&pageSize=50) first.**
 
 We ask you to do this because StackOverflow has a much better job at keeping popular questions visible. Unfortunately good answers get lost and outdated on GitHub.
 
-Some questions take a long time to get an answer. **If your question gets closed or you don’t get a reply on StackOverflow for longer than a few days,** we encourage you to post an issue linking to your question. We will close your issue but this will give people watching the repo an opportunity to see your question and reply to it on StackOverflow if they know the answer.
+Some questions take a long time to get an answer. **If your question gets closed or you don't get a reply on StackOverflow for longer than a few days,** we encourage you to post an issue linking to your question. We will close your issue but this will give people watching the repo an opportunity to see your question and reply to it on StackOverflow if they know the answer.
 
 Please be considerate when doing this as this is not the primary purpose of the issue tracker.
 
@@ -89,7 +89,7 @@ npm run test:watch
 
 ### Docs
 
-Improvements to the documentation are always welcome. In the docs we abide by typographic rules, so instead of ' you should use ’. Same goes for “ ” and dashes (—) where appropriate. These rules only apply to the text, not to code blocks.
+Improvements to the documentation are always welcome. In the docs we abide by typographic rules, so instead of ' you should use '. Same goes for “ ” and dashes (—) where appropriate. These rules only apply to the text, not to code blocks.
 
 #### Installing Gitbook
 
@@ -152,7 +152,7 @@ Please visit the [Examples page](http://redux.js.org/docs/introduction/Examples.
 
 ### Sending a Pull Request
 
-For non-trivial changes, please open an issue with a proposal for a new feature or refactoring before starting on the work. We don’t want you to waste your efforts on a pull request that we won’t want to accept.
+For non-trivial changes, please open an issue with a proposal for a new feature or refactoring before starting on the work. We don't want you to waste your efforts on a pull request that we won't want to accept.
 
 On the other hand, sometimes the best way to start a conversation *is* to send a pull request. Use your best judgement!
 
@@ -166,6 +166,6 @@ In general, the contribution workflow looks like this:
 
 Please try to keep your pull request focused in scope and avoid including unrelated commits.
 
-After you have submitted your pull request, we’ll try to get back to you as soon as possible. We may suggest some changes or improvements.
+After you have submitted your pull request, we'll try to get back to you as soon as possible. We may suggest some changes or improvements.
 
 Thank you for contributing!
diff --git a/README.md b/README.md
index b3d56378ce..a4593fbdf8 100644
--- a/README.md
+++ b/README.md
@@ -1,7 +1,7 @@
 # <a href='http://redux.js.org'><img src='https://camo.githubusercontent.com/f28b5bc7822f1b7bb28a96d8d09e7d79169248fc/687474703a2f2f692e696d6775722e636f6d2f4a65567164514d2e706e67' height='60'></a>
 
 Redux is a predictable state container for JavaScript apps.  
-(If you’re looking for a WordPress framework, check out [Redux Framework](https://reduxframework.com/).)
+(If you're looking for a WordPress framework, check out [Redux Framework](https://reduxframework.com/).)
 
 It helps you write applications that behave consistently, run in different environments (client, server, and native), and are easy to test. On top of that, it provides a great developer experience, such as [live code editing combined with a time traveling debugger](https://github.com/gaearon/redux-devtools).
 
@@ -20,7 +20,7 @@ It is tiny (2kB, including dependencies).
 
 ### Testimonials
 
->[“Love what you’re doing with Redux”](https://twitter.com/jingc/status/616608251463909376)  
+>[“Love what you're doing with Redux”](https://twitter.com/jingc/status/616608251463909376)  
 >Jing Chen, creator of Flux
 
 >[“I asked for comments on Redux in FB's internal JS discussion group, and it was universally praised. Really awesome work.”](https://twitter.com/fisherwebdev/status/616286955693682688)  
@@ -47,24 +47,24 @@ npm install --save redux
 ```
 
 This assumes you are using [npm](https://www.npmjs.com/) as your package manager.  
-If you don’t, you can [access these files on npmcdn](https://npmcdn.com/redux/), download them, or point your package manager to them.
+If you don't, you can [access these files on npmcdn](https://npmcdn.com/redux/), download them, or point your package manager to them.
 
 Most commonly people consume Redux as a collection of [CommonJS](http://webpack.github.io/docs/commonjs.html) modules. These modules are what you get when you import `redux` in a [Webpack](http://webpack.github.io), [Browserify](http://browserify.org/), or a Node environment. If you like to live on the edge and use [Rollup](http://rollupjs.org), we support that as well.
 
-If you don’t use a module bundler, it’s also fine. The `redux` npm package includes precompiled production and development [UMD](https://github.com/umdjs/umd) builds in the [`dist` folder](https://npmcdn.com/redux/dist/). They can be used directly without a bundler and are thus compatible with many popular JavaScript module loaders and environments. For example, you can drop a UMD build as a [`<script>` tag](https://npmcdn.com/redux/dist/redux.js) on the page, or [tell Bower to install it](https://github.com/reactjs/redux/pull/1181#issuecomment-167361975). The UMD builds make Redux available as a `window.Redux` global variable.
+If you don't use a module bundler, it's also fine. The `redux` npm package includes precompiled production and development [UMD](https://github.com/umdjs/umd) builds in the [`dist` folder](https://npmcdn.com/redux/dist/). They can be used directly without a bundler and are thus compatible with many popular JavaScript module loaders and environments. For example, you can drop a UMD build as a [`<script>` tag](https://npmcdn.com/redux/dist/redux.js) on the page, or [tell Bower to install it](https://github.com/reactjs/redux/pull/1181#issuecomment-167361975). The UMD builds make Redux available as a `window.Redux` global variable.
 
-The Redux source code is written in ES2015 but we precompile both CommonJS and UMD builds to ES5 so they work in [any modern browser](http://caniuse.com/#feat=es5). You don’t need to use Babel or a module bundler to [get started with Redux](https://github.com/reactjs/redux/blob/master/examples/counter-vanilla/index.html).
+The Redux source code is written in ES2015 but we precompile both CommonJS and UMD builds to ES5 so they work in [any modern browser](http://caniuse.com/#feat=es5). You don't need to use Babel or a module bundler to [get started with Redux](https://github.com/reactjs/redux/blob/master/examples/counter-vanilla/index.html).
 
 #### Complementary Packages
 
-Most likely, you’ll also need [the React bindings](https://github.com/reactjs/react-redux) and [the developer tools](https://github.com/gaearon/redux-devtools).
+Most likely, you'll also need [the React bindings](https://github.com/reactjs/react-redux) and [the developer tools](https://github.com/gaearon/redux-devtools).
 
 ```
 npm install --save react-redux
 npm install --save-dev redux-devtools
 ```
 
-Note that unlike Redux itself, many packages in the Redux ecosystem don’t provide UMD builds, so we recommend using CommonJS module bundlers like [Webpack](http://webpack.github.io) and [Browserify](http://browserify.org/) for the most comfortable development experience.
+Note that unlike Redux itself, many packages in the Redux ecosystem don't provide UMD builds, so we recommend using CommonJS module bundlers like [Webpack](http://webpack.github.io) and [Browserify](http://browserify.org/) for the most comfortable development experience.
 
 ### The Gist
 
@@ -72,7 +72,7 @@ The whole state of your app is stored in an object tree inside a single *store*.
 The only way to change the state tree is to emit an *action*, an object describing what happened.  
 To specify how the actions transform the state tree, you write pure *reducers*.
 
-That’s it!
+That's it!
 
 ```js
 import { createStore } from 'redux'
@@ -105,7 +105,7 @@ function counter(state = 0, action) {
 let store = createStore(counter)
 
 // You can use subscribe() to update the UI in response to state changes.
-// Normally you’d use a view binding library (e.g. React Redux) rather than subscribe() directly.
+// Normally you'd use a view binding library (e.g. React Redux) rather than subscribe() directly.
 // However it can also be handy to persist the current state in the localStorage.
 
 store.subscribe(() =>
@@ -122,9 +122,9 @@ store.dispatch({ type: 'DECREMENT' })
 // 1
 ```
 
-Instead of mutating the state directly, you specify the mutations you want to happen with plain objects called *actions*. Then you write a special function called a *reducer* to decide how every action transforms the entire application’s state.
+Instead of mutating the state directly, you specify the mutations you want to happen with plain objects called *actions*. Then you write a special function called a *reducer* to decide how every action transforms the entire application's state.
 
-If you’re coming from Flux, there is a single important difference you need to understand. Redux doesn’t have a Dispatcher or support many stores. Instead, there is just a single store with a single root reducing function. As your app grows, instead of adding stores, you split the root reducer into smaller reducers independently operating on the different parts of the state tree. This is exactly like there is just one root component in a React app, but it is composed out of many small components.
+If you're coming from Flux, there is a single important difference you need to understand. Redux doesn't have a Dispatcher or support many stores. Instead, there is just a single store with a single root reducing function. As your app grows, instead of adding stores, you split the root reducer into smaller reducers independently operating on the different parts of the state tree. This is exactly like there is just one root component in a React app, but it is composed out of many small components.
 
 This architecture might seem like an overkill for a counter app, but the beauty of this pattern is how well it scales to large and complex apps. It also enables very powerful developer tools, because it is possible to trace every mutation to the action that caused it. You can record user sessions and reproduce them just by replaying every action.
 
@@ -151,7 +151,7 @@ So, what are you waiting for?
 
 #### [Watch the 30 Free Videos!](https://egghead.io/series/getting-started-with-redux)
 
-If you enjoyed my course, consider supporting Egghead by [buying a subscription](https://egghead.io/pricing). Subscribers have access to the source code for the example in every one of my videos, as well as to tons of advanced lessons on other topics, including JavaScript in depth, React, Angular, and more. Many [Egghead instructors](https://egghead.io/instructors) are also open source library authors, so buying a subscription is a nice way to thank them for the work that they’ve done.
+If you enjoyed my course, consider supporting Egghead by [buying a subscription](https://egghead.io/pricing). Subscribers have access to the source code for the example in every one of my videos, as well as to tons of advanced lessons on other topics, including JavaScript in depth, React, Angular, and more. Many [Egghead instructors](https://egghead.io/instructors) are also open source library authors, so buying a subscription is a nice way to thank them for the work that they've done.
 
 ### Documentation
 
@@ -178,7 +178,7 @@ For PDF, ePub, and MOBI exports for offline reading, and instructions on how to
 * [Universal](http://redux.js.org/docs/introduction/Examples.html#universal) ([source](https://github.com/reactjs/redux/tree/master/examples/universal))
 * [Real World](http://redux.js.org/docs/introduction/Examples.html#real-world) ([source](https://github.com/reactjs/redux/tree/master/examples/real-world))
 
-If you’re new to the NPM ecosystem and have troubles getting a project up and running, or aren’t sure where to paste the gist above, check out [simplest-redux-example](https://github.com/jackielii/simplest-redux-example) that uses Redux together with React and Browserify.
+If you're new to the NPM ecosystem and have troubles getting a project up and running, or aren't sure where to paste the gist above, check out [simplest-redux-example](https://github.com/jackielii/simplest-redux-example) that uses Redux together with React and Browserify.
 
 ### Discussion
 
diff --git a/docs/FAQ.md b/docs/FAQ.md
index 8c1f1a7e89..4f80f8c7db 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -10,7 +10,7 @@
   - [How do I share state between two reducers? Do I have to use combineReducers?](#reducers-share-state) 
   - [Do I have to use the switch statement to handle actions?](#reducers-use-switch) 
 - **Organizing State**
-  - [Do I have to put all my state into Redux? Should I ever use React’s setState()?](#organizing-state-only-redux-state) 
+  - [Do I have to put all my state into Redux? Should I ever use React's setState()?](#organizing-state-only-redux-state) 
   - [Can I put functions, promises, or other non-serializable items in my store state?](#organizing-state-non-serializable) 
   - [How do I organize nested or duplicate data in my state?](#organizing-state-nested-data) 
 - **Store Setup**
@@ -27,15 +27,15 @@
   - [How should I split my logic between reducers and action creators? Where should my “business logic” go?](#structure-business-logic) 
 - **Performance**
   - [How well does Redux “scale” in terms of performance and architecture?](#performance-scaling)
-  - [Won’t calling “all my reducers” for each action be slow?](#performance-all-reducers)
-  - [Do I have to deep-clone my state in a reducer? Isn’t copying my state going to be slow?](#performance-clone-state)
+  - [Won't calling “all my reducers” for each action be slow?](#performance-all-reducers)
+  - [Do I have to deep-clone my state in a reducer? Isn't copying my state going to be slow?](#performance-clone-state)
   - [How can I reduce the number of store update events?](#performance-update-events)
   - [Will having “one state tree” cause memory problems? Will dispatching many actions take up memory?](#performance-state-memory)
 - **React Redux**
-  - [Why isn’t my component re-rendering, or my mapStateToProps running?](#react-not-rerendering)
+  - [Why isn't my component re-rendering, or my mapStateToProps running?](#react-not-rerendering)
   - [Why is my component re-rendering too often?](#react-rendering-too-often)
   - [How can I speed up my mapStateToProps?](#react-mapstate-speed)
-  - [Why don’t I have this.props.dispatch available in my connected component?](#react-props-dispatch)
+  - [Why don't I have this.props.dispatch available in my connected component?](#react-props-dispatch)
   - [Should I only connect my top component, or can I connect multiple components in my tree?](#react-multiple-components)
 - **Miscellaneous**
   - [Are there any larger, “real” Redux projects?](#miscellaneous-real-projects)
@@ -49,13 +49,13 @@
 
 Pete Hunt, one of the early contributors to React, says:
 
-> You’ll know when you need Flux. If you aren’t sure if you need it, you don’t need it.
+> You'll know when you need Flux. If you aren't sure if you need it, you don't need it.
 
 Similarly, Dan Abramov, one of the creators of Redux, says:
 
-> I would like to amend this: don’t use Redux until you have problems with vanilla React.
+> I would like to amend this: don't use Redux until you have problems with vanilla React.
 
-In general, use Redux when you have reasonable amounts of data changing over time, you need a single source of truth, and you find that approaches like keeping everything in a top-level React component’s state are no longer sufficient.
+In general, use Redux when you have reasonable amounts of data changing over time, you need a single source of truth, and you find that approaches like keeping everything in a top-level React component's state are no longer sufficient.
 
 #### Further information
 
@@ -64,7 +64,7 @@ In general, use Redux when you have reasonable amounts of data changing over tim
 
 **Discussions**
 - [React How-To](https://github.com/petehunt/react-howto)
-- [Twitter: Don’t use Redux until...](https://twitter.com/dan_abramov/status/699241546248536064)
+- [Twitter: Don't use Redux until...](https://twitter.com/dan_abramov/status/699241546248536064)
 - [The Case for Flux](https://medium.com/swlh/the-case-for-flux-379b7d1982c6)
 - [Stack Overflow: Why use Redux over Facebook Flux?](http://stackoverflow.com/questions/32461229/why-use-redux-over-facebook-flux)
 - [Stack Overflow: Why should I use Redux in this example?](http://stackoverflow.com/questions/35675339/why-should-i-use-redux-in-this-example)
@@ -82,7 +82,7 @@ Redux is originally written in ES6 and transpiled for production into ES5 with W
 
 > The new Counter Vanilla example is aimed to dispel the myth that Redux requires Webpack, React, hot reloading, sagas, action creators, constants, Babel, npm, CSS modules, decorators, fluent Latin, an Egghead subscription, a PhD, or an Exceeds Expectations O.W.L. level.
 
->Nope, it’s just HTML, some artisanal `<script>` tags, and plain old DOM manipulation. Enjoy!
+>Nope, it's just HTML, some artisanal `<script>` tags, and plain old DOM manipulation. Enjoy!
 
 
 ## Reducers
@@ -90,7 +90,7 @@ Redux is originally written in ES6 and transpiled for production into ES5 with W
 <a id="reducers-share-state"></a>
 ### How do I share state between two reducers? Do I have to use `combineReducers`?
 
-The suggested structure for a Redux store is to split the state object into multiple “slices” or “domains” by key, and provide a separate reducer function to manage each individual data slice. This is similar to how the standard Flux pattern has multiple independent stores, and Redux provides the [`combineReducers`](api/combineReducers.md) utility function to make this pattern easier. However, it’s important to note that `combineReducers` is *not* required—it is simply a utility function for the common use case of having a single reducer function per state slice, with plain JavaScript objects for the data.
+The suggested structure for a Redux store is to split the state object into multiple “slices” or “domains” by key, and provide a separate reducer function to manage each individual data slice. This is similar to how the standard Flux pattern has multiple independent stores, and Redux provides the [`combineReducers`](api/combineReducers.md) utility function to make this pattern easier. However, it's important to note that `combineReducers` is *not* required—it is simply a utility function for the common use case of having a single reducer function per state slice, with plain JavaScript objects for the data.
 
 Many users later want to try to share data between two reducers, but find that `combineReducers` does not allow them to do so. There are several approaches that can be used:
 
@@ -115,7 +115,7 @@ In general, remember that reducers are just functions—you can organize them an
 <a id="reducers-use-switch"></a>
 ### Do I have to use the `switch` statement to handle actions?
 
-No. You are welcome to use any approach you’d like to respond to an action in a reducer. The `switch` statement is the most common approach, but it’s fine to use `if` statements, a lookup table of functions, or to create a function that abstracts this away.
+No. You are welcome to use any approach you'd like to respond to an action in a reducer. The `switch` statement is the most common approach, but it's fine to use `if` statements, a lookup table of functions, or to create a function that abstracts this away.
 
 #### Further information
 
@@ -130,9 +130,9 @@ No. You are welcome to use any approach you’d like to respond to an action in
 ## Organizing State
 
 <a id="organizing-state-only-redux-state"></a>
-### Do I have to put all my state into Redux? Should I ever use React’s `setState()`?
+### Do I have to put all my state into Redux? Should I ever use React's `setState()`?
 
-There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component’s internal state. Find a balance that works for you, and go with it.
+There is no “right” answer for this. Some users prefer to keep every single piece of data in Redux, to maintain a fully serializable and controlled version of their application at all times. Others prefer to keep non-critical or UI state, such as “is this dropdown currently open”, inside a component's internal state. Find a balance that works for you, and go with it.
 
 There are a number of community packages that implement various approaches for storing per-component state in a Redux store instead, such as [redux-ui](https://github.com/tonyhb/redux-ui), [redux-component](https://github.com/tomchentw/redux-component), [redux-react-local](https://github.com/threepointone/redux-react-local), and more.
 
@@ -150,7 +150,7 @@ There are a number of community packages that implement various approaches for s
 <a id="organizing-state-non-serializable"></a>
 ### Can I put functions, promises, or other non-serializable items in my store state?
 
-It is highly recommended that you only put plain serializable objects, arrays, and primitives into your store. It’s *technically* possible to insert non-serializable items into the store, but doing so can break the ability to persist and rehydrate the contents of a store.
+It is highly recommended that you only put plain serializable objects, arrays, and primitives into your store. It's *technically* possible to insert non-serializable items into the store, but doing so can break the ability to persist and rehydrate the contents of a store.
 
 #### Further information
 
@@ -193,11 +193,11 @@ Some valid reasons for using multiple stores in Redux might include:
 * Solving a performance issue caused by too frequent updates of some part of the state, when confirmed by profiling the app.
 * Isolating a Redux app as a component in a bigger application, in which case you might want to create a store per root component instance.
 
-However, creating new stores shouldn’t be your first instinct, especially if you come from a Flux background. Try reducer composition first, and only use multiple stores if it doesn’t solve your problem.
+However, creating new stores shouldn't be your first instinct, especially if you come from a Flux background. Try reducer composition first, and only use multiple stores if it doesn't solve your problem.
 
 Similarly, while you *can* reference your store instance by importing it directly, this is not a recommended pattern in Redux. If you create a store instance and export it from a module, it will become a singleton. This means it will be harder to isolate a Redux app as a component of a larger app, if this is ever necessary, or to enable server rendering, because on the server you want to create separate store instances for every request.
 
-With [React Redux](https://github.com/rackt/react-redux), the wrapper classes generated by the `connect()` function do actually look for `props.store` if it exists, but it’s best if you wrap your root component in `<Provider store={store}>` and let React Redux worry about passing the store down. This way components don’t need to worry about importing a store module, and isolating a Redux app or enabling server rendering is much easier to do later.
+With [React Redux](https://github.com/rackt/react-redux), the wrapper classes generated by the `connect()` function do actually look for `props.store` if it exists, but it's best if you wrap your root component in `<Provider store={store}>` and let React Redux worry about passing the store down. This way components don't need to worry about importing a store module, and isolating a Redux app or enabling server rendering is much easier to do later.
 
 #### Further information
 
@@ -255,11 +255,11 @@ The new state is not passed to the listeners in order to simplify implementing s
 <a id="actions-string-constants"></a>
 ### Why should `type` be a string, or at least serializable? Why should my action types be constants?
 
-As with state, serializable actions enable several of Redux’s defining features, such as time travel debugging, and recording and replaying actions. Using something like a `Symbol` for the `type` value or using `instanceof` checks for actions themselves would break that. Strings are serializable and easily self-descriptive, and so are a better choice. Note that it *is* okay to use Symbols, Promises, or other non-serializable values in an action if the action is intended for use by middleware. Actions only need to be serializable by the time they actually reach the store and are passed to the reducers.
+As with state, serializable actions enable several of Redux's defining features, such as time travel debugging, and recording and replaying actions. Using something like a `Symbol` for the `type` value or using `instanceof` checks for actions themselves would break that. Strings are serializable and easily self-descriptive, and so are a better choice. Note that it *is* okay to use Symbols, Promises, or other non-serializable values in an action if the action is intended for use by middleware. Actions only need to be serializable by the time they actually reach the store and are passed to the reducers.
 
-We can’t reliably enforce serializable actions for performance reasons, so Redux only checks that every action is a plain object, and that the `type` is defined. The rest is up to you, but you might find that keeping everything serializable helps debug and reproduce issues.
+We can't reliably enforce serializable actions for performance reasons, so Redux only checks that every action is a plain object, and that the `type` is defined. The rest is up to you, but you might find that keeping everything serializable helps debug and reproduce issues.
 
-Encapsulating and centralizing commonly used pieces of code is a key concept in programming. While it is certainly possible to manually create action objects everywhere, and write each `type` value by hand, defining reusable constants makes maintaining code easier. If you put constants in a separate file, you can [check your `import` statements against typos](https://www.npmjs.com/package/eslint-plugin-import) so you can’t accidentally use the wrong string.
+Encapsulating and centralizing commonly used pieces of code is a key concept in programming. While it is certainly possible to manually create action objects everywhere, and write each `type` value by hand, defining reusable constants makes maintaining code easier. If you put constants in a separate file, you can [check your `import` statements against typos](https://www.npmjs.com/package/eslint-plugin-import) so you can't accidentally use the wrong string.
 
 #### Further information
 
@@ -297,7 +297,7 @@ This is a long and complex topic, with a wide variety of opinions on how code sh
 
 Any meaningful web app needs to execute complex logic, usually including asynchronous work such as making AJAX requests. That code is no longer purely a function of its inputs, and the interactions with the outside world are known as [“side effects”](https://en.wikipedia.org/wiki/Side_effect_%28computer_science%29)
 
-Redux is inspired by functional programming, and out of the box, has no place for side effects to be executed. In particular, reducer functions *must* always be pure functions of `(state, action) => newState`. However, Redux’s middleware makes it possible to intercept dispatched actions and add additional complex behavior around them, including side effects.
+Redux is inspired by functional programming, and out of the box, has no place for side effects to be executed. In particular, reducer functions *must* always be pure functions of `(state, action) => newState`. However, Redux's middleware makes it possible to intercept dispatched actions and add additional complex behavior around them, including side effects.
 
 In general, Redux suggests that code with side effects should be part of the action creation process. While that logic *can* be performed inside of a UI component, it generally makes sense to extract that logic into a reusable function so that the same logic can be called from multiple places—in other words, an action creator function.
 
@@ -330,11 +330,11 @@ The simplest and most common way to do this is to add the [Redux Thunk](https://
 <a id="actions-multiple-actions"></a>
 ### Should I dispatch multiple actions in a row from one action creator?
 
-There’s no specific rule for how you should structure your actions. Using an async middleware like Redux Thunk certainly enables scenarios such as dispatching multiple distinct but related actions in a row, dispatching actions to represent progression of an AJAX request, dispatching actions conditionally based on state, or even dispatching an action and checking the updated state immediately afterwards.
+There's no specific rule for how you should structure your actions. Using an async middleware like Redux Thunk certainly enables scenarios such as dispatching multiple distinct but related actions in a row, dispatching actions to represent progression of an AJAX request, dispatching actions conditionally based on state, or even dispatching an action and checking the updated state immediately afterwards.
 
-In general, ask if these actions are related but independent, or should actually be represented as one action. Do what makes sense for your own situation but try to balance the readability of reducers with readability of the action log. For example, an action that includes the whole new state tree would make your reducer a one-liner, but the downside is now you have no history of *why* the changes are happening, so debugging gets really difficult. On the other hand, if you emit actions in a loop to keep them granular, it’s a sign that you might want to introduce a new action type that is handled in a different way.
+In general, ask if these actions are related but independent, or should actually be represented as one action. Do what makes sense for your own situation but try to balance the readability of reducers with readability of the action log. For example, an action that includes the whole new state tree would make your reducer a one-liner, but the downside is now you have no history of *why* the changes are happening, so debugging gets really difficult. On the other hand, if you emit actions in a loop to keep them granular, it's a sign that you might want to introduce a new action type that is handled in a different way.
 
-Try to avoid dispatching several times synchronously in a row in the places where you’re concerned about performance. If you use React, note that you can improve performance of multiple synchronous dispatches by wrapping them in `ReactDOM.unstable_batchedUpdates()`, but this API is experimental and may be removed in any React release so don’t rely on it too heavily. Take a look at [redux-batched-actions](https://github.com/tshelburne/redux-batched-actions) that lets you dispatch several actions as if it was one and “unpack” them in the reducer, and [redux-batched-subscribe](https://github.com/tappleby/redux-batched-subscribe) which lets you debounce subscriber calls for multiple dispatches.
+Try to avoid dispatching several times synchronously in a row in the places where you're concerned about performance. If you use React, note that you can improve performance of multiple synchronous dispatches by wrapping them in `ReactDOM.unstable_batchedUpdates()`, but this API is experimental and may be removed in any React release so don't rely on it too heavily. Take a look at [redux-batched-actions](https://github.com/tshelburne/redux-batched-actions) that lets you dispatch several actions as if it was one and “unpack” them in the reducer, and [redux-batched-subscribe](https://github.com/tappleby/redux-batched-subscribe) which lets you debounce subscriber calls for multiple dispatches.
 
 #### Further information
 
@@ -357,7 +357,7 @@ Since Redux is just a data store library, it has no direct opinion on how your p
 - Domain-style: separate folders per feature or domain, possibly with sub-folders per file type
 - “Ducks”: similar to domain style, but explicitly tying together actions and reducers, often by defining them in the same file
 
-It’s generally suggested that selectors are defined alongside reducers and exported, and then reused elsewhere (such as in `mapStateToProps` functions, in async action creators, or sagas) to colocate all the code that knows about the actual shape of the state tree in the reducer files.
+It's generally suggested that selectors are defined alongside reducers and exported, and then reused elsewhere (such as in `mapStateToProps` functions, in async action creators, or sagas) to colocate all the code that knows about the actual shape of the state tree in the reducer files.
 
 #### Further information
 
@@ -375,7 +375,7 @@ It’s generally suggested that selectors are defined alongside reducers and exp
 <a id="structure-business-logic"></a>
 ### How should I split my logic between reducers and action creators? Where should my “business logic” go?
 
-There’s no single clear answer to exactly what pieces of logic should go in a reducer or an action creator. Some developers prefer to have “fat” action creators, with “thin” reducers that simply take the data in an action and blindly merge it into the corresponding state. Others try to emphasize keeping actions as small as possible, and minimize the usage of `getState()` in an action creator.
+There's no single clear answer to exactly what pieces of logic should go in a reducer or an action creator. Some developers prefer to have “fat” action creators, with “thin” reducers that simply take the data in an action and blindly merge it into the corresponding state. Others try to emphasize keeping actions as small as possible, and minimize the usage of `getState()` in an action creator.
 
 This comment sums up the dichotomy nicely:
 
@@ -397,9 +397,9 @@ Find the balance between these two extremes, and you will master Redux.
 <a id="performance-scaling"></a>
 ### How well does Redux “scale” in terms of performance and architecture? 
 
-While there’s no single definitive answer to this, most of the time this should not be a concern in either case.
+While there's no single definitive answer to this, most of the time this should not be a concern in either case.
 
-The work done by Redux generally falls into a few areas: processing actions in middleware and reducers (including object duplication for immutable updates), notifying subscribers after actions are dispatched, and updating UI components based on the state changes. While it’s certainly *possible* for each of these to become a performance concern in sufficiently complex situations, there’s nothing inherently slow or inefficient about how Redux is implemented. In fact, React Redux in particular is heavily optimized to cut down on unnecessary re-renders.
+The work done by Redux generally falls into a few areas: processing actions in middleware and reducers (including object duplication for immutable updates), notifying subscribers after actions are dispatched, and updating UI components based on the state changes. While it's certainly *possible* for each of these to become a performance concern in sufficiently complex situations, there's nothing inherently slow or inefficient about how Redux is implemented. In fact, React Redux in particular is heavily optimized to cut down on unnecessary re-renders.
 
 As for architecture, anecdotal evidence is that Redux works well for varying project and team sizes. Redux is currently used by hundreds of companies and thousands of developers, with several hundred thousand monthly installations from NPM. One developer reported:
 
@@ -416,11 +416,11 @@ As for architecture, anecdotal evidence is that Redux works well for varying pro
 - [Twitter: Redux scaling](https://twitter.com/NickPresta/status/684058236828266496)
 
 <a id="performance-all-reducers"></a>
-### Won’t calling “all my reducers” for each action be slow?
+### Won't calling “all my reducers” for each action be slow?
 
-It’s important to note that a Redux store really only has a single reducer function. The store passes the current state and dispatched action to that one reducer function, and lets the reducer handle things appropriately.
+It's important to note that a Redux store really only has a single reducer function. The store passes the current state and dispatched action to that one reducer function, and lets the reducer handle things appropriately.
 
-Obviously, trying to handle every possible action in a single function does not scale well, simply in terms of function size and readability, so it makes sense to split the actual work into separate functions that can be called by the top-level reducer. In particular, the common suggested pattern is to have a separate sub-reducer function that is responsible for managing updates to a particular slice of state at a specific key. The `combineReducers()` that comes with Redux is one of the many possible ways to achieve this. It’s also highly suggested to keep your store state as flat and as normalized as possible. Ultimately, though, you are in charge of organizing your reducer logic any way you want.
+Obviously, trying to handle every possible action in a single function does not scale well, simply in terms of function size and readability, so it makes sense to split the actual work into separate functions that can be called by the top-level reducer. In particular, the common suggested pattern is to have a separate sub-reducer function that is responsible for managing updates to a particular slice of state at a specific key. The `combineReducers()` that comes with Redux is one of the many possible ways to achieve this. It's also highly suggested to keep your store state as flat and as normalized as possible. Ultimately, though, you are in charge of organizing your reducer logic any way you want.
 
 However, even if you happen to have many different independent sub-reducers, and even have deeply nested state, reducer speed is unlikely to be a problem. JavaScript engines are capable of running a very large number of function calls per second, and most of your sub-reducers are probably just using a `switch` statement and returning the existing state by default in response to most actions.
 
@@ -435,13 +435,13 @@ If you actually are concerned about reducer performance, you can use a utility s
 - [Stack Overflow: How does Redux deal with deeply nested models?](http://stackoverflow.com/questions/34494866/how-does-redux-deals-with-deeply-nested-models/34495397)
 
 <a id="performance-clone-state"></a>
-### Do I have to deep-clone my state in a reducer? Isn’t copying my state going to be slow?
+### Do I have to deep-clone my state in a reducer? Isn't copying my state going to be slow?
 
 Immutably updating state generally means making shallow copies, not deep copies. Shallow copies are much faster than deep copies, because fewer objects and fields have to be copied, and it effectively comes down to moving some pointers around.
 
-However, you *do* need to create a copied and updated object for each level of nesting that is affected. Although that shouldn’t be particularly expensive, it’s another good reason why you should keep your state normalized and shallow if possible.
+However, you *do* need to create a copied and updated object for each level of nesting that is affected. Although that shouldn't be particularly expensive, it's another good reason why you should keep your state normalized and shallow if possible.
 
-> Common Redux misconception: you need to deeply clone the state. Reality: if something inside doesn’t change, keep its reference the same!
+> Common Redux misconception: you need to deeply clone the state. Reality: if something inside doesn't change, keep its reference the same!
 
 #### Further information
 
@@ -484,11 +484,11 @@ Redux does not store a history of actions itself. However, the Redux DevTools do
 ## React Redux
 
 <a id="react-not-rerendering"></a>
-### Why isn’t my component re-rendering, or my mapStateToProps running?
+### Why isn't my component re-rendering, or my mapStateToProps running?
 
 Accidentally mutating or modifying your state directly is by far the most common reason why components do not re-render after an action has been dispatched. Redux expects that your reducers will update their state “immutably”, which effectively means always making copies of your data, and applying your changes to the copies. If you return the same object from a reducer, Redux assumes that nothing has been changed, even if you made changes to its contents. Similarly, React Redux tries to improve performance by doing shallow equality reference checks on incoming props in `shouldComponentUpdate`, and if all references are the same, returns `false` to skip actually updating your original component.
 
-It’s important to remember that whenever you update a nested value, you must also return new copies of anything above it in your state tree. If you have `state.a.b.c.d`, and you want to make an update to `d`, you would also need to return new copies of `c`, `b`, `a`, and `state`. This [state tree mutation diagram](http://arqex.com/wp-content/uploads/2015/02/trees.png) demonstrates how a change deep in a tree requires changes all the way up.
+It's important to remember that whenever you update a nested value, you must also return new copies of anything above it in your state tree. If you have `state.a.b.c.d`, and you want to make an update to `d`, you would also need to return new copies of `c`, `b`, `a`, and `state`. This [state tree mutation diagram](http://arqex.com/wp-content/uploads/2015/02/trees.png) demonstrates how a change deep in a tree requires changes all the way up.
 
 Note that “updating data immutably” does *not* mean that you must use [Immutable.js](https://facebook.github.io/immutable-js/), although that is certainly an option. You can do immutable updates to plain JS objects and arrays using several different approaches:
 
@@ -528,7 +528,7 @@ Even though the array might contain the exact same object references each time,
 
 The extra re-renders could be resolved by saving the array of objects into the state using a reducer, caching the mapped array using [Reselect](https://github.com/reactjs/reselect), or implementing `shouldComponentUpdate` in the component by hand and doing a more in-depth props comparison using a function such as `_.isEqual`. Be careful to not make your custom `shouldComponentUpdate()` more expensive than the rendering itself! Always use a profiler to check your assumptions about performance.
 
-For non-connected components, you may want to check what props are being passed in. A common issue is having a parent component re-bind a callback inside its render function, like `<Child onClick={this.handleClick.bind(this)} />`. That creates a new function reference every time the parent re-renders. It’s generally good practice to only bind callbacks once in the parent component’s constructor.
+For non-connected components, you may want to check what props are being passed in. A common issue is having a parent component re-bind a callback inside its render function, like `<Child onClick={this.handleClick.bind(this)} />`. That creates a new function reference every time the parent re-renders. It's generally good practice to only bind callbacks once in the parent component's constructor.
 
 #### Further information
 
@@ -540,7 +540,7 @@ For non-connected components, you may want to check what props are being passed
 <a id="react-mapstate-speed"></a>
 ### How can I speed up my `mapStateToProps`?
 
-While React Redux does work to minimize the number of times that your `mapStateToProps` function is called, it’s still a good idea to ensure that your `mapStateToProps` runs quickly and also minimizes the amount of work it does. The common recommended approach is to create memoized “selector” functions using [Reselect](https://github.com/reactjs/reselect). These selectors can be combined and composed together, and selectors later in a pipeline will only run if their inputs have changed. This means you can create selectors that do things like filtering or sorting, and ensure that the real work only happens if needed.
+While React Redux does work to minimize the number of times that your `mapStateToProps` function is called, it's still a good idea to ensure that your `mapStateToProps` runs quickly and also minimizes the amount of work it does. The common recommended approach is to create memoized “selector” functions using [Reselect](https://github.com/reactjs/reselect). These selectors can be combined and composed together, and selectors later in a pipeline will only run if their inputs have changed. This means you can create selectors that do things like filtering or sorting, and ensure that the real work only happens if needed.
 
 #### Further information
 
@@ -552,9 +552,9 @@ While React Redux does work to minimize the number of times that your `mapStateT
 - [Reselect #47: Memoizing Hierarchical Selectors](https://github.com/reactjs/reselect/issues/47)
 
 <a id="react-props-dispatch"></a>
-### Why don’t I have `this.props.dispatch` available in my connected component?
+### Why don't I have `this.props.dispatch` available in my connected component?
 
-The `connect()` function takes two primary arguments, both optional. The first, `mapStateToProps`, is a function you provide to pull data from the store when it changes, and pass those values as props to your component. The second, `mapDispatchToProps`, is a function you provide to make use of the store’s `dispatch` function, usually by creating pre-bound versions of action creators that will automatically dispatch their actions as soon as they are called.
+The `connect()` function takes two primary arguments, both optional. The first, `mapStateToProps`, is a function you provide to pull data from the store when it changes, and pass those values as props to your component. The second, `mapDispatchToProps`, is a function you provide to make use of the store's `dispatch` function, usually by creating pre-bound versions of action creators that will automatically dispatch their actions as soon as they are called.
 
 If you do not provide your own `mapDispatchToProps` function when calling `connect()`, React Redux will provide a default version, which simply returns the `dispatch` function as a prop. That means that if you *do* provide your own function, `dispatch` is *not* automatically provided.  If you still want it available as a prop, you need to explicitly return it yourself in your `mapDispatchToProps` implementation.
 
@@ -576,7 +576,7 @@ Early Redux documentation advised that you should only have a few connected comp
 
 The current suggested best practice is to categorize your components as “presentational” or “container” components, and extract a connected container component wherever it makes sense:
 
-> Emphasizing “one container component at the top” in Redux examples was a mistake. Don’t take this as a maxim. Try to keep your presentation components separate. Create container components by connecting them when it’s convenient. Whenever you feel like you’re duplicating code in parent components to provide data for same kinds of children, time to extract a container. Generally as soon as you feel a parent knows too much about “personal” data or actions of its children, time to extract a container.
+> Emphasizing “one container component at the top” in Redux examples was a mistake. Don't take this as a maxim. Try to keep your presentation components separate. Create container components by connecting them when it's convenient. Whenever you feel like you're duplicating code in parent components to provide data for same kinds of children, time to extract a container. Generally as soon as you feel a parent knows too much about “personal” data or actions of its children, time to extract a container.
 
 In general, try to find a balance between understandable data flow and areas of responsibility with your components.
 
diff --git a/docs/Glossary.md b/docs/Glossary.md
index 9b8ed71ab5..d2b6398238 100644
--- a/docs/Glossary.md
+++ b/docs/Glossary.md
@@ -10,7 +10,7 @@ type State = any
 
 *State* (also called the *state tree*) is a broad term, but in the Redux API it usually refers to the single state value that is managed by the store and returned by [`getState()`](api/Store.md#getState). It represents the entire state of a Redux application, which is often a deeply nested object.
 
-By convention, the top-level state is an object or some other key-value collection like a Map, but technically it can be any type. Still, you should do your best to keep the state serializable. Don’t put anything inside it that you can’t easily turn into JSON.
+By convention, the top-level state is an object or some other key-value collection like a Map, but technically it can be any type. Still, you should do your best to keep the state serializable. Don't put anything inside it that you can't easily turn into JSON.
 
 ## Action
 
@@ -20,9 +20,9 @@ type Action = Object
 
 An *action* is a plain object that represents an intention to change the state. Actions are the only way to get data into the store. Any data, whether from UI events, network callbacks, or other sources such as WebSockets needs to eventually be dispatched as actions.
 
-Actions must have a `type` field that indicates the type of action being performed. Types can be defined as constants and imported from another module. It’s better to use strings for `type` than [Symbols](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Symbol) because strings are serializable.
+Actions must have a `type` field that indicates the type of action being performed. Types can be defined as constants and imported from another module. It's better to use strings for `type` than [Symbols](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Symbol) because strings are serializable.
 
-Other than `type`, the structure of an action object is really up to you. If you’re interested, check out [Flux Standard Action](https://github.com/acdlite/flux-standard-action) for recommendations on how actions should be constructed.
+Other than `type`, the structure of an action object is really up to you. If you're interested, check out [Flux Standard Action](https://github.com/acdlite/flux-standard-action) for recommendations on how actions should be constructed.
 
 See also [async action](#async-action) below.
 
@@ -53,7 +53,7 @@ A *dispatching function* (or simply *dispatch function*) is a function that acce
 
 We must distinguish between dispatching functions in general and the base [`dispatch`](api/Store.md#dispatch) function provided by the store instance without any middleware.
 
-The base dispatch function *always* synchronously sends an action to the store’s reducer, along with the previous state returned by the store, to calculate a new state. It expects actions to be plain objects ready to be consumed by the reducer.
+The base dispatch function *always* synchronously sends an action to the store's reducer, along with the previous state returned by the store, to calculate a new state. It expects actions to be plain objects ready to be consumed by the reducer.
 
 [Middleware](#middleware) wraps the base dispatch function. It allows the dispatch function to handle [async actions](#async-action) in addition to actions. Middleware may transform, delay, ignore, or otherwise interpret actions or async actions before passing them to the next middleware. See below for more information.
 
@@ -65,7 +65,7 @@ type ActionCreator = (...args: any) => Action | AsyncAction
 
 An *action creator* is, quite simply, a function that creates an action. Do not confuse the two terms—again, an action is a payload of information, and an action creator is a factory that creates an action.
 
-Calling an action creator only produces an action, but does not dispatch it. You need to call the store’s [`dispatch`](api/Store.md#dispatch) function to actually cause the mutation. Sometimes we say *bound action creators* to mean functions that call an action creator and immediately dispatch its result to a specific store instance.
+Calling an action creator only produces an action, but does not dispatch it. You need to call the store's [`dispatch`](api/Store.md#dispatch) function to actually cause the mutation. Sometimes we say *bound action creators* to mean functions that call an action creator and immediately dispatch its result to a specific store instance.
 
 If an action creator needs to read the current state, perform an API call, or cause a side effect, like a routing transition, it should return an [async action](#async-action) instead of an action.
 
@@ -101,13 +101,13 @@ type Store = {
 }
 ```
 
-A store is an object that holds the application’s state tree.  
+A store is an object that holds the application's state tree.  
 There should only be a single store in a Redux app, as the composition happens on the reducer level.
 
 - [`dispatch(action)`](api/Store.md#dispatch) is the base dispatch function described above.
 - [`getState()`](api/Store.md#getState) returns the current state of the store.
 - [`subscribe(listener)`](api/Store.md#subscribe) registers a function to be called on state changes.
-- [`replaceReducer(nextReducer)`](api/Store.md#replaceReducer) can be used to implement hot reloading and code splitting. Most likely you won’t use it.
+- [`replaceReducer(nextReducer)`](api/Store.md#replaceReducer) can be used to implement hot reloading and code splitting. Most likely you won't use it.
 
 See the complete [store API reference](api/Store.md#dispatch) for more details.
 
@@ -131,4 +131,4 @@ Store enhancers are much the same concept as higher-order components in React, w
 
 Because a store is not an instance, but rather a plain-object collection of functions, copies can be easily created and modified without mutating the original store. There is an example in [`compose`](api/compose.md) documentation demonstrating that.
 
-Most likely you’ll never write a store enhancer, but you may use the one provided by the [developer tools](https://github.com/gaearon/redux-devtools). It is what makes time travel possible without the app being aware it is happening. Amusingly, the [Redux middleware implementation](api/applyMiddleware.md) is itself a store enhancer.
+Most likely you'll never write a store enhancer, but you may use the one provided by the [developer tools](https://github.com/gaearon/redux-devtools). It is what makes time travel possible without the app being aware it is happening. Amusingly, the [Redux middleware implementation](api/applyMiddleware.md) is itself a store enhancer.
diff --git a/docs/Troubleshooting.md b/docs/Troubleshooting.md
index 1bf1f703d2..da866d96b9 100644
--- a/docs/Troubleshooting.md
+++ b/docs/Troubleshooting.md
@@ -9,9 +9,9 @@ Sometimes, you are trying to dispatch an action, but your view does not update.
 
 #### Never mutate reducer arguments
 
-It is tempting to modify the `state` or `action` passed to you by Redux. Don’t do this!
+It is tempting to modify the `state` or `action` passed to you by Redux. Don't do this!
 
-Redux assumes that you never mutate the objects it gives to you in the reducer. **Every single time, you must return the new state object.** Even if you don’t use a library like [Immutable](https://facebook.github.io/immutable-js/), you need to completely avoid mutation.
+Redux assumes that you never mutate the objects it gives to you in the reducer. **Every single time, you must return the new state object.** Even if you don't use a library like [Immutable](https://facebook.github.io/immutable-js/), you need to completely avoid mutation.
 
 Immutability is what lets [react-redux](https://github.com/gaearon/react-redux) efficiently subscribe to fine-grained updates of your state. It also enables great developer experience features such as time travel with [redux-devtools](http://github.com/gaearon/redux-devtools).
 
@@ -68,7 +68,7 @@ function todos(state = [], action) {
 }
 ```
 
-It’s more code, but it’s exactly what makes Redux predictable and efficient. If you want to have less code, you can use a helper like [`React.addons.update`](https://facebook.github.io/react/docs/update.html) to write immutable transformations with a terse syntax:
+It's more code, but it's exactly what makes Redux predictable and efficient. If you want to have less code, you can use a helper like [`React.addons.update`](https://facebook.github.io/react/docs/update.html) to write immutable transformations with a terse syntax:
 
 ```js
 // Before:
@@ -91,9 +91,9 @@ return update(state, {
 })
 ```
 
-Finally, to update objects, you’ll need something like `_.extend` from Underscore, or better, an [`Object.assign`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) polyfill.
+Finally, to update objects, you'll need something like `_.extend` from Underscore, or better, an [`Object.assign`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) polyfill.
 
-Make sure that you use `Object.assign` correctly. For example, instead of returning something like `Object.assign(state, newData)` from your reducers, return `Object.assign({}, state, newData)`. This way you don’t override the previous `state`.
+Make sure that you use `Object.assign` correctly. For example, instead of returning something like `Object.assign(state, newData)` from your reducers, return `Object.assign({}, state, newData)`. This way you don't override the previous `state`.
 
 You can also enable the [object spread operator proposal](recipes/UsingObjectSpreadOperator.md) for a more succinct syntax:
 
@@ -119,7 +119,7 @@ return state.map((todo, index) => {
 
 Note that experimental language features are subject to change.
 
-#### Don’t forget to call [`dispatch(action)`](api/Store.md#dispatch)
+#### Don't forget to call [`dispatch(action)`](api/Store.md#dispatch)
 
 If you define an action creator, calling it will *not* automatically dispatch the action. For example, this code will do nothing:
 
@@ -154,7 +154,7 @@ class AddTodo extends Component {
 }
 ```
 
-It doesn’t work because your action creator is just a function that *returns* an action. It is up to you to actually dispatch it. We can’t bind your action creators to a particular Store instance during the definition because apps that render on the server need a separate Redux store for every request.
+It doesn't work because your action creator is just a function that *returns* an action. It is up to you to actually dispatch it. We can't bind your action creators to a particular Store instance during the definition because apps that render on the server need a separate Redux store for every request.
 
 The fix is to call [`dispatch()`](api/Store.md#dispatch) method on the [store](api/Store.md) instance:
 
@@ -165,7 +165,7 @@ handleClick() {
 }
 ```
 
-If you’re somewhere deep in the component hierarchy, it is cumbersome to pass the store down manually. This is why [react-redux](https://github.com/gaearon/react-redux) lets you use a `connect` [higher-order component](https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750) that will, apart from subscribing you to a Redux store, inject `dispatch` into your component’s props.
+If you're somewhere deep in the component hierarchy, it is cumbersome to pass the store down manually. This is why [react-redux](https://github.com/gaearon/react-redux) lets you use a `connect` [higher-order component](https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750) that will, apart from subscribing you to a Redux store, inject `dispatch` into your component's props.
 
 The fixed code looks like this:
 #### `AddTodo.js`
@@ -199,7 +199,7 @@ You can then pass `dispatch` down to other components manually, if you want to.
 
 It's possible you're correctly dispatching an action and applying your reducer but the corresponding state is not being correctly translated into props.
 
-## Something else doesn’t work
+## Something else doesn't work
 
 Ask around on the **#redux** [Reactiflux](http://reactiflux.com/) Discord channel, or [create an issue](https://github.com/reactjs/redux/issues).  
 If you figure it out, [edit this document](https://github.com/reactjs/redux/edit/master/docs/Troubleshooting.md) as a courtesy to the next person having the same problem.
diff --git a/docs/advanced/AsyncActions.md b/docs/advanced/AsyncActions.md
index cad3576f27..f33f3ab629 100644
--- a/docs/advanced/AsyncActions.md
+++ b/docs/advanced/AsyncActions.md
@@ -8,11 +8,11 @@ In this guide, we will build a different, asynchronous application. It will use
 
 When you call an asynchronous API, there are two crucial moments in time: the moment you start the call, and the moment when you receive an answer (or a timeout).
 
-Each of these two moments can usually require a change in the application state; to do that, you need to dispatch normal actions that will be processed by reducers synchronously. Usually, for any API request you’ll want to dispatch at least three different kinds of actions:
+Each of these two moments can usually require a change in the application state; to do that, you need to dispatch normal actions that will be processed by reducers synchronously. Usually, for any API request you'll want to dispatch at least three different kinds of actions:
 
 * **An action informing the reducers that the request began.**
 
-  The reducers may handle this action by toggling an `isFetching` flag in the state. This way the UI knows it’s time to show a spinner.
+  The reducers may handle this action by toggling an `isFetching` flag in the state. This way the UI knows it's time to show a spinner.
 
 * **An action informing the reducers that the request finished successfully.**
 
@@ -38,14 +38,14 @@ Or you can define separate types for them:
 { type: 'FETCH_POSTS_SUCCESS', response: { ... } }
 ```
 
-Choosing whether to use a single action type with flags, or multiple action types, is up to you. It’s a convention you need to decide with your team. Multiple types leave less room for a mistake, but this is not an issue if you generate action creators and reducers with a helper library like [redux-actions](https://github.com/acdlite/redux-actions).
+Choosing whether to use a single action type with flags, or multiple action types, is up to you. It's a convention you need to decide with your team. Multiple types leave less room for a mistake, but this is not an issue if you generate action creators and reducers with a helper library like [redux-actions](https://github.com/acdlite/redux-actions).
 
 Whatever convention you choose, stick with it throughout the application.  
-We’ll use separate types in this tutorial.
+We'll use separate types in this tutorial.
 
 ## Synchronous Action Creators
 
-Let’s start by defining the several synchronous action types and action creators we need in our example app. Here, the user can select a subreddit to display:
+Let's start by defining the several synchronous action types and action creators we need in our example app. Here, the user can select a subreddit to display:
 
 #### `actions.js`
 
@@ -75,7 +75,7 @@ export function invalidateSubreddit(subreddit) {
 
 These were the actions governed by the user interaction. We will also have another kind of action, governed by the network requests. We will see how to dispatch them later, but for now, we just want to define them.
 
-When it’s time to fetch the posts for some subreddit, we will dispatch a `REQUEST_POSTS` action:
+When it's time to fetch the posts for some subreddit, we will dispatch a `REQUEST_POSTS` action:
 
 ```js
 export const REQUEST_POSTS = 'REQUEST_POSTS'
@@ -88,7 +88,7 @@ export function requestPosts(subreddit) {
 }
 ```
 
-It is important for it to be separate from `SELECT_SUBREDDIT` or `INVALIDATE_SUBREDDIT`. While they may occur one after another, as the app grows more complex, you might want to fetch some data independently of the user action (for example, to prefetch the most popular subreddits, or to refresh stale data once in a while). You may also want to fetch in response to a route change, so it’s not wise to couple fetching to some particular UI event early on.
+It is important for it to be separate from `SELECT_SUBREDDIT` or `INVALIDATE_SUBREDDIT`. While they may occur one after another, as the app grows more complex, you might want to fetch some data independently of the user action (for example, to prefetch the most popular subreddits, or to refresh stale data once in a while). You may also want to fetch in response to a route change, so it's not wise to couple fetching to some particular UI event early on.
 
 Finally, when the network request comes through, we will dispatch `RECEIVE_POSTS`:
 
@@ -109,17 +109,17 @@ This is all we need to know for now. The particular mechanism to dispatch these
 
 >##### Note on Error Handling
 
->In a real app, you’d also want to dispatch an action on request failure. We won’t implement error handling in this tutorial, but the [real world example](../introduction/Examples.md#real-world) shows one of the possible approaches.
+>In a real app, you'd also want to dispatch an action on request failure. We won't implement error handling in this tutorial, but the [real world example](../introduction/Examples.md#real-world) shows one of the possible approaches.
 
 ## Designing the State Shape
 
-Just like in the basic tutorial, you’ll need to [design the shape of your application’s state](../basics/Reducers.md#designing-the-state-shape) before rushing into the implementation. With asynchronous code, there is more state to take care of, so we need to think it through.
+Just like in the basic tutorial, you'll need to [design the shape of your application's state](../basics/Reducers.md#designing-the-state-shape) before rushing into the implementation. With asynchronous code, there is more state to take care of, so we need to think it through.
 
 This part is often confusing to beginners, because it is not immediately clear what information describes the state of an asynchronous application, and how to organize it in a single tree.
 
-We’ll start with the most common use case: lists. Web applications often show lists of things. For example, a list of posts, or a list of friends. You’ll need to figure out what sorts of lists your app can show. You want to store them separately in the state, because this way you can cache them and only fetch again if necessary.
+We'll start with the most common use case: lists. Web applications often show lists of things. For example, a list of posts, or a list of friends. You'll need to figure out what sorts of lists your app can show. You want to store them separately in the state, because this way you can cache them and only fetch again if necessary.
 
-Here’s what the state shape for our “Reddit headlines” app might look like:
+Here's what the state shape for our “Reddit headlines” app might look like:
 
 ```js
 {
@@ -151,13 +151,13 @@ Here’s what the state shape for our “Reddit headlines” app might look like
 
 There are a few important bits here:
 
-* We store each subreddit’s information separately so we can cache every subreddit. When the user switches between them the second time, the update will be instant, and we won’t need to refetch unless we want to. Don’t worry about all these items being in memory: unless you’re dealing with tens of thousands of items, and your user rarely closes the tab, you won’t need any sort of cleanup.
+* We store each subreddit's information separately so we can cache every subreddit. When the user switches between them the second time, the update will be instant, and we won't need to refetch unless we want to. Don't worry about all these items being in memory: unless you're dealing with tens of thousands of items, and your user rarely closes the tab, you won't need any sort of cleanup.
 
-* For every list of items, you’ll want to store `isFetching` to show a spinner, `didInvalidate` so you can later toggle it when the data is stale, `lastUpdated` so you know when it was fetched the last time, and the `items` themselves. In a real app, you’ll also want to store pagination state like `fetchedPageCount` and `nextPageUrl`.
+* For every list of items, you'll want to store `isFetching` to show a spinner, `didInvalidate` so you can later toggle it when the data is stale, `lastUpdated` so you know when it was fetched the last time, and the `items` themselves. In a real app, you'll also want to store pagination state like `fetchedPageCount` and `nextPageUrl`.
 
 >##### Note on Nested Entities
 
->In this example, we store the received items together with the pagination information. However, this approach won’t work well if you have nested entities referencing each other, or if you let the user edit items. Imagine the user wants to edit a fetched post, but this post is duplicated in several places in the state tree. This would be really painful to implement.
+>In this example, we store the received items together with the pagination information. However, this approach won't work well if you have nested entities referencing each other, or if you let the user edit items. Imagine the user wants to edit a fetched post, but this post is duplicated in several places in the state tree. This would be really painful to implement.
 
 >If you have nested entities, or if you let users edit received entities, you should keep them separately in the state as if it was a database. In pagination information, you would only refer to them by their IDs. This lets you always keep them up to date. The [real world example](../introduction/Examples.md#real-world) shows this approach, together with [normalizr](https://github.com/gaearon/normalizr) to normalize the nested API responses. With this approach, your state might look like this:
 
@@ -200,7 +200,7 @@ There are a few important bits here:
 > }
 >```
 
->In this guide, we won’t normalize entities, but it’s something you should consider for a more dynamic application.
+>In this guide, we won't normalize entities, but it's something you should consider for a more dynamic application.
 
 ## Handling Actions
 
@@ -208,7 +208,7 @@ Before going into the details of dispatching actions together with network reque
 
 >##### Note on Reducer Composition
 
-> Here, we assume that you understand reducer composition with [`combineReducers()`](../api/combineReducers.md), as described in the [Splitting Reducers](../basics/Reducers.md#splitting-reducers) section on the [basics guide](../basics/README.md). If you don’t, please [read it first](../basics/Reducers.md#splitting-reducers).
+> Here, we assume that you understand reducer composition with [`combineReducers()`](../api/combineReducers.md), as described in the [Splitting Reducers](../basics/Reducers.md#splitting-reducers) section on the [basics guide](../basics/README.md). If you don't, please [read it first](../basics/Reducers.md#splitting-reducers).
 
 #### `reducers.js`
 
@@ -292,15 +292,15 @@ In this code, there are two interesting parts:
   nextState[action.subreddit] = posts(state[action.subreddit], action)
   return Object.assign({}, state, nextState)
   ```
-* We extracted `posts(state, action)` that manages the state of a specific post list. This is just [reducer composition](../basics/Reducers.md#splitting-reducers)! It is our choice how to split the reducer into smaller reducers, and in this case, we’re delegating updating items inside an object to a `posts` reducer. The [real world example](../introduction/Examples.md#real-world) goes even further, showing how to create a reducer factory for parameterized pagination reducers.
+* We extracted `posts(state, action)` that manages the state of a specific post list. This is just [reducer composition](../basics/Reducers.md#splitting-reducers)! It is our choice how to split the reducer into smaller reducers, and in this case, we're delegating updating items inside an object to a `posts` reducer. The [real world example](../introduction/Examples.md#real-world) goes even further, showing how to create a reducer factory for parameterized pagination reducers.
 
 Remember that reducers are just functions, so you can use functional composition and higher-order functions as much as you feel comfortable.
 
 ## Async Action Creators
 
-Finally, how do we use the synchronous action creators we [defined earlier](#synchronous-action-creators) together with network requests? The standard way to do it with Redux is to use the [Redux Thunk middleware](https://github.com/gaearon/redux-thunk). It comes in a separate package called `redux-thunk`. We’ll explain how middleware works in general [later](Middleware.md); for now, there is just one important thing you need to know: by using this specific middleware, an action creator can return a function instead of an action object. This way, the action creator becomes a [thunk](https://en.wikipedia.org/wiki/Thunk).
+Finally, how do we use the synchronous action creators we [defined earlier](#synchronous-action-creators) together with network requests? The standard way to do it with Redux is to use the [Redux Thunk middleware](https://github.com/gaearon/redux-thunk). It comes in a separate package called `redux-thunk`. We'll explain how middleware works in general [later](Middleware.md); for now, there is just one important thing you need to know: by using this specific middleware, an action creator can return a function instead of an action object. This way, the action creator becomes a [thunk](https://en.wikipedia.org/wiki/Thunk).
 
-When an action creator returns a function, that function will get executed by the Redux Thunk middleware. This function doesn’t need to be pure; it is thus allowed to have side effects, including executing asynchronous API calls. The function can also dispatch actions—like those synchronous actions we defined earlier.
+When an action creator returns a function, that function will get executed by the Redux Thunk middleware. This function doesn't need to be pure; it is thus allowed to have side effects, including executing asynchronous API calls. The function can also dispatch actions—like those synchronous actions we defined earlier.
 
 We can still define these special thunk action creators inside our `actions.js` file:
 
@@ -368,16 +368,16 @@ export function fetchPosts(subreddit) {
 
 >##### Note on `fetch`
 
->We use [`fetch` API](https://developer.mozilla.org/en/docs/Web/API/Fetch_API) in the examples. It is a new API for making network requests that replaces `XMLHttpRequest` for most common needs. Because most browsers don’t yet support it natively, we suggest that you use [`isomorphic-fetch`](https://github.com/matthew-andrews/isomorphic-fetch) library:
+>We use [`fetch` API](https://developer.mozilla.org/en/docs/Web/API/Fetch_API) in the examples. It is a new API for making network requests that replaces `XMLHttpRequest` for most common needs. Because most browsers don't yet support it natively, we suggest that you use [`isomorphic-fetch`](https://github.com/matthew-andrews/isomorphic-fetch) library:
 
 >```js
 // Do this in every file where you use `fetch`
 >import fetch from 'isomorphic-fetch'
 >```
 
->Internally, it uses [`whatwg-fetch` polyfill](https://github.com/github/fetch) on the client, and [`node-fetch`](https://github.com/bitinn/node-fetch) on the server, so you won’t need to change API calls if you change your app to be [universal](https://medium.com/@mjackson/universal-javascript-4761051b7ae9).
+>Internally, it uses [`whatwg-fetch` polyfill](https://github.com/github/fetch) on the client, and [`node-fetch`](https://github.com/bitinn/node-fetch) on the server, so you won't need to change API calls if you change your app to be [universal](https://medium.com/@mjackson/universal-javascript-4761051b7ae9).
 
->Be aware that any `fetch` polyfill assumes a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) polyfill is already present. The easiest way to ensure you have a Promise polyfill is to enable Babel’s ES6 polyfill in your entry point before any other code runs:
+>Be aware that any `fetch` polyfill assumes a [Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise) polyfill is already present. The easiest way to ensure you have a Promise polyfill is to enable Babel's ES6 polyfill in your entry point before any other code runs:
 
 >```js
 >// Do this once before any other code in your app
@@ -490,7 +490,7 @@ store.dispatch(fetchPostsIfNeeded('reactjs')).then(() =>
 
 >Async action creators are especially convenient for server rendering. You can create a store, dispatch a single async action creator that dispatches other async action creators to fetch data for a whole section of your app, and only render after the Promise it returns, completes. Then your store will already be hydrated with the state you need before rendering.
 
-[Thunk middleware](https://github.com/gaearon/redux-thunk) isn’t the only way to orchestrate asynchronous actions in Redux:
+[Thunk middleware](https://github.com/gaearon/redux-thunk) isn't the only way to orchestrate asynchronous actions in Redux:
 - You can use [redux-promise](https://github.com/acdlite/redux-promise) or [redux-promise-middleware](https://github.com/pburtchaell/redux-promise-middleware) to dispatch Promises instead of functions.
 - You can use [redux-observable](https://github.com/redux-observable/redux-observable) to dispatch Observables.
 - You can use the [redux-saga](https://github.com/yelouafi/redux-saga/) middleware to build more complex asynchronous actions.
@@ -500,7 +500,7 @@ It is up to you to try a few options, choose a convention you like, and follow i
 
 ## Connecting to UI
 
-Dispatching async actions is no different from dispatching synchronous actions, so we won’t discuss this in detail. See [Usage with React](../basics/UsageWithReact.md) for an introduction into using Redux from React components. See [Example: Reddit API](ExampleRedditAPI.md) for the complete source code discussed in this example.
+Dispatching async actions is no different from dispatching synchronous actions, so we won't discuss this in detail. See [Usage with React](../basics/UsageWithReact.md) for an introduction into using Redux from React components. See [Example: Reddit API](ExampleRedditAPI.md) for the complete source code discussed in this example.
 
 ## Next Steps
 
diff --git a/docs/advanced/AsyncFlow.md b/docs/advanced/AsyncFlow.md
index 7c4b1e9807..8d9722fb36 100644
--- a/docs/advanced/AsyncFlow.md
+++ b/docs/advanced/AsyncFlow.md
@@ -4,7 +4,7 @@ Without [middleware](Middleware.md), Redux store only supports [synchronous data
 
 You may enhance [`createStore()`](../api/createStore.md) with [`applyMiddleware()`](../api/applyMiddleware.md). It is not required, but it lets you [express asynchronous actions in a convenient way](AsyncActions.md).
 
-Asynchronous middleware like [redux-thunk](https://github.com/gaearon/redux-thunk) or [redux-promise](https://github.com/acdlite/redux-promise) wraps the store’s [`dispatch()`](../api/Store.md#dispatch) method and allows you to dispatch something other than actions, for example, functions or Promises. Any middleware you use can then interpret anything you dispatch, and in turn, can pass actions to the next middleware in chain. For example, a Promise middleware can intercept Promises and dispatch a pair of begin/end actions asynchronously in response to each Promise.
+Asynchronous middleware like [redux-thunk](https://github.com/gaearon/redux-thunk) or [redux-promise](https://github.com/acdlite/redux-promise) wraps the store's [`dispatch()`](../api/Store.md#dispatch) method and allows you to dispatch something other than actions, for example, functions or Promises. Any middleware you use can then interpret anything you dispatch, and in turn, can pass actions to the next middleware in chain. For example, a Promise middleware can intercept Promises and dispatch a pair of begin/end actions asynchronously in response to each Promise.
 
 When the last middleware in the chain dispatches an action, it has to be a plain object. This is when the [synchronous Redux data flow](../basics/DataFlow.md) takes place.
 
@@ -12,4 +12,4 @@ Check out [the full source code for the async example](ExampleRedditAPI.md).
 
 ## Next Steps
 
-Now you saw an example of what middleware can do in Redux, it’s time to learn how it actually works, and how you can create your own. Go on to the next detailed section about [Middleware](Middleware.md). 
+Now you saw an example of what middleware can do in Redux, it's time to learn how it actually works, and how you can create your own. Go on to the next detailed section about [Middleware](Middleware.md). 
diff --git a/docs/advanced/Middleware.md b/docs/advanced/Middleware.md
index badc968e4e..fe51ff6493 100644
--- a/docs/advanced/Middleware.md
+++ b/docs/advanced/Middleware.md
@@ -1,6 +1,6 @@
 # Middleware
 
-You’ve seen middleware in action in the [Async Actions](../advanced/AsyncActions.md) example. If you’ve used server-side libraries like [Express](http://expressjs.com/) and [Koa](http://koajs.com/), you were also probably already familiar with the concept of *middleware*. In these frameworks, middleware is some code you can put between the framework receiving a request, and the framework generating a response. For example, Express or Koa middleware may add CORS headers, logging, compression, and more. The best feature of middleware is that it’s composable in a chain. You can use multiple independent third-party middleware in a single project.
+You've seen middleware in action in the [Async Actions](../advanced/AsyncActions.md) example. If you've used server-side libraries like [Express](http://expressjs.com/) and [Koa](http://koajs.com/), you were also probably already familiar with the concept of *middleware*. In these frameworks, middleware is some code you can put between the framework receiving a request, and the framework generating a response. For example, Express or Koa middleware may add CORS headers, logging, compression, and more. The best feature of middleware is that it's composable in a chain. You can use multiple independent third-party middleware in a single project.
 
 Redux middleware solves different problems than Express or Koa middleware, but in a conceptually similar way. **It provides a third-party extension point between dispatching an action, and the moment it reaches the reducer.** People use Redux middleware for logging, crash reporting, talking to an asynchronous API, routing, and more.
 
@@ -8,13 +8,13 @@ This article is divided into an in-depth intro to help you grok the concept, and
 
 ## Understanding Middleware
 
-While middleware can be used for a variety of things, including asynchronous API calls, it’s really important that you understand where it comes from. We’ll guide you through the thought process leading to middleware, by using logging and crash reporting as examples.
+While middleware can be used for a variety of things, including asynchronous API calls, it's really important that you understand where it comes from. We'll guide you through the thought process leading to middleware, by using logging and crash reporting as examples.
 
 ### Problem: Logging
 
 One of the benefits of Redux is that it makes state changes predictable and transparent. Every time an action is dispatched, the new state is computed and saved. The state cannot change by itself, it can only change as a consequence of a specific action.
 
-Wouldn’t it be nice if we logged every action that happens in the app, together with the state computed after it? When something goes wrong, we can look back at our log, and figure out which action corrupted the state.
+Wouldn't it be nice if we logged every action that happens in the app, together with the state computed after it? When something goes wrong, we can look back at our log, and figure out which action corrupted the state.
 
 <img src='http://i.imgur.com/BjGBlES.png' width='70%'>
 
@@ -22,11 +22,11 @@ How do we approach this with Redux?
 
 ### Attempt #1: Logging Manually
 
-The most naïve solution is just to log the action and the next state yourself every time you call [`store.dispatch(action)`](../api/Store.md#dispatch). It’s not really a solution, but just a first step towards understanding the problem.
+The most naïve solution is just to log the action and the next state yourself every time you call [`store.dispatch(action)`](../api/Store.md#dispatch). It's not really a solution, but just a first step towards understanding the problem.
 
 >##### Note
 
->If you’re using [react-redux](https://github.com/gaearon/react-redux) or similar bindings, you likely won’t have direct access to the store instance in your components. For the next few paragraphs, just assume you pass the store down explicitly.
+>If you're using [react-redux](https://github.com/gaearon/react-redux) or similar bindings, you likely won't have direct access to the store instance in your components. For the next few paragraphs, just assume you pass the store down explicitly.
 
 Say, you call this when creating a todo:
 
@@ -44,7 +44,7 @@ store.dispatch(action)
 console.log('next state', store.getState())
 ```
 
-This produces the desired effect, but you wouldn’t want to do it every time.
+This produces the desired effect, but you wouldn't want to do it every time.
 
 ### Attempt #2: Wrapping Dispatch
 
@@ -64,11 +64,11 @@ You can then use it everywhere instead of `store.dispatch()`:
 dispatchAndLog(store, addTodo('Use Redux'))
 ```
 
-We could end this here, but it’s not very convenient to import a special function every time.
+We could end this here, but it's not very convenient to import a special function every time.
 
 ### Attempt #3: Monkeypatching Dispatch
 
-What if we just replace the `dispatch` function on the store instance? The Redux store is just a plain object with [a few methods](../api/Store.md), and we’re writing JavaScript, so we can just monkeypatch the `dispatch` implementation:
+What if we just replace the `dispatch` function on the store instance? The Redux store is just a plain object with [a few methods](../api/Store.md), and we're writing JavaScript, so we can just monkeypatch the `dispatch` implementation:
 
 ```js
 let next = store.dispatch
@@ -86,11 +86,11 @@ This is already closer to what we want!  No matter where we dispatch an action,
 
 What if we want to apply **more than one** such transformation to `dispatch`?
 
-A different useful transformation that comes to my mind is reporting JavaScript errors in production. The global `window.onerror` event is not reliable because it doesn’t provide stack information in some older browsers, which is crucial to understand why an error is happening.
+A different useful transformation that comes to my mind is reporting JavaScript errors in production. The global `window.onerror` event is not reliable because it doesn't provide stack information in some older browsers, which is crucial to understand why an error is happening.
 
-Wouldn’t it be useful if, any time an error is thrown as a result of dispatching an action, we would send it to a crash reporting service like [Sentry](https://getsentry.com/welcome/) with the stack trace, the action that caused the error, and the current state? This way it’s much easier to reproduce the error in development.
+Wouldn't it be useful if, any time an error is thrown as a result of dispatching an action, we would send it to a crash reporting service like [Sentry](https://getsentry.com/welcome/) with the stack trace, the action that caused the error, and the current state? This way it's much easier to reproduce the error in development.
 
-However, it is important that we keep logging and crash reporting separate. Ideally we want them to be different modules, potentially in different packages. Otherwise we can’t have an ecosystem of such utilities. (Hint: we’re slowly getting to what middleware is!)
+However, it is important that we keep logging and crash reporting separate. Ideally we want them to be different modules, potentially in different packages. Otherwise we can't have an ecosystem of such utilities. (Hint: we're slowly getting to what middleware is!)
 
 If logging and crash reporting are separate utilities, they might look like this:
 
@@ -131,11 +131,11 @@ patchStoreToAddLogging(store)
 patchStoreToAddCrashReporting(store)
 ```
 
-Still, this isn’t nice.
+Still, this isn't nice.
 
 ### Attempt #4: Hiding Monkeypatching
 
-Monkeypatching is a hack. “Replace any method you like”, what kind of API is that? Let’s figure out the essence of it instead. Previously, our functions replaced `store.dispatch`. What if they *returned* the new `dispatch` function instead?
+Monkeypatching is a hack. “Replace any method you like”, what kind of API is that? Let's figure out the essence of it instead. Previously, our functions replaced `store.dispatch`. What if they *returned* the new `dispatch` function instead?
 
 ```js
 function logger(store) {
@@ -174,11 +174,11 @@ applyMiddlewareByMonkeypatching(store, [ logger, crashReporter ])
 ```
 
 However, it is still monkeypatching.  
-The fact that we hide it inside the library doesn’t alter this fact.
+The fact that we hide it inside the library doesn't alter this fact.
 
 ### Attempt #5: Removing Monkeypatching
 
-Why do we even overwrite `dispatch`? Of course, to be able to call it later, but there’s also another reason: so that every middleware can access (and call) the previously wrapped `store.dispatch`:
+Why do we even overwrite `dispatch`? Of course, to be able to call it later, but there's also another reason: so that every middleware can access (and call) the previously wrapped `store.dispatch`:
 
 ```js
 function logger(store) {
@@ -196,9 +196,9 @@ function logger(store) {
 
 It is essential to chaining middleware!
 
-If `applyMiddlewareByMonkeypatching` doesn’t assign `store.dispatch` immediately after processing the first middleware, `store.dispatch` will keep pointing to the original `dispatch` function. Then the second middleware will also be bound to the original `dispatch` function.
+If `applyMiddlewareByMonkeypatching` doesn't assign `store.dispatch` immediately after processing the first middleware, `store.dispatch` will keep pointing to the original `dispatch` function. Then the second middleware will also be bound to the original `dispatch` function.
 
-But there’s also a different way to enable chaining. The middleware could accept the `next()` dispatch function as a parameter instead of reading it from the `store` instance.
+But there's also a different way to enable chaining. The middleware could accept the `next()` dispatch function as a parameter instead of reading it from the `store` instance.
 
 ```js
 function logger(store) {
@@ -213,7 +213,7 @@ function logger(store) {
 }
 ```
 
-It’s a [“we need to go deeper”](http://knowyourmeme.com/memes/we-need-to-go-deeper) kind of moment, so it might take a while for this to make sense. The function cascade feels intimidating. ES6 arrow functions make this [currying](https://en.wikipedia.org/wiki/Currying) easier on eyes:
+It's a [“we need to go deeper”](http://knowyourmeme.com/memes/we-need-to-go-deeper) kind of moment, so it might take a while for this to make sense. The function cascade feels intimidating. ES6 arrow functions make this [currying](https://en.wikipedia.org/wiki/Currying) easier on eyes:
 
 ```js
 const logger = store => next => action => {
@@ -241,7 +241,7 @@ const crashReporter = store => next => action => {
 
 **This is exactly what Redux middleware looks like.**
 
-Now middleware takes the `next()` dispatch function, and returns a dispatch function, which in turn serves as `next()` to the middleware to the left, and so on. It’s still useful to have access to some store methods like `getState()`, so `store` stays available as the top-level argument.
+Now middleware takes the `next()` dispatch function, and returns a dispatch function, which in turn serves as `next()` to the middleware to the left, and so on. It's still useful to have access to some store methods like `getState()`, so `store` stays available as the top-level argument.
 
 ### Attempt #6: Naïvely Applying the Middleware
 
@@ -302,7 +302,7 @@ const crashReporter = store => next => action => {
 }
 ```
 
-Here’s how to apply it to a Redux store:
+Here's how to apply it to a Redux store:
 
 ```js
 import { createStore, combineReducers, applyMiddleware } from 'redux'
@@ -315,7 +315,7 @@ let store = createStore(
 )
 ```
 
-That’s it! Now any actions dispatched to the store instance will flow through `logger` and `crashReporter`:
+That's it! Now any actions dispatched to the store instance will flow through `logger` and `crashReporter`:
 
 ```js
 // Will flow through both logger and crashReporter middleware!
@@ -472,7 +472,7 @@ const thunk = store => next => action =>
     next(action)
 
 
-// You can use all of them! (It doesn’t mean you should.)
+// You can use all of them! (It doesn't mean you should.)
 let todoApp = combineReducers(reducers)
 let store = createStore(
   todoApp,
diff --git a/docs/advanced/NextSteps.md b/docs/advanced/NextSteps.md
index 555cd78bd4..df04746950 100644
--- a/docs/advanced/NextSteps.md
+++ b/docs/advanced/NextSteps.md
@@ -1,4 +1,4 @@
 # Next Steps
 
-Sorry, but we’re still writing this doc.  
+Sorry, but we're still writing this doc.  
 Stay tuned, it will appear in a day or two.
diff --git a/docs/advanced/UsageWithReactRouter.md b/docs/advanced/UsageWithReactRouter.md
index d4b6263f11..e44a0526b1 100644
--- a/docs/advanced/UsageWithReactRouter.md
+++ b/docs/advanced/UsageWithReactRouter.md
@@ -1,4 +1,4 @@
 # Usage with React Router
 
-Sorry, but we’re still writing this doc.  
+Sorry, but we're still writing this doc.  
 Stay tuned, it will appear in a day or two.
diff --git a/docs/api/README.md b/docs/api/README.md
index 9473f5f467..3890f65453 100644
--- a/docs/api/README.md
+++ b/docs/api/README.md
@@ -2,7 +2,7 @@
 
 The Redux API surface is tiny. Redux defines a set of contracts for you to implement (such as [reducers](../Glossary.md#reducer)) and provides a few helper functions to tie these contracts together.
 
-This section documents the complete Redux API. Keep in mind that Redux is only concerned with managing the state. In a real app, you’ll also want to use UI bindings like [react-redux](https://github.com/gaearon/react-redux).
+This section documents the complete Redux API. Keep in mind that Redux is only concerned with managing the state. In a real app, you'll also want to use UI bindings like [react-redux](https://github.com/gaearon/react-redux).
 
 ### Top-Level Exports
 
diff --git a/docs/api/Store.md b/docs/api/Store.md
index b0519c6a14..fa6279380e 100644
--- a/docs/api/Store.md
+++ b/docs/api/Store.md
@@ -3,12 +3,12 @@
 A store holds the whole [state tree](../Glossary.md#state) of your application.  
 The only way to change the state inside it is to dispatch an [action](../Glossary.md#action) on it.  
 
-A store is not a class. It’s just an object with a few methods on it.  
+A store is not a class. It's just an object with a few methods on it.  
 To create it, pass your root [reducing function](../Glossary.md#reducer) to [`createStore`](createStore.md).
 
 >##### A Note for Flux Users
 
->If you’re coming from Flux, there is a single important difference you need to understand. Redux doesn’t have a Dispatcher or support many stores. **Instead, there is just a single store with a single root [reducing function](../Glossary.md#reducer).** As your app grows, instead of adding stores, you split the root reducer into smaller reducers independently operating on the different parts of the state tree. You can use a helper like [`combineReducers`](combineReducers.md) to combine them. This is similar to how there is just one root component in a React app, but it is composed out of many small components.
+>If you're coming from Flux, there is a single important difference you need to understand. Redux doesn't have a Dispatcher or support many stores. **Instead, there is just a single store with a single root [reducing function](../Glossary.md#reducer).** As your app grows, instead of adding stores, you split the root reducer into smaller reducers independently operating on the different parts of the state tree. You can use a helper like [`combineReducers`](combineReducers.md) to combine them. This is similar to how there is just one root component in a React app, but it is composed out of many small components.
 
 ### Store Methods
 
@@ -22,7 +22,7 @@ To create it, pass your root [reducing function](../Glossary.md#reducer) to [`cr
 ### <a id='getState'></a>[`getState()`](#getState)
 
 Returns the current state tree of your application.  
-It is equal to the last value returned by the store’s reducer.
+It is equal to the last value returned by the store's reducer.
 
 #### Returns
 
@@ -34,16 +34,16 @@ It is equal to the last value returned by the store’s reducer.
 
 Dispatches an action. This is the only way to trigger a state change.
 
-The store’s reducing function will be called with the current [`getState()`](#getState) result and the given `action` synchronously. Its return value will be considered the next state. It will be returned from [`getState()`](#getState) from now on, and the change listeners will immediately be notified.
+The store's reducing function will be called with the current [`getState()`](#getState) result and the given `action` synchronously. Its return value will be considered the next state. It will be returned from [`getState()`](#getState) from now on, and the change listeners will immediately be notified.
 
 >##### A Note for Flux Users
->If you attempt to call `dispatch` from inside the [reducer](../Glossary.md#reducer), it will throw with an error saying “Reducers may not dispatch actions.” This is similar to “Cannot dispatch in a middle of dispatch” error in Flux, but doesn’t cause the problems associated with it. In Flux, a dispatch is forbidden while Stores are handling the action and emitting updates. This is unfortunate because it makes it impossible to dispatch actions from component lifecycle hooks or other benign places.
+>If you attempt to call `dispatch` from inside the [reducer](../Glossary.md#reducer), it will throw with an error saying “Reducers may not dispatch actions.” This is similar to “Cannot dispatch in a middle of dispatch” error in Flux, but doesn't cause the problems associated with it. In Flux, a dispatch is forbidden while Stores are handling the action and emitting updates. This is unfortunate because it makes it impossible to dispatch actions from component lifecycle hooks or other benign places.
 
 >In Redux, subscriptions are called after the root reducer has returned the new state, so you *may* dispatch in the subscription listeners. You are only disallowed to dispatch inside the reducers because they must have no side effects. If you want to cause a side effect in response to an action, the right place to do this is in the potentially async [action creator](../Glossary.md#action-creator).
 
 #### Arguments
 
-1. `action` (*Object*<sup>†</sup>): A plain object describing the change that makes sense for your application. Actions are the only way to get data into the store, so any data, whether from the UI events, network callbacks, or other sources such as WebSockets needs to eventually be dispatched as actions. Actions must have a `type` field that indicates the type of action being performed. Types can be defined as constants and imported from another module. It’s better to use strings for `type` than [Symbols](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Symbol) because strings are serializable. Other than `type`, the structure of an action object is really up to you. If you’re interested, check out [Flux Standard Action](https://github.com/acdlite/flux-standard-action) for recommendations on how actions could be constructed.
+1. `action` (*Object*<sup>†</sup>): A plain object describing the change that makes sense for your application. Actions are the only way to get data into the store, so any data, whether from the UI events, network callbacks, or other sources such as WebSockets needs to eventually be dispatched as actions. Actions must have a `type` field that indicates the type of action being performed. Types can be defined as constants and imported from another module. It's better to use strings for `type` than [Symbols](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Symbol) because strings are serializable. Other than `type`, the structure of an action object is really up to you. If you're interested, check out [Flux Standard Action](https://github.com/acdlite/flux-standard-action) for recommendations on how actions could be constructed.
 
 #### Returns
 
@@ -90,13 +90,13 @@ You may call [`dispatch()`](#dispatch) from a change listener, with the followin
 
 3. The listener should not expect to see all state changes, as the state might have been updated multiple times during a nested [`dispatch()`](#dispatch) before the listener is called. It is, however, guaranteed that all subscribers registered before the [`dispatch()`](#dispatch) started will be called with the latest state by the time it exits.
 
-It is a low-level API. Most likely, instead of using it directly, you’ll use React (or other) bindings. If you commonly use the callback as a hook to react to state changes, you might want to [write a custom `observeStore` utility](https://github.com/reactjs/redux/issues/303#issuecomment-125184409). The `Store` is also an [`Observable`](https://github.com/zenparsing/es-observable), so you can `subscribe` to changes with libraries like [RxJS](https://github.com/ReactiveX/RxJS). 
+It is a low-level API. Most likely, instead of using it directly, you'll use React (or other) bindings. If you commonly use the callback as a hook to react to state changes, you might want to [write a custom `observeStore` utility](https://github.com/reactjs/redux/issues/303#issuecomment-125184409). The `Store` is also an [`Observable`](https://github.com/zenparsing/es-observable), so you can `subscribe` to changes with libraries like [RxJS](https://github.com/ReactiveX/RxJS). 
 
 To unsubscribe the change listener, invoke the function returned by `subscribe`.
 
 #### Arguments
 
-1. `listener` (*Function*): The callback to be invoked any time an action has been dispatched, and the state tree might have changed. You may call [`getState()`](#getState) inside this callback to read the current state tree. It is reasonable to expect that the store’s reducer is a pure function, so you may compare references to some deep path in the state tree to learn whether its value has changed.
+1. `listener` (*Function*): The callback to be invoked any time an action has been dispatched, and the state tree might have changed. You may call [`getState()`](#getState) inside this callback to read the current state tree. It is reasonable to expect that the store's reducer is a pure function, so you may compare references to some deep path in the state tree to learn whether its value has changed.
 
 ##### Returns
 
diff --git a/docs/api/applyMiddleware.md b/docs/api/applyMiddleware.md
index 6d91c0b60d..07c76154dc 100644
--- a/docs/api/applyMiddleware.md
+++ b/docs/api/applyMiddleware.md
@@ -1,6 +1,6 @@
 # `applyMiddleware(...middlewares)`
 
-Middleware is the suggested way to extend Redux with custom functionality. Middleware lets you wrap the store’s [`dispatch`](Store.md#dispatch) method for fun and profit. The key feature of middleware is that it is composable. Multiple middleware can be combined together, where each middleware requires no knowledge of what comes before or after it in the chain.
+Middleware is the suggested way to extend Redux with custom functionality. Middleware lets you wrap the store's [`dispatch`](Store.md#dispatch) method for fun and profit. The key feature of middleware is that it is composable. Multiple middleware can be combined together, where each middleware requires no knowledge of what comes before or after it in the chain.
 
 The most common use case for middleware is to support asynchronous actions without much boilerplate code or a dependency on a library like [Rx](https://github.com/Reactive-Extensions/RxJS). It does so by letting you dispatch [async actions](../Glossary.md#async-action) in addition to normal actions.
 
@@ -10,7 +10,7 @@ Middleware is not baked into [`createStore`](createStore.md) and is not a fundam
 
 #### Arguments
 
-* `...middlewares` (*arguments*): Functions that conform to the Redux *middleware API*. Each middleware receives [`Store`](Store.md)’s [`dispatch`](Store.md#dispatch) and [`getState`](Store.md#getState) functions as named arguments, and returns a function. That function will be given the `next` middleware’s dispatch method, and is expected to return a function of `action` calling `next(action)` with a potentially different argument, or at a different time, or maybe not calling it at all. The last middleware in the chain will receive the real store’s [`dispatch`](Store.md#dispatch) method as the `next` parameter, thus ending the chain. So, the middleware signature is `({ getState, dispatch }) => next => action`.
+* `...middlewares` (*arguments*): Functions that conform to the Redux *middleware API*. Each middleware receives [`Store`](Store.md)'s [`dispatch`](Store.md#dispatch) and [`getState`](Store.md#getState) functions as named arguments, and returns a function. That function will be given the `next` middleware's dispatch method, and is expected to return a function of `action` calling `next(action)` with a potentially different argument, or at a different time, or maybe not calling it at all. The last middleware in the chain will receive the real store's [`dispatch`](Store.md#dispatch) method as the `next` parameter, thus ending the chain. So, the middleware signature is `({ getState, dispatch }) => next => action`.
 
 #### Returns
 
@@ -126,7 +126,7 @@ store.dispatch(
   makeASandwichWithSecretSauce('Me')
 )
 
-// It even takes care to return the thunk’s return value
+// It even takes care to return the thunk's return value
 // from the dispatch, so I can chain Promises as long as I return them.
 
 store.dispatch(
@@ -143,7 +143,7 @@ function makeSandwichesForEverybody() {
   return function (dispatch, getState) {
     if (!getState().sandwiches.isShopOpen) {
 
-      // You don’t have to return Promises, but it’s a handy convention
+      // You don't have to return Promises, but it's a handy convention
       // so the caller can always call .then() on async dispatch result.
 
       return Promise.resolve()
@@ -216,11 +216,11 @@ export default connect(
 
 #### Tips
 
-* Middleware only wraps the store’s [`dispatch`](Store.md#dispatch) function. Technically, anything a middleware can do, you can do manually by wrapping every `dispatch` call, but it’s easier to manage this in a single place and define action transformations on the scale of the whole project.
+* Middleware only wraps the store's [`dispatch`](Store.md#dispatch) function. Technically, anything a middleware can do, you can do manually by wrapping every `dispatch` call, but it's easier to manage this in a single place and define action transformations on the scale of the whole project.
 
-* If you use other store enhancers in addition to `applyMiddleware`, make sure to put `applyMiddleware` before them in the composition chain because the middleware is potentially asynchronous. For example, it should go before [redux-devtools](https://github.com/gaearon/redux-devtools) because otherwise the DevTools won’t see the raw actions emitted by the Promise middleware and such.
+* If you use other store enhancers in addition to `applyMiddleware`, make sure to put `applyMiddleware` before them in the composition chain because the middleware is potentially asynchronous. For example, it should go before [redux-devtools](https://github.com/gaearon/redux-devtools) because otherwise the DevTools won't see the raw actions emitted by the Promise middleware and such.
 
-* If you want to conditionally apply a middleware, make sure to only import it when it’s needed:
+* If you want to conditionally apply a middleware, make sure to only import it when it's needed:
 
   ```js
   let middleware = [ a, b ]
@@ -239,8 +239,8 @@ export default connect(
 
   This makes it easier for bundling tools to cut out unneeded modules and reduces the size of your builds.
 
-* Ever wondered what `applyMiddleware` itself is? It ought to be an extension mechanism more powerful than the middleware itself. Indeed, `applyMiddleware` is an example of the most powerful Redux extension mechanism called [store enhancers](../Glossary.md#store-enhancer). It is highly unlikely you’ll ever want to write a store enhancer yourself. Another example of a store enhancer is [redux-devtools](https://github.com/gaearon/redux-devtools). Middleware is less powerful than a store enhancer, but it is easier to write.
+* Ever wondered what `applyMiddleware` itself is? It ought to be an extension mechanism more powerful than the middleware itself. Indeed, `applyMiddleware` is an example of the most powerful Redux extension mechanism called [store enhancers](../Glossary.md#store-enhancer). It is highly unlikely you'll ever want to write a store enhancer yourself. Another example of a store enhancer is [redux-devtools](https://github.com/gaearon/redux-devtools). Middleware is less powerful than a store enhancer, but it is easier to write.
 
-* Middleware sounds much more complicated than it really is. The only way to really understand middleware is to see how the existing middleware works, and try to write your own. The function nesting can be intimidating, but most of the middleware you’ll find are, in fact, 10-liners, and the nesting and composability is what makes the middleware system powerful.
+* Middleware sounds much more complicated than it really is. The only way to really understand middleware is to see how the existing middleware works, and try to write your own. The function nesting can be intimidating, but most of the middleware you'll find are, in fact, 10-liners, and the nesting and composability is what makes the middleware system powerful.
 
 * To apply multiple store enhancers, you may use [`compose()`](./compose.md).
diff --git a/docs/api/bindActionCreators.md b/docs/api/bindActionCreators.md
index 1ec9349362..68d7bf74ed 100644
--- a/docs/api/bindActionCreators.md
+++ b/docs/api/bindActionCreators.md
@@ -4,7 +4,7 @@ Turns an object whose values are [action creators](../Glossary.md#action-creator
 
 Normally you should just call [`dispatch`](Store.md#dispatch) directly on your [`Store`](Store.md) instance. If you use Redux with React, [react-redux](https://github.com/gaearon/react-redux) will provide you with the [`dispatch`](Store.md#dispatch) function so you can call it directly, too.
 
-The only use case for `bindActionCreators` is when you want to pass some action creators down to a component that isn’t aware of Redux, and you don’t want to pass [`dispatch`](Store.md#dispatch) or the Redux store to it.
+The only use case for `bindActionCreators` is when you want to pass some action creators down to a component that isn't aware of Redux, and you don't want to pass [`dispatch`](Store.md#dispatch) or the Redux store to it.
 
 For convenience, you can also pass a single function as the first argument, and get a function in return.
 
@@ -57,10 +57,10 @@ class TodoListContainer extends Component {
     // Injected by react-redux:
     let { dispatch } = this.props
 
-    // Note: this won’t work:
+    // Note: this won't work:
     // TodoActionCreators.addTodo('Use Redux')
 
-    // You’re just calling a function that creates an action.
+    // You're just calling a function that creates an action.
     // You must dispatch the action, too!
 
     // This will work:
@@ -72,7 +72,7 @@ class TodoListContainer extends Component {
     // Injected by react-redux:
     let { todos, dispatch } = this.props
 
-    // Here’s a good use case for bindActionCreators:
+    // Here's a good use case for bindActionCreators:
     // You want a child component to be completely unaware of Redux.
 
     let boundActionCreators = bindActionCreators(TodoActionCreators, dispatch)
@@ -102,6 +102,6 @@ export default connect(
 
 #### Tips
 
-* You might ask: why don’t we bind the action creators to the store instance right away, like in classical Flux? The problem is that this won’t work well with universal apps that need to render on the server. Most likely you want to have a separate store instance per request so you can prepare them with different data, but binding action creators during their definition means you’re stuck with a single store instance for all requests.
+* You might ask: why don't we bind the action creators to the store instance right away, like in classical Flux? The problem is that this won't work well with universal apps that need to render on the server. Most likely you want to have a separate store instance per request so you can prepare them with different data, but binding action creators during their definition means you're stuck with a single store instance for all requests.
 
-* If you use ES5, instead of `import * as` syntax you can just pass `require('./TodoActionCreators')` to `bindActionCreators` as the first argument. The only thing it cares about is that the values of the `actionCreators` arguments are functions. The module system doesn’t matter.
+* If you use ES5, instead of `import * as` syntax you can just pass `require('./TodoActionCreators')` to `bindActionCreators` as the first argument. The only thing it cares about is that the values of the `actionCreators` arguments are functions. The module system doesn't matter.
diff --git a/docs/api/combineReducers.md b/docs/api/combineReducers.md
index 66c21187d8..76a4b1b8b8 100644
--- a/docs/api/combineReducers.md
+++ b/docs/api/combineReducers.md
@@ -1,6 +1,6 @@
 # `combineReducers(reducers)`
 
-As your app grows more complex, you’ll want to split your [reducing function](../Glossary.md#reducer) into separate functions, each managing independent parts of the [state](../Glossary.md#state).
+As your app grows more complex, you'll want to split your [reducing function](../Glossary.md#reducer) into separate functions, each managing independent parts of the [state](../Glossary.md#state).
 
 The `combineReducers` helper function turns an object whose values are different reducing functions into a single reducing function you can pass to [`createStore`](createStore.md).
 
@@ -35,7 +35,7 @@ A popular convention is to name reducers after the state slices they manage, so
 
 #### Notes
 
-This function is mildly opinionated and is skewed towards helping beginners avoid common pitfalls. This is why it attempts to enforce some rules that you don’t have to follow if you write the root reducer manually.
+This function is mildly opinionated and is skewed towards helping beginners avoid common pitfalls. This is why it attempts to enforce some rules that you don't have to follow if you write the root reducer manually.
 
 Any reducer passed to `combineReducers` must satisfy these rules:
 
@@ -118,4 +118,4 @@ console.log(store.getState())
 
 * This helper is just a convenience! You can write your own `combineReducers` that [works differently](https://github.com/acdlite/reduce-reducers), or even assemble the state object from the child reducers manually and write a root reducing function explicitly, like you would write any other function.
 
-* You may call `combineReducers` at any level of the reducer hierarchy. It doesn’t have to happen at the top. In fact you may use it again to split the child reducers that get too complicated into independent grandchildren, and so on.
+* You may call `combineReducers` at any level of the reducer hierarchy. It doesn't have to happen at the top. In fact you may use it again to split the child reducers that get too complicated into independent grandchildren, and so on.
diff --git a/docs/api/compose.md b/docs/api/compose.md
index a1c5494504..887de902d0 100644
--- a/docs/api/compose.md
+++ b/docs/api/compose.md
@@ -34,4 +34,4 @@ const store = createStore(
 
 #### Tips
 
-* All `compose` does is let you write deeply nested function transformations without the rightward drift of the code. Don’t give it too much credit!
+* All `compose` does is let you write deeply nested function transformations without the rightward drift of the code. Don't give it too much credit!
diff --git a/docs/api/createStore.md b/docs/api/createStore.md
index 2eedb78fe7..8ccdec7d13 100644
--- a/docs/api/createStore.md
+++ b/docs/api/createStore.md
@@ -42,14 +42,14 @@ console.log(store.getState())
 
 #### Tips
 
-* Don’t create more than one store in an application! Instead, use [`combineReducers`](combineReducers.md) to create a single root reducer out of many.
+* Don't create more than one store in an application! Instead, use [`combineReducers`](combineReducers.md) to create a single root reducer out of many.
 
-* It is up to you to choose the state format. You can use plain objects or something like [Immutable](http://facebook.github.io/immutable-js/). If you’re not sure, start with plain objects.
+* It is up to you to choose the state format. You can use plain objects or something like [Immutable](http://facebook.github.io/immutable-js/). If you're not sure, start with plain objects.
 
-* If your state is a plain object, make sure you never mutate it! For example, instead of returning something like `Object.assign(state, newData)` from your reducers, return `Object.assign({}, state, newData)`. This way you don’t override the previous `state`. You can also write `return { ...state, ...newData }` if you enable the [object spread operator proposal](../recipes/UsingObjectSpreadOperator.md).
+* If your state is a plain object, make sure you never mutate it! For example, instead of returning something like `Object.assign(state, newData)` from your reducers, return `Object.assign({}, state, newData)`. This way you don't override the previous `state`. You can also write `return { ...state, ...newData }` if you enable the [object spread operator proposal](../recipes/UsingObjectSpreadOperator.md).
 
 * For universal apps that run on the server, create a store instance with every request so that they are isolated. Dispatch a few data fetching actions to a store instance and wait for them to complete before rendering the app on the server.
 
-* When a store is created, Redux dispatches a dummy action to your reducer to populate the store with the initial state. You are not meant to handle the dummy action directly. Just remember that your reducer should return some kind of initial state if the state given to it as the first argument is `undefined`, and you’re all set.
+* When a store is created, Redux dispatches a dummy action to your reducer to populate the store with the initial state. You are not meant to handle the dummy action directly. Just remember that your reducer should return some kind of initial state if the state given to it as the first argument is `undefined`, and you're all set.
 
 * To apply multiple store enhancers, you may use [`compose()`](./compose.md).
diff --git a/docs/basics/Actions.md b/docs/basics/Actions.md
index 89cbc1fae0..a03fc3be40 100644
--- a/docs/basics/Actions.md
+++ b/docs/basics/Actions.md
@@ -1,10 +1,10 @@
 # Actions
 
-First, let’s define some actions.
+First, let's define some actions.
 
 **Actions** are payloads of information that send data from your application to your store. They are the *only* source of information for the store. You send them to the store using [`store.dispatch()`](../api/Store.md#dispatch).
 
-Here’s an example action which represents adding a new todo item:
+Here's an example action which represents adding a new todo item:
 
 ```js
 const ADD_TODO = 'ADD_TODO'
@@ -25,11 +25,11 @@ import { ADD_TODO, REMOVE_TODO } from '../actionTypes'
 
 >##### Note on Boilerplate
 
->You don’t have to define action type constants in a separate file, or even to define them at all. For a small project, it might be easier to just use string literals for action types. However, there are some benefits to explicitly declaring constants in larger codebases. Read [Reducing Boilerplate](../recipes/ReducingBoilerplate.md) for more practical tips on keeping your codebase clean.
+>You don't have to define action type constants in a separate file, or even to define them at all. For a small project, it might be easier to just use string literals for action types. However, there are some benefits to explicitly declaring constants in larger codebases. Read [Reducing Boilerplate](../recipes/ReducingBoilerplate.md) for more practical tips on keeping your codebase clean.
 
-Other than `type`, the structure of an action object is really up to you. If you’re interested, check out [Flux Standard Action](https://github.com/acdlite/flux-standard-action) for recommendations on how actions could be constructed.
+Other than `type`, the structure of an action object is really up to you. If you're interested, check out [Flux Standard Action](https://github.com/acdlite/flux-standard-action) for recommendations on how actions could be constructed.
 
-We’ll add one more action type to describe a user ticking off a todo as completed. We refer to a particular todo by `index` because we store them in an array. In a real app, it is wiser to generate a unique ID every time something new is created.
+We'll add one more action type to describe a user ticking off a todo as completed. We refer to a particular todo by `index` because we store them in an array. In a real app, it is wiser to generate a unique ID every time something new is created.
 
 ```js
 {
@@ -38,9 +38,9 @@ We’ll add one more action type to describe a user ticking off a todo as comple
 }
 ```
 
-It’s a good idea to pass as little data in each action as possible. For example, it’s better to pass `index` than the whole todo object.
+It's a good idea to pass as little data in each action as possible. For example, it's better to pass `index` than the whole todo object.
 
-Finally, we’ll add one more action type for changing the currently visible todos.
+Finally, we'll add one more action type for changing the currently visible todos.
 
 ```js
 {
@@ -93,7 +93,7 @@ const boundAddTodo = (text) => dispatch(addTodo(text))
 const boundCompleteTodo = (index) => dispatch(completeTodo(index))
 ```
 
-Now you’ll be able to call them directly:
+Now you'll be able to call them directly:
 
 ```
 boundAddTodo(text)
@@ -102,7 +102,7 @@ boundCompleteTodo(index)
 
 The `dispatch()` function can be accessed directly from the store as [`store.dispatch()`](../api/Store.md#dispatch), but more likely you'll access it using a helper like [react-redux](http://github.com/gaearon/react-redux)'s `connect()`. You can use [`bindActionCreators()`](../api/bindActionCreators.md) to automatically bind many action creators to a `dispatch()` function.
 
-Action creators can also be asynchronous and have side-effects. You can read about [async actions](../advanced/AsyncActions.md) in the [advanced tutorial](../advanced/README.md) to learn how to handle AJAX responses and compose action creators into async control flow. Don’t skip ahead to async actions until you’ve completed the basics tutorial, as it covers other important concepts that are prerequisite for the advanced tutorial and async actions.
+Action creators can also be asynchronous and have side-effects. You can read about [async actions](../advanced/AsyncActions.md) in the [advanced tutorial](../advanced/README.md) to learn how to handle AJAX responses and compose action creators into async control flow. Don't skip ahead to async actions until you've completed the basics tutorial, as it covers other important concepts that are prerequisite for the advanced tutorial and async actions.
 
 ## Source Code
 
@@ -146,5 +146,5 @@ export function setVisibilityFilter(filter) {
 
 ## Next Steps
 
-Now let’s [define some reducers](Reducers.md) to specify how the state updates when you dispatch these actions!
+Now let's [define some reducers](Reducers.md) to specify how the state updates when you dispatch these actions!
 
diff --git a/docs/basics/DataFlow.md b/docs/basics/DataFlow.md
index 8eccb89040..00d07f205f 100644
--- a/docs/basics/DataFlow.md
+++ b/docs/basics/DataFlow.md
@@ -18,7 +18,7 @@ The data lifecycle in any Redux app follows these 4 steps:
     { type: 'ADD_TODO', text: 'Read the Redux docs.' }
     ```
 
-  Think of an action as a very brief snippet of news. “Mary liked article 42.” or “‘Read the Redux docs.’ was added to the list of todos.”
+  Think of an action as a very brief snippet of news. “Mary liked article 42.” or “‘Read the Redux docs.' was added to the list of todos.”
 
   You can call [`store.dispatch(action)`](../api/Store.md#dispatch) from anywhere in your app, including components and XHR callbacks, or even at scheduled intervals.
 
@@ -48,13 +48,13 @@ The data lifecycle in any Redux app follows these 4 steps:
     let nextState = todoApp(previousState, action)
     ```
 
-    Note that a reducer is a pure function. It only *computes* the next state. It should be completely predictable: calling it with the same inputs many times should produce the same outputs. It shouldn’t perform any side effects like API calls or router transitions. These should happen before an action is dispatched.
+    Note that a reducer is a pure function. It only *computes* the next state. It should be completely predictable: calling it with the same inputs many times should produce the same outputs. It shouldn't perform any side effects like API calls or router transitions. These should happen before an action is dispatched.
 
 3. **The root reducer may combine the output of multiple reducers into a single state tree.**
 
   How you structure the root reducer is completely up to you. Redux ships with a [`combineReducers()`](../api/combineReducers.md) helper function, useful for “splitting” the root reducer into separate functions that each manage one branch of the state tree.
 
-  Here’s how [`combineReducers()`](../api/combineReducers.md) works. Let’s say you have two reducers, one for a list of todos, and another for the currently selected filter setting:
+  Here's how [`combineReducers()`](../api/combineReducers.md) works. Let's say you have two reducers, one for a list of todos, and another for the currently selected filter setting:
 
     ```js
     function todos(state = [], action) {
@@ -89,7 +89,7 @@ The data lifecycle in any Redux app follows these 4 steps:
     }
     ```
 
-  While [`combineReducers()`](../api/combineReducers.md) is a handy helper utility, you don’t have to use it; feel free to write your own root reducer!
+  While [`combineReducers()`](../api/combineReducers.md) is a handy helper utility, you don't have to use it; feel free to write your own root reducer!
 
 4. **The Redux store saves the complete state tree returned by the root reducer.**
 
@@ -99,7 +99,7 @@ The data lifecycle in any Redux app follows these 4 steps:
 
 ## Next Steps
 
-Now that you know how Redux works, let’s [connect it to a React app](UsageWithReact.md).
+Now that you know how Redux works, let's [connect it to a React app](UsageWithReact.md).
 
 >##### Note for Advanced Users
->If you’re already familiar with the basic concepts and have previously completed this tutorial, don’t forget to check out [async flow](../advanced/AsyncFlow.md) in the [advanced tutorial](../advanced/README.md) to learn how middleware transforms [async actions](../advanced/AsyncActions.md) before they reach the reducer.
+>If you're already familiar with the basic concepts and have previously completed this tutorial, don't forget to check out [async flow](../advanced/AsyncFlow.md) in the [advanced tutorial](../advanced/README.md) to learn how middleware transforms [async actions](../advanced/AsyncActions.md) before they reach the reducer.
diff --git a/docs/basics/README.md b/docs/basics/README.md
index f2d2767f2b..1e51f4d0fa 100644
--- a/docs/basics/README.md
+++ b/docs/basics/README.md
@@ -1,8 +1,8 @@
 # Basics
 
-Don’t be fooled by all the fancy talk about reducers, middleware, store enhancers—Redux is incredibly simple. If you’ve ever built a Flux application, you will feel right at home. If you’re new to Flux, it’s easy too!
+Don't be fooled by all the fancy talk about reducers, middleware, store enhancers—Redux is incredibly simple. If you've ever built a Flux application, you will feel right at home. If you're new to Flux, it's easy too!
 
-In this guide, we’ll walk through the process of creating a simple Todo app.
+In this guide, we'll walk through the process of creating a simple Todo app.
 
 * [Actions](Actions.md)
 * [Reducers](Reducers.md)
diff --git a/docs/basics/Reducers.md b/docs/basics/Reducers.md
index dd3db55e66..ee9cb0bda8 100644
--- a/docs/basics/Reducers.md
+++ b/docs/basics/Reducers.md
@@ -1,17 +1,17 @@
 # Reducers
 
-[Actions](./Actions.md) describe the fact that *something happened*, but don’t specify how the application’s state changes in response. This is the job of a reducer.
+[Actions](./Actions.md) describe the fact that *something happened*, but don't specify how the application's state changes in response. This is the job of a reducer.
 
 ## Designing the State Shape
 
-In Redux, all application state is stored as a single object. It’s a good idea to think of its shape before writing any code. What’s the minimal representation of your app’s state as an object?
+In Redux, all application state is stored as a single object. It's a good idea to think of its shape before writing any code. What's the minimal representation of your app's state as an object?
 
 For our todo app, we want to store two different things:
 
 * The currently selected visibility filter;
 * The actual list of todos.
 
-You’ll often find that you need to store some data, as well as some UI state, in the state tree. This is fine, but try to keep the data separate from the UI state.
+You'll often find that you need to store some data, as well as some UI state, in the state tree. This is fine, but try to keep the data separate from the UI state.
 
 ```js
 {
@@ -31,27 +31,27 @@ You’ll often find that you need to store some data, as well as some UI state,
 
 >##### Note on Relationships
 
->In a more complex app, you’re going to want different entities to reference each other. We suggest that you keep your state as normalized as possible, without any nesting. Keep every entity in an object stored with an ID as a key, and use IDs to reference it from other entities, or lists. Think of the app’s state as a database. This approach is described in [normalizr's](https://github.com/gaearon/normalizr) documentation in detail. For example, keeping `todosById: { id -> todo }` and `todos: array<id>` inside the state would be a better idea in a real app, but we’re keeping the example simple.
+>In a more complex app, you're going to want different entities to reference each other. We suggest that you keep your state as normalized as possible, without any nesting. Keep every entity in an object stored with an ID as a key, and use IDs to reference it from other entities, or lists. Think of the app's state as a database. This approach is described in [normalizr's](https://github.com/gaearon/normalizr) documentation in detail. For example, keeping `todosById: { id -> todo }` and `todos: array<id>` inside the state would be a better idea in a real app, but we're keeping the example simple.
 
 ## Handling Actions
 
-Now that we’ve decided what our state object looks like, we’re ready to write a reducer for it. The reducer is a pure function that takes the previous state and an action, and returns the next state.
+Now that we've decided what our state object looks like, we're ready to write a reducer for it. The reducer is a pure function that takes the previous state and an action, and returns the next state.
 
 ```js
 (previousState, action) => newState
 ```
 
-It’s called a reducer because it’s the type of function you would pass to [`Array.prototype.reduce(reducer, ?initialValue)`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce). It’s very important that the reducer stays pure. Things you should **never** do inside a reducer:
+It's called a reducer because it's the type of function you would pass to [`Array.prototype.reduce(reducer, ?initialValue)`](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array/Reduce). It's very important that the reducer stays pure. Things you should **never** do inside a reducer:
 
 * Mutate its arguments;
 * Perform side effects like API calls and routing transitions;
 * Call non-pure functions, e.g. `Date.now()` or `Math.random()`.
 
-We’ll explore how to perform side effects in the [advanced walkthrough](../advanced/README.md). For now, just remember that the reducer must be pure. **Given the same arguments, it should calculate the next state and return it. No surprises. No side effects. No API calls. No mutations. Just a calculation.**
+We'll explore how to perform side effects in the [advanced walkthrough](../advanced/README.md). For now, just remember that the reducer must be pure. **Given the same arguments, it should calculate the next state and return it. No surprises. No side effects. No API calls. No mutations. Just a calculation.**
 
-With this out of the way, let’s start writing our reducer by gradually teaching it to understand the [actions](Actions.md) we defined earlier.
+With this out of the way, let's start writing our reducer by gradually teaching it to understand the [actions](Actions.md) we defined earlier.
 
-We’ll start by specifying the initial state. Redux will call our reducer with an `undefined` state for the first time. This is our chance to return the initial state of our app:
+We'll start by specifying the initial state. Redux will call our reducer with an `undefined` state for the first time. This is our chance to return the initial state of our app:
 
 ```js
 import { VisibilityFilters } from './actions'
@@ -66,7 +66,7 @@ function todoApp(state, action) {
     return initialState
   }
 
-  // For now, don’t handle any actions
+  // For now, don't handle any actions
   // and just return the state given to us.
   return state
 }
@@ -76,13 +76,13 @@ One neat trick is to use the [ES6 default arguments syntax](https://developer.mo
 
 ```js
 function todoApp(state = initialState, action) {
-  // For now, don’t handle any actions
+  // For now, don't handle any actions
   // and just return the state given to us.
   return state
 }
 ```
 
-Now let’s handle `SET_VISIBILITY_FILTER`. All it needs to do is to change `visibilityFilter` on the state. Easy:
+Now let's handle `SET_VISIBILITY_FILTER`. All it needs to do is to change `visibilityFilter` on the state. Easy:
 
 ```js
 function todoApp(state = initialState, action) {
@@ -99,23 +99,23 @@ function todoApp(state = initialState, action) {
 
 Note that:
 
-1. **We don’t mutate the `state`.** We create a copy with [`Object.assign()`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign). `Object.assign(state, { visibilityFilter: action.filter })` is also wrong: it will mutate the first argument. You **must** supply an empty object as the first parameter. You can also enable the [object spread operator proposal](../recipes/UsingObjectSpreadOperator.md) to write `{ ...state, ...newState }` instead.
+1. **We don't mutate the `state`.** We create a copy with [`Object.assign()`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign). `Object.assign(state, { visibilityFilter: action.filter })` is also wrong: it will mutate the first argument. You **must** supply an empty object as the first parameter. You can also enable the [object spread operator proposal](../recipes/UsingObjectSpreadOperator.md) to write `{ ...state, ...newState }` instead.
 
-2. **We return the previous `state` in the `default` case.** It’s important to return the previous `state` for any unknown action.
+2. **We return the previous `state` in the `default` case.** It's important to return the previous `state` for any unknown action.
 
 >##### Note on `Object.assign`
 
->[`Object.assign()`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) is a part of ES6, but is not implemented by most browsers yet. You’ll need to either use a polyfill, a [Babel plugin](https://www.npmjs.com/package/babel-plugin-transform-object-assign), or a helper from another library like [`_.assign()`](https://lodash.com/docs#assign).
+>[`Object.assign()`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) is a part of ES6, but is not implemented by most browsers yet. You'll need to either use a polyfill, a [Babel plugin](https://www.npmjs.com/package/babel-plugin-transform-object-assign), or a helper from another library like [`_.assign()`](https://lodash.com/docs#assign).
 
 >##### Note on `switch` and Boilerplate
 
 >The `switch` statement is *not* the real boilerplate. The real boilerplate of Flux is conceptual: the need to emit an update, the need to register the Store with a Dispatcher, the need for the Store to be an object (and the complications that arise when you want a universal app). Redux solves these problems by using pure reducers instead of event emitters.
 
->It’s unfortunate that many still choose a framework based on whether it uses `switch` statements in the documentation. If you don’t like `switch`, you can use a custom `createReducer` function that accepts a handler map, as shown in [“reducing boilerplate”](../recipes/ReducingBoilerplate.md#reducers).
+>It's unfortunate that many still choose a framework based on whether it uses `switch` statements in the documentation. If you don't like `switch`, you can use a custom `createReducer` function that accepts a handler map, as shown in [“reducing boilerplate”](../recipes/ReducingBoilerplate.md#reducers).
 
 ## Handling More Actions
 
-We have two more actions to handle! Let’s extend our reducer to handle `ADD_TODO`.
+We have two more actions to handle! Let's extend our reducer to handle `ADD_TODO`.
 
 ```js
 function todoApp(state = initialState, action) {
@@ -142,7 +142,7 @@ function todoApp(state = initialState, action) {
 
 Just like before, we never write directly to `state` or its fields, and instead we return new objects. The new `todos` is equal to the old `todos` concatenated with a single new item at the end. The fresh todo was constructed using the data from the action.
 
-Finally, the implementation of the `TOGGLE_TODO` handler shouldn’t come as a complete surprise:
+Finally, the implementation of the `TOGGLE_TODO` handler shouldn't come as a complete surprise:
 
 ```js
 case TOGGLE_TODO:
@@ -158,7 +158,7 @@ case TOGGLE_TODO:
   })
 ```
 
-Because we want to update a specific item in the array without resorting to mutations, we have to create a new array with the same items except the item at the index. If you find yourself often writing such operations, it’s a good idea to use a helper like [react-addons-update](https://facebook.github.io/react/docs/update.html), [updeep](https://github.com/substantial/updeep), or even a library like [Immutable](http://facebook.github.io/immutable-js/) that has native support for deep updates. Just remember to never assign to anything inside the `state` unless you clone it first.
+Because we want to update a specific item in the array without resorting to mutations, we have to create a new array with the same items except the item at the index. If you find yourself often writing such operations, it's a good idea to use a helper like [react-addons-update](https://facebook.github.io/react/docs/update.html), [updeep](https://github.com/substantial/updeep), or even a library like [Immutable](http://facebook.github.io/immutable-js/) that has native support for deep updates. Just remember to never assign to anything inside the `state` unless you clone it first.
 
 ## Splitting Reducers
 
@@ -242,9 +242,9 @@ function todoApp(state = initialState, action) {
 }
 ```
 
-Note that `todos` also accepts `state`—but it’s an array! Now `todoApp` just gives it the slice of the state to manage, and `todos` knows how to update just that slice. **This is called *reducer composition*, and it’s the fundamental pattern of building Redux apps.**
+Note that `todos` also accepts `state`—but it's an array! Now `todoApp` just gives it the slice of the state to manage, and `todos` knows how to update just that slice. **This is called *reducer composition*, and it's the fundamental pattern of building Redux apps.**
 
-Let’s explore reducer composition more. Can we also extract a reducer managing just `visibilityFilter`? We can:
+Let's explore reducer composition more. Can we also extract a reducer managing just `visibilityFilter`? We can:
 
 ```js
 function visibilityFilter(state = SHOW_ALL, action) {
@@ -257,7 +257,7 @@ function visibilityFilter(state = SHOW_ALL, action) {
 }
 ```
 
-Now we can rewrite the main reducer as a function that calls the reducers managing parts of the state, and combines them into a single object. It also doesn’t need to know the complete initial state anymore. It’s enough that the child reducers return their initial state when given `undefined` at first.
+Now we can rewrite the main reducer as a function that calls the reducers managing parts of the state, and combines them into a single object. It also doesn't need to know the complete initial state anymore. It's enough that the child reducers return their initial state when given `undefined` at first.
 
 ```js
 function todos(state = [], action) {
@@ -349,7 +349,7 @@ function reducer(state = {}, action) {
 }
 ```
 
-All [`combineReducers()`](../api/combineReducers.md) does is generate a function that calls your reducers **with the slices of state selected according to their keys**, and combining their results into a single object again. [It’s not magic.](https://github.com/reactjs/redux/issues/428#issuecomment-129223274)
+All [`combineReducers()`](../api/combineReducers.md) does is generate a function that calls your reducers **with the slices of state selected according to their keys**, and combining their results into a single object again. [It's not magic.](https://github.com/reactjs/redux/issues/428#issuecomment-129223274)
 
 >##### Note for ES6 Savvy Users
 
@@ -362,7 +362,7 @@ All [`combineReducers()`](../api/combineReducers.md) does is generate a function
 >const todoApp = combineReducers(reducers)
 >```
 >
->Because `import *` is still new syntax, we don’t use it anymore in the documentation to avoid [confusion](https://github.com/reactjs/redux/issues/428#issuecomment-129223274), but you may encounter it in some community examples.
+>Because `import *` is still new syntax, we don't use it anymore in the documentation to avoid [confusion](https://github.com/reactjs/redux/issues/428#issuecomment-129223274), but you may encounter it in some community examples.
 
 ## Source Code
 
@@ -416,4 +416,4 @@ export default todoApp
 
 ## Next Steps
 
-Next, we’ll explore how to [create a Redux store](Store.md) that holds the state and takes care of calling your reducer when you dispatch an action.
+Next, we'll explore how to [create a Redux store](Store.md) that holds the state and takes care of calling your reducer when you dispatch an action.
diff --git a/docs/basics/Store.md b/docs/basics/Store.md
index ae2f32258d..8cc92f3495 100644
--- a/docs/basics/Store.md
+++ b/docs/basics/Store.md
@@ -10,9 +10,9 @@ The **Store** is the object that brings them together. The store has the followi
 * Registers listeners via [`subscribe(listener)`](../api/Store.md#subscribe);
 * Handles unregistering of listeners via the function returned by [`subscribe(listener)`](../api/Store.md#subscribe).
 
-It’s important to note that you’ll only have a single store in a Redux application. When you want to split your data handling logic, you’ll use [reducer composition](Reducers.md#splitting-reducers) instead of many stores.
+It's important to note that you'll only have a single store in a Redux application. When you want to split your data handling logic, you'll use [reducer composition](Reducers.md#splitting-reducers) instead of many stores.
 
-It’s easy to create a store if you have a reducer. In the [previous section](Reducers.md), we used [`combineReducers()`](../api/combineReducers.md) to combine several reducers into one. We will now import it, and pass it to [`createStore()`](../api/createStore.md).
+It's easy to create a store if you have a reducer. In the [previous section](Reducers.md), we used [`combineReducers()`](../api/combineReducers.md) to combine several reducers into one. We will now import it, and pass it to [`createStore()`](../api/createStore.md).
 
 ```js
 import { createStore } from 'redux'
@@ -28,7 +28,7 @@ let store = createStore(todoApp, window.STATE_FROM_SERVER)
 
 ## Dispatching Actions
 
-Now that we have created a store, let’s verify our program works! Even without any UI, we can already test the update logic.
+Now that we have created a store, let's verify our program works! Even without any UI, we can already test the update logic.
 
 ```js
 import { addTodo, toggleTodo, setVisibilityFilter, VisibilityFilters } from './actions'
@@ -58,7 +58,7 @@ You can see how this causes the state held by the store to change:
 
 <img src='http://i.imgur.com/zMMtoMz.png' width='70%'>
 
-We specified the behavior of our app before we even started writing the UI. We won’t do this in this tutorial, but at this point you can write tests for your reducers and action creators. You won’t need to mock anything because they are just functions. Call them, and make assertions on what they return.
+We specified the behavior of our app before we even started writing the UI. We won't do this in this tutorial, but at this point you can write tests for your reducers and action creators. You won't need to mock anything because they are just functions. Call them, and make assertions on what they return.
 
 ## Source Code
 
diff --git a/docs/basics/UsageWithReact.md b/docs/basics/UsageWithReact.md
index 82dcac4a79..2542b3d284 100644
--- a/docs/basics/UsageWithReact.md
+++ b/docs/basics/UsageWithReact.md
@@ -14,13 +14,13 @@ We will use React to build our simple todo app.
 npm install --save react-redux
 ```
 
-If you don’t use npm, you may grab the latest UMD build from npmcdn (either a [development](https://npmcdn.com/react-redux@latest/dist/react-redux.js) or a [production](https://npmcdn.com/react-redux@latest/dist/react-redux.min.js) build). The UMD build exports a global called `window.ReactRedux` if you add it to your page via a `<script>` tag.
+If you don't use npm, you may grab the latest UMD build from npmcdn (either a [development](https://npmcdn.com/react-redux@latest/dist/react-redux.js) or a [production](https://npmcdn.com/react-redux@latest/dist/react-redux.min.js) build). The UMD build exports a global called `window.ReactRedux` if you add it to your page via a `<script>` tag.
 
 ## Presentational and Container Components
 
-React bindings for Redux embrace the idea of **separating presentational and container components**. If you’re not familiar with these terms, [read about them first](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0), and then come back. They are important, so we’ll wait!
+React bindings for Redux embrace the idea of **separating presentational and container components**. If you're not familiar with these terms, [read about them first](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0), and then come back. They are important, so we'll wait!
 
-Finished reading the article? Let’s recount their differences:
+Finished reading the article? Let's recount their differences:
 
 <table>
     <thead>
@@ -59,13 +59,13 @@ Finished reading the article? Let’s recount their differences:
     </tbody>
 </table>
 
-Most of the components we’ll write will be presentational, but we’ll need to generate a few container components to connect them to the Redux store.
+Most of the components we'll write will be presentational, but we'll need to generate a few container components to connect them to the Redux store.
 
-Technically you could write the container components by hand using [`store.subscribe()`](../api/Store.md#subscribe). We don’t advise you to do this because React Redux makes many performance optimizations that are hard to do by hand. For this reason, rather than write container components, we will generate them using the [`connect()`](https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) function provided by React Redux, as you will see below.
+Technically you could write the container components by hand using [`store.subscribe()`](../api/Store.md#subscribe). We don't advise you to do this because React Redux makes many performance optimizations that are hard to do by hand. For this reason, rather than write container components, we will generate them using the [`connect()`](https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) function provided by React Redux, as you will see below.
 
 ## Designing Component Hierarchy
 
-Remember how we [designed the shape of the root state object](Reducers.md)? It’s time we design the UI hierarchy to match it. This is not a Redux-specific task. [Thinking in React](https://facebook.github.io/react/docs/thinking-in-react.html) is a great tutorial that explains the process.
+Remember how we [designed the shape of the root state object](Reducers.md)? It's time we design the UI hierarchy to match it. This is not a Redux-specific task. [Thinking in React](https://facebook.github.io/react/docs/thinking-in-react.html) is a great tutorial that explains the process.
 
 Our design brief is simple. We want to show a list of todo items. On click, a todo item is crossed out as completed. We want to show a field where the user may add a new todo. In the footer, we want to show a toggle to show all, only completed, or only active todos.
 
@@ -85,7 +85,7 @@ I see the following presentational components and their props emerge from this b
 * **`Footer`** is where we let the user change currently visible todos.
 * **`App`** is the root component that renders everything else.
 
-They describe the *look* but don’t know *where* the data comes from, or *how* to change it. They only render what’s given to them. If you migrate from Redux to something else, you’ll be able to keep all these components exactly the same. They have no dependency on Redux.
+They describe the *look* but don't know *where* the data comes from, or *how* to change it. They only render what's given to them. If you migrate from Redux to something else, you'll be able to keep all these components exactly the same. They have no dependency on Redux.
 
 ### Container Components
 
@@ -97,19 +97,19 @@ We will also need some container components to connect the presentational compon
 
 ### Other Components
 
-Sometimes it’s hard to tell if some component should be a presentational component or a container. For example, sometimes form and function are really coupled together, such as in case of this tiny component:
+Sometimes it's hard to tell if some component should be a presentational component or a container. For example, sometimes form and function are really coupled together, such as in case of this tiny component:
 
 * **`AddTodo`** is an input field with an “Add” button
 
-Technically we could split it into two components but it might be too early at this stage. It’s fine to mix presentation and logic in a component that is very small. As it grows, it will be more obvious how to split it, so we’ll leave it mixed.
+Technically we could split it into two components but it might be too early at this stage. It's fine to mix presentation and logic in a component that is very small. As it grows, it will be more obvious how to split it, so we'll leave it mixed.
 
 ## Implementing Components
 
-Let’s write the components! We begin with the presentational components so we don’t need to think about binding to Redux yet.
+Let's write the components! We begin with the presentational components so we don't need to think about binding to Redux yet.
 
 ### Presentational Components
 
-These are all normal React components, so we won’t examine them in detail. We write functional stateless components unless we need to use local state or the lifecycle methods. This doesn’t mean that presentational components *have to* be functions—it’s just easier to define them this way. If and when you need to add local state, lifecycle methods, or performance optimizations, you can convert them to classes.
+These are all normal React components, so we won't examine them in detail. We write functional stateless components unless we need to use local state or the lifecycle methods. This doesn't mean that presentational components *have to* be functions—it's just easier to define them this way. If and when you need to add local state, lifecycle methods, or performance optimizations, you can convert them to classes.
 
 #### `components/Todo.js`
 
@@ -245,7 +245,7 @@ export default App
 
 ### Container Components
 
-Now it’s time to hook up those presentational components to Redux by creating some containers. Technically, a container component is just a React component that uses [`store.subscribe()`](../api/Store.md#subscribe) to read a part of the Redux state tree and supply props to a presentational component it renders. You could write a container component by hand, but we suggest instead generating container components with the React Redux library’s [`connect()`](https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) function, which provides many useful optimizations to prevent unnecessary re-renders. (One result of this is that you shouldn’t have to worry about the [React performance suggestion](https://facebook.github.io/react/docs/advanced-performance.html) of implementing `shouldComponentUpdate` yourself.)
+Now it's time to hook up those presentational components to Redux by creating some containers. Technically, a container component is just a React component that uses [`store.subscribe()`](../api/Store.md#subscribe) to read a part of the Redux state tree and supply props to a presentational component it renders. You could write a container component by hand, but we suggest instead generating container components with the React Redux library's [`connect()`](https://github.com/reactjs/react-redux/blob/master/docs/api.md#connectmapstatetoprops-mapdispatchtoprops-mergeprops-options) function, which provides many useful optimizations to prevent unnecessary re-renders. (One result of this is that you shouldn't have to worry about the [React performance suggestion](https://facebook.github.io/react/docs/advanced-performance.html) of implementing `shouldComponentUpdate` yourself.)
 
 To use `connect()`, you need to define a special function called `mapStateToProps` that tells how to transform the current Redux store state into the props you want to pass to a presentational component you are wrapping. For example, `VisibleTodoList` needs to calculate `todos` to pass to the `TodoList`, so we define a function that filters the `state.todos` according to the `state.visibilityFilter`, and use it in its `mapStateToProps`:
 
diff --git a/docs/introduction/Ecosystem.md b/docs/introduction/Ecosystem.md
index 67676929cd..1bb684d44b 100644
--- a/docs/introduction/Ecosystem.md
+++ b/docs/introduction/Ecosystem.md
@@ -4,7 +4,7 @@ Redux is a tiny library, but its contracts and APIs are carefully chosen to spaw
 
 For an extensive list of everything related to Redux, we recommend [Awesome Redux](https://github.com/xgrommx/awesome-redux). It contains examples, boilerplates, middleware, utility libraries, and more. [React/Redux Links](https://github.com/markerikson/react-redux-links) contains tutorials and other useful resources for anyone learning React or Redux, and [Redux Ecosystem Links](https://github.com/markerikson/redux-ecosystem-links) lists many Redux-related libraries and addons.
 
-On this page we will only feature a few of them that the Redux maintainers have vetted personally. Don’t let this discourage you from trying the rest of them! The ecosystem is growing too fast, and we have a limited time to look at everything. Consider these the “staff picks”, and don’t hesitate to submit a PR if you’ve built something wonderful with Redux.
+On this page we will only feature a few of them that the Redux maintainers have vetted personally. Don't let this discourage you from trying the rest of them! The ecosystem is growing too fast, and we have a limited time to look at everything. Consider these the “staff picks”, and don't hesitate to submit a PR if you've built something wonderful with Redux.
 
 ## Learning Redux
 
@@ -24,7 +24,7 @@ On this page we will only feature a few of them that the Redux maintainers have
 * [Redux Tutorial](https://github.com/happypoulp/redux-tutorial)
 * [Redux Egghead Course Notes](https://github.com/tayiorbeii/egghead.io_redux_course_notes)
 * [Integrating Data with React Native](http://makeitopen.com/tutorials/building-the-f8-app/data/)
-* [What the Flux?! Let’s Redux.](https://blog.andyet.com/2015/08/06/what-the-flux-lets-redux)
+* [What the Flux?! Let's Redux.](https://blog.andyet.com/2015/08/06/what-the-flux-lets-redux)
 * [Leveling Up with React: Redux](https://css-tricks.com/learning-react-redux/)
 * [A cartoon intro to Redux](https://code-cartoons.com/a-cartoon-intro-to-redux-3afb775501a6)
 * [Understanding Redux](http://www.youhavetolearncomputers.com/blog/2015/9/15/a-conceptual-overview-of-redux-or-how-i-fell-in-love-with-a-javascript-state-container)
diff --git a/docs/introduction/Examples.md b/docs/introduction/Examples.md
index 598eeae4d6..7b47272a01 100644
--- a/docs/introduction/Examples.md
+++ b/docs/introduction/Examples.md
@@ -81,7 +81,7 @@ npm start
 open http://localhost:3000/
 ```
 
-This is the classical [TodoMVC](http://todomvc.com/) example. It’s here for the sake of comparison, but it covers the same points as the Todos example.
+This is the classical [TodoMVC](http://todomvc.com/) example. It's here for the sake of comparison, but it covers the same points as the Todos example.
 
 This example includes tests.
 
diff --git a/docs/introduction/Motivation.md b/docs/introduction/Motivation.md
index 5b64f24e31..7c2c7a8ab8 100644
--- a/docs/introduction/Motivation.md
+++ b/docs/introduction/Motivation.md
@@ -2,10 +2,10 @@
 
 As the requirements for JavaScript single-page applications have become increasingly complicated, **our code must manage more state than ever before**. This state can include server responses and cached data, as well as locally created data that has not yet been persisted to the server. UI state is also increasing in complexity, as we need to manage the active route, the selected tab, whether to show a spinner or not, should pagination controls be displayed, and so on.
 
-Managing this ever-changing state is hard. If a model can update another model, then a view can update a model, which updates another model, and this, in turn, might cause another view to update. At some point, you no longer understand what happens in your app as you have **lost control over the when, why, and how of its state.** When a system is opaque and non-deterministic, it’s hard to reproduce bugs or add new features.
+Managing this ever-changing state is hard. If a model can update another model, then a view can update a model, which updates another model, and this, in turn, might cause another view to update. At some point, you no longer understand what happens in your app as you have **lost control over the when, why, and how of its state.** When a system is opaque and non-deterministic, it's hard to reproduce bugs or add new features.
 
-As if this wasn’t bad enough, consider the **new requirements becoming common in front-end product development**. As developers, we are expected to handle optimistic updates, server-side rendering, fetching data before performing route transitions, and so on. We find ourselves trying to manage a complexity that we have never had to deal with before, and we inevitably ask the question: [is it time to give up?](http://www.quirksmode.org/blog/archives/2015/07/stop_pushing_th.html) The answer is _no_.
+As if this wasn't bad enough, consider the **new requirements becoming common in front-end product development**. As developers, we are expected to handle optimistic updates, server-side rendering, fetching data before performing route transitions, and so on. We find ourselves trying to manage a complexity that we have never had to deal with before, and we inevitably ask the question: [is it time to give up?](http://www.quirksmode.org/blog/archives/2015/07/stop_pushing_th.html) The answer is _no_.
 
-This complexity is difficult to handle as **we’re mixing two concepts** that are very hard for the human mind to reason about: **mutation and asynchronicity.** I call them [Mentos and Coke](https://en.wikipedia.org/wiki/Diet_Coke_and_Mentos_eruption). Both can be great in separation, but together they create a mess. Libraries like [React](http://facebook.github.io/react) attempt to solve this problem in the view layer by removing both asynchrony and direct DOM manipulation. However, managing the state of your data is left up to you. This is where Redux enters.
+This complexity is difficult to handle as **we're mixing two concepts** that are very hard for the human mind to reason about: **mutation and asynchronicity.** I call them [Mentos and Coke](https://en.wikipedia.org/wiki/Diet_Coke_and_Mentos_eruption). Both can be great in separation, but together they create a mess. Libraries like [React](http://facebook.github.io/react) attempt to solve this problem in the view layer by removing both asynchrony and direct DOM manipulation. However, managing the state of your data is left up to you. This is where Redux enters.
 
 Following in the steps of [Flux](http://facebook.github.io/flux), [CQRS](http://martinfowler.com/bliki/CQRS.html), and [Event Sourcing](http://martinfowler.com/eaaDev/EventSourcing.html), **Redux attempts to make state mutations predictable** by imposing certain restrictions on how and when updates can happen. These restrictions are reflected in the [three principles](ThreePrinciples.md) of Redux.
diff --git a/docs/introduction/PriorArt.md b/docs/introduction/PriorArt.md
index 893ce20f9e..72af25da07 100644
--- a/docs/introduction/PriorArt.md
+++ b/docs/introduction/PriorArt.md
@@ -1,27 +1,27 @@
 # Prior Art
 
-Redux has a mixed heritage. It is similar to some patterns and technologies, but is also different from them in important ways. We’ll explore some of the similarities and the differences below.
+Redux has a mixed heritage. It is similar to some patterns and technologies, but is also different from them in important ways. We'll explore some of the similarities and the differences below.
 
 ### Flux
 
 Can Redux be considered a [Flux](https://facebook.github.io/flux/) implementation?  
 [Yes](https://twitter.com/fisherwebdev/status/616278911886884864), and [no](https://twitter.com/andrestaltz/status/616270755605708800).
 
-(Don’t worry, [Flux creators](https://twitter.com/jingc/status/616608251463909376) [approve of it](https://twitter.com/fisherwebdev/status/616286955693682688), if that’s all you wanted to know.)
+(Don't worry, [Flux creators](https://twitter.com/jingc/status/616608251463909376) [approve of it](https://twitter.com/fisherwebdev/status/616286955693682688), if that's all you wanted to know.)
 
 Redux was inspired by several important qualities of Flux. Like Flux, Redux prescribes that you concentrate your model update logic in a certain layer of your application (“stores” in Flux, “reducers” in Redux). Instead of letting the application code directly mutate the data, both tell you to describe every mutation as a plain object called an “action”.
 
-Unlike Flux, **Redux does not have the concept of a Dispatcher**. This is because it relies on pure functions instead of event emitters, and pure functions are easy to compose and don’t need an additional entity managing them. Depending on how you view Flux, you may see this as either a deviation or an implementation detail. Flux has often been [described as `(state, action) => state`](https://speakerdeck.com/jmorrell/jsconf-uy-flux-those-who-forget-the-past-dot-dot-dot-1). In this sense, Redux is true to the Flux architecture, but makes it simpler thanks to pure functions.
+Unlike Flux, **Redux does not have the concept of a Dispatcher**. This is because it relies on pure functions instead of event emitters, and pure functions are easy to compose and don't need an additional entity managing them. Depending on how you view Flux, you may see this as either a deviation or an implementation detail. Flux has often been [described as `(state, action) => state`](https://speakerdeck.com/jmorrell/jsconf-uy-flux-those-who-forget-the-past-dot-dot-dot-1). In this sense, Redux is true to the Flux architecture, but makes it simpler thanks to pure functions.
 
 Another important difference from Flux is that **Redux assumes you never mutate your data**. You can use plain objects and arrays for your state just fine, but mutating them inside the reducers is strongly discouraged. You should always return a new object, which is easy with the [object spread operator proposal](../recipes/UsingObjectSpreadOperator.md), or with a library like [Immutable](https://facebook.github.io/immutable-js).
 
-While it is technically *possible* to [write impure reducers](https://github.com/reactjs/redux/issues/328#issuecomment-125035516) that mutate the data for performance corner cases, we actively discourage you from doing this. Development features like time travel, record/replay, or hot reloading will break. Moreover it doesn’t seem like immutability poses performance problems in most real apps, because, as [Om](https://github.com/omcljs/om) demonstrates, even if you lose out on object allocation, you still win by avoiding expensive re-renders and re-calculations, as you know exactly what changed thanks to reducer purity.
+While it is technically *possible* to [write impure reducers](https://github.com/reactjs/redux/issues/328#issuecomment-125035516) that mutate the data for performance corner cases, we actively discourage you from doing this. Development features like time travel, record/replay, or hot reloading will break. Moreover it doesn't seem like immutability poses performance problems in most real apps, because, as [Om](https://github.com/omcljs/om) demonstrates, even if you lose out on object allocation, you still win by avoiding expensive re-renders and re-calculations, as you know exactly what changed thanks to reducer purity.
 
 ### Elm
 
 [Elm](http://elm-lang.org/) is a functional programming language inspired by Haskell and created by [Evan Czaplicki](https://twitter.com/czaplic). It enforces [a “model view update” architecture](https://github.com/evancz/elm-architecture-tutorial/), where the update has the following signature: `(action, state) => state`. Elm “updaters” serve the same purpose as reducers in Redux.
 
-Unlike Redux, Elm is a language, so it is able to benefit from many things like enforced purity, static typing, out of the box immutability, and pattern matching (using the `case` expression). Even if you don’t plan to use Elm, you should read about the Elm architecture, and play with it. There is an interesting [JavaScript library playground implementing similar ideas](https://github.com/paldepind/noname-functional-frontend-framework). We should look there for inspiration on Redux! One way that we can get closer to the static typing of Elm is by [using a gradual typing solution like Flow](https://github.com/reactjs/redux/issues/290).
+Unlike Redux, Elm is a language, so it is able to benefit from many things like enforced purity, static typing, out of the box immutability, and pattern matching (using the `case` expression). Even if you don't plan to use Elm, you should read about the Elm architecture, and play with it. There is an interesting [JavaScript library playground implementing similar ideas](https://github.com/paldepind/noname-functional-frontend-framework). We should look there for inspiration on Redux! One way that we can get closer to the static typing of Elm is by [using a gradual typing solution like Flow](https://github.com/reactjs/redux/issues/290).
 
 ### Immutable
 
@@ -29,17 +29,17 @@ Unlike Redux, Elm is a language, so it is able to benefit from many things like
 
 Immutable and most similar libraries are orthogonal to Redux. Feel free to use them together!
 
-**Redux doesn’t care *how* you store the state—it can be a plain object, an Immutable object, or anything else.** You’ll probably want a (de)serialization mechanism for writing universal apps and hydrating their state from the server, but other than that, you can use any data storage library *as long as it supports immutability*. For example, it doesn’t make sense to use Backbone for Redux state, because Backbone models are mutable.
+**Redux doesn't care *how* you store the state—it can be a plain object, an Immutable object, or anything else.** You'll probably want a (de)serialization mechanism for writing universal apps and hydrating their state from the server, but other than that, you can use any data storage library *as long as it supports immutability*. For example, it doesn't make sense to use Backbone for Redux state, because Backbone models are mutable.
 
-Note that, even if your immutable library supports cursors, you shouldn’t use them in a Redux app. The whole state tree should be considered read-only, and you should use Redux for updating the state, and subscribing to the updates. Therefore writing via cursor doesn’t make sense for Redux. **If your only use case for cursors is decoupling the state tree from the UI tree and gradually refining the cursors, you should look at selectors instead.** Selectors are composable getter functions. See [reselect](http://github.com/faassen/reselect) for a really great and concise implementation of composable selectors.
+Note that, even if your immutable library supports cursors, you shouldn't use them in a Redux app. The whole state tree should be considered read-only, and you should use Redux for updating the state, and subscribing to the updates. Therefore writing via cursor doesn't make sense for Redux. **If your only use case for cursors is decoupling the state tree from the UI tree and gradually refining the cursors, you should look at selectors instead.** Selectors are composable getter functions. See [reselect](http://github.com/faassen/reselect) for a really great and concise implementation of composable selectors.
 
 ### Baobab
 
 [Baobab](https://github.com/Yomguithereal/baobab) is another popular library implementing immutable API for updating plain JavaScript objects. While you can use it with Redux, there is little benefit in using them together.
 
-Most of the functionality Baobab provides is related to updating the data with cursors, but Redux enforces that the only way to update the data is to dispatch an action. Therefore they solve the same problem differently, and don’t complement each other.
+Most of the functionality Baobab provides is related to updating the data with cursors, but Redux enforces that the only way to update the data is to dispatch an action. Therefore they solve the same problem differently, and don't complement each other.
 
-Unlike Immutable, Baobab doesn’t yet implement any special efficient data structures under the hood, so you don’t really win anything from using it together with Redux. It’s easier to just use plain objects in this case.
+Unlike Immutable, Baobab doesn't yet implement any special efficient data structures under the hood, so you don't really win anything from using it together with Redux. It's easier to just use plain objects in this case.
 
 ### Rx
 
@@ -61,6 +61,6 @@ function toObservable(store) {
 
 Similarly, you can compose different asynchronous streams to turn them into actions before feeding them to `store.dispatch()`.
 
-The question is: do you really need Redux if you already use Rx? Maybe not. It’s not hard to [re-implement Redux in Rx](https://github.com/jas-chen/rx-redux). Some say it’s a two-liner using Rx `.scan()` method. It may very well be!
+The question is: do you really need Redux if you already use Rx? Maybe not. It's not hard to [re-implement Redux in Rx](https://github.com/jas-chen/rx-redux). Some say it's a two-liner using Rx `.scan()` method. It may very well be!
 
-If you’re in doubt, check out the Redux source code (there isn’t much going on there), as well as its ecosystem (for example, [the developer tools](https://github.com/gaearon/redux-devtools)). If you don’t care too much about it and want to go with the reactive data flow all the way, you might want to explore something like [Cycle](http://cycle.js.org) instead, or even combine it with Redux. Let us know how it goes!
+If you're in doubt, check out the Redux source code (there isn't much going on there), as well as its ecosystem (for example, [the developer tools](https://github.com/gaearon/redux-devtools)). If you don't care too much about it and want to go with the reactive data flow all the way, you might want to explore something like [Cycle](http://cycle.js.org) instead, or even combine it with Redux. Let us know how it goes!
diff --git a/docs/introduction/ThreePrinciples.md b/docs/introduction/ThreePrinciples.md
index c04c7588ce..567833e280 100644
--- a/docs/introduction/ThreePrinciples.md
+++ b/docs/introduction/ThreePrinciples.md
@@ -6,7 +6,7 @@ Redux can be described in three fundamental principles:
 
 **The [state](../Glossary.md#state) of your whole application is stored in an object tree within a single [store](../Glossary.md#store).**
 
-This makes it easy to create universal apps, as the state from your server can be serialized and hydrated into the client with no extra coding effort. A single state tree also makes it easier to debug or introspect an application; it also enables you to persist your app’s state in development, for a faster development cycle. Some functionality which has been traditionally difficult to implement - Undo/Redo, for example - can suddenly become trivial to implement, if all of your state is stored in a single tree.
+This makes it easy to create universal apps, as the state from your server can be serialized and hydrated into the client with no extra coding effort. A single state tree also makes it easier to debug or introspect an application; it also enables you to persist your app's state in development, for a faster development cycle. Some functionality which has been traditionally difficult to implement - Undo/Redo, for example - can suddenly become trivial to implement, if all of your state is stored in a single tree.
 
 ```js
 console.log(store.getState())
@@ -92,4 +92,4 @@ let reducer = combineReducers({ visibilityFilter, todos })
 let store = createStore(reducer)
 ```
 
-That’s it! Now you know what Redux is all about.
+That's it! Now you know what Redux is all about.
diff --git a/docs/recipes/ComputingDerivedData.md b/docs/recipes/ComputingDerivedData.md
index 9dbb811072..992e96762a 100644
--- a/docs/recipes/ComputingDerivedData.md
+++ b/docs/recipes/ComputingDerivedData.md
@@ -54,7 +54,7 @@ We would like to replace `getVisibleTodos` with a memoized selector that recalcu
 
 Reselect provides a function `createSelector` for creating memoized selectors. `createSelector` takes an array of input-selectors and a transform function as its arguments. If the Redux state tree is mutated in a way that causes the value of an input-selector to change, the selector will call its transform function with the values of the input-selectors as arguments and return the result. If the values of the input-selectors are the same as the previous call to the selector, it will return the previously computed value instead of calling the transform function.
 
-Let’s define a memoized selector named `getVisibleTodos` to replace the non-memoized version above:
+Let's define a memoized selector named `getVisibleTodos` to replace the non-memoized version above:
 
 #### `selectors/index.js`
 
@@ -132,7 +132,7 @@ export default VisibleTodoList
 
 ### Accessing React Props in Selectors
 
-> This section introduces an hypothetical extension to our app that allows it to support multiple Todo Lists. Please note that a full implementation of this extension requires changes to the reducers, components, actions etc. that aren’t directly relevant to the topics discussed and have been omitted for brevity.
+> This section introduces an hypothetical extension to our app that allows it to support multiple Todo Lists. Please note that a full implementation of this extension requires changes to the reducers, components, actions etc. that aren't directly relevant to the topics discussed and have been omitted for brevity.
 
 So far we have only seen selectors receive the Redux store state as an argument, but a selector can receive props too.
 
@@ -155,7 +155,7 @@ const App = () => (
 )
 ```
 
-Each `VisibleTodoList` container should select a different slice of the state depending on the value of the `listId` prop, so let’s modify `getVisibilityFilter` and `getTodos` to accept a props argument:
+Each `VisibleTodoList` container should select a different slice of the state depending on the value of the `listId` prop, so let's modify `getVisibilityFilter` and `getTodos` to accept a props argument:
 
 #### `selectors/todoSelectors.js`
 
@@ -232,7 +232,7 @@ const VisibleTodoList = connect(
 export default VisibleTodoList
 ```
 
-A selector created with `createSelector` only returns the cached value when its set of arguments is the same as its previous set of arguments. If we alternate between rendering `<VisibleTodoList listId="1" />` and `<VisibleTodoList listId="2" />`, the shared selector will alternate between receiving `{listId: 1}` and `{listId: 2}` as its `props` argument. This will cause the arguments to be different on each call, so the selector will always recompute instead of returning the cached value. We’ll see how to overcome this limitation in the next section.
+A selector created with `createSelector` only returns the cached value when its set of arguments is the same as its previous set of arguments. If we alternate between rendering `<VisibleTodoList listId="1" />` and `<VisibleTodoList listId="2" />`, the shared selector will alternate between receiving `{listId: 1}` and `{listId: 2}` as its `props` argument. This will cause the arguments to be different on each call, so the selector will always recompute instead of returning the cached value. We'll see how to overcome this limitation in the next section.
 
 ### Sharing Selectors Across Multiple Components
 
@@ -240,7 +240,7 @@ A selector created with `createSelector` only returns the cached value when its
 
 In order to share a selector across multiple `VisibleTodoList` components **and** retain memoization, each instance of the component needs its own private copy of the selector.
 
-Let’s create a function named `makeGetVisibleTodos` that returns a new copy of the `getVisibleTodos` selector each time it is called:
+Let's create a function named `makeGetVisibleTodos` that returns a new copy of the `getVisibleTodos` selector each time it is called:
 
 #### `selectors/todoSelectors.js`
 
@@ -328,4 +328,4 @@ export default VisibleTodoList
 
 ## Next Steps
 
-Check out the [official documentation](https://github.com/reactjs/reselect) of Reselect as well as its [FAQ](https://github.com/reactjs/reselect#faq). Most Redux projects start using Reselect when they have performance problems because of too many derived computations and wasted re-renders, so make sure you are familiar with it before you build something big. It can also be useful to study [its source code](https://github.com/reactjs/reselect/blob/master/src/index.js) so you don’t think it’s magic.
+Check out the [official documentation](https://github.com/reactjs/reselect) of Reselect as well as its [FAQ](https://github.com/reactjs/reselect#faq). Most Redux projects start using Reselect when they have performance problems because of too many derived computations and wasted re-renders, so make sure you are familiar with it before you build something big. It can also be useful to study [its source code](https://github.com/reactjs/reselect/blob/master/src/index.js) so you don't think it's magic.
diff --git a/docs/recipes/ImplementingUndoHistory.md b/docs/recipes/ImplementingUndoHistory.md
index 63fd0800a7..6556f29d07 100644
--- a/docs/recipes/ImplementingUndoHistory.md
+++ b/docs/recipes/ImplementingUndoHistory.md
@@ -23,7 +23,7 @@ In the second part of this recipe, we will show how to use [Redux Undo](https://
 
 ### Designing the State Shape
 
-Undo history is also part of your app’s state, and there is no reason why we should approach it differently. Regardless of the type of the state changing over time, when you implement Undo and Redo, you want to keep track of the *history* of this state at different points in time.
+Undo history is also part of your app's state, and there is no reason why we should approach it differently. Regardless of the type of the state changing over time, when you implement Undo and Redo, you want to keep track of the *history* of this state at different points in time.
 
 For example, the state shape of a counter app might look like this:
 
@@ -33,7 +33,7 @@ For example, the state shape of a counter app might look like this:
 }
 ```
 
-If we wanted to implement Undo and Redo in such an app, we’d need to store more state so we can answer the following questions:
+If we wanted to implement Undo and Redo in such an app, we'd need to store more state so we can answer the following questions:
 
 * Is there anything left to undo or redo?
 * What is the current state?
@@ -87,7 +87,7 @@ When the user presses “Redo”, we want to move one step back into the future:
 }
 ```
 
-Finally, if the user performs an action (e.g. decrement the counter) while we’re in the middle of the undo stack, we’re going to discard the existing future:
+Finally, if the user performs an action (e.g. decrement the counter) while we're in the middle of the undo stack, we're going to discard the existing future:
 
 ```js
 {
@@ -182,7 +182,7 @@ Regardless of the specific data type, the shape of the undo history state is the
 }
 ```
 
-Let’s talk through the algorithm to manipulate the state shape described above. We can define two actions to operate on this state: `UNDO` and `REDO`. In our reducer, we will do the following steps to handle these actions:
+Let's talk through the algorithm to manipulate the state shape described above. We can define two actions to operate on this state: `UNDO` and `REDO`. In our reducer, we will do the following steps to handle these actions:
 
 #### Handling Undo
 
@@ -238,21 +238,21 @@ function undoable(state = initialState, action) {
 }
 ```
 
-This implementation isn’t usable because it leaves out three important questions:
+This implementation isn't usable because it leaves out three important questions:
 
-* Where do we get the initial `present` state from? We don’t seem to know it beforehand.
+* Where do we get the initial `present` state from? We don't seem to know it beforehand.
 * Where do we react to the external actions to save the `present` to the `past`?
 * How do we actually delegate the control over the `present` state to a custom reducer?
 
-It seems that reducer isn’t the right abstraction, but we’re very close.
+It seems that reducer isn't the right abstraction, but we're very close.
 
 ### Meet Reducer Enhancers
 
 You might be familiar with [higher order functions](https://en.wikipedia.org/wiki/Higher-order_function). If you use React, you might be familiar with [higher order components](https://medium.com/@dan_abramov/mixins-are-dead-long-live-higher-order-components-94a0d2f9e750). Here is a variation on the same pattern, applied to reducers.
 
-A *reducer enhancer* (or a *higher order reducer*) is a function that takes a reducer, and returns a new reducer that is able to handle new actions, or to hold more state, delegating control to the inner reducer for the actions it doesn’t understand. This isn’t a new pattern—technically, [`combineReducers()`](../api/combineReducers.md) is also a reducer enhancer because it takes reducers and returns a new reducer.
+A *reducer enhancer* (or a *higher order reducer*) is a function that takes a reducer, and returns a new reducer that is able to handle new actions, or to hold more state, delegating control to the inner reducer for the actions it doesn't understand. This isn't a new pattern—technically, [`combineReducers()`](../api/combineReducers.md) is also a reducer enhancer because it takes reducers and returns a new reducer.
 
-A reducer enhancer that doesn’t do anything looks like this:
+A reducer enhancer that doesn't do anything looks like this:
 
 ```js
 function doNothingWith(reducer) {
@@ -358,11 +358,11 @@ store.dispatch({
 
 There is an important gotcha: you need to remember to append `.present` to the current state when you retrieve it. You may also check `.past.length` and `.future.length` to determine whether to enable or to disable the Undo and Redo buttons, respectively.
 
-You might have heard that Redux was influenced by [Elm Architecture](https://github.com/evancz/elm-architecture-tutorial/). It shouldn’t come as a surprise that this example is very similar to [elm-undo-redo package](http://package.elm-lang.org/packages/TheSeamau5/elm-undo-redo/2.0.0).
+You might have heard that Redux was influenced by [Elm Architecture](https://github.com/evancz/elm-architecture-tutorial/). It shouldn't come as a surprise that this example is very similar to [elm-undo-redo package](http://package.elm-lang.org/packages/TheSeamau5/elm-undo-redo/2.0.0).
 
 ## Using Redux Undo
 
-This was all very informative, but can’t we just drop a library and use it instead of implementing `undoable` ourselves? Sure, we can! Meet [Redux Undo](https://github.com/omnidan/redux-undo), a library that provides simple Undo and Redo functionality for any part of your Redux tree.
+This was all very informative, but can't we just drop a library and use it instead of implementing `undoable` ourselves? Sure, we can! Meet [Redux Undo](https://github.com/omnidan/redux-undo), a library that provides simple Undo and Redo functionality for any part of your Redux tree.
 
 In this part of the recipe, you will learn how to make the [Todo List example](http://redux.js.org/docs/basics/ExampleTodoList.html) undoable. You can find the full source of this recipe in the [`todos-with-undo` example that comes with Redux](https://github.com/reactjs/redux/tree/master/examples/todos-with-undo).
 
@@ -398,7 +398,7 @@ const undoableTodos = undoable(todos, {
 export default undoableTodos
 ```
 
-The `distinctState()` filter serves to ignore the actions that didn’t result in a state change. There are [many other options](https://github.com/omnidan/redux-undo#configuration) to configure your undoable reducer, like setting the action type for Undo and Redo actions.
+The `distinctState()` filter serves to ignore the actions that didn't result in a state change. There are [many other options](https://github.com/omnidan/redux-undo#configuration) to configure your undoable reducer, like setting the action type for Undo and Redo actions.
 
 Note that your `combineReducers()` call will stay exactly as it was, but the `todos` reducer will now refer to the reducer enhanced with Redux Undo:
 
@@ -457,7 +457,7 @@ const mapStateToProps = (state) => {
 
 Now all you need to do is add the buttons for the Undo and Redo actions.
 
-First, create a new container component called `UndoRedo` for these buttons. We won’t bother to split the presentational part into a separate file because it is very small:
+First, create a new container component called `UndoRedo` for these buttons. We won't bother to split the presentational part into a separate file because it is very small:
 
 #### `containers/UndoRedo.js`
 
@@ -478,7 +478,7 @@ let UndoRedo = ({ canUndo, canRedo, onUndo, onRedo }) => (
 )
 ```
 
-You will use `connect()` from [React Redux](https://github.com/reactjs/react-redux) to generate a container component. To determine whether to enable Undo and Redo buttons, you can check `state.todos.past.length` and `state.todos.future.length`. You won’t need to write action creators for performing undo and redo because Redux Undo already provides them:
+You will use `connect()` from [React Redux](https://github.com/reactjs/react-redux) to generate a container component. To determine whether to enable Undo and Redo buttons, you can check `state.todos.past.length` and `state.todos.future.length`. You won't need to write action creators for performing undo and redo because Redux Undo already provides them:
 
 #### `containers/UndoRedo.js`
 
diff --git a/docs/recipes/IsolatingSubapps.md b/docs/recipes/IsolatingSubapps.md
index 0baa6583b9..652406c466 100644
--- a/docs/recipes/IsolatingSubapps.md
+++ b/docs/recipes/IsolatingSubapps.md
@@ -20,10 +20,10 @@ class BigApp extends Component {
 }
 ```
 
-These `<SubApp>`s will be completely independent. They won’t share data or
-actions, and won’t see or communicate with each other.
+These `<SubApp>`s will be completely independent. They won't share data or
+actions, and won't see or communicate with each other.
 
-It’s best not to mix this approach with standard Redux reducer composition.
+It's best not to mix this approach with standard Redux reducer composition.
 For typical web apps, stick with reducer composition. For
 “product hubs”, “dashboards”, or enterprise software that groups disparate
 tools into a unified package, give the sub-app approach a try.
@@ -32,17 +32,17 @@ The sub-app approach is also useful for large teams that are divided by product
 or feature verticals. These teams can ship sub-apps independently or in combination
 with an enclosing “app shell”.
 
-Below is a sub-app’s root connected component.
+Below is a sub-app's root connected component.
 As usual, it can render more components, connected or not, as children.
-Usually we’d render it in `<Provider>` and be done with it.
+Usually we'd render it in `<Provider>` and be done with it.
 
 ```js
 class App extends Component { ... }
 export default connect(mapStateToProps)(App)
 ```
 
-However, we don’t have to call `ReactDOM.render(<Provider><App /></Provider>)`
-if we’re interested in hiding the fact that the sub-app component is a Redux app.
+However, we don't have to call `ReactDOM.render(<Provider><App /></Provider>)`
+if we're interested in hiding the fact that the sub-app component is a Redux app.
 
 Maybe we want to be able to run multiple instances of it in the same “bigger” app
 and keep it as a complete black box, with Redux being an implementation detail.
@@ -75,7 +75,7 @@ class SubApp extends Component {
 This way every instance will be independent.
 
 This pattern is *not* recommended for parts of the same app that share data.
-However, it can be useful when the bigger app has zero access to the smaller apps’ internals,
-and we’d like to keep the fact that they are implemented with Redux as an implementation detail.
-Each component instance will have its own store, so they won’t “know” about each other.
+However, it can be useful when the bigger app has zero access to the smaller apps' internals,
+and we'd like to keep the fact that they are implemented with Redux as an implementation detail.
+Each component instance will have its own store, so they won't “know” about each other.
 
diff --git a/docs/recipes/MigratingToRedux.md b/docs/recipes/MigratingToRedux.md
index e0bd4822f0..5f6333d3f7 100644
--- a/docs/recipes/MigratingToRedux.md
+++ b/docs/recipes/MigratingToRedux.md
@@ -1,13 +1,13 @@
 # Migrating to Redux
 
-Redux is not a monolithic framework, but a set of contracts and a [few functions that make them work together](../api/README.md). The majority of your “Redux code” will not even use Redux APIs, as most of the time you’ll be writing functions. 
+Redux is not a monolithic framework, but a set of contracts and a [few functions that make them work together](../api/README.md). The majority of your “Redux code” will not even use Redux APIs, as most of the time you'll be writing functions. 
 
 This makes it easy to migrate both to and from Redux.  
-We don’t want to lock you in!
+We don't want to lock you in!
 
 ## From Flux
 
-[Reducers](../Glossary.md#reducer) capture “the essence” of Flux Stores, so it’s possible to gradually migrate an existing Flux project towards Redux, whether you are using [Flummox](http://github.com/acdlite/flummox), [Alt](http://github.com/goatslacker/alt), [traditional Flux](https://github.com/facebook/flux), or any other Flux library.
+[Reducers](../Glossary.md#reducer) capture “the essence” of Flux Stores, so it's possible to gradually migrate an existing Flux project towards Redux, whether you are using [Flummox](http://github.com/acdlite/flummox), [Alt](http://github.com/goatslacker/alt), [traditional Flux](https://github.com/facebook/flux), or any other Flux library.
 
 It is also possible to do the reverse and migrate from Redux to any of these libraries following the same steps.
 
@@ -21,10 +21,10 @@ Your process will look like this:
 
 * When you have ported all of your Flux Stores to be implemented on top of reducers, you can replace the Flux library with a single Redux store, and combine those reducers you already have into one using [`combineReducers(reducers)`](../api/combineReducers.md).
 
-* Now all that’s left to do is to port the UI to [use react-redux](../basics/UsageWithReact.md) or equivalent.
+* Now all that's left to do is to port the UI to [use react-redux](../basics/UsageWithReact.md) or equivalent.
 
 * Finally, you might want to begin using some Redux idioms like middleware to further simplify your asynchronous code.
 
 ## From Backbone
 
-Backbone’s model layer is quite different from Redux, so we don’t suggest mixing them. If possible, it is best that you rewrite your app’s model layer from scratch instead of connecting Backbone to Redux. However, if a rewrite is not feasible, you may use [backbone-redux](https://github.com/redbooth/backbone-redux) to migrate gradually, and keep the Redux store in sync with Backbone models and collections.
+Backbone's model layer is quite different from Redux, so we don't suggest mixing them. If possible, it is best that you rewrite your app's model layer from scratch instead of connecting Backbone to Redux. However, if a rewrite is not feasible, you may use [backbone-redux](https://github.com/redbooth/backbone-redux) to migrate gradually, and keep the Redux store in sync with Backbone models and collections.
diff --git a/docs/recipes/ReducingBoilerplate.md b/docs/recipes/ReducingBoilerplate.md
index b8f4d3a11d..2ac1cfcb15 100644
--- a/docs/recipes/ReducingBoilerplate.md
+++ b/docs/recipes/ReducingBoilerplate.md
@@ -1,12 +1,12 @@
 # Reducing Boilerplate
 
-Redux is in part [inspired by Flux](../introduction/PriorArt.md), and the most common complaint about Flux is how it makes you write a lot of boilerplate. In this recipe, we will consider how Redux lets us choose how verbose we’d like our code to be, depending on personal style, team preferences, longer term maintainability, and so on.
+Redux is in part [inspired by Flux](../introduction/PriorArt.md), and the most common complaint about Flux is how it makes you write a lot of boilerplate. In this recipe, we will consider how Redux lets us choose how verbose we'd like our code to be, depending on personal style, team preferences, longer term maintainability, and so on.
 
 ## Actions
 
-Actions are plain objects describing what happened in the app, and serve as the sole way to describe an intention to mutate the data. It’s important that **actions being objects you have to dispatch is not boilerplate, but one of the [fundamental design choices](../introduction/ThreePrinciples.md) of Redux**.
+Actions are plain objects describing what happened in the app, and serve as the sole way to describe an intention to mutate the data. It's important that **actions being objects you have to dispatch is not boilerplate, but one of the [fundamental design choices](../introduction/ThreePrinciples.md) of Redux**.
 
-There are frameworks claiming to be similar to Flux, but without a concept of action objects. In terms of being predictable, this is a step backwards from Flux or Redux. If there are no serializable plain object actions, it is impossible to record and replay user sessions, or to implement [hot reloading with time travel](https://www.youtube.com/watch?v=xsSnOQynTHs). If you’d rather modify data directly, you don’t need Redux.
+There are frameworks claiming to be similar to Flux, but without a concept of action objects. In terms of being predictable, this is a step backwards from Flux or Redux. If there are no serializable plain object actions, it is impossible to record and replay user sessions, or to implement [hot reloading with time travel](https://www.youtube.com/watch?v=xsSnOQynTHs). If you'd rather modify data directly, you don't need Redux.
 
 Actions look like this:
 
@@ -29,9 +29,9 @@ const LOAD_ARTICLE = 'LOAD_ARTICLE'
 Why is this beneficial? **It is often claimed that constants are unnecessary, and for small projects, this might be correct.** For larger projects, there are some benefits to defining action types as constants:
 
 * It helps keep the naming consistent because all action types are gathered in a single place.
-* Sometimes you want to see all existing actions before working on a new feature. It may be that the action you need was already added by somebody on the team, but you didn’t know.
+* Sometimes you want to see all existing actions before working on a new feature. It may be that the action you need was already added by somebody on the team, but you didn't know.
 * The list of action types that were added, removed, and changed in a Pull Request helps everyone on the team keep track of scope and implementation of new features.
-* If you make a typo when importing an action constant, you will get `undefined`. Redux will immediately throw when dispatching such an action, and you’ll find the mistake sooner.
+* If you make a typo when importing an action constant, you will get `undefined`. Redux will immediately throw when dispatching such an action, and you'll find the mistake sooner.
 
 It is up to you to choose the conventions for your project. You may start by using inline strings, and later transition to constants, and maybe later group them into a single file. Redux does not have any opinion here, so use your best judgment.
 
@@ -71,9 +71,9 @@ import { addTodo } from './actionCreators'
 dispatch(addTodo('Use Redux'))
 ```
 
-Action creators have often been criticized as boilerplate. Well, you don’t have to write them! **You can use object literals if you feel this better suits your project.** There are, however, some benefits for writing action creators you should know about.
+Action creators have often been criticized as boilerplate. Well, you don't have to write them! **You can use object literals if you feel this better suits your project.** There are, however, some benefits for writing action creators you should know about.
 
-Let’s say a designer comes back to us after reviewing our prototype, and tells that we need to allow three todos maximum. We can enforce this by rewriting our action creator to a callback form with [redux-thunk](https://github.com/gaearon/redux-thunk) middleware and adding an early exit:
+Let's say a designer comes back to us after reviewing our prototype, and tells that we need to allow three todos maximum. We can enforce this by rewriting our action creator to a callback form with [redux-thunk](https://github.com/gaearon/redux-thunk) middleware and adding an early exit:
 
 ```js
 function addTodoWithoutCheck(text) {
@@ -97,11 +97,11 @@ export function addTodo(text) {
 }
 ```
 
-We just modified how the `addTodo` action creator behaves, completely invisible to the calling code. **We don’t have to worry about looking at each place where todos are being added, to make sure they have this check.** Action creators let you decouple additional logic around dispatching an action, from the actual components emitting those actions. It’s very handy when the application is under heavy development, and the requirements change often.
+We just modified how the `addTodo` action creator behaves, completely invisible to the calling code. **We don't have to worry about looking at each place where todos are being added, to make sure they have this check.** Action creators let you decouple additional logic around dispatching an action, from the actual components emitting those actions. It's very handy when the application is under heavy development, and the requirements change often.
 
 ### Generating Action Creators
 
-Some frameworks like [Flummox](https://github.com/acdlite/flummox) generate action type constants automatically from the action creator function definitions. The idea is that you don’t need to both define `ADD_TODO` constant and `addTodo()` action creator. Under the hood, such solutions still generate action type constants, but they’re created implicitly so it’s a level of indirection and can cause confusion. We recommend creating your action type constants explicitly.
+Some frameworks like [Flummox](https://github.com/acdlite/flummox) generate action type constants automatically from the action creator function definitions. The idea is that you don't need to both define `ADD_TODO` constant and `addTodo()` action creator. Under the hood, such solutions still generate action type constants, but they're created implicitly so it's a level of indirection and can cause confusion. We recommend creating your action type constants explicitly.
 
 Writing simple action creators can be tiresome and often ends up generating redundant boilerplate code:
 
@@ -249,7 +249,7 @@ The simplest example of middleware is [redux-thunk](https://github.com/gaearon/r
 
 >##### Note
 
->Thunk middleware is just one example of middleware. Middleware is not about “letting you dispatch functions”. It’s about letting you dispatch anything that the particular middleware you use knows how to handle. Thunk middleware adds a specific behavior when you dispatch functions, but it really depends on the middleware you use.
+>Thunk middleware is just one example of middleware. Middleware is not about “letting you dispatch functions”. It's about letting you dispatch anything that the particular middleware you use knows how to handle. Thunk middleware adds a specific behavior when you dispatch functions, but it really depends on the middleware you use.
 
 Consider the code above rewritten with [redux-thunk](https://github.com/gaearon/redux-thunk):
 
@@ -323,9 +323,9 @@ export default connect(state => ({
 }))(Posts)
 ```
 
-This is much less typing! If you’d like, you can still have “vanilla” action creators like `loadPostsSuccess` which you’d use from a container `loadPosts` action creator.
+This is much less typing! If you'd like, you can still have “vanilla” action creators like `loadPostsSuccess` which you'd use from a container `loadPosts` action creator.
 
-**Finally, you can write your own middleware.** Let’s say you want to generalize the pattern above and describe your async action creators like this instead:
+**Finally, you can write your own middleware.** Let's say you want to generalize the pattern above and describe your async action creators like this instead:
 
 ```js
 export function loadPosts(userId) {
@@ -475,11 +475,11 @@ export function todos(state = [], action) {
 
 The `switch` statement is *not* the real boilerplate. The real boilerplate of Flux is conceptual: the need to emit an update, the need to register the Store with a Dispatcher, the need for the Store to be an object (and the complications that arise when you want a universal app).
 
-It’s unfortunate that many still choose Flux framework based on whether it uses `switch` statements in the documentation. If you don’t like `switch`, you can solve this with a single function, as we show below.
+It's unfortunate that many still choose Flux framework based on whether it uses `switch` statements in the documentation. If you don't like `switch`, you can solve this with a single function, as we show below.
 
 ### Generating Reducers
 
-Let’s write a function that lets us express reducers as an object mapping from action types to handlers. For example, if we want our `todos` reducers to be defined like this:
+Let's write a function that lets us express reducers as an object mapping from action types to handlers. For example, if we want our `todos` reducers to be defined like this:
 
 ```js
 export const todos = createReducer([], {
@@ -504,6 +504,6 @@ function createReducer(initialState, handlers) {
 }
 ```
 
-This wasn’t difficult, was it? Redux doesn’t provide such a helper function by default because there are many ways to write it. Maybe you want it to automatically convert plain JS objects to Immutable objects to hydrate the server state. Maybe you want to merge the returned state with the current state. There may be different approaches to a “catch all” handler. All of this depends on the conventions you choose for your team on a specific project.
+This wasn't difficult, was it? Redux doesn't provide such a helper function by default because there are many ways to write it. Maybe you want it to automatically convert plain JS objects to Immutable objects to hydrate the server state. Maybe you want to merge the returned state with the current state. There may be different approaches to a “catch all” handler. All of this depends on the conventions you choose for your team on a specific project.
 
 The Redux reducer API is `(state, action) => state`, but how you create those reducers is up to you.
diff --git a/docs/recipes/ServerRendering.md b/docs/recipes/ServerRendering.md
index e81a8794cd..cf5c965b4f 100644
--- a/docs/recipes/ServerRendering.md
+++ b/docs/recipes/ServerRendering.md
@@ -6,7 +6,7 @@ We will use React in the examples below, but the same techniques can be used wit
 
 ### Redux on the Server
 
-When using Redux with server rendering, we must also send the state of our app along in our response, so the client can use it as the initial state. This is important because, if we preload any data before generating the HTML, we want the client to also have access to this data. Otherwise, the markup generated on the client won’t match the server markup, and the client would have to load the data again.
+When using Redux with server rendering, we must also send the state of our app along in our response, so the client can use it as the initial state. This is important because, if we preload any data before generating the HTML, we want the client to also have access to this data. Otherwise, the markup generated on the client won't match the server markup, and the client would have to load the data again.
 
 To send the data down to the client, we need to:
 
@@ -16,15 +16,15 @@ To send the data down to the client, we need to:
 * and then pass the state along to the client.
 
 On the client side, a new Redux store will be created and initialized with the state provided from the server.  
-Redux’s **_only_** job on the server side is to provide the **initial state** of our app.
+Redux's **_only_** job on the server side is to provide the **initial state** of our app.
 
 ## Setting Up
 
-In the following recipe, we are going to look at how to set up server-side rendering. We’ll use the simplistic [Counter app](https://github.com/reactjs/redux/tree/master/examples/counter) as a guide and show how the server can render state ahead of time based on the request.
+In the following recipe, we are going to look at how to set up server-side rendering. We'll use the simplistic [Counter app](https://github.com/reactjs/redux/tree/master/examples/counter) as a guide and show how the server can render state ahead of time based on the request.
 
 ### Install Packages
 
-For this example, we’ll be using [Express](http://expressjs.com/) as a simple web server. We also need to install the React bindings for Redux, since they are not included in Redux by default.
+For this example, we'll be using [Express](http://expressjs.com/) as a simple web server. We also need to install the React bindings for Redux, since they are not included in Redux by default.
 
 ```
 npm install --save express react-redux
@@ -32,7 +32,7 @@ npm install --save express react-redux
 
 ## The Server Side
 
-The following is the outline for what our server side is going to look like. We are going to set up an [Express middleware](http://expressjs.com/guide/using-middleware.html) using [app.use](http://expressjs.com/api.html#app.use) to handle all requests that come in to our server. If you’re unfamiliar with Express or middleware, just know that our handleRender function will be called every time the server receives a request.
+The following is the outline for what our server side is going to look like. We are going to set up an [Express middleware](http://expressjs.com/guide/using-middleware.html) using [app.use](http://expressjs.com/api.html#app.use) to handle all requests that come in to our server. If you're unfamiliar with Express or middleware, just know that our handleRender function will be called every time the server receives a request.
 
 ##### `server.js`
 
@@ -120,13 +120,13 @@ function renderFullPage(html, preloadedState) {
 
 >##### Note on String Interpolation Syntax
 
->In the example above, we use ES6 [template strings](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings) syntax. It lets us write multiline strings and interpolate values, but it requires ES6 support. If you’d like to write your Node code using ES6, check out [Babel require hook](https://babeljs.io/docs/usage/require/) documentation. Or you can just keep writing ES5 code.
+>In the example above, we use ES6 [template strings](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/template_strings) syntax. It lets us write multiline strings and interpolate values, but it requires ES6 support. If you'd like to write your Node code using ES6, check out [Babel require hook](https://babeljs.io/docs/usage/require/) documentation. Or you can just keep writing ES5 code.
 
 ## The Client Side
 
 The client side is very straightforward. All we need to do is grab the initial state from `window.__PRELOADED_STATE__`, and pass it to our [`createStore()`](../api/createStore.md) function as the initial state.
 
-Let’s take a look at our new client file:
+Let's take a look at our new client file:
 
 #### `client.js`
 
@@ -156,7 +156,7 @@ You can set up your build tool of choice (Webpack, Browserify, etc.) to compile
 
 When the page loads, the bundle file will be started up and [`ReactDOM.render()`](https://facebook.github.io/react/docs/top-level-api.html#reactdom.render) will hook into the `data-react-id` attributes from the server-rendered HTML. This will connect our newly-started React instance to the virtual DOM used on the server. Since we have the same initial state for our Redux store and used the same code for all our view components, the result will be the same real DOM.
 
-And that’s it! That is all we need to do to implement server side rendering.
+And that's it! That is all we need to do to implement server side rendering.
 
 But the result is pretty vanilla. It essentially renders a static view from dynamic code. What we need to do next is build an initial state dynamically to allow that rendered view to be dynamic.
 
@@ -168,7 +168,7 @@ Because the client side executes ongoing code, it can start with an empty initia
 
 The only input for server side code is the request made when loading up a page in your app in your browser. You may choose to configure the server during its boot (such as when you are running in a development vs. production environment), but that configuration is static.
 
-The request contains information about the URL requested, including any query parameters, which will be useful when using something like [React Router](https://github.com/reactjs/react-router). It can also contain headers with inputs like cookies or authorization, or POST body data. Let’s see how we can set the initial counter state based on a query parameter.
+The request contains information about the URL requested, including any query parameters, which will be useful when using something like [React Router](https://github.com/reactjs/react-router). It can also contain headers with inputs like cookies or authorization, or POST body data. Let's see how we can set the initial counter state based on a query parameter.
 
 #### `server.js`
 
@@ -202,15 +202,15 @@ function handleRender(req, res) {
 }
 ```
 
-The code reads from the Express `Request` object passed into our server middleware. The parameter is parsed into a number and then set in the initial state. If you visit [http://localhost:3000/?counter=100](http://localhost:3000/?counter=100) in your browser, you’ll see the counter starts at 100. In the rendered HTML, you’ll see the counter output as 100 and the `__PRELOADED_STATE__` variable has the counter set in it.
+The code reads from the Express `Request` object passed into our server middleware. The parameter is parsed into a number and then set in the initial state. If you visit [http://localhost:3000/?counter=100](http://localhost:3000/?counter=100) in your browser, you'll see the counter starts at 100. In the rendered HTML, you'll see the counter output as 100 and the `__PRELOADED_STATE__` variable has the counter set in it.
 
 ### Async State Fetching
 
-The most common issue with server side rendering is dealing with state that comes in asynchronously. Rendering on the server is synchronous by nature, so it’s necessary to map any asynchronous fetches into a synchronous operation.
+The most common issue with server side rendering is dealing with state that comes in asynchronously. Rendering on the server is synchronous by nature, so it's necessary to map any asynchronous fetches into a synchronous operation.
 
-The easiest way to do this is to pass through some callback back to your synchronous code. In this case, that will be a function that will reference the response object and send back our rendered HTML to the client. Don’t worry, it’s not as hard as it may sound.
+The easiest way to do this is to pass through some callback back to your synchronous code. In this case, that will be a function that will reference the response object and send back our rendered HTML to the client. Don't worry, it's not as hard as it may sound.
 
-For our example, we’ll imagine there is an external datastore that contains the counter’s initial value (Counter As A Service, or CaaS). We’ll make a mock call over to them and build our initial state from the result. We’ll start by building out our API call:
+For our example, we'll imagine there is an external datastore that contains the counter's initial value (Counter As A Service, or CaaS). We'll make a mock call over to them and build our initial state from the result. We'll start by building out our API call:
 
 #### `api/counter.js`
 
@@ -226,7 +226,7 @@ export function fetchCounter(callback) {
 }
 ```
 
-Again, this is just a mock API, so we use `setTimeout` to simulate a network request that takes 500 milliseconds to respond (this should be much faster with a real world API). We pass in a callback that returns a random number asynchronously. If you’re using a Promise-based API client, then you would issue this callback in your `then` handler.
+Again, this is just a mock API, so we use `setTimeout` to simulate a network request that takes 500 milliseconds to respond (this should be much faster with a real world API). We pass in a callback that returns a random number asynchronously. If you're using a Promise-based API client, then you would issue this callback in your `then` handler.
 
 On the server side, we simply wrap our existing code in the `fetchCounter` and receive the result in the callback:
 
@@ -266,7 +266,7 @@ function handleRender(req, res) {
 }
 ```
 
-Because we call `res.send()` inside of the callback, the server will hold open the connection and won’t send any data until that callback executes. You’ll notice a 500ms delay is now added to each server request as a result of our new API call. A more advanced usage would handle errors in the API gracefully, such as a bad response or timeout.
+Because we call `res.send()` inside of the callback, the server will hold open the connection and won't send any data until that callback executes. You'll notice a 500ms delay is now added to each server request as a result of our new API call. A more advanced usage would handle errors in the API gracefully, such as a bad response or timeout.
 
 ### Security Considerations
 
@@ -274,7 +274,7 @@ Because we have introduced more code that relies on user generated content (UGC)
 
 In our example, we take a rudimentary approach to security. When we obtain the parameters from the request, we use `parseInt` on the `counter` parameter to ensure this value is a number. If we did not do this, you could easily get dangerous data into the rendered HTML by providing a script tag in the request. That might look like this: `?counter=</script><script>doSomethingBad();</script>`
 
-For our simplistic example, coercing our input into a number is sufficiently secure. If you’re handling more complex input, such as freeform text, then you should run that input through an appropriate sanitization function, such as [validator.js](https://www.npmjs.com/package/validator).
+For our simplistic example, coercing our input into a number is sufficiently secure. If you're handling more complex input, such as freeform text, then you should run that input through an appropriate sanitization function, such as [validator.js](https://www.npmjs.com/package/validator).
 
 Furthermore, you can add additional layers of security by sanitizing your state output. `JSON.stringify` can be subject to script injections. To counter this, you can scrub the JSON string of HTML tags and other dangerous characters. This can be done with either a simple text replacement on the string or via more sophisticated libraries such as [serialize-javascript](https://github.com/yahoo/serialize-javascript).
 
diff --git a/docs/recipes/UsingObjectSpreadOperator.md b/docs/recipes/UsingObjectSpreadOperator.md
index 6c8954f510..494c2cd5ae 100644
--- a/docs/recipes/UsingObjectSpreadOperator.md
+++ b/docs/recipes/UsingObjectSpreadOperator.md
@@ -1,6 +1,6 @@
 # Using Object Spread Operator
 
-Since one of the core tenets of Redux is to never mutate state, you’ll often find yourself using [`Object.assign()`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) to create
+Since one of the core tenets of Redux is to never mutate state, you'll often find yourself using [`Object.assign()`](https://developer.mozilla.org/en/docs/Web/JavaScript/Reference/Global_Objects/Object/assign) to create
 copies of objects with new or updated values. For example, in the `todoApp` below `Object.assign()` is used to return a new
 `state` object with an updated `visibilityFilter` property:
 
@@ -33,7 +33,7 @@ function todoApp(state = initialState, action) {
 }
 ```
 
-The advantage of using the object spread syntax becomes more apparent when you’re composing complex objects. Below `getAddedIds` maps an array of `id` values to an array of objects with values returned from `getProduct` and `getQuantity`.
+The advantage of using the object spread syntax becomes more apparent when you're composing complex objects. Below `getAddedIds` maps an array of `id` values to an array of objects with values returned from `getProduct` and `getQuantity`.
 
 ```js
 return getAddedIds(state.cart).map(id => Object.assign(
@@ -54,7 +54,7 @@ return getAddedIds(state.cart).map(id => ({
 }))
 ```
 
-Since the object spread syntax is still a Stage 2 proposal for ECMAScript you’ll need to use a transpiler such as [Babel](http://babeljs.io/) to use it in production. You can use your existing `es2015` preset, install [`babel-plugin-transform-object-rest-spread`](http://babeljs.io/docs/plugins/transform-object-rest-spread/) and add it individually to the `plugins` array in your `.babelrc`.
+Since the object spread syntax is still a Stage 2 proposal for ECMAScript you'll need to use a transpiler such as [Babel](http://babeljs.io/) to use it in production. You can use your existing `es2015` preset, install [`babel-plugin-transform-object-rest-spread`](http://babeljs.io/docs/plugins/transform-object-rest-spread/) and add it individually to the `plugins` array in your `.babelrc`.
 
 ```js
 {
diff --git a/docs/recipes/WritingTests.md b/docs/recipes/WritingTests.md
index 9e0c8dd2bd..e4fda3ab48 100644
--- a/docs/recipes/WritingTests.md
+++ b/docs/recipes/WritingTests.md
@@ -5,7 +5,7 @@ Because most of the Redux code you write are functions, and many of them are pur
 ### Setting Up
 
 We recommend [Mocha](http://mochajs.org/) as the testing engine.
-Note that it runs in a Node environment, so you won’t have access to the DOM.
+Note that it runs in a Node environment, so you won't have access to the DOM.
 
 ```
 npm install --save-dev mocha
@@ -76,7 +76,7 @@ describe('actions', () => {
 
 ### Async Action Creators
 
-For async action creators using [Redux Thunk](https://github.com/gaearon/redux-thunk) or other middleware, it’s best to completely mock the Redux store for tests. You can apply the middleware to a mock store using [redux-mock-store](https://github.com/arnaudbenard/redux-mock-store). You can also use [nock](https://github.com/pgte/nock) to mock the HTTP requests.
+For async action creators using [Redux Thunk](https://github.com/gaearon/redux-thunk) or other middleware, it's best to completely mock the Redux store for tests. You can apply the middleware to a mock store using [redux-mock-store](https://github.com/arnaudbenard/redux-mock-store). You can also use [nock](https://github.com/pgte/nock) to mock the HTTP requests.
 
 #### Example
 
@@ -151,7 +151,7 @@ describe('async actions', () => {
 
 ### Reducers
 
-A reducer should return the new state after applying the action to the previous state, and that’s the behavior tested below.
+A reducer should return the new state after applying the action to the previous state, and that's the behavior tested below.
 
 #### Example
 
@@ -363,7 +363,7 @@ In a unit test, you would normally import the `App` component like this:
 import App from './App'
 ```
 
-However, when you import it, you’re actually holding the wrapper component returned by `connect()`, and not the `App` component itself. If you want to test its interaction with Redux, this is good news: you can wrap it in a [`<Provider>`](https://github.com/reactjs/react-redux#provider-store) with a store created specifically for this unit test. But sometimes you want to test just the rendering of the component, without a Redux store.
+However, when you import it, you're actually holding the wrapper component returned by `connect()`, and not the `App` component itself. If you want to test its interaction with Redux, this is good news: you can wrap it in a [`<Provider>`](https://github.com/reactjs/react-redux#provider-store) with a store created specifically for this unit test. But sometimes you want to test just the rendering of the component, without a Redux store.
 
 In order to be able to test the App component itself without having to deal with the decorator, we recommend you to also export the undecorated component:
 
@@ -377,7 +377,7 @@ export class App extends Component { /* ... */ }
 export default connect(mapStateToProps)(App)
 ```
 
-Since the default export is still the decorated component, the import statement pictured above will work as before so you won’t have to change your application code. However, you can now import the undecorated `App` components in your test file like this:
+Since the default export is still the decorated component, the import statement pictured above will work as before so you won't have to change your application code. However, you can now import the undecorated `App` components in your test file like this:
 
 ```js
 // Note the curly braces: grab the named export instead of default export
@@ -457,4 +457,4 @@ describe('middleware', () => {
 
 - [React Test Utils](http://facebook.github.io/react/docs/test-utils.html): Test Utilities for React. Used by Enzyme.
 
-- [Shallow rendering](http://airbnb.io/enzyme/docs/api/shallow.html): Shallow rendering lets you instantiate a component and effectively get the result of its `render` method just a single level deep instead of rendering components recursively to a DOM. Shallow rendering is useful for unit tests, where you test a particular component only, and importantly not its children. This also means that changing a child component won’t affect the tests for the parent component. Testing a component and all its children can be accomplished with [Enzyme's `mount()` method](http://airbnb.io/enzyme/docs/api/mount.html), aka full DOM rendering.
+- [Shallow rendering](http://airbnb.io/enzyme/docs/api/shallow.html): Shallow rendering lets you instantiate a component and effectively get the result of its `render` method just a single level deep instead of rendering components recursively to a DOM. Shallow rendering is useful for unit tests, where you test a particular component only, and importantly not its children. This also means that changing a child component won't affect the tests for the parent component. Testing a component and all its children can be accomplished with [Enzyme's `mount()` method](http://airbnb.io/enzyme/docs/api/mount.html), aka full DOM rendering.
diff --git a/examples/real-world/actions/index.js b/examples/real-world/actions/index.js
index 2692fcb069..96680788f5 100644
--- a/examples/real-world/actions/index.js
+++ b/examples/real-world/actions/index.js
@@ -76,7 +76,7 @@ function fetchStarred(login, nextPageUrl) {
 }
 
 // Fetches a page of starred repos by a particular user.
-// Bails out if page is cached and user didn’t specifically request next page.
+// Bails out if page is cached and user didn't specifically request next page.
 // Relies on Redux Thunk middleware.
 export function loadStarred(login, nextPage) {
   return (dispatch, getState) => {
@@ -111,7 +111,7 @@ function fetchStargazers(fullName, nextPageUrl) {
 }
 
 // Fetches a page of stargazers for a particular repo.
-// Bails out if page is cached and user didn’t specifically request next page.
+// Bails out if page is cached and user didn't specifically request next page.
 // Relies on Redux Thunk middleware.
 export function loadStargazers(fullName, nextPage) {
   return (dispatch, getState) => {
diff --git a/examples/real-world/containers/UserPage.js b/examples/real-world/containers/UserPage.js
index 2b5bd9b0fa..d29fa015cc 100644
--- a/examples/real-world/containers/UserPage.js
+++ b/examples/real-world/containers/UserPage.js
@@ -44,7 +44,7 @@ class UserPage extends Component {
   render() {
     const { user, login } = this.props
     if (!user) {
-      return <h1><i>Loading {login}’s profile...</i></h1>
+      return <h1><i>Loading {login}'s profile...</i></h1>
     }
 
     const { starredRepos, starredRepoOwners, starredPagination } = this.props
@@ -55,7 +55,7 @@ class UserPage extends Component {
         <List renderItem={this.renderRepo}
               items={zip(starredRepos, starredRepoOwners)}
               onLoadMoreClick={this.handleLoadMoreClick}
-              loadingLabel={`Loading ${login}’s starred...`}
+              loadingLabel={`Loading ${login}'s starred...`}
               {...starredPagination} />
       </div>
     )
diff --git a/index.d.ts b/index.d.ts
index 03c29ffd5d..b043c71dae 100644
--- a/index.d.ts
+++ b/index.d.ts
@@ -6,11 +6,11 @@
  *
  * Actions must have a `type` field that indicates the type of action being
  * performed. Types can be defined as constants and imported from another
- * module. It’s better to use strings for `type` than Symbols because strings
+ * module. It's better to use strings for `type` than Symbols because strings
  * are serializable.
  *
  * Other than `type`, the structure of an action object is really up to you.
- * If you’re interested, check out Flux Standard Action for recommendations on
+ * If you're interested, check out Flux Standard Action for recommendations on
  * how actions should be constructed.
  */
 export interface Action {
@@ -84,7 +84,7 @@ export function combineReducers<S>(reducers: ReducersMapObject): Reducer<S>;
  * `dispatch` function provided by the store instance without any middleware.
  *
  * The base dispatch function *always* synchronously sends an action to the
- * store’s reducer, along with the previous state returned by the store, to
+ * store's reducer, along with the previous state returned by the store, to
  * calculate a new state. It expects actions to be plain objects ready to be
  * consumed by the reducer.
  *
@@ -105,7 +105,7 @@ export interface Unsubscribe {
 }
 
 /**
- * A store is an object that holds the application’s state tree.
+ * A store is an object that holds the application's state tree.
  * There should only be a single store in a Redux app, as the composition
  * happens on the reducer level.
  *
@@ -211,7 +211,7 @@ export interface StoreCreator {
  * original store. There is an example in `compose` documentation
  * demonstrating that.
  *
- * Most likely you’ll never write a store enhancer, but you may use the one
+ * Most likely you'll never write a store enhancer, but you may use the one
  * provided by the developer tools. It is what makes time travel possible
  * without the app being aware it is happening. Amusingly, the Redux
  * middleware implementation is itself a store enhancer.
@@ -299,7 +299,7 @@ export function applyMiddleware(...middlewares: Middleware[]): GenericStoreEnhan
  * an action creator is a factory that creates an action.
  *
  * Calling an action creator only produces an action, but does not dispatch
- * it. You need to call the store’s `dispatch` function to actually cause the
+ * it. You need to call the store's `dispatch` function to actually cause the
  * mutation. Sometimes we say *bound action creators* to mean functions that
  * call an action creator and immediately dispatch its result to a specific
  * store instance.
diff --git a/logo/README.md b/logo/README.md
index 7aed001ee2..b6f6dc7476 100644
--- a/logo/README.md
+++ b/logo/README.md
@@ -1,7 +1,7 @@
 # The Redux Logo
 
 This is the only official Redux logo.  
-Don’t use any other logos to represent Redux.  
+Don't use any other logos to represent Redux.  
 
 It comes in several flavors.
 
@@ -21,7 +21,7 @@ Download as [PNG](https://raw.githubusercontent.com/reactjs/redux/master/logo/lo
 
 <img src='https://raw.githubusercontent.com/reactjs/redux/master/logo/logo-title-light.png' alt='Redux Logo with Light Title' width='500'>
 
-*(You can’t see the text but it’s there, in white.)*
+*(You can't see the text but it's there, in white.)*
 
 Download as [PNG](https://raw.githubusercontent.com/reactjs/redux/master/logo/logo-title-light.png).
 
@@ -29,7 +29,7 @@ Download as [PNG](https://raw.githubusercontent.com/reactjs/redux/master/logo/lo
 
 Whenever possible, we ask you to use the originals provided on this page.
 
-If for some reason you must change how the title is rendered and can’t use the prerendered version we provide, we ask that you use the free [Lato Black](http://www.latofonts.com/lato-free-fonts/) font and ensure there is enough space between the logo and the title.
+If for some reason you must change how the title is rendered and can't use the prerendered version we provide, we ask that you use the free [Lato Black](http://www.latofonts.com/lato-free-fonts/) font and ensure there is enough space between the logo and the title.
 
 When in doubt, use the original logos.