📖 Fixed client-side and server-side grammar in all files

docs/guide/caching-http.md

@@ -5,7 +5,7 @@ Besides server-side caching that we have described in the previous sections, Web
 also exploit client-side caching to save the time for generating and transmitting the same page content.
 
 To use client-side caching, you may configure [[yii\filters\HttpCache]] as a filter for controller
-actions whose rendering result may be cached on the client side. [[yii\filters\HttpCache|HttpCache]]
+actions whose rendering result may be cached on the client-side. [[yii\filters\HttpCache|HttpCache]]
 only works for `GET` and `HEAD` requests. It can handle three kinds of cache-related HTTP headers for these requests:
 
 * [[yii\filters\HttpCache::lastModified|Last-Modified]]
@@ -52,14 +52,14 @@ The above code states that HTTP caching should be enabled for the `index` action
 generate a `Last-Modified` HTTP header based on the last update time of posts. When a browser visits
 the `index` page for the first time, the page will be generated on the server and sent to the browser;
 If the browser visits the same page again and there is no post being modified during the period,
-the server will not re-generate the page, and the browser will use the cached version on the client side.
+the server will not re-generate the page, and the browser will use the cached version on the client-side.
 As a result, server-side rendering and page content transmission are both skipped.
 
 
 ## `ETag` Header <span id="etag"></span>
 
 The "Entity Tag" (or `ETag` for short) header use a hash to represent the content of a page. If the page
-is changed, the hash will be changed as well. By comparing the hash kept on the client side with the hash
+is changed, the hash will be changed as well. By comparing the hash kept on the client-side with the hash
 generated on the server-side, the cache may determine whether the page has been changed and should be re-transmitted.
 
 You may configure the [[yii\filters\HttpCache::etagSeed]] property to enable sending the `ETag` header.
@@ -97,7 +97,7 @@ The above code states that HTTP caching should be enabled for the `view` action
 generate an `ETag` HTTP header based on the title and content of the requested post. When a browser visits
 the `view` page for the first time, the page will be generated on the server and sent to the browser;
 If the browser visits the same page again and there is no change to the title and content of the post,
-the server will not re-generate the page, and the browser will use the cached version on the client side.
+the server will not re-generate the page, and the browser will use the cached version on the client-side.
 As a result, server-side rendering and page content transmission are both skipped.
 
 ETags allow more complex and/or more precise caching strategies than `Last-Modified` headers.

docs/guide/caching-overview.md

@@ -8,7 +8,7 @@ required to generate the data from scratch every time.
 Caching can occur at different levels and places in a Web application. On the server-side, at the lower level,
 cache may be used to store basic data, such as a list of most recent article information fetched from database;
 and at the higher level, cache may be used to store fragments or whole of Web pages, such as the rendering result
-of the most recent articles. On the client side, HTTP caching may be used to keep most recently visited page content in
+of the most recent articles. On the client-side, HTTP caching may be used to keep most recently visited page content in
 the browser cache.
 
 Yii supports all these caching mechanisms:

docs/guide/caching-page.md

@@ -1,7 +1,7 @@
 Page Caching
 ============
 
-Page caching refers to caching the content of a whole page on the server side. Later when the same page
+Page caching refers to caching the content of a whole page on the server-side. Later when the same page
 is requested again, its content will be served from the cache instead of regenerating it from scratch.
 
 Page caching is supported by [[yii\filters\PageCache]], an [action filter](structure-filters.md).

docs/guide/runtime-responses.md

@@ -189,7 +189,7 @@ a chained call to the [[yii\web\Response::send()]] method to ensure no extra con
 
 When the current request is an AJAX request, sending a `Location` header will not automatically cause the browser
 to redirect. To solve this problem, the [[yii\web\Response::redirect()]] method sets an `X-Redirect` header with 
-the redirection URL as its value. On the client side, you may write JavaScript code to read this header value and
+the redirection URL as its value. On the client-side, you may write JavaScript code to read this header value and
 redirect the browser accordingly.
 
 > Info: Yii comes with a `yii.js` JavaScript file which provides a set of commonly used JavaScript utilities,

docs/guide/runtime-sessions-cookies.md

