free-programming-books/docs/CONTRIBUTING-fa_IR.md
David Ordás 97022b79cd
chore(docs): Apply #6822 (playground definition) to the rest of CONTRIBUTING files (#6824)
* Added playground definition

Added a small definition about programming/coding playgrounds for making it understandable to beginners

* Define what is a playground

Via / completes:
- What's a programming playground? #6107
- Added playground definition #6817
- Sentence added under playground #6819

Thanks @Suman373 for the initial idea.

Co-authored-by: Suman Roy <95040233+Suman373@users.noreply.github.com>

* reword playground definition as suggested

Co-authored-by: Eric Hellman <eric@hellman.net>

* copy #6822 playground definition into rest files

* translate #6822 (playground definition) to spanish

* translate #6822 (playground definition) to italian

Co-authored-by: ImVector <59611597+LuigiImVector@users.noreply.github.com>

* translate #6822 (playground definition) to french

Thanks to @Existential-nonce

Co-authored-by: nonce <77142078+Existential-nonce@users.noreply.github.com>

* translate EbookFoundation#6822 (playground definition) to chinese

Provided by @kang8. Thank you too much!

Co-authored-by: kang <1115610574@qq.com>

* Improve playground definition in `zh_TW` language

Co-authored-by: Alan Syue <33183531+AlanSyue@users.noreply.github.com>

* Minor improve playground definition in `fr` language

Co-authored-by: lorrding <mathias.berthonneau@gmail.com>

Co-authored-by: Suman Roy <95040233+Suman373@users.noreply.github.com>
Co-authored-by: Eric Hellman <eric@hellman.net>
Co-authored-by: ImVector <59611597+LuigiImVector@users.noreply.github.com>
Co-authored-by: nonce <77142078+Existential-nonce@users.noreply.github.com>
Co-authored-by: kang <1115610574@qq.com>
Co-authored-by: Alan Syue <33183531+AlanSyue@users.noreply.github.com>
Co-authored-by: lorrding <mathias.berthonneau@gmail.com>
2022-07-25 14:37:35 +02:00

14 KiB

این متن را در زبان‌های دیگر بخوانید

توافقنامه‌ی مجوز همکاری

مشارکت در این مخزن به معنی موافقت شما با مجوز LICENSE این مخزن است.

مرام‌نامه‌ی همکار

مشارکت در این پروژه به معنی موافقت با احترام به مرام‌نامه‌ی این مخزن است. (translations)

به طور خلاصه

  1. "لینکی برای دانلود ساده‌ی یک کتاب" همیشه به معنی لینکی به یک کتاب رایگان نیست. لطفا فقط محتوای رایگان را قرار دهید. مطمئن شوید که این محتوا رایگان است. ما لینک‌هایی را که وارد کردن ایمیل کاری را برای دانلود کتاب اجباری کرده‌اند نمی‌پذیریم اما اگر بدون اجبار، این ایمیل را بخواهند، در این مخزن فهرستشان می‌کنیم.

  2. نیاز نیست گیت بلد باشید: اگر چیز جذابی پیدا کردید که در این مخزن وجود ندارد، یک Issue با نوشتن لینک‌ها درست کنید.

    • اگر Git را می شناسید، لطفاً مخزن را Fork کنید و درخواست های کششی (PR) ارسال کنید.
  3. ما شش نوع فهرست داریم. فهرست درست را انتخاب کنید:

    • کتاب‌ها : PDF، HTML، ePub، سایت بر اساس gitbook.io، یک مخزن گیت و غیره.
    • دوره‌ها : دوره محتوایی آموزشی است که کتاب نیست. مثلا این یک دوره است.
    • آموزش‌های تعاملی : وبسایتی تعاملی که به کاربر اجازه‌ی تایپ کد یا دستور می‌دهد و نتیجه را ارزیابی می‌کند (منظور ما از "ارزیابی"، "نمره‌دهی" نیست). مثلا: Try Haskell, Try GitHub.
    • Playgrounds : are online and interactive websites, games or desktop software for learning programming. Write, compile (or run), and share code snippets. Playgrounds often allow you to fork and get your hands dirty by playing with code.
    • پادکست‌ها و اسکرین‌کست‌ها
    • مجموعه مشکلات و برنامه‌نویسی رقابتی : وبسایت یا نرم‌افزاری که به شما امکان بررسی مهارت‌های برنامه‌نویسی را با کمک حل مشکلات ساده یا پیچیده، با یا بدون بررسی کد، با یا بدون مقایسه‌ی نتایج با کاربران دیگر می‌دهد.
  4. مطمئن شوید که از راهنماها پیروی می‌کنید و طبق فرمت‌بندی مارک‌داون می‌نویسید.

  5. GitHub Actions تست‌هایی را اجرا می‌کند که مطمئن شود فهرست شما الفبایی است و قوانین فرمت‌بندی رعایت شده است. مطمئن شوید که تغییرات شما تست‌ها را با موفقیت گذرانده است.

