From ce2e57bd0086620bb8ab4226d1d0fcd8f0e3ed09 Mon Sep 17 00:00:00 2001 From: GitHub Action Date: Wed, 2 Mar 2022 20:24:51 +0000 Subject: [PATCH] Update content of files --- data/corefork.telegram.org/api/auth.html | 6 +++--- data/corefork.telegram.org/api/datacenter.html | 4 ++-- data/corefork.telegram.org/api/payments.html | 4 ++-- data/corefork.telegram.org/bots.html | 4 ++-- data/corefork.telegram.org/bots/inline.html | 6 +++--- .../constructor/upload.cdnFileReuploadNeeded | 6 +++--- .../method/messages.setInlineBotResults | 2 +- data/corefork.telegram.org/methods.html | 6 +++--- data/corefork.telegram.org/mtproto/TL-dependent.html | 6 +++--- data/corefork.telegram.org/mtproto/TL-formal.html | 2 +- data/corefork.telegram.org/mtproto/TL-optargs.html | 2 +- data/corefork.telegram.org/type/Bool.html | 2 +- data/corefork.telegram.org/type/upload.CdnFile | 2 +- 13 files changed, 26 insertions(+), 26 deletions(-) diff --git a/data/corefork.telegram.org/api/auth.html b/data/corefork.telegram.org/api/auth.html index 109c9c6aab..554a87f7a5 100644 --- a/data/corefork.telegram.org/api/auth.html +++ b/data/corefork.telegram.org/api/auth.html @@ -41,13 +41,13 @@
-

Authorization is associated with a client’s encryption key identifier: auth_key_id. No additional parameters need to be passed into methods following authorization.

+

Authorization is associated with a client's encryption key identifier: auth_key_id. No additional parameters need to be passed into methods following authorization.

To log in as a bot, follow these instructions ».

Sending a verification code

Example implementations: telegram for android, tdlib.

To show a nicely formatted and validated phone number field, the help.countriesList constructor can be obtained using the help.getCountriesList method.
The help.countriesList config is then used as described here ».

-

Authorization requires that a text message containing an authorization code first be sent to the user’s phone.
+

Authorization requires that a text message containing an authorization code first be sent to the user's phone.
This may be done using the auth.sendCode method. The system will automatically choose how to send the authorization code; there are four possible ways the code can arrive:

Beyond sending commands in private messages or groups, users can interact with your bot via inline queries. If inline queries are enabled, users can call your bot by typing its username and a query in the text input field in any chat. The query is sent to your bot in an update. This way, people can request content from your bot in any of their chats, groups, or channels without sending any messages at all.

-
+
-

To enable this option, send the /setinline command to @BotFather and provide the placeholder text that the user will see in the input field after typing your bot’s name.

+

To enable this option, send the /setinline command to @BotFather and provide the placeholder text that the user will see in the input field after typing your bot's name.

See the Bot API Manual for the relevant methods and objects.

@@ -90,7 +90,7 @@

To know which of the provided results your users are sending to their chat partners, send @Botfather the /setinlinefeedback command. With this enabled, you will receive updates on the results chosen by your users.

Please note that this can create load issues for popular bots – you may receive more results than actual requests due to caching (see the cache_time parameter in answerInlineQuery). For these cases, we recommend adjusting the probability setting to receive 1/10, 1/100 or 1/1000 of the results.

Inline bot samples

-

Here are some sample inline bots, in case you’re curious to see one in action. Try any of these: +

Here are some sample inline bots, in case you're curious to see one in action. Try any of these: @gif – GIF search @vid – Video search @pic – Yandex image search diff --git a/data/corefork.telegram.org/constructor/upload.cdnFileReuploadNeeded b/data/corefork.telegram.org/constructor/upload.cdnFileReuploadNeeded index db9ee2506e..74c2f2af2f 100644 --- a/data/corefork.telegram.org/constructor/upload.cdnFileReuploadNeeded +++ b/data/corefork.telegram.org/constructor/upload.cdnFileReuploadNeeded @@ -4,10 +4,10 @@ upload.cdnFileReuploadNeeded - + - + @@ -39,7 +39,7 @@

upload.cdnFileReuploadNeeded

-

The file was cleared from the temporary RAM cache of the CDN and has to be reuploaded.

+

