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:
Kam
2026-03-28 19:01:41 +03:00
committed by Andrew Scott
parent b16a8a32d8
commit 4739bde9fb
10 changed files with 15 additions and 15 deletions
+2 -2
View File
@@ -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.
+1 -1
View File
@@ -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.
+1 -1
View File
@@ -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).
+5 -5
View File
@@ -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
+1 -1
View File
@@ -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 |
+1 -1
View File
@@ -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
+1 -1
View File
@@ -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.
+1 -1
View File
@@ -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_