راهنماها

  • مطمئن شوید که یک کتاب رایگان است. اگر لازم بود، دوباره هم بررسی کنید. اگر درباره‌ی علت این که فکر می‌کنید کتاب رایگان است در پول‌ریکوئست (PR)، کامنت بگذارید، به ادمین‌ها کمک کرده‌اید.
  • ما فایل‌هایی را قبول نمی‌کنیم که روی گوگل‌درایو، دراپ‌باکس، مگا، اسکریبد، ایسیو یا پلتفرم‌های آپلود فایل مشابه قرار دارند
  • لینک‌های خود را به ترتیب الفبایی وارد کنید, همان طور که در زیر توضیح داده شده است.
  • از لینک معتبرترین منبع استفاده کنید (این یعنی وبسایت نویسنده بهتر از وبسایت ویراستار و وبسایت ویراستار بهتر از وبسایت سوم شخص است)
    • از سرویس‌های اشتراک‌گذاری فایل استفاده نکنید (این سرویس‌ها شامل (و نه محدود به) لینک‌های دراپ‌باکس و گوگل‌درایو است)
  • همیشه یک لینک https به یک لینک http ترجیح داده می‌شود -- تا وقتی که هر دو لینک دامنه‌ی یکسانی داشته باشند و محتوای یکسانی نمایش دهند.
  • در دامنه‌های اصلی، از گذاشتن / خودداری کنید: http://example.com به جای http://example.com/
  • همیشه کوتاه‌ترین لینک ترجیح داده می‌شود: http://example.com/dir/ بهتر است از http://example.com/dir/index.html
    • از لینک‌های کوتاه‌ساز استفاده نکنید.
  • معمولا لینک "فعلی" بهتر از لینک "نسخه‌ها" است: http://example.com/dir/book/current/ بهتر است از http://example.com/dir/book/v1.0.0/index.html
  • اگر لینکی مشکل certificate/self-signed certificate/SSL از هر نوع دیگری داشت:
    1. با همتای http همان لینک جایگزینش کنید (چون پذیرش استثناقائل شدن برای آن وبسایت در دستگاه‌های موبایل سخت است).
    2. اگر نسخه‌ی http ندارد اما همچنان با https و اضافه کردن استثناقائل‌شدن برای آن وبسایت در مرورگر یا نادیده گرفتن هشدار قابل دسترس است، به همان حالت بگذاریدش
    3. در غیر این صورت حذفش کنید
  • اگر لینکی در چندین فرمت وجود داشت، لینکی جدا با یادداشتی درباره‌ی هر فرمت قرار دهید.
  • اگر منبعی در جاهای دیگری از اینترنت وجود دارد
    • از لینک معتبرترین منبع استفاده کنید (این یعنی وبسایت نویسنده بهتر از وبسایت ویراستار و وبسایت ویراستار بهتر از وبسایت سوم شخص است)
    • اگر به ویرایش‌های مختلف لینک شده است و شما معتقدید این ویرایش‌ها به حد کافی متفاوت هستند که هر دو نگه داشته شوند، یک لینک جدا با یادداشتی درباره‌ی هر ویرایش بنویسید (برای مشارکت در فرمت‌بندی Issue #2353 را ببینید).
  • کامیت‌های تکی (یک کامیت اضافه کردن/ حذف کردن/ تغییر دادن) بهتر از کامیت‌های بزرگ هستند. نیاز نیست کامیت‌های خود را قبل از ثبت یک پی‌آر خرد کنید (ما به دنبال اجباری کردن این قانون نیستیم چون این قانون فقط به خاطر راحتی نگه‌دارندگان مخزن است)
  • اگر کتاب قدیمی است، تاریخ انتشار را در کنار عنوان بنویسید.
  • نام نویسنده یا نویسندگان را در صورت امکان بنویسید. می‌توانید فهرست نویسندگان را با "و همکاران" (به انگلیسی: "et al.") کوتاه کنید.
  • اگر کتاب هنوز تمام نشده است و هنوز روی آن کار می‌شود، عبارت "in process" را همان طور که در پایین صفحه آمده به آن اضافه کنید.
  • اگر پیش از دانلود، نشانی ایمیل یا ساخت حساب کاربری خواسته می‌شود، در پرانتز توضیح متناسبی بنویسید. مثلا: (نشانی ایمیل *خواسته می‌شود* اما اجباری نیست).

فرمت‌بندی

  • همه فهرست‌ها فایل‌های ".md" هستند. سعی کنید دستور زبان Markdown را یاد بگیرید. ساده است!
  • همه فهرست‌ها با یک فهرست محتوایی شروع می‌شود. ایده این است که همه بخش‌ها و زیربخش‌ها در این فهرست محتوایی لیست و لینک شوند. این فهرست محتوایی را به ترتیب الفبایی قرار دهید.
  • بخش‌ها از تیترهای سطح 3 (###) استفاده می‌کنند و زیربخش‌ها از تیترهای سطح 4 (###).

ایده این است که این موارد رعایت شوند:

  • 2 خط خالی بین آخرین لینک و بخش جدید
  • 1 خط خالی بین تیتر و لینک اول همان بخش
  • 0 خط خالی بین دو لینک
  • 1 خط خالی در آخر هر فایل .md

مثال:

[...]
* [یک کتاب عالی](http://example.com/example.html)
                                (خط خالی)
                                (خط خالی)
### مثال
                                (خط خالی)
* [یک کتاب عالی دیگر](http://example.com/book.html)
* [یک کتاب دیگر](http://example.com/other.html)
  • بین ] و ( space نگذارید:

    بد : * [یک کتاب عالی دیگر] (http://example.com/book.html)
    خوب: * [یک کتاب عالی دیگر](http://example.com/book.html)
    
  • اگر اسم نویسنده را اضافه می‌کنید، از - استفاده کنید (یک dash با دو single space):

    بد : * [یک کتاب عالی دیگر](http://example.com/book.html)- نام نویسنده
    خوب: * [یک کتاب عالی دیگر](http://example.com/book.html) - نام نویسنده
    
  • یک single space بین لینک و فرمت قرار دهید:

    بد : * [یک کتاب خیلی عالی](https://example.org/book.pdf)(PDF)
    خوب: * [یک کتاب خیلی عالی](https://example.org/book.pdf) (PDF)
    
  • نویسنده قبل از فرمت می‌آید:

    بد : * [یک کتاب خیلی عالی](https://example.org/book.pdf)- (PDF) نام نویسنده
    خوب: * [یک کتاب خیلی عالی](https://example.org/book.pdf) - یک نویسنده دیگر (PDF)
    
  • چند فرمتی‌ها:

    بد : * [یک کتاب عالی دیگر](http://example.com/)- نام نویسنده (HTML)
    بد : * [یک کتاب عالی دیگر](https://downloads.example.org/book.html)- نام نویسنده (download site)
    خوب: * [یک کتاب عالی دیگر](http://example.com/) - نام نویسنده (HTML) [(PDF, EPUB)](https://downloads.example.org/book.html)
    
  • سال انتشار برای کتاب‌های قدیمی را در عنوان ینویسید:

    بد : * [یک کتاب خیلی عالی](https://example.org/book.html) - نام نویسنده - 1970
    خوب: * [یک کتاب خیلی عالی (1970)](https://example.org/book.html) - نام نویسنده
    
  • کتاب‌های در دست تالیف:

    خوب: * [کتابی که عالی خواهدشد](http://example.com/book2.html) - نام نویسنده (HTML) (:construction: *in process*)
    

ترتیب الفبایی

  • وقتی چند عنوان با حرف یکسانی شروع می‌شوند، آنها را به ترتیب حرف دوم مرتب کنید و به همین ترتیب برای حرف‌های بعدی. مثلا aa قبل از ab می‌آید.
  • همچنین one two قبل از onetwo می‌آید.

اگر لینکی را در جای نادرست دیدید، پیام خطای linter را ببینید تا بفهمید کدام خط‌ها باید جابجا شوند.

خودکارسازی

  • قوانین فرمت‌بندی از طریق GitHub Actions با استفاده از fpb-lint بررسی می‌شوند (.github/workflows/fpb-lint.yml را ببینید)

  • اعتبارسنجی لینک‌ها با استفاده از awesome_bot انجام می‌شود.

  • برای اجرای اعتبارسنجی لینک‌ها، کامیتی پوش کنید که در بدنه‌ی آن check_urls=file_to_check نوشته شده باشد:

    check_urls=free-programming-books.md free-programming-books-fa_IR.md
    
  • با استفاده از single space برای جدا کردن هر ورودی، می‌توانید بیشتر از یک فایل را برای بررسی مشخص کنید.

  • اگر بیش از یک فایل را مشخص کردید، نتایج بیلد بر اساس نتیجه آخرین فایل بررسی‌شده خواهد بود. دقت کنید که ممکن است به همین علت، نتیجه سبز را ببینید. پس برای اطمینان لاگ بیلد را با کلیک روی "Show all checks" -> "Details" در پایان پول ریکوئست (PR) ببینید.