Skip to content

fix(index.pr): fixed typos in translated persian #667

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

fix(index.pr): fixed typos in translated persian #667

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion config.yaml
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -473,7 +473,7 @@ languages:
weight: 26
languageName: "فارسی"
title: Conventional Commits
description: مشخصات برای اضافه کردن معانی خوانا برای اسنان و ماشین به پیام های کامیت
description: مشخصات برای اضافه کردن معانی خوانا برای انسان و ماشین به پیام های کامیت
actions:
- label: خلاصه
url: '# خلاصه'
Expand Down
16 changes: 8 additions & 8 deletions content/v1.0.0/index.pr.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -27,15 +27,15 @@ aliases: ["/pr/"]
---

<br />
کامیت استاندارد شامل المان های ساختاری زیر است تا کاربرات ارتباط بهتری با کتابخانه شما برقرار کنند:
کامیت استاندارد شامل عناصر ساختاری زیر است تا کاربران ارتباط بهتری با کتابخانه شما برقرار کنند:

1. **fix:** کامیت نوع `fix` نشانگر اصلاح یک باگ در کد شماست(مصداق [`PATCH`](http://semver.org/#summary) در ورژن‌بندی سمانتیک)
2. **feat:** کامیت نوع `feat` ایجاد یک ویژگی جدید را در کد معرفی میکند(مصداق [`MINOR`](http://semver.org/#summary) در ورژن‌بندی سمانتیک)
3. **BREAKING CHANGE:** یک کامیت که شامل فوتر با عنوان `BREAKING CHANGE:` باشد یا `!` در کنار نوع/اسکوپ آن آمده باشد معرف یک تغییر ناسازگار (Breaking Change) در API است. (مصداق [`MAJOR`](http://semver.org/#summary) در ورژن‌بندی سمانتیک)
BREAKING CHANGE می‌تواند بخشی از هر نوع کامیت باشد.
4. انواع دیگری بغیر از `fix:` و `feat` نیز مجاز هستند. بعنوان مثال [@commitlint/config-conventional](https://github.com/conventional-changelog/commitlint/tree/master/%40commitlint/config-conventional) (بر پایه [Angular convention](https://github.com/angular/angular/blob/22b96b9/CONTRIBUTING.md#-commit-message-guidelines)) `build:`, `chore:`,
`ci:`, `docs:`, `style:`, `refactor:`, `perf:`, `test:`, و غیره را پیشنهاد می‌دهد.
5. فوتر های دیگری نیز بجز `BREAKING CHANGE: <description>` ممکن است اراوه شوند و از قاعده [git trailer format](https://git-scm.com/docs/git-interpret-trailers) پیروی کنند.
5. فوترهای دیگری نیز بجز `BREAKING CHANGE: <description>` ممکن است ارائه شوند و از قاعده [git trailer format](https://git-scm.com/docs/git-interpret-trailers) پیروی کنند.

نواع (Types) اضافی دیگر در مشخصات Conventional Commits اجباری نیستند و به‌طور پیش‌فرض تأثیری در نسخه‌بندی معنایی (Semantic Versioning) ندارند (مگر اینکه شامل یک BREAKING CHANGE باشند).
<br /><br/>
Expand Down Expand Up @@ -92,20 +92,20 @@ Reviewed-by: Z
Refs: #123
```

## مشحصات
## مشخصات

کلمات کلیدی “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” باید طبق [RFC 2119](https://www.ietf.org/rfc/rfc2119.txt) تفسیر شوند.

1. کامیت‌ها باید(MUST) با یک نوع مانند `feat`, `fix` و غیره شروع شوند و اسکوپ و `!` بصورت اختیاری(OPTIONAL) در ادامه آورده شود که دونقطه و فاصله ضروری(REQUIRED) است.
2. نوع `feat` باید(MUST) وقتی استفاده شود که کامیت یک ویژگی جدید به برنامه یا کتابخانه شما اضافه کند.
3. نوع `fix` باید(MUST) وقتی استفاده شود که کامیت یک باگ از برنامه یا کتابخانه شما برطرف کند.
4. ممکن(MAY) است بعد از نوع اسکوپ بیان شود. یک اسکوب باید(MUST) یک اسم داخل پرانتز باشد که اسکوپ کامیت را توضیح دهد، بعنوان مثال `fix(parser):`
5. توضیح باید(MUST) بلافاصله بعد از دونقطه و فاصله پس از نوع/اسک.پ آورده شود.
5. توضیح باید(MUST) بلافاصله بعد از دونقطه و فاصله پس از نوع/اسکوپ آورده شود.
این توضیح شامل یک متن کوتاه درباره تغییر درحال کامیت است، مثلا _fix: array parsing issue when multiple spaces were contained in string_.
6. ممکن(MAY) است پس از توضیحات کوتاه، توضیح طولانی‌تری ارائه شود که اطلاعات متنی بیشتری در مورد تغییرات کد ارائه می‌کند. متن باید یک خط خالی بعد از توضیحات اول شروع شود.
7. بصورت آزاد است و ممکن(MAY) است از هر تعداد پاراگراف جدا شده از خط جدید تشکیل شده باشد.
8. ممکن(MAY) است یک یا چند فوتر بعد از یک خط خالی بعد از بدنه توضیحات ارائه شود. هر فوتر باید(MUST) شامل یک توکن (کلمه کلیدی) باشد که به دنبال آن یک جداکننده :<space> (دو نقطه و یک فاصله) یا <space># (یک فاصله و علامت #) قرار می‌گیرد و سپس یک مقدار متنی (String Value) (این قالب‌بندی از کنوانسیون تریلرهای گیت [git trailer convention](https://git-scm.com/docs/git-interpret-trailers) الهام گرفته شده است).
9. نشانه فوتر باید(MUST) از «-» به جای کاراکترهای فضای خالی استفاده کند، به عنوان مثال، «Acked-by» (این به تمایز بخش t,jv از بدنه کمک می کند). یک استثنا برای `BREAKING CHANGE` ایجاد شده است که ممکن است به عنوان نشانه نیز استفاده شود.
9. نشانه فوتر باید(MUST) از «-» به جای کاراکترهای فضای خالی استفاده کند، به عنوان مثال، «Acked-by» (این به تمایز بخش توضیحات از بدنه کمک می کند). یک استثنا برای `BREAKING CHANGE` ایجاد شده است که ممکن است به عنوان نشانه نیز استفاده شود.
10. مقدار فوتر ممکن(MAY) است حاوی فاصله و خطوط جدید باشد و پارسر باید(MUST) با مشاهده جفت نشانه/جداکننده فوتر معتبر بعدی خاتمه یابد.
11. BREAKING CHANGE باید(MUST) در پیشوند نوع/حوزه یک کامیت یا به عنوان ابتدای فوتر حضور داشته باشد.
12. اگر BREAKING CHANGE در فوتر گنجانده شود، آن(MUST) حروف بزرگ BREAKING CHANGE، به دنبال آن دو نقطه، فاصله و توضیحات باشد، به عنوان مثال، مثلا _BREAKING CHANGE: environment variables now take precedence over config files_.
Expand All @@ -131,9 +131,9 @@ Refs: #123

### آیا نوع‌ها باید از حروف کوچک استفاده کنند یا حروف بزرگ؟

تفاوتی نم‌کند اما بهتر است یکدست باشد.
تفاوتی نمی‌کند اما بهتر است یکدست باشد.

### اگر گامیت با بیش از یک نوع از انواع استاندارد مطابقت داشت، چه کاری باید بکنم؟
### اگر کامیت با بیش از یک نوع از انواع استاندارد مطابقت داشت، چه کاری باید بکنم؟

ترجیحا به عقب برگردید و کامیت های بیشتری تولید کنید. بخشی از مزایای قاعده استاندارد توانایی آن در سوق دادن ما به انجام تعهدات و روابط عمومی بیشتر است.

Expand Down Expand Up @@ -163,7 +163,7 @@ Refs: #123

در بدترین حالت، اگر کامیتی که با مشخصات قاعده استاندارد کامیت مطابقت ندارد وارد شود، دنیا به پایان نمی‌رسد. این فقط به این معنی است که آن کامیت توسط ابزارهایی که بر اساس این مشخصات کار می‌کنند، نادیده گرفته خواهد شد.

### آیا همه مشارکت ککندگان پروژه من باید از مشخصات قاعده استاندارد کامیت پیروی کنند؟
### آیا همه مشارکت‌کنندگان پروژه من باید از مشخصات قاعده استاندارد کامیت پیروی کنند؟

نه! اگر از یک گردش کار مبتنی بر Squash در گیت استفاده کنید، نگه‌دارندگان اصلی می‌توانند پیام‌های کامیت را در حین ادغام تمیز و مرتب کنند بدون اینکه بار کاری اضافه‌ای به مشارکت‌کنندگان معمولی تحمیل شود.
یک گردش کار رایج برای این مورد این است که سیستم گیت شما به‌طور خودکار کامیت‌های یک درخواست pull را Squash کند و یک فرم به نگه‌دارنده اصلی ارائه دهد تا پیام کامیت مناسب را برای ادغام وارد کند.
Expand Down