diff --git a/pages/Functions.md b/pages/Functions.md
index fc07ef3e9..01f11581e 100644
--- a/pages/Functions.md
+++ b/pages/Functions.md
@@ -2,7 +2,7 @@
 
 Functions are the fundamental building block of any applications in JavaScript.
 They're how you build up layers of abstraction, mimicking classes, information hiding, and modules.
-In TypeScript, while there are classes and modules, function still play the key role in describing how to `do` things.
+In TypeScript, while there are classes, namespaces, and modules, function still play the key role in describing how to *do* things.
 TypeScript also adds some new capabilities to the standard JavaScript functions to make them easier to work with.
 
 # Functions
diff --git a/pages/Generics.md b/pages/Generics.md
index 15b1b99cc..fe728c24a 100644
--- a/pages/Generics.md
+++ b/pages/Generics.md
@@ -190,7 +190,7 @@ When we use `GenericIdentityFn`, we now will also need to specify the correspond
 Understanding when to put the type parameter directly on the call signature and when to put it on the interface itself will be helpful in describing what aspects of a type are generic.
 
 In addition to generic interfaces, we can also create generic classes.
-Note that it is not possible to create generic enums and modules.
+Note that it is not possible to create generic enums and namespaces.
 
 # Generic Classes
 
diff --git a/pages/Modules.md b/pages/Namespaces and Modules.md
similarity index 72%
rename from pages/Modules.md
rename to pages/Namespaces and Modules.md
index cbfc3baab..1614996a4 100644
--- a/pages/Modules.md
+++ b/pages/Namespaces and Modules.md	
@@ -1,12 +1,24 @@
 # Introduction
-This post outlines the various ways to organize your code using modules in TypeScript.
-We'll be covering internal and external modules and we'll discuss when each is appropriate and how to use them.
-We'll also go over some advanced topics of how to use external modules, and address some common pitfalls when using modules in TypeScript.
+
+This post outlines the various ways to organize your code using namespaces and modules in TypeScript.
+We'll be covering namespaces (previously "internal modules") and modules (previously called "external modules") and we'll discuss when each is appropriate and how to use them.
+We'll also go over some advanced topics of how to use namespaces and modules, and address some common pitfalls when using them in TypeScript.
+
+## A note about terminology
+
+We just alluded to "internal modules" and "external modules".
+If you're vaguely familiar with these terms, it's important to note that in TypeScript 1.5, the nomenclature has changed.
+"Internal modules" are now "namespaces".
+"External modules" are now simply "modules", as to align with ECMAScript 6's terminology.
+
+Additionally, anywhere the `module` keyword was used when declaring an internal module, the `namespace` keyword can and should be used instead.
+
+This avoids confusing new users by overloading them with similarly named terms.
 
 ## First steps
 
 Let's start with the program we'll be using as our example throughout this page.
-We've written a small set of simplistic string validators, like you might use when checking a user's input on a form in a webpage or checking the format of an externally-provided data file.
+We've written a small set of simplistic string validators, as you might write to check a user's input on a form in a webpage or check the format of an externally-provided data file.
 
 ##### Validators in a single file
 
@@ -44,20 +56,20 @@ strings.forEach(s => {
 });
 ```
 
-## Adding Modularity
+## Namespacing
 
 As we add more validators, we're going to want to have some kind of organization scheme so that we can keep track of our types and not worry about name collisions with other objects.
-Instead of putting lots of different names into the global namespace, let's wrap up our objects into a module.
+Instead of putting lots of different names into the global namespace, let's wrap up our objects into a namespace.
 
-In this example, we'll move all validator-related entities into a module called `Validation`.
-Because we want the interfaces and classes here to be visible outside the module, we preface them with `export`.
-Conversely, the variables `lettersRegexp` and `numberRegexp` are implementation details, so they are left unexported and will not be visible to code outside the module.
-In the test code at the bottom of the file, we now need to qualify the names of the types when used outside the module, e.g. `Validation.LettersOnlyValidator`.
+In this example, we'll move all validator-related entities into a namespace called `Validation`.
+Because we want the interfaces and classes here to be visible outside the namespace, we preface them with `export`.
+Conversely, the variables `lettersRegexp` and `numberRegexp` are implementation details, so they are left unexported and will not be visible to code outside the namespace.
+In the test code at the bottom of the file, we now need to qualify the names of the types when used outside the namespace, e.g. `Validation.LettersOnlyValidator`.
 
-##### Modularized Validators
+##### Namespaced Validators
 
 ```TypeScript
