diff --git a/config.yaml b/config.yaml
index c54a8016..ad768d8a 100644
--- a/config.yaml
+++ b/config.yaml
@@ -473,7 +473,7 @@ languages:
     weight: 26
     languageName: "فارسی"
     title: Conventional Commits
-    description: مشخصات برای اضافه کردن معانی خوانا برای اسنان و ماشین به پیام های کامیت
+    description: مشخصات برای اضافه کردن معانی خوانا برای انسان و ماشین به پیام های کامیت
     actions:
       - label: خلاصه
         url: '# خلاصه'
diff --git a/content/v1.0.0/index.pr.md b/content/v1.0.0/index.pr.md
index 8a7f59ab..df4450cc 100644
--- a/content/v1.0.0/index.pr.md
+++ b/content/v1.0.0/index.pr.md
@@ -27,7 +27,7 @@ aliases: ["/pr/"]
 ---
 
 <br />
-کامیت استاندارد شامل المان های ساختاری زیر است تا کاربرات ارتباط بهتری با کتابخانه شما برقرار کنند:
+کامیت استاندارد شامل عناصر ساختاری زیر است تا کاربران ارتباط بهتری با کتابخانه شما برقرار کنند:
 
 1. **fix:** کامیت نوع `fix` نشانگر اصلاح یک باگ در کد شماست(مصداق [`PATCH`](http://semver.org/#summary) در ورژن‌بندی سمانتیک)
 2. **feat:** کامیت نوع `feat` ایجاد یک ویژگی جدید را در کد معرفی میکند(مصداق [`MINOR`](http://semver.org/#summary) در ورژن‌بندی سمانتیک)
@@ -35,7 +35,7 @@ aliases: ["/pr/"]
 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/>
@@ -92,7 +92,7 @@ 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) تفسیر شوند.
 
@@ -100,12 +100,12 @@ Refs: #123
 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_.
@@ -131,9 +131,9 @@ Refs: #123
 
 ### آیا نوع‌ها باید از حروف کوچک استفاده کنند یا حروف بزرگ؟
 
-تفاوتی نم‌کند اما بهتر است یکدست باشد.
+تفاوتی نمی‌کند اما بهتر است یکدست باشد.
 
-### اگر گامیت با بیش از یک نوع از انواع استاندارد مطابقت داشت، چه کاری باید بکنم؟
+### اگر کامیت با بیش از یک نوع از انواع استاندارد مطابقت داشت، چه کاری باید بکنم؟
 
 ترجیحا به عقب برگردید و کامیت های بیشتری تولید کنید. بخشی از مزایای قاعده استاندارد توانایی آن در سوق دادن ما به انجام تعهدات و روابط عمومی بیشتر است.
 
@@ -163,7 +163,7 @@ Refs: #123
 
 در بدترین حالت، اگر کامیتی که با مشخصات قاعده استاندارد کامیت مطابقت ندارد وارد شود، دنیا به پایان نمی‌رسد. این فقط به این معنی است که آن کامیت توسط ابزارهایی که بر اساس این مشخصات کار می‌کنند، نادیده گرفته خواهد شد.
 
-### آیا همه مشارکت ککندگان پروژه من باید از مشخصات قاعده استاندارد کامیت پیروی کنند؟
+### آیا همه مشارکت‌کنندگان پروژه من باید از مشخصات قاعده استاندارد کامیت پیروی کنند؟
 
 نه! اگر از یک گردش کار مبتنی بر Squash در گیت استفاده کنید، نگه‌دارندگان اصلی می‌توانند پیام‌های کامیت را در حین ادغام تمیز و مرتب کنند بدون اینکه بار کاری اضافه‌ای به مشارکت‌کنندگان معمولی تحمیل شود.
 یک گردش کار رایج برای این مورد این است که سیستم گیت شما به‌طور خودکار کامیت‌های یک درخواست pull را Squash کند و یک فرم به نگه‌دارنده اصلی ارائه دهد تا پیام کامیت مناسب را برای ادغام وارد کند.