Update content of files

data/web/corefork.telegram.org/api/folders.html

@@ -102,7 +102,7 @@ Clients can also receive <a href="/constructor/updateDialogFilters">updateDialog
 <p>If the new value of the toggle is different, the method will emit an <a href="/constructor/updateDialogFilters">updateDialogFilters</a> to all other currently-logged in sessions, which should trigger a call to <a href="/method/messages.toggleDialogFilterTags">messages.toggleDialogFilterTags</a> to load the new value of the toggle, in <a href="/constructor/messages.dialogFilters">messages.dialogFilters</a>.<code>tags_enabled</code>.  </p>
 <p>If folder tags are enabled, clients should add folder tags (one for each folder the dialog entry is a part of, except for the "All chats" folder represented by <a href="/constructor/dialogFilterDefault">dialogFilterDefault</a> and tags with <code>color=-1</code>) to all dialog entries, under the preview of the latest message.  </p>
 <p>These folder tags should contain the name of the folder, and should be colored with the <code>color</code> specified in the dialog folder entry.<br>
-The color is an integer ranging from -1 to to 6; if -1, the tag must not be shown in the dialog list; use red, orange, violet, green, cyan, blue, pink for indexes 0 to 6 (i.e. the same colors used for randomized fallback <a href="/api/colors">message accent colors</a>).</p>
+The color is an integer ranging from -1 to 6; if -1, the tag must not be shown in the dialog list; use red, orange, violet, green, cyan, blue, pink for indexes 0 to 6 (i.e. the same colors used for randomized fallback <a href="/api/colors">message accent colors</a>).</p>
 <p>The tag <code>color</code> may only be changed if the user has a <a href="/api/premium">Premium</a> subscription and tags are enabled.  </p>
 <h4><a class="anchor" href="#shared-folders" id="shared-folders" name="shared-folders"><i class="anchor-icon"></i></a>Shared folders</h4>
 <pre><code><a href='/constructor/inputChatlistDialogFilter'>inputChatlistDialogFilter</a>#f3e0da33 filter_id:<a href='/type/int'>int</a> = <a href='/type/InputChatlist'>InputChatlist</a>;

data/web/corefork.telegram.org/api/forum.html

@@ -95,7 +95,7 @@ To fetch information about one or more topics by their ID, use <a href="/method/
 On the other hand, topics with <code>id != 1</code> are just the <a href="/api/threads">message thread</a> of the <a href="/constructor/messageActionTopicCreate">messageActionTopicCreate</a> service message that created that topic.<br>
 This means that topics should be treated similarly to <a href="/api/threads">message threads</a> by the client.<br>
 To send messages to these topics, pass the topic ID to the <code>reply_to_msg_id</code> parameter of <a href="/constructor/inputReplyToMessage">inputReplyToMessage</a>, passed to <code>reply_to</code> when invoking <a href="/method/messages.sendMessage">messages.sendMessage</a>, <a href="/method/messages.sendMedia">messages.sendMedia</a> et cetera.  </p>
-<p>To reply to messages within a topic, pass the ID of the message to reply to to <a href="/constructor/inputReplyToMessage">inputReplyToMessage</a>.<code>reply_to_msg_id</code>, and, unless we're replying to a message in the "General" topic, pass the topic ID to <a href="/constructor/inputReplyToMessage">inputReplyToMessage</a>.<code>top_msg_id</code>.<br>
+<p>To reply to messages within a topic, pass the ID of the message to reply to <a href="/constructor/inputReplyToMessage">inputReplyToMessage</a>.<code>reply_to_msg_id</code>, and, unless we're replying to a message in the "General" topic, pass the topic ID to <a href="/constructor/inputReplyToMessage">inputReplyToMessage</a>.<code>top_msg_id</code>.<br>
 Note that when replying to messages in a topic, the <a href="/constructor/inputReplyToMessage">inputReplyToMessage</a>.<code>top_msg_id</code> field must contain the topic ID <strong>if and only if</strong> we're replying to messages in <a href="/api/forum#forum-topics">forum topics</a> different from the "General" topic (i.e. <code>reply_to_msg_id</code> is set and <code>reply_to_msg_id != topicID</code> and <code>topicID != 1</code>): this way, if the replied-to message is deleted before the method finishes execution, the value in this field will be used to send the message to the correct topic, instead of the "General" topic.<br>
 Also note that since <a href="/api/threads">message threads</a> can't have nested message threads, topics (except for the "General" topic) also can't have message threads (so replies to messages within topics won't generate further message threads).  </p>
 <p>Topics have a name (<code>title</code>) and an icon: the icon can be a <a href="/api/custom-emoji">custom emoji</a> specified by the <code>icon_emoji_id</code>, or a default chat icon if <code>icon_emoji_id</code> is not set, filled with the color specified in <code>icon_color</code>.<br>

data/web/corefork.telegram.org/api/peers.html

@@ -119,7 +119,7 @@ Info about these IDs may be fetched with the zero access hash even by users.  </
 <li><a href="/method/account.toggleUsername">account.toggleUsername</a>, <a href="/method/account.reorderUsernames">account.reorderUsernames</a> - For ourselves</li>
 <li><a href="/method/bots.toggleUsername">bots.toggleUsername</a>, <a href="/method/bots.reorderUsernames">bots.reorderUsernames</a> - For the bot whose username we updated</li>
 </ul>
-<p>Info should <strong>only</strong> be manually refreshed with a call to <a href="/method/users.getUsers">users.getUsers</a> if the new username order/active username cannot be applied locally (i.e. the methods successfully set as active some username that isn't associated to the user in our local cache, and so on), otherwise the <code>username</code> and <code>usernames</code> fields of the peer info database should be updated locally, using the info that was passed to to the toggle/reorder methods by the user.  </p>
+<p>Info should <strong>only</strong> be manually refreshed with a call to <a href="/method/users.getUsers">users.getUsers</a> if the new username order/active username cannot be applied locally (i.e. the method call successfully set as active some username that isn't associated to the user in our local cache, and so on), otherwise the <code>username</code> and <code>usernames</code> fields of the peer info database should be updated locally, using the info that was passed to the toggle/reorder methods by the user.  </p>
 </li>
 </ul>
 <p>Do not refresh peer information in any other case, to avoid overloading the server by continuously requesting changes for the same unchanged information.  </p>

data/web/corefork.telegram.org/constructor/phoneCall.html

@@ -124,7 +124,7 @@
 <tr>
 <td><strong>connections</strong></td>
 <td style="text-align: center;"><a href="/type/Vector%20t">Vector</a>&lt;<a href="/type/PhoneConnection">PhoneConnection</a>&gt;</td>
-<td>List of endpoints the user can connect to to exchange call data</td>
+<td>List of endpoints the user can connect to exchange call data</td>
 </tr>
 <tr>
 <td><strong>start_date</strong></td>