Commit 4ad23de
File tree
- .github/workflows
- builtins
- library
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -117,4 +117,4 @@ jobs: | |||
| 117 | 117 | exit 0 | |
| 118 | 118 | fi | |
| 119 | 119 | git commit -m "chore: sync msgids with CPython $CPYTHON_TAG" | |
| 120 | - git push | ||
| 120 | + git push | ||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -49,18 +49,12 @@ | |||
| 49 | 49 | ## فرایند ترجمه | |
| 50 | 50 | ||
| 51 | 51 | 1. پرونده‌ای را انتخاب کنید و بررسی کنید آیا [ایشوی](https://github.com/python/python-docs-fa/issues) مربوط به آن باز شده است یا نه (قالب «درخواست ترجمه‌ی صفحه»). اگر باز شده و ترجمه‌ی کامل آن در حال انجام است، پرونده‌ی دیگری را انتخاب کنید؛ در غیر این صورت یک ایشو باز کرده و شروع به کار کنید. | |
| 52 | - | ||
| 53 | 52 | 2. پرونده‌ی `.po` مورد نظر را با [Poedit](https://poedit.net) یا هر ویرایشگر متنی باز کنید. | |
| 54 | 53 | - در Poedit رشته‌های ترجمه‌نشده یا `fuzzy` را از پنل فیلتر (Filter) پیدا کنید. | |
| 55 | - | ||
| 56 | 54 | 3. متن `msgid` را ترجمه کنید و در `msgstr` وارد کنید. | |
| 57 | - | ||
| 58 | 55 | 4. برای پیدا کردن ترجمه‌ی مناسب برای کلمات و عبارات تخصصی، از [این پیوند](http://python.github.io/python-docs-fa/glossary-searcher) به واژه‌یاب پایتون رفته و واژه/عبارت موردنظر خود را جست‌جو کنید. | |
| 59 | - | ||
| 60 | 56 | 5. **نشانه‌گذاری‌های Sphinx** مثل `` :class:`int` ``، `` :func:`repr` ``، `` :ref:`...` ``، `` ``code`` `` و **جای‌گذارها** مثل `%s` یا `{name}` را دقیقاً بدون تغییر نگه دارید؛ فقط متن اطراف آن‌ها ترجمه می‌شود. در `` :term:`target` ``، اگر عبارت داخل بک‌تیک با شناسه‌ی واژه‌نامه یکی است، می‌توانید آن را به شکل `` :term:`ترجمه <target>` `` بنویسید تا هم متن ترجمه‌شده نمایش داده شود و هم لینک درست کار کند؛ در این حالت فقط بخش نمایشی (پیش از `<`) ترجمه می‌شود و `target` داخل `<>` باید دقیقاً همان شناسه‌ی انگلیسی اصلی (بدون تغییر) باقی بماند، چون تغییر آن لینک را خراب می‌کند. | |
| 61 | - | ||
| 62 | 57 | 6. داخل کدها (بلوک‌های `code-block`) نام متغیرها، توابع، کلمات کلیدی و **کامنت‌ها** ترجمه نمی‌شوند؛ چون کد از راست به چپ نوشته نمی‌شود و وجود متن فارسی داخل آن، کد را ناخوانا می‌کند. فقط رشته‌های متنی (string) قابل‌ترجمه‌اند. | |
| 63 | - | ||
| 64 | 58 | 7. اگر به اصطلاحی برخوردید که در واژه‌نامه نبود و فکر میکنید که باید در واژه‌نامه باشد، به بخش «افزودن واژه یا اصطلاح جدید به واژه‌نامه» همین پرونده بروید. | |
| 65 | 59 | ||
| 66 | 60 | ### بررسی‌ها قبل از ارسال پول‌ریکوئست | |
@@ -82,11 +76,8 @@ python3 scripts/check_markup.py your_file.po | |||
| 82 | 76 | برای یکدست ماندن ترجمه‌ها، این نکات نگارشی را رعایت کنید: | |
| 83 | 77 | ||
| 84 | 78 | - **«هٔ» در برابر «ه‌ی»:** از ترکیب «هٔ» (ه همزه‌دار/ سریا) استفاده نکنید؛ به‌جای آن از «ه‌ی» (با نیم‌فاصله) استفاده کنید. مثال درست: «برنامه‌ی پایتون». مثال نادرست: «برنامهٔ پایتون». | |
| 85 | - | ||
| 86 | 79 | - **نیم‌فاصله (ZWNJ):** در جاهایی که نیم‌فاصله لازم است (مثل «می‌شود»، «میکنید»، جمع با «ها» نظیر «پرونده‌ها»، یا پیشوندهایی مثل «بی» و «نا») از کاراکتر نیم‌فاصله‌ی واقعی (U+200C) استفاده کنید، نه فاصله‌ی معمولی یا بدون فاصله. مثال درست: «پرونده‌های ترجمه‌نشده». مثال نادرست: «پرونده های ترجمه نشده» یا «فایلهای ترجمه‌نشده». | |
| 87 | - | ||
| 88 | 80 | - **اعداد فارسی در برابر اعداد لاتین:** در متن روایی فارسی از ارقام فارسی (۰۱۲۳۴۵۶۷۸۹) استفاده کنید (مثلاً «در نسخه‌ی ۳ پایتون»). اما داخل کد، شماره‌ی نسخه‌ی پایتون، مسیر پرونده‌ها، لینک‌ها و هر جایی که عدد بخشی از یک شناسه‌ی فنی است (مثل `v3.14.6`)، همیشه از ارقام لاتین استفاده کنید و آن‌ها را تغییر ندهید. | |
| 89 | - | ||
| 90 | 81 | - **علائم نگارشی فارسی در برابر انگلیسی:** در متن فارسی از علائم فارسی استفاده کنید: «،» به‌جای «,» و «؟» به‌جای «?». علائمی که داخل کد، نشانه‌گذاری‌های Sphinx، یا جای‌گذارها هستند دست‌نخورده باقی می‌مانند (چون بخشی از متن انگلیسی اصلی محسوب نمی‌شوند و نباید تغییر کنند). | |
| 91 | 82 | ||
| 92 | 83 | ## سطح رسمیت و لحن نوشتار | |
@@ -175,22 +166,29 @@ python3 scripts/update_python_version.py v3.15.0 --keep-src | |||
| 175 | 166 | - محل دقیق ترجمه‌ی مشکل‌دار (مسیر پرونده یا لینک صفحه) | |
| 176 | 167 | - در صورت نیاز، تصویری از ترجمه | |
| 177 | 168 | - در صورت دسترسی، متن msgid و msgstr مربوطه | |
| 178 | - | ||
| 179 | - | ||
| 180 | 169 | ## پیشنهاد تغییر در واژه یا شیوه‌ی نگارش | |
| 181 | 170 | ||
| 182 | 171 | اگر می‌خواهید تغییری در ترجمه‌ی یک واژه‌ی موجود در واژه‌نامه یا در یکی از شیوه‌های نگارشی رایج پروژه پیشنهاد دهید، این فرایند را دنبال کنید: | |
| 183 | 172 | ||
| 184 | 173 | 1. یک ایشو با قالب **«پیشنهاد تغییرات در ترجمه»** باز کنید. | |
| 185 | - 2. پس از بررسی و تأیید اولیه‌ی نگهدارندگان پروژه، یک نظرسنجی هم‌زمان در گروه تلگرام و در همان ایشوی گیت‌هاب (با گزینه‌های پسندیدن/نپسندیدن) آغاز می‌شود. | ||
| 186 | - 3. این نظرسنجی به مدت **دو هفته** باز می‌ماند. در پایان این بازه، مجموع آرای موافق و مخالف به‌عنوان مبنای تصمیم‌گیری درباره‌ی اعمال یا رد تغییر در مستندات در نظر گرفته می‌شود. | ||
| 187 | - 4. اگر پیشنهاد تغییر رأی موافق کسب نکند، همان پیشنهاد را می‌توان پس از گذشت **چهار هفته** دوباره به رأی گذاشت. | ||
| 188 | - 5. اگر پیشنهاد تغییر رأی موافق کسب کند، به یک ایشوی اصلی (master issue) که فهرست کارها و تغییرات قابل‌انجام را پیگیری می‌کند اضافه خواهد شد تا هر مشارکت‌کننده‌ای که مایل باشد بتواند اجرای آن را بر عهده بگیرد. | ||
| 174 | + 2. پس از بررسی اولیه‌ی نگهدارندگان پروژه، در صورت تأیید، یک نظرسنجی هم‌زمان در گروه تلگرام و در همان ایشوی گیت‌هاب (با گزینه‌های پسندیدن/نپسندیدن) آغاز می‌شود. | ||
| 175 | + 3. نظرسنجی به مدت **دو هفته** باز می‌ماند. در پایان این بازه، نتیجه‌ی نظرسنجی به‌عنوان نظر جامعه‌ی مشارکت‌کنندگان درباره‌ی پیشنهاد در نظر گرفته می‌شود و نگهدارندگان پروژه بر اساس آن، و با توجه به قوانین و استانداردهای فنی و نگارشی پروژه، درباره‌ی اجرای پیشنهاد تصمیم می‌گیرند. | ||
| 176 | + 4. نگهدارندگان پروژه تنها در صورتی می‌توانند اجرای نتیجه‌ی نظرسنجی را به تعویق بیندازند یا از اجرای آن خودداری کنند که نتیجه با یکی از موارد زیر تعارض داشته باشد: | ||
| 177 | + | ||
| 178 | + - معنای فنی یا مفهومی متن اصلی؛ | ||
| 179 | + - الزامات فنی مستندات یا نشانه‌گذاری‌های Sphinx؛ | ||
| 180 | + - قوانین و شیوه‌نامه‌های مصوب پروژه؛ | ||
| 181 | + - یا صحت و یکپارچگی فنی مستندات. | ||
| 182 | + | ||
| 183 | + در چنین مواردی، دلیل تصمیم باید به‌صورت عمومی در همان ایشو توضیح داده شود و در صورت امکان، پیشنهاد برای بررسی دوباره یا اصلاح به جامعه بازگردانده شود. | ||
| 184 | + | ||
| 185 | + 5. اگر پیشنهاد تغییر رأی موافق کسب نکند، همان پیشنهاد را می‌توان پس از گذشت **چهار هفته** دوباره به رأی گذاشت؛ مشروط بر اینکه در این فاصله دلیل یا شواهد جدیدی برای بازنگری در آن ارائه شده باشد. | ||
| 186 | + 6. اگر پیشنهاد تغییر پذیرفته شود، به یک ایشوی اصلی (master issue) که فهرست کارها و تغییرات قابل‌انجام را پیگیری می‌کند اضافه خواهد شد تا هر مشارکت‌کننده‌ای که مایل باشد بتواند اجرای آن را بر عهده بگیرد. | ||
| 189 | 187 | ||
| 190 | 188 | ## افزودن واژه یا اصطلاح جدید به واژه‌نامه | |
| 191 | 189 | ||
| 192 | 190 | اگر واژه یا اصطلاحی در واژه‌نامه‌ی پروژه وجود ندارد و می‌خواهید معادل پیشنهادی برای آن اضافه شود، یک ایشو با قالب **«پیشنهاد تغییرات در ترجمه»** باز کنید و واژه‌ی انگلیسی، معادل پیشنهادی، و دلیل انتخاب آن را توضیح دهید. | |
| 193 | 191 | ||
| 194 | 192 | پیشنهادهای افزودن واژه‌ی جدید نیز پس از بررسی اولیه‌ی نگهدارندگان، در صورت نیاز از همان فرایند نظرسنجی توضیح داده شده در بالا استفاده خواهند کرد تا درباره‌ی پذیرش یا رد آن تصمیم‌گیری شود. | |
| 195 | 193 | ||
| 196 | - مشارکت‌ها به واژه‌نامه باید به پرونده‌ی `glossary.tsv` انجام شوند. | ||
| 194 | + مشارکت‌ها به واژه‌نامه باید به پرونده‌ی `glossary.tsv` انجام شوند. | ||
| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
@@ -48,5 +48,5 @@ | |||
| 48 | 48 | <!-- STATS_START --> | |
| 49 | 49 | ### مشارکت‌های کاربران | |
| 50 | 50 |  | |
| 51 | - (به‌روزرسانی: 2026-09-19) | ||
| 51 | + (به‌روزرسانی: 2026-09-21) | ||
| 52 | 52 | <!-- STATS_END --> | |
0 commit comments