minor solution.md fixes

solution.md

@@ -107,7 +107,7 @@ and it's good and convenient enough for API prototyping.
 ## OMDB format
 
 Unfortunately, I couldn't find any clear documentation on OMDB response format.
-Instead, I just picked a few actual OMDB responses (mostly the ones described in [`omdb/converters.spec.ts`](src/integration/movies/omdb/converters.spec.ts)),
+Instead, I just picked a few actual OMDB responses (mostly the ones listed in [`omdb/converters.spec.ts`](src/integration/movies/omdb/converters.spec.ts)),
 and adapted my type definitions and converters to them.
 
 As a result, I assume that all responses from OMDB satisfy
@@ -143,7 +143,7 @@ sample JSONs only have one language per movie, as a two-letter code,
 while IMDB data contains a list of languages, not all of them even having two-letter codes
 (because there are more languages in the world than two letter-codes):
 for example, tt7394674 has `Language: 'English, Micmac'` in OMDB response;
-a blockbuster tt11866324 (shot mostly in Komanche) has `Language: 'English, North American Indian, French'`.
+a blockbuster tt11866324 (shot mostly in Comanche) has `Language: 'English, North American Indian, French'`.
 So I decided to ignore the language field from OMDB, and only use the language field from the internal database.
 
 After all these adjustments, the merging algorithm was as simple as doing `const mergedData = { ...normalizedOmdbData, ...normalizedInternalData }`,
@@ -160,7 +160,7 @@ I decided to use plural names for all six.
 The original assignment didn't mention anything about how should one handle requests for movies
 that are present in our "database" but not OMDB, or vice versa.
 On practice, all four entries present in sample JSONs have corresponding entries in OMDB.
-For simplicity (and in order to guarantee that `/api/movied/:id` endpoint always returns full merged `MovieData` object),
+For simplicity (and in order to guarantee that `/api/movies/:id` endpoint always returns full merged `MovieData` object),
 I decided to return 404 when at least one of the sources does not have any data.
 Changing the implementation so that API returns partial data if only one of the sources knows about the requested movie would be trivial.
 
@@ -185,7 +185,7 @@ I did not have any time to come up with a good test cases, so most tests work on
 ## Git
 
 The assignment has two contradicting messages:
-that I should use git to document my work ("We will look at the git history of your pull request to determine the way you approached this"),
+that I should use git to document my work ("_We will look at the git history of your pull request to determine the way you approached this_"),
 without squashing or bundling;
 but also that you will evaluate the proper use of git.