The file was cleared from the temporary RAM cache of the CDN and has to be re-uploaded.

  • diff --git a/data/corefork.telegram.org/method/messages.setInlineBotResults b/data/corefork.telegram.org/method/messages.setInlineBotResults index 707b6ccae3..fa5dfe162c 100644 --- a/data/corefork.telegram.org/method/messages.setInlineBotResults +++ b/data/corefork.telegram.org/method/messages.setInlineBotResults @@ -99,7 +99,7 @@ next_offset flags.2?string -Pass the offset that a client should send in the next query with the same text to receive more results. Pass an empty string if there are no more results or if you don‘t support pagination. Offset length can’t exceed 64 bytes. +Pass the offset that a client should send in the next query with the same text to receive more results. Pass an empty string if there are no more results or if you don‘t support pagination. Offset length can't exceed 64 bytes. switch_pm diff --git a/data/corefork.telegram.org/methods.html b/data/corefork.telegram.org/methods.html index 2cbea10334..78a149d86a 100644 --- a/data/corefork.telegram.org/methods.html +++ b/data/corefork.telegram.org/methods.html @@ -186,11 +186,11 @@ invokeAfterMsg -Invokes a query after successfull completion of one of the previous queries. +Invokes a query after successful completion of one of the previous queries. invokeAfterMsgs -Invokes a query after a successfull completion of previous queries +Invokes a query after a successful completion of previous queries invokeWithLayer @@ -834,7 +834,7 @@ upload.saveFilePart -Saves a part of file for futher sending to one of the methods. +Saves a part of file for further sending to one of the methods. messages.uploadEncryptedFile diff --git a/data/corefork.telegram.org/mtproto/TL-dependent.html b/data/corefork.telegram.org/mtproto/TL-dependent.html index d81e3ac97b..925cf5475a 100644 --- a/data/corefork.telegram.org/mtproto/TL-dependent.html +++ b/data/corefork.telegram.org/mtproto/TL-dependent.html @@ -42,7 +42,7 @@ In certain cases, types may depend not only on other types (polymorphism), but a

    TL-dependent

    Main article: TL Language.

    -

    In certain cases, types may depend not only on other types (polymorphism), but also on the parameters of another type (dependent types). The TL language provides very limited support for this functionality: dependence is only allowed on a natural parameter whose type is designated using # (alias nat, but this is private -- TL doesn’t currently support this synonym). Values of type # are serialized as 32-bit signed numbers from 0 to 2^31-1.

    +

    In certain cases, types may depend not only on other types (polymorphism), but also on the parameters of another type (dependent types). The TL language provides very limited support for this functionality: dependence is only allowed on a natural parameter whose type is designated using # (alias nat, but this is private -- TL doesn't currently support this synonym). Values of type # are serialized as 32-bit signed numbers from 0 to 2^31-1.

    Example: integer tuples (vectors)

    Suppose we want to use induction to define the types “one integer”, “two integers”, and “three integers”. We could try to define them as follows:

    empty = Empty;
