mirror of
https://github.com/angular/angular.git
synced 2026-09-14 13:54:52 +08:00
docs: fix typos and grammar errors across documentation
Fix various typos, misspellings, and grammar issues across contributing docs, adev content guides, and agent skills documentation. - "an minimum" → "a minimum" (CONTRIBUTING.md) - "GitHub accounts" → "GitHub account" (CONTRIBUTING.md) - "decendants" → "descendants" (components/styling.md) - "templates are using" → "templates is using" (hydration.md) - "A automated" → "An automated" (branches-and-versioning.md) - "Github" → "GitHub" (branches-and-versioning.md, commit-message-guidelines.md) - "practices makes" → "practice makes" (caretaking.md) - "corresponds" → "correspond" (triage-and-labelling.md) - "one a line" → "a line" (documentation-authoring.md) - "straight forward" → "straightforward" (using-fixup-commits.md) - "or you decide" → "or you can decide" (anatomy-of-components.md) - "whenver" → "whenever" (angular-new-app/SKILL.md)
This commit is contained in:
+2
-2
@@ -71,7 +71,7 @@ You can file new issues by selecting from our [new issue templates](https://gith
|
||||
|
||||
### <a name="pr-quality"></a> Contribution Quality
|
||||
|
||||
We strongly value open source contribution and pull requests from community contributors. Please note that every pull request is reviewed and merged by an actual person on the team, which does take time and effort. That is time and effort that does take away from other valuable work. With that in mind we have an minimum set of expectations that are required of any community contribution pull request that is opened.
|
||||
We strongly value open source contribution and pull requests from community contributors. Please note that every pull request is reviewed and merged by an actual person on the team, which does take time and effort. That is time and effort that does take away from other valuable work. With that in mind we have a minimum set of expectations that are required of any community contribution pull request that is opened.
|
||||
|
||||
1. Search [GitHub](https://github.com/angular/angular/pulls) for an open or closed PR that relates to your submission.
|
||||
- You don't want to duplicate existing efforts.
|
||||
@@ -238,7 +238,7 @@ changes to be accepted, the CLA must be signed. It's a quick process, we promise
|
||||
- For corporations, we'll need you to
|
||||
[print, sign and one of scan+email, fax or mail the form][corporate-cla].
|
||||
|
||||
If you have more than one GitHub accounts, or multiple email addresses associated with a single GitHub account, you must sign the CLA using the primary email address of the GitHub account used to author Git commits and send pull requests.
|
||||
If you have more than one GitHub account, or multiple email addresses associated with a single GitHub account, you must sign the CLA using the primary email address of the GitHub account used to author Git commits and send pull requests.
|
||||
|
||||
The following documents can help you sort out issues with GitHub accounts and multiple email addresses:
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ You can alternatively choose to write your template and styles in separate files
|
||||
export class ProfilePhoto {}
|
||||
```
|
||||
|
||||
This can help separate the concerns of _presentation_ from _behavior_ in your project. You can choose one approach for your entire project, or you decide which to use for each component.
|
||||
This can help separate the concerns of _presentation_ from _behavior_ in your project. You can choose one approach for your entire project, or you can decide which to use for each component.
|
||||
|
||||
Both `templateUrl` and `styleUrl` are relative to the directory in which the component resides.
|
||||
|
||||
|
||||
@@ -94,7 +94,7 @@ For example:
|
||||
|
||||
So, in effect, the `<a>` element may be in the component's template, or in any of its projected or child content.
|
||||
|
||||
- With `:host ::ng-deep p a`, both the `<a>` and `<p>` elements must be decendants of the component's host element.
|
||||
- With `:host ::ng-deep p a`, both the `<a>` and `<p>` elements must be descendants of the component's host element.
|
||||
|
||||
They can come from the component's template or the views of its child components, but not elsewhere in the app.
|
||||
|
||||
|
||||
@@ -142,7 +142,7 @@ Providing a custom or a "noop" Zone.js implementation may lead to a different ti
|
||||
|
||||
## Errors
|
||||
|
||||
There are several hydration related errors you may encounter ranging from node mismatches to cases when the `ngSkipHydration` was used on an invalid host node. The most common error case that may occur is due to direct DOM manipulation using native APIs that results in hydration being unable to find or match the expected DOM tree structure on the client that was rendered by the server. The other case you may encounter this type of error was mentioned in the [Valid HTML structure](#valid-html-structure) section earlier. So, make sure the HTML in your templates are using valid structure, and you'll avoid that error case.
|
||||
There are several hydration related errors you may encounter ranging from node mismatches to cases when the `ngSkipHydration` was used on an invalid host node. The most common error case that may occur is due to direct DOM manipulation using native APIs that results in hydration being unable to find or match the expected DOM tree structure on the client that was rendered by the server. The other case you may encounter this type of error was mentioned in the [Valid HTML structure](#valid-html-structure) section earlier. So, make sure the HTML in your templates is using valid structure, and you'll avoid that error case.
|
||||
|
||||
For a full reference on hydration related errors, visit the [Errors Reference Guide](/errors).
|
||||
|
||||
|
||||
@@ -102,14 +102,14 @@ major version.
|
||||
|
||||
Two additional target labels do not map to specific versions while still defining which branch to merge into.
|
||||
|
||||
| Label | Description |
|
||||
| ------------------ | ----------------------------------------------------- |
|
||||
| target: automation | A automated change made by the angular-robot account. |
|
||||
| target: feature | A change to be made in a feature branch. |
|
||||
| Label | Description |
|
||||
| ------------------ | ------------------------------------------------------ |
|
||||
| target: automation | An automated change made by the angular-robot account. |
|
||||
| target: feature | A change to be made in a feature branch. |
|
||||
|
||||
Changes made to a feature branch, outside of our typical branching and merging process utilize the
|
||||
`target: feature` branch. Additionally, the `target: automation` label, which is only able to be
|
||||
utilized by the `angular-robot` account targets only the branch defined within the Github UI.
|
||||
utilized by the `angular-robot` account targets only the branch defined within the GitHub UI.
|
||||
|
||||
### Pull request examples
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ pnpm ng-dev pr merge <pr number>
|
||||
Some directories in the Angular codebase have additional protections or rules. For example, code
|
||||
under `//packages/core/primitives` must be merged and synced into Google separately from other
|
||||
changes. Attempting to combine changes in `primitives` with other changes results in an error. This
|
||||
practices makes it significantly easier to rollback or revert changes in the event of a breakage or
|
||||
practice makes it significantly easier to rollback or revert changes in the event of a breakage or
|
||||
outage.
|
||||
|
||||
## PRs that require global presubmits
|
||||
|
||||
@@ -45,7 +45,7 @@ Must be one of the following:
|
||||
| Type | Description |
|
||||
| ------------ | --------------------------------------------------------------------------------------------------- |
|
||||
| **build** | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
|
||||
| **ci** | Changes to our CI configuration files and scripts (examples: Github Actions, SauceLabs) |
|
||||
| **ci** | Changes to our CI configuration files and scripts (examples: GitHub Actions, SauceLabs) |
|
||||
| **docs** | Documentation only changes |
|
||||
| **feat** | A new feature |
|
||||
| **fix** | A bug fix |
|
||||
|
||||
@@ -94,7 +94,7 @@ because they are _very_ common.
|
||||
- Use callouts for a brief aside that offers more context on a topic that's not strictly
|
||||
necessary to understanding the main content
|
||||
- Never put multiple callouts next to each other or in proximity (such as separated
|
||||
by one a line or two of text)
|
||||
by a line or two of text)
|
||||
- Never put a callout inside another element, such as a card or table cell
|
||||
- **Alerts**
|
||||
- Use sparingly to call attention to a very brief but relevant point
|
||||
|
||||
@@ -9,7 +9,7 @@ The owner of the component is then responsible for the detailed / component-leve
|
||||
### Areas
|
||||
|
||||
The caretaker should be able to determine the _area_ for incoming issues.
|
||||
Most areas generally corresponds to a specific directory or set of directories in this repo. Some
|
||||
Most areas generally correspond to a specific directory or set of directories in this repo. Some
|
||||
areas are more cross-cutting (e.g. for performance or security). Apply all labels that make sense
|
||||
for an issue. Each `area: ` label on GitHub should have a description of what it's for.
|
||||
|
||||
|
||||
@@ -51,7 +51,7 @@ However, amending an existing commit with the changes makes it difficult for the
|
||||
exactly what has changed since the last time they reviewed the Pull Request.
|
||||
|
||||
Here is where fixup commits come in handy.
|
||||
By addressing review feedback in fixup commits, you make it very straight forward for the reviewer
|
||||
By addressing review feedback in fixup commits, you make it very straightforward for the reviewer
|
||||
to see what are the new changes that need to be reviewed and verify that their earlier feedback has
|
||||
been addressed.
|
||||
This can save a lot of effort, especially on larger Pull Requests (where having to re-review _all_
|
||||
|
||||
Reference in New Issue
Block a user