fresh builds + docx version

.gitignore

@@ -1,4 +1,5 @@
 .vscode
 node_modules
 package-lock.json
-*/desktop.ini
+*/desktop.ini
+*/~*.doc*

README.md

@@ -18,6 +18,8 @@ The work is distributed under a Creative Commons Attribution-NonCommercial 4.0 l
 
 See full license in LICENSE.md file or at [Creative Commons Website](http://creativecommons.org/licenses/by-nc/4.0/).
 
+You might support this work [on Patreon](https://www.patreon.com/yatwirl).
+
 ## Current State and the Roadmap
 
 Right now Section I (‘API Design’) is finished. The Section is lacking readable schemes, I'll draw them later.

build-docx.mjs

@@ -0,0 +1,24 @@
+import { readFileSync, writeFileSync } from 'fs';
+import { resolve } from 'path';
+import htmlDocxJs from 'html-docx-js';
+
+const dir = process.cwd();
+
+const languages = (process.argv[2] && process.argv[2].split(',')) || [
+    'en',
+    'ru'
+];
+
+languages.forEach(async (lang) => {
+    const l10n = JSON.parse(
+        readFileSync(resolve(dir, 'src', lang, 'l10n.json'))
+    );
+    const html = readFileSync(
+        resolve(dir, 'docs', `${l10n.file}.${lang}.html`),
+        'utf-8'
+    );
+    writeFileSync(
+        resolve(dir, 'docs', `${l10n.file}.${lang}.docx`),
+        htmlDocxJs.asBlob(html)
+    );
+});

build.mjs

@@ -1,6 +1,6 @@
 import { resolve as pathResolve } from 'path';
 import templates from './src/templates.js';
-import { init, plugins } from '../The-Book-Builder/index.js';
+import { init, plugins } from '@twirl/book-builder';
 import { readFileSync } from 'fs';
 
 const l10n = {

package.json

@@ -5,9 +5,11 @@
     "author": "Sergey Konstantinov <twirl-team@yandex.ru>",
     "repository": "github.com:twirl/The-API-Book",
     "devDependencies": {
-        "@twirl/book-builder": "0.0.9"
+        "@twirl/book-builder": "0.0.10",
+        "html-docx-js": "^0.3.1"
     },
     "scripts": {
-        "build": "node build.mjs"
+        "build": "node build.mjs",
+        "build-docx": "node build-docx.mjs"
     }
 }

src/css/style.css

@@ -107,7 +107,6 @@ h2 {
 
 h3 {
     font-size: 140%;
-    font-variant: small-caps;
 }
 
 h4,

src/en/clean-copy/01-Introduction/01.md

@@ -1,12 +1,8 @@
 ### On the Structure of This Book
 
-The book you're holding in your hands comprises this Introduction and three large sections.
+The book you're holding in your hands comprises this Introduction and 'The API Design' Section. We will discuss designing APIs as a concept: how to build the architecture properly, from high-level planning down to final interfaces.
 
-In Section I we'll discuss designing APIs as a concept: how to build the architecture properly, from high-level planning down to final interfaces.
-
-Section II is dedicated to an API's lifecycle: how interfaces evolve over time, and how to elaborate the product to match users' needs.
-
-Finally, Section III is more about the un-engineering sides of the API, like API marketing, organizing support, and working with a community.
+Two more sections are planned for the future revisions of this book: Section II will be dedicated to an API's lifecycle: how interfaces evolve over time, and how to elaborate the product to match users' needs. Finally, Section III will be more about the un-engineering sides of the API, like API marketing, organizing support, and working with a community.
 
 First, two sections are interesting to engineers mostly, while the third section is more relevant to both engineers and product managers. However, we insist that the third section is the most important for the API software developer. Since an API is a product for engineers, you cannot simply pronounce a non-engineering team responsible for product planning and support. Nobody but you understands more about your API's product features.
 

src/en/clean-copy/01-Introduction/02.md

@@ -12,14 +12,9 @@ In other words, hundreds or even thousands of different APIs must work correctly
 
 **An API is an obligation**. A formal obligation to connect different programmable contexts.
 
-When I'm asked for an example of a well-designed API, I usually show the picture of a Roman aqueduct:
+When I'm asked for an example of a well-designed API, I usually show a picture of a Roman aqueduct:
 
-<<<<<<< HEAD
 [![igorelick @ pixabay](/img/pont-du-gard.jpg "The Pont-du-Gard aqueduct. Built in the 1st century AD")](https://pixabay.com/photos/pont-du-gard-france-aqueduct-bridge-3909998/)
-=======
-![The Pont-du-Gard aqueduct. Built in the 1st century CE](/src/img/pont-du-gard.jpg "The Pont-du-Gard aqueduct. Built in the 1st century CE")
-###### Photo credit: [igorelick @ pixabay](https://pixabay.com/photos/pont-du-gard-france-aqueduct-bridge-3909998/)
->>>>>>> 68182b4 (typos, style fixes, errors)
 
   * it interconnects two areas;
   * backwards compatibility being broken not a single time in two thousand years.

src/en/clean-copy/intro.html

@@ -8,8 +8,10 @@
         <a href="mailto:twirl-team@yandex.ru">twirl-team@yandex.ru</a>
         &nbsp;&middot;
         <a href="https://www.linkedin.com/in/twirl/"
-            >https://www.linkedin.com/in/twirl/</a
+            >www.linkedin.com/in/twirl/</a
         >
+        &nbsp;&middot;
+        <a href="https://www.patreon.com/yatwirl">www.patreon.com/yatwirl</a>
     </p>
     <p>
         The API-first development is one of the hottest technical topics in
@@ -24,7 +26,7 @@
     <p>
         Illustrations by Maria Konstantinova<br /><a
             href="https://www.instagram.com/art.mari.ka/"
-            >https://www.instagram.com/art.mari.ka/</a
+            >www.instagram.com/art.mari.ka/</a
         >
     </p>
 

src/en/l10n.json

@@ -4,7 +4,7 @@
     "chapter": "Chapter",
     "toc": "Table of Contents",
     "frontPage": "Front Page",
-    "description": "Designing APIs is a very special skill: API is a multiplier to both your opportunities and mistakes. This book is written to share the expertise and describe the best practices in the API design. The book comprises three large sections. In Section I we'll discuss designing APIs as a concept: how to build the architecture properly, from high-level planning down to final interfaces. Section II is dedicated to an API's lifecycle: how interfaces evolve over time, and how to elaborate the product to match users' needs. Finally, Section III is more about un-engineering sides of the API, like API marketing, organizing support, and working with a community.",
+    "description": "Designing APIs is a very special skill: API is a multiplier to both your opportunities and mistakes. This book is written to share the expertise and describe the best practices in the API design. In Section I we'll discuss designing APIs as a concept: how to build the architecture properly, from high-level planning down to final interfaces.",
     "locale": "en_US",
     "file": "API",
     "url": "https://twirl.github.io/The-API-Book/docs/API.en.html",

src/ru/clean-copy/intro.html

@@ -8,8 +8,10 @@
         <a href="mailto:twirl-team@yandex.ru">twirl-team@yandex.ru</a>
         &nbsp;&middot;
         <a href="https://www.linkedin.com/in/twirl/"
-            >https://www.linkedin.com/in/twirl/</a
+            >www.linkedin.com/in/twirl/</a
         >
+        &nbsp;&middot;
+        <a href="https://www.patreon.com/yatwirl">www.patreon.com/yatwirl</a>
     </p>
     <p>
         «API-first» подход — одна из самых горячих горячих тем в разработке
@@ -25,7 +27,7 @@
     <p>
         Иллюстрации: Мария Константинова<br /><a
             href="https://www.instagram.com/art.mari.ka/"
-            >https://www.instagram.com/art.mari.ka/</a
+            >www.instagram.com/art.mari.ka/</a
         >
     </p>