@@ -133,7 +133,7 @@ Vector : Type -> Type;

    Moreover, we can define arbitrarily-sized matrices:

    matrix {X:Type} m:# n:# a:(%Tuple (%Tuple X m) n) = Matrix X;

    In this case using vector would result in storing the length of a row (m) in each row, e.g. n times.

    -

    Note that the serializations of values of type %Tuple X n and vector X (also known as %vector X and %Vector X) nearly match when n > 0: in both cases we obtain a single 32-bit number (equal to n-1 or n depending on the version) followed by the serializations of n objects of type X. (This is slightly untrue: values of type %Tuple X n can only be serialized if n is a constant or value known from one of the preceding fields of the enclosing entry; but then this n won’t be serialized explicitly anywhere).

    +

    Note that the serializations of values of type %Tuple X n and vector X (also known as %vector X and %Vector X) nearly match when n > 0: in both cases we obtain a single 32-bit number (equal to n-1 or n depending on the version) followed by the serializations of n objects of type X. (This is slightly untrue: values of type %Tuple X n can only be serialized if n is a constant or value known from one of the preceding fields of the enclosing entry; but then this n won't be serialized explicitly anywhere).

    Special syntax for repetitions

    In view of the importance of the construction presented above, it is built into the TL language in the following manner. A substructure in the form of [ array-field-name ":" ] [ nat-ident "" ] "[" field-descr ... "]” may be used in the declaration of any combinator, where nat-ident* is the name of any previously encountered field of type # (if it is not explicitly indicated, the most recent is used). In abstract, this substructure is equivalent to:

    aux_type *field-descr* ... = AuxType;
@@ -159,7 +159,7 @@ vector {X:Type} # [ X ] = Vector X;

For example, in cons {X:Type} hd:X tl:(list X) = list X the parameter X may be made optional, because it is located at the very beginning of the argument list and is unambiguously determined by the list X result type. Similarly, in tcons {X:Type} {n:#} hd:X tl:(%Tuple X n) = Tuple X (S n) the values of X and n are completely determined based on the Tuple X (S n) result type, therefore they made be made optional parameters.

-

It usually makes sense to move all of a constructor’s arguments satisfying the second condition to the beginning of the list, arrange them in the order they appear in the result type’s parameters, and make them optional. Given such an approach, the full version of a constructor is rarely needed -- only when we want to transmit the value of the polymorphic or dependent type as a value of type Object. In all other cases, the type of the expected value from the context is already known, which means that all optional parameters can be recovered during decomposition.

+

It usually makes sense to move all of a constructor's arguments satisfying the second condition to the beginning of the list, arrange them in the order they appear in the result type's parameters, and make them optional. Given such an approach, the full version of a constructor is rarely needed -- only when we want to transmit the value of the polymorphic or dependent type as a value of type Object. In all other cases, the type of the expected value from the context is already known, which means that all optional parameters can be recovered during decomposition.

See also Optional combinator parameters and their values.

diff --git a/data/corefork.telegram.org/mtproto/TL-formal.html b/data/corefork.telegram.org/mtproto/TL-formal.html index 52f8a42e66..4891df0d35 100644 --- a/data/corefork.telegram.org/mtproto/TL-formal.html +++ b/data/corefork.telegram.org/mtproto/TL-formal.html @@ -230,7 +230,7 @@ user_present {flags:#} info:%(User flags) = UserInfo flags;
user_absent {flags:#} = UserInfo flags;
getUser flags:# id:int = !UserInfo flags;

-

In the future, bits 3 and 4 in the flags field may be used to transmit new fields after changing the names and types of the reserved3 and reserved4 fields. This will change the user constructor’s number, but this isn’t too important, since the User flags type is only used as a bare type. Transmitting bits 3 or 4 in the flags field in a getUser query before these fields have actually been defined will lead to an error in the (de)serialization of the request.

+

In the future, bits 3 and 4 in the flags field may be used to transmit new fields after changing the names and types of the reserved3 and reserved4 fields. This will change the user constructor's number, but this isn't too important, since the User flags type is only used as a bare type. Transmitting bits 3 or 4 in the flags field in a getUser query before these fields have actually been defined will lead to an error in the (de)serialization of the request.

  • The type True with a single null constructor true plays a role similar to the void type in C/C++. It is especially useful as a bare type %True, alias true, because its serialization has zero length. For example, the first_name:flags.1?string constructor used above is in fact shorthand for (the as-yet unsupported) alternative-type general constructor first_name:(flags.1?string:true).
diff --git a/data/corefork.telegram.org/mtproto/TL-optargs.html b/data/corefork.telegram.org/mtproto/TL-optargs.html index 171b87fb63..b4f5ff0053 100644 --- a/data/corefork.telegram.org/mtproto/TL-optargs.html +++ b/data/corefork.telegram.org/mtproto/TL-optargs.html @@ -44,7 +44,7 @@

A (sub)expression may be serialized/deserialized in one of two ways:

  • -

    The result type is known (for example, we’re parsing the response to a previously sent RPC query and therefore know the value of some type is expected). In this case, the result type may be used to determine the values of the combinator's implicit parameters.

    +

    The result type is known (for example, we're parsing the response to a previously sent RPC query and therefore know the value of some type is expected). In this case, the result type may be used to determine the values of the combinator's implicit parameters.

  • The result type is not known. It is determined as a result of (de)serialization (for example, we are serializing an RPC query). In this case, it is necessary to explicitly specify (and serialize) all of the combinator's optional parameters by using the full version of the combinator.

    diff --git a/data/corefork.telegram.org/type/Bool.html b/data/corefork.telegram.org/type/Bool.html index 819298d3c9..f0ab8d2864 100644 --- a/data/corefork.telegram.org/type/Bool.html +++ b/data/corefork.telegram.org/type/Bool.html @@ -266,7 +266,7 @@ upload.saveFilePart -Saves a part of file for futher sending to one of the methods. +Saves a part of file for further sending to one of the methods. messages.discardEncryption diff --git a/data/corefork.telegram.org/type/upload.CdnFile b/data/corefork.telegram.org/type/upload.CdnFile index 275cd01f66..f59c6b43f4 100644 --- a/data/corefork.telegram.org/type/upload.CdnFile +++ b/data/corefork.telegram.org/type/upload.CdnFile @@ -69,7 +69,7 @@ upload.cdnFileReuploadNeeded -The file was cleared from the temporary RAM cache of the CDN and has to be reuploaded. +The file was cleared from the temporary RAM cache of the CDN and has to be re-uploaded. upload.cdnFile