-module Validation {
+namespace Validation {
     export interface StringValidator {
         isAcceptable(s: string): boolean;
     }
@@ -96,17 +108,17 @@ strings.forEach(s => {
 
 As our application grows, we'll want to split the code across multiple files to make it easier to maintain.
 
-## Multi-file internal modules
+## Multi-file namespaces
 
-Here, we'll split our `Validation` module across many files.
-Even though the files are separate, they can each contribute to the same module and can be consumed as if they were all defined in one place.
+Here, we'll split our `Validation` namespace across many files.
+Even though the files are separate, they can each contribute to the same namespace and can be consumed as if they were all defined in one place.
 Because there are dependencies between files, we'll add reference tags to tell the compiler about the relationships between the files.
 Our test code is otherwise unchanged.
 
 ##### Validation.ts
 
 ```TypeScript
-module Validation {
+namespace Validation {
     export interface StringValidator {
         isAcceptable(s: string): boolean;
     }
@@ -117,7 +129,7 @@ module Validation {
 
 ```TypeScript
 /// <reference path="Validation.ts" />
-module Validation {
+namespace Validation {
     var lettersRegexp = /^[A-Za-z]+$/;
     export class LettersOnlyValidator implements StringValidator {
         isAcceptable(s: string) {
@@ -131,7 +143,7 @@ module Validation {
 
 ```TypeScript
 /// <reference path="Validation.ts" />
-module Validation {
+namespace Validation {
     var numberRegexp = /^[0-9]+$/;
     export class ZipCodeValidator implements StringValidator {
         isAcceptable(s: string) {
@@ -162,7 +174,8 @@ strings.forEach(s => {
 });
 ```
 
-Once there are multiple files involved, we'll need to make sure all of the compiled code gets loaded. There are two ways of doing this.
+Once there are multiple files involved, we'll need to make sure all of the compiled code gets loaded.
+There are two ways of doing this.
 
 First, we can use concatenated output using the `--out` flag to compile all of the input files into a single JavaScript output file:
 
@@ -176,7 +189,8 @@ The compiler will automatically order the output file based on the reference tag
 tsc --out sample.js Validation.ts LettersOnlyValidator.ts ZipCodeValidator.ts Test.ts
 ```
 
-Alternatively, we can use per-file compilation (the default) to emit one JavaScript file for each input file. If multiple JS files get produced, we'll need to use `<script>` tags on our webpage to load each emitted file in the appropriate order, for example:
+Alternatively, we can use per-file compilation (the default) to emit one JavaScript file for each input file.
+If multiple JS files get produced, we'll need to use `<script>` tags on our webpage to load each emitted file in the appropriate order, for example:
 
 ##### MyTestPage.html (excerpt)
 
@@ -187,33 +201,34 @@ Alternatively, we can use per-file compilation (the default) to emit one JavaScr
     <script src="Test.js" type="text/javascript" />
 ```
 
-# Going External
+# Going Modular
 
-TypeScript also has the concept of an external module. External modules are used in two cases: node.js and require.js.
-Applications not using node.js or require.js do not need to use external modules and can best be organized using the internal module concept outlined above.
+TypeScript also has the concept of modules.
+Modules are used in two cases: Node.js and require.js.
+Applications not using Node.js or require.js do not need to use modules and can best be organized using the namespaces, outlined above.
 
-In external modules, relationships between files are specified in terms of imports and exports at the file level.
-In TypeScript, any file containing a top-level `import` or `export` is considered an external module.
+When using modules, relationships between files are specified in terms of imports and exports at the file level.
+In TypeScript, any file containing a top-level `import` or `export` is considered a module.
 
-Below, we have converted the previous example to use external modules.
-Notice that we no longer use the module keyword – the files themselves constitute a module and are identified by their filenames.
+Below, we have converted the previous example to use modules.
+Notice that we do not have to use a `module` keyword - the files themselves constitute a module and are identified by their filenames.
 
 The reference tags have been replaced with `import` statements that specify the dependencies between modules.
-The `import` statement has two parts: the name that the module will be known by in this file, and the require keyword that specifies the path to the required module:
+The `import` statement has two parts: the name that the module will be known by in this file, and the `require` keyword that specifies the path to the required module:
 
 ```TypeScript
 import someMod = require('someModule');
 ```
 
-We specify which objects are visible outside the module by using the `export` keyword on a top-level declaration, similarly to how `export` defined the public surface area of an internal module.
+We specify which objects are visible outside the module by using the `export` keyword on a top-level declaration, similarly to how `export` defined the public surface area of a namespace.
 
-To compile, we must specify a module target on the command line. For node.js, use `--module commonjs`; for require.js, use `--module amd`. For example:
+To compile, we must specify a module target on the command line. For Node.js, use `--module commonjs`; for require.js, use `--module amd`. For example:
 
 ```Shell
 tsc --module commonjs Test.ts
 ```
 
-When compiled, each external module will become a separate `.js` file.
+When compiled, each module will become a separate `.js` file.
 As with reference tags, the compiler will follow `import` statements to compile dependent files.
 
 ##### Validation.ts
@@ -269,9 +284,9 @@ strings.forEach(s => {
 });
 ```
 
-## Code Generation for External Modules
+## Code Generation for Modules
 
-Depending on the module target specified during compilation, the compiler will generate appropriate code for either node.js (commonjs) or require.js (AMD) module-loading systems.
+Depending on the module target specified during compilation, the compiler will generate appropriate code for either Node.js (commonjs) or require.js (AMD) module-loading systems.
 For more information on what the `define` and `require` calls in the generated code do, consult the documentation for each module loader.
 
 This simple example shows how the names used during importing and exporting get translated into the module loading code.
@@ -299,14 +314,15 @@ exports.t = m.something + 1;
 ```
 
 # Export =
-In the previous example, when we consumed each validator, each module only exported one value. In
-cases like this, it's cumbersome to work with these symbols through their qualified name when a single identifier would do just as well.
+In the previous example, when we consumed each validator, each module only exported one value.
+In cases like this, it's cumbersome to work with these symbols through their qualified name when a single identifier would do just as well.
 
 The `export =` syntax specifies a single object that is exported from the module.
-This can be a class, interface, module, function, or enum. When imported, the exported symbol is consumed directly and is not qualified by any name.
+This can be a class, interface, namespace, function, or enum.
+When imported, the exported symbol is consumed directly and is not qualified by any name.
 
 Below, we've simplified the Validator implementations to only export a single object from each module using the `export =` syntax.
-This simplifies the consumption code – instead of referring to `zip.ZipCodeValidator`, we can simply refer to `zipValidator`.
+This simplifies the consumption code – instead of referring to `zip.ZipCodeValidator`, we can simply refer to `zipValidator`.
 
 ##### Validation.ts
 
@@ -366,14 +382,14 @@ strings.forEach(s => {
 # Aliases
 
 Another way that you can simplify working with either kind of module is to use `import q = x.y.z` to create shorter names for commonly-used objects.
-Not to be confused with the `import x = require('name')` syntax used to load external modules, this syntax simply creates an alias for the specified symbol.
-You can use these sorts of imports (commonly referred to as aliases) for any kind of identifier, including objects created from external module imports.
+Not to be confused with the `import x = require('name')` syntax used to load modules, this syntax simply creates an alias for the specified symbol.
+You can use these sorts of imports (commonly referred to as aliases) for any kind of identifier, including objects created from module imports.
 
 ##### Basic Aliasing
 
 ```TypeScript
-module Shapes {
-    export module Polygons {
+namespace Shapes {
+    export namespace Polygons {
         export class Triangle { }
         export class Square { }
     }
@@ -393,18 +409,18 @@ In some cases, you may want to only load a module under some conditions.
 In TypeScript, we can use the pattern shown below to implement this and other advanced loading scenarios to directly invoke the module loaders without losing type safety.
 
 The compiler detects whether each module is used in the emitted JavaScript.
-For modules that are only used as part of the type system, no require calls are emitted.
+If a module identifier is only ever used in type annotations and never as an expression then no `require` call is emitted for that module.
 This culling of unused references is a good performance optimization, and also allows for optional loading of those modules.
 
-The core idea of the pattern is that the `import id = require('...')` statement gives us access to the types exposed by the external module.
-The module loader is invoked (through require) dynamically, as shown in the if blocks below.
+The core idea of the pattern is that the `import id = require('...')` statement gives us access to the types exposed by the module.
+The module loader is invoked (through `require`) dynamically, as shown in the `if` blocks below.
 This leverages the reference-culling optimization so that the module is only loaded when needed.
-For this pattern to work, it's important that the symbol defined via import is only used in type positions (i.e. never in a position that would be emitted into the JavaScript).
+For this pattern to work, it's important that the symbol defined via an `import` is only used in type positions (i.e. never in a position that would be emitted into the JavaScript).
 
 To maintain type safety, we can use the `typeof` keyword.
-The `typeof` keyword, when used in a type position, produces the type of a value, in this case the type of the external module.
+The `typeof` keyword, when used in a type position, produces the type of a value, in this case the type of the module.
 
-##### Dynamic Module Loading in node.js
+##### Dynamic Module Loading in Node.js
 
 ```TypeScript
 declare var require;
@@ -430,22 +446,24 @@ if (needZipValidation) {
 # Working with Other JavaScript Libraries
 
 To describe the shape of libraries not written in TypeScript, we need to declare the API that the library exposes.
-Because most JavaScript libraries expose only a few top-level objects, modules are a good way to represent them.
+Because most JavaScript libraries expose only a few top-level objects, namespaces and modules are a good way to represent them.
 We call declarations that don't define an implementation "ambient".
 Typically these are defined in `.d.ts` files.
 If you're familiar with C/C++, you can think of these as `.h` files.
-Let's look at a few examples with both internal and external examples.
+Let's look at a few examples.
 
-## Ambient Internal Modules
+## Ambient Namespaces
 
 The popular library D3 defines its functionality in a global object called `d3`.
-Because this library is loaded through a `<script>` tag (instead of a module loader), its declaration uses internal modules to define its shape.
-For the TypeScript compiler to see this shape, we use an ambient internal module declaration. For example:
+Because this library is loaded through a `<script>` tag (instead of a module loader), its declaration uses namespaces to define its shape.
+For the TypeScript compiler to see this shape, we use an ambient namespace declaration.
+For example, we could begin writing it as follows:
 
 ##### D3.d.ts (simplified excerpt)
 
+<!-- TODO: This is not at all how it's done on DT - do we want to change this? -->
 ```TypeScript
-declare module D3 {
+declare namespace d3 {
     export interface Selectors {
         select: {
             (selector: string): Selection;
@@ -466,10 +484,12 @@ declare module D3 {
 declare var d3: D3.Base;
 ```
 
-## Ambient External Modules
+## Ambient Modules
+
 In Node.js, most tasks are accomplished by loading one or more modules.
 We could define each module in its own `.d.ts` file with top-level export declarations, but it's more convenient to write them as one larger `.d.ts` file.
-To do so, we use the quoted name of the module which will be available to a later import. For example:
+To do so, we use a construct similar to ambient namespaces, but we use the `module` keyword and the quoted name of the module which will be available to a later import.
+For example:
 
 ##### node.d.ts (simplified excerpt)
 
@@ -499,27 +519,26 @@ import url = require("url");
 var myUrl = url.parse("http://www.typescriptlang.org");
 ```
 
+# Pitfalls of Namespaces and Modules
 
-# Pitfalls of Modules
-
-In this section we'll describe various common pitfalls in using internal and external modules, and how to avoid them.
+In this section we'll describe various common pitfalls in using namespaces and modules, and how to avoid them.
 
-## `/// <reference>`-ing an external module
+## `/// <reference>`-ing a module
 
-A common mistake is to try to use the `/// <reference>` syntax to refer to an external module file, rather than using import.
-To understand the distinction, we first need to understand the three ways that the compiler can locate the type information for an external module.
+A common mistake is to try to use the `/// <reference>` syntax to refer to a module file, rather than using import.
+To understand the distinction, we first need to understand the three ways that the compiler can locate the type information for a module.
 
 The first is by finding a `.ts` file named by an `import x = require(...);` declaration.
 That file should be an implementation file with top-level import or export declarations.
 
 The second is by finding a `.d.ts` file, similar to above, except that instead of being an implementation file, it's a declaration file (also with top-level import or export declarations).
 
-The final way is by seeing an "ambient external module declaration", where we `declare` a module with a matching quoted name.
+The final way is by seeing an "ambient module declaration", where we `declare` a module with a matching quoted name.
 
 ##### myModules.d.ts
 
 ```TypeScript
-// In a .d.ts file or .ts file that is not an external module:
+// In a .d.ts file or .ts file that is not a module:
 declare module "SomeModule" {
     export function fn(): string;
 }
@@ -532,16 +551,16 @@ declare module "SomeModule" {
 import m = require("SomeModule");
 ```
 
-The reference tag here allows us to locate the declaration file that contains the declaration for the ambient external module.
+The reference tag here allows us to locate the declaration file that contains the declaration for the ambient module.
 This is how the node.d.ts file that several of the TypeScript samples use is consumed, for example.
 
 ## Needless Namespacing
 
-If you're converting a program from internal modules to external modules, it can be easy to end up with a file that looks like this:
+If you're converting a program from namespaces to modules, it can be easy to end up with a file that looks like this:
 
 ##### shapes.ts
 ```TypeScript
-export module Shapes {
+export namespace Shapes {
     export class Triangle { /* ... */ }
     export class Square { /* ... */ }
 }
@@ -556,11 +575,11 @@ import shapes = require('./shapes');
 var t = new shapes.Shapes.Triangle(); // shapes.Shapes?
 ```
 
-A key feature of external modules in TypeScript is that two different external modules will never contribute names to the same scope.
-Because the consumer of an external module decides what name to assign it, there's no need to proactively wrap up the exported symbols in a namespace.
+A key feature of modules in TypeScript is that two different modules will never contribute names to the same scope.
+Because the consumer of a module decides what name to assign it, there's no need to proactively wrap up the exported symbols in a namespace.
 
-To reiterate why you shouldn't try to namespace your external module contents, the general idea of namespacing is to provide logical grouping of constructs and to prevent name collisions.
-Because the external module file itself is already a logical grouping, and its top-level name is defined by the code that imports it, it's unnecessary to use an additional module layer for exported objects.
+To reiterate why you shouldn't try to namespace your module contents, the general idea of namespacing is to provide logical grouping of constructs and to prevent name collisions.
+Because the module file itself is already a logical grouping, and its top-level name is defined by the code that imports it, it's unnecessary to use an additional module layer for exported objects.
 
 Here's a revised example:
 
@@ -577,7 +596,7 @@ import shapes = require('./shapes');
 var t = new shapes.Triangle();
 ```
 
-## Trade-offs of External Modules
+## Trade-offs of Modules
 
-Just as there is a one-to-one correspondence between JS files and modules, TypeScript has a one-to-one correspondence between external module source files and their emitted JS files.
-One effect of this is that it's not possible to use the `--out` compiler switch to concatenate multiple external module source files into a single JavaScript file.
+Just as there is a one-to-one correspondence between JS files and modules, TypeScript has a one-to-one correspondence between module source files and their emitted JS files.
+One effect of this is that it's not possible to use the `--out` compiler switch to concatenate multiple module source files into a single JavaScript file.
diff --git a/pages/Writing Definition Files.md b/pages/Writing Definition Files.md
index 6cd70f5e8..24260a2f2 100644
--- a/pages/Writing Definition Files.md	
+++ b/pages/Writing Definition Files.md	
@@ -12,9 +12,9 @@ The examples below will be written as if you were reading documentation that pre
 
 ## Namespacing
 
-When defining interfaces (for example, "options" objects), you have a choice about whether to put these types inside a module or not.
+When defining interfaces (for example, "options" objects), you have a choice about whether to put these types inside a namespace or not.
 This is largely a judgement call -- if the consumer is likely to often declare variables or parameters of that type, and the type can be named without risk of colliding with other types, prefer placing it in the global namespace.
-If the type is not likely to be referenced directly, or can't be named with a reasonably unique name, do use a module to prevent it from colliding with other types.
+If the type is not likely to be referenced directly, or can't be named with a reasonably unique name, do use a namespace to prevent it from colliding with other types.
 
 ## Callbacks
 
@@ -114,7 +114,7 @@ animalFactory.create("cat", { height: 32 });
 #### Typing
 
 ```TypeScript
-module animalFactory {
+namespace animalFactory {
     interface AnimalOptions {
         name: string;
         height?: number;
@@ -136,9 +136,9 @@ zooKeeper(giraffeCage);
 #### Typing
 
 ```TypeScript
-// Note: Function must precede module
+// Note: Function must precede namespace
 function zooKeeper(cage: AnimalCage);
-module zooKeeper {
+namespace zooKeeper {
     var workSchedule: string;
 }
 ```
@@ -185,7 +185,7 @@ zoo.open();
 #### Typing
 
 ```TypeScript
-module zoo {
+namespace zoo {
   function open(): void;
 }
 
@@ -194,7 +194,7 @@ declare module "zoo" {
 }
 ```
 
-## Single Complex Object in External Modules
+## Single Complex Object in Modules
 
 #### Usage
 
@@ -214,7 +214,7 @@ eagle.favorite = 'golden';
 ```TypeScript
 // Note: can use any name here, but has to be the same throughout this file
 declare function eagle(name: string): eagle;
-declare module eagle {
+declare namespace eagle {
     var favorite: string;
     function fly(): void;
 }
@@ -230,7 +230,7 @@ export = eagle;
 #### Usage
 
 ```TypeScript
-addLater(3, 4, (x) => console.log('x = ' + x));
+addLater(3, 4, x => console.log('x = ' + x));
 ```
 
 #### Typing
@@ -240,5 +240,5 @@ addLater(3, 4, (x) => console.log('x = ' + x));
 function addLater(x: number, y: number, (sum: number) => void): void;
 ```
 
-Please post a comment [here](https://github.com/Microsoft/TypeScript/issues) if there's a pattern you'd like to see documented!
+Please post a comment [here](https://github.com/Microsoft/TypeScript-Handbook/issues) if there's a pattern you'd like to see documented!
 We'll add to this as we can.