Update CURLOPT constant descriptions #3818
Conversation
| @@ -127,10 +130,10 @@ | |||
| </term> | |||
| <listitem> | |||
| <para> | |||
| Provides AWS V4 signature authentication on HTTP(S) header. | |||
| Provides AWS V4 signature authentication on HTTP(S) header as a <type>string</type>. | |||
There was a problem hiding this comment.
Could also use &string;, but <type>string</type> might be preferred nowadays.
There was a problem hiding this comment.
The only reason I didn't use the entities is that there are only a few hundred uses of them in doc-en but thousands of uses of the <type> tags.
There was a problem hiding this comment.
If I remember correctly, we deliberately decided to not use the entities in the function signatures (where <type>string</type> is supposed to occur often).
Maybe @Girgias knows whether it's preferable to use type elements or the respective entities elsewhere.
There was a problem hiding this comment.
It is better to use the <type> element, as some translations translate the entity (don't ask me why doc-fr does it, but it does).
There was a problem hiding this comment.
With the same reasoning, they can translate the element as well. And soon we're back to
beschneide(zeichenkette $zeichenkette, zeichenkette $zeichen = " \n\r\t\v\x00"): zeichenkette
There was a problem hiding this comment.
I'm pretty sure some of the QA scripts that can be used for translation check this. Usually the entity is better used when we want to talk about the "concept" of a string (or other type) rather then directly referring to it as a PHP type.
But the distinction is not useful most of the time. So maybe we should just fix translations that do that.
|
I think I have addressed all review comments such as:
|
Updated descriptions of
CURLOPT_*constants with the following:CURLALTSVC_*instead of listing allCURLALTSVC_constants individually)<literal>tags, etc.)Unfortunately since
CURLOPTconstants are the biggest subset of all cURL constants, the diff is pretty big.