privacyguides/i18n
1
0
Fork 0
mirror of https://github.com/privacyguides/i18n.git synced 2025-06-18 16:54:21 +00:00
Code Activity

New Crowdin translations by GitHub Action

Browse Source
This commit is contained in:
Crowdin Bot
2024-07-15 14:32:22 +00:00
parent b643336997
commit dc40b8699e
29 changed files with 1247 additions and 609 deletions
Download Patch File Download Diff File Expand all files Collapse all files

64
i18n/ar/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/bn-IN/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/bn/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/cs/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/de/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/el/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/eo/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/es/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/fa/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/fr/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Messages de commit
Pour nos messages de commit, nous suivons le style fourni par [Conventional Commits](https://conventionalcommits.org). Toutes ces suggestions ne sont pas appropriées pour Privacy Guides, c'est pourquoi les principales que nous utilisons sont les suivantes : Pour nos messages de commit, nous suivons le style fourni par [Conventional Commits](https://conventionalcommits.org). Toutes ces suggestions ne sont pas appropriées pour Privacy Guides, c'est pourquoi les principales que nous utilisons sont les suivantes :
## Update to existing text
Cet exemple peut être utilisé pour un article déjà présent sur le site, mais dont la description a été légèrement modifiée.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Message de commit avec correction ## Message de commit avec correction
Nous utilisons `fix` pour des choses simples comme les fautes d'orthographe ou les bugs liés au site. Ces choses ont généralement le label `correction` ou `bug` sur GitHub. Nous utilisons `fix` pour des choses simples comme les fautes d'orthographe ou les bugs liés au site. Ces choses ont généralement le label `correction` ou `bug` sur GitHub.
@ -12,24 +32,6 @@ Nous utilisons `fix` pour des choses simples comme les fautes d'orthographe ou l
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Mise à jour du site
Cet exemple concerne la suppression d'un élément (mais il pourrait également être utilisé pour un ajout) ; vous pouvez expliquer pourquoi il a été supprimé dans le paragraphe d'engagement ci-dessous. Il peut également être utilisé pour l'ajout de nouvelles pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Mise à jour d'un élément spécifique
Cet exemple peut être utilisé pour un article déjà présent sur le site, mais dont la description a été légèrement modifiée.
```text
foobar: Add mention of security audit (#0000)
```
## Fonctionnalité/amélioration ## Fonctionnalité/amélioration
Pour les nouvelles fonctionnalités ou les améliorations du site, par exemple les choses qui ont le label `enhancements` sur GitHub, il peut être approprié de les signifier avec : Pour les nouvelles fonctionnalités ou les améliorations du site, par exemple les choses qui ont le label `enhancements` sur GitHub, il peut être approprié de les signifier avec :
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Mise à jour de module ## Development-related types
Les mises à jour des dépendances suivent les recommandations normales qui consistent à commencer par : These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/he/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/hi/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/hu/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/id/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/it/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/ja/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/ko/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/ku-IQ/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/nl/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/pl/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/pt-BR/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/pt/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/ru/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/sv/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/tr/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/uk/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/vi/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/zh-Hant/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: 提交訊息
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## 站台更新
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## 模組更新 ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```

64
i18n/zh/meta/commit-messages.md
View File

@ -4,6 +4,26 @@ title: Commit Messages
For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are: For our commit messages we follow the style provided by [Conventional Commits](https://conventionalcommits.org). Not all of those suggestions are appropriate for Privacy Guides, so the main ones we use are:
## Update to existing text
This example could be used for an item already on the site, but includes a minor update to the description.
```text
update: Add mention of security audit (#0000)
```
## Addition or removal of recommendations/pages
This example is for the addition or removal of an item. You may elaborate why it was removed in the commit paragraph below. Note the extra `!` to draw attention to a major change.
```text
update!: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
You can actually add a `!` to _any_ of the types on this page to denote particularly large changes, but this is generally where it will be most appropriate.
## Commit message with correction ## Commit message with correction
We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub. We use `fix` for simple things like spelling mistakes or site related bugs. These things will usually have the `correction` or `bug` label on GitHub.
@ -12,24 +32,6 @@ We use `fix` for simple things like spelling mistakes or site related bugs. Thes
fix: Correct spelling on XYZ page (#0000) fix: Correct spelling on XYZ page (#0000)
``` ```
## Update to site
This example is for a removal of an item (but could also be used for an addition); you may elaborate why it was removed in the commit paragraph below. It can also be used for the addition of any new pages.
```text
update: Remove foobar (#0000)
Foobar was removed due to it having numerious security issues and being unmaintained.
```
## Update to specific item
This example could be used for an item already on the site, but includes a minor update to the description.
```text
foobar: Add mention of security audit (#0000)
```
## Feature/enhancement ## Feature/enhancement
For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with: For new features or enhancements to the site, e.g. things that have the `enhancements` label on GitHub, it may be appropriate to signify these with:
@ -40,10 +42,30 @@ feat: Add blah blah (#0000)
This change adds the forum topics to the main page This change adds the forum topics to the main page
``` ```
## Module update ## Development-related types
Dependency updates follow the normal recommendations of beginning with: These commit types are typically used for changes that won't be visible to the general audience.
We use `docs:` to denote changes to the developer documentation for this website, including (but not limited to) for example the README file, or most pages in `/docs/about` or `/docs/meta`:
```text ```text
chore: Bump modules/mkdocs-material from 463e535 to 621a5b8 docs: Update Git commit message guidelines (#0000)
```
We use `build:` for commits related to our build process, mainly dependency updates.
```text
build: Bump modules/mkdocs-material from 463e535 to 621a5b8
```
We use `ci:` for commits related to GitHub Actions, DevContainers, or other automated build platforms.
```text
ci: Update Netlify config (#0000)
```
We use `refactor:` for changes which neither fix a bug nor add a feature.
```text
refactor: Move docs/assets to theme/assets
``` ```