@@ -303,7 +303,7 @@ information, such as [[yii\web\Cookie::domain|domain]], [[yii\web\Cookie::expire
 properties as needed to prepare a cookie and then add it to the response's cookie collection.
 
 > Note: For better security, the default value of [[yii\web\Cookie::httpOnly]] is set to true. This helps mitigate
-the risk of a client side script accessing the protected cookie (if the browser supports it). You may read
+the risk of a client-side script accessing the protected cookie (if the browser supports it). You may read
 the [httpOnly wiki article](https://www.owasp.org/index.php/HttpOnly) for more details.
 
 
@@ -311,8 +311,8 @@ the [httpOnly wiki article](https://www.owasp.org/index.php/HttpOnly) for more d
 
 When you are reading and sending cookies through the `request` and `response` components as shown in the last
 two subsections, you enjoy the added security of cookie validation which protects cookies from being modified
-on the client side. This is achieved by signing each cookie with a hash string, which allows the application to
-tell if a cookie has been modified on the client side. If so, the cookie will NOT be accessible through the
+on the client-side. This is achieved by signing each cookie with a hash string, which allows the application to
+tell if a cookie has been modified on the client-side. If so, the cookie will NOT be accessible through the
 [[yii\web\Request::cookies|cookie collection]] of the `request` component.
 
 > Note: Cookie validation only protects cookie values from being modified. If a cookie fails the validation, 

docs/guide/start-forms.md

@@ -208,10 +208,10 @@ You may wonder how the HTML form works behind the scene, because it seems almost
 display a label for each input field and show error messages if you do not enter the data correctly
 without reloading the page.
 
-Yes, the data validation is initially done on the client side using JavaScript, and secondarily performed on the server side via PHP.
+Yes, the data validation is initially done on the client-side using JavaScript, and secondarily performed on the server-side via PHP.
 [[yii\widgets\ActiveForm]] is smart enough to extract the validation rules that you have declared in `EntryForm`,
 turn them into executable JavaScript code, and use the JavaScript to perform data validation. In case you have disabled
-JavaScript on your browser, the validation will still be performed on the server side, as shown in
+JavaScript on your browser, the validation will still be performed on the server-side, as shown in
 the `actionEntry()` method. This ensures data validity in all circumstances.
 
 > Warning: Client-side validation is a convenience that provides for a better user experience. Server-side validation

docs/guide/tutorial-core-validators.md

@@ -111,7 +111,7 @@ you can use a combination of compare and date validator like the following:
 As validators are executed in the order they are specified this will first validate that the values entered in
 `fromDate` and `toDate` are valid date values and if so, they will be converted into a machine readable format.
 Afterwards these two values are compared with the compare validator.
-Client validation is not enabled as this will only work on the server side because the date validator currently does not
+Client validation is not enabled as this will only work on the server-side because the date validator currently does not
 provide client validation, so [[yii\validators\CompareValidator::$enableClientValidation|$enableClientValidation]]
 is set to `false` on the compare validator too.
 

framework/captcha/CaptchaAction.php

@@ -142,7 +142,7 @@ class CaptchaAction extends Action
     }
 
     /**
-     * Generates a hash code that can be used for client side validation.
+     * Generates a hash code that can be used for client-side validation.
      * @param string $code the CAPTCHA code
      * @return string a hash code generated from the CAPTCHA code
      */

framework/validators/FileValidator.php

@@ -383,10 +383,10 @@ class FileValidator extends Validator
     }
 
     /**
-     * Returns the client side validation options.
+     * Returns the client-side validation options.
      * @param \yii\base\Model $model the model being validated
      * @param string $attribute the attribute name being validated
-     * @return array the client side validation options
+     * @return array the client-side validation options
      */
     protected function getClientOptions($model, $attribute)
     {

framework/validators/Validator.php

@@ -141,8 +141,8 @@ class Validator extends Component
      * The signature of the callable should be `function ($model, $attribute)`, where `$model` and `$attribute`
      * refer to the model and the attribute currently being validated. The callable should return a boolean value.
      *
-     * This property is mainly provided to support conditional validation on the server side.
-     * If this property is not set, this validator will be always applied on the server side.
+     * This property is mainly provided to support conditional validation on the server-side.
+     * If this property is not set, this validator will be always applied on the server-side.
      *
      * The following example will enable the validator only when the country currently selected is USA:
      *
@@ -157,12 +157,12 @@ class Validator extends Component
     public $when;
     /**
      * @var string a JavaScript function name whose return value determines whether this validator should be applied
-     * on the client side. The signature of the function should be `function (attribute, value)`, where
+     * on the client-side. The signature of the function should be `function (attribute, value)`, where
      * `attribute` is an object describing the attribute being validated (see [[clientValidateAttribute()]])
      * and `value` the current value of the attribute.
      *
-     * This property is mainly provided to support conditional validation on the client side.
-     * If this property is not set, this validator will be always applied on the client side.
+     * This property is mainly provided to support conditional validation on the client-side.
+     * If this property is not set, this validator will be always applied on the client-side.
      *
      * The following example will enable the validator only when the country currently selected is USA:
      *

framework/web/UploadedFile.php

@@ -40,7 +40,7 @@ class UploadedFile extends Object
     public $tempName;
     /**
      * @var string the MIME-type of the uploaded file (such as "image/gif").
-     * Since this MIME type is not checked on the server side, do not take this value for granted.
+     * Since this MIME type is not checked on the server-side, do not take this value for granted.
      * Instead, use [[\yii\helpers\FileHelper::getMimeType()]] to determine the exact MIME type.
      */
     public $type;