โครงการนี้ยินดีต้อนรับการมีส่วนร่วมและข้อเสนอแนะ ส่วนใหญ่การมีส่วนร่วมจะต้องให้คุณยอมรับข้อตกลง Contributor License Agreement (CLA) ซึ่งเป็นการประกาศว่าคุณมีสิทธิ์และได้ให้สิทธิ์แก่เราในการใช้ผลงานของคุณ สำหรับรายละเอียดเพิ่มเติม โปรดเยี่ยมชม https://cla.opensource.microsoft.com
เมื่อคุณส่ง pull request ระบบ CLA bot จะตรวจสอบโดยอัตโนมัติว่าคุณจำเป็นต้องส่ง CLA หรือไม่ และจะเพิ่มสถานะหรือคอมเมนต์ใน PR ตามที่เหมาะสม เพียงแค่ทำตามคำแนะนำที่บอทให้ไว้ คุณจะต้องทำเพียงครั้งเดียวสำหรับทุกรีโปที่ใช้ CLA ของเรา
เพื่อเตรียมสภาพแวดล้อมสำหรับการพัฒนาในโครงการนี้ เราแนะนำให้ใช้ Poetry สำหรับจัดการ dependencies เราใช้ไฟล์ pyproject.toml ในการจัดการ dependencies ของโปรเจกต์ ดังนั้นในการติดตั้ง dependencies คุณควรใช้ Poetry
python -m venv .venvpoetry init-
Windows:
.venv\Scripts\activate.bat
-
Mac/Linux:
source .venv/bin/activate
poetry shellpoetry installก่อนส่ง PR ควรทดสอบฟังก์ชันการแปลกับเอกสารจริง:
-
สร้างไดเรกทอรีทดสอบในไดเรกทอรีหลัก:
mkdir test_docs
-
คัดลอกเอกสาร markdown และรูปภาพที่ต้องการแปลไปยังไดเรกทอรีทดสอบ เช่น:
cp /path/to/your/docs/*.md test_docs/ cp /path/to/your/images/*.png test_docs/
-
ติดตั้งแพ็กเกจในเครื่อง:
pip install -e . -
รัน Co-op Translator กับเอกสารทดสอบของคุณ:
python -m co_op_translator --language-codes ko --root-dir test_docs
-
ตรวจสอบไฟล์แปลใน
test_docs/translationsและtest_docs/translated_imagesเพื่อยืนยันว่า:- คุณภาพการแปลดี
- คอมเมนต์ metadata ถูกต้อง
- โครงสร้าง markdown เดิมยังคงอยู่
- ลิงก์และรูปภาพทำงานได้อย่างถูกต้อง
การทดสอบด้วยตนเองนี้ช่วยให้มั่นใจว่าการเปลี่ยนแปลงของคุณทำงานได้ดีในสถานการณ์จริง
- สร้างไฟล์
.envในไดเรกทอรีหลักโดยคัดลอกจากไฟล์.env.templateที่ให้มา - กรอกตัวแปรสภาพแวดล้อมตามคำแนะนำ
Tip
นอกจากการรันโปรเจกต์ในเครื่องแล้ว คุณยังสามารถใช้ GitHub Codespaces หรือ VS Code Dev Containers เป็นตัวเลือกสภาพแวดล้อมการพัฒนาได้
คุณสามารถรันตัวอย่างนี้แบบเสมือนจริงโดยใช้ GitHub Codespaces โดยไม่ต้องตั้งค่าหรือกำหนดค่าเพิ่มเติม
ปุ่มนี้จะเปิด VS Code เวอร์ชันเว็บในเบราว์เซอร์ของคุณ:
ตัวเลือกที่เกี่ยวข้องคือ VS Code Dev Containers ซึ่งจะเปิดโปรเจกต์ใน VS Code บนเครื่องของคุณโดยใช้ Dev Containers extension:
เราใช้ Black เป็นตัวจัดรูปแบบโค้ด Python เพื่อรักษาความสม่ำเสมอของรูปแบบโค้ดในโปรเจกต์ Black เป็นตัวจัดรูปแบบโค้ดที่ไม่ยืดหยุ่นซึ่งจะจัดรูปแบบโค้ด Python โดยอัตโนมัติเพื่อให้เป็นไปตามรูปแบบของ Black
การตั้งค่า Black ถูกกำหนดไว้ในไฟล์ pyproject.toml ของเรา:
[tool.black]
line-length = 88
target-version = ['py310']
include = '\.pyi?$'คุณสามารถติดตั้ง Black ได้โดยใช้ Poetry (แนะนำ) หรือ pip:
Black จะถูกติดตั้งโดยอัตโนมัติเมื่อคุณตั้งค่าสภาพแวดล้อมการพัฒนา:
poetry installถ้าคุณใช้ pip คุณสามารถติดตั้ง Black ได้โดยตรง:
pip install black-
จัดรูปแบบไฟล์ Python ทั้งหมดในโปรเจกต์:
poetry run black . -
จัดรูปแบบไฟล์หรือไดเรกทอรีเฉพาะ:
poetry run black path/to/file_or_directory
-
จัดรูปแบบไฟล์ Python ทั้งหมดในโปรเจกต์:
black . -
จัดรูปแบบไฟล์หรือไดเรกทอรีเฉพาะ:
black path/to/file_or_directory
Tip
เราแนะนำให้ตั้งค่า editor ของคุณให้จัดรูปแบบโค้ดด้วย Black อัตโนมัติเมื่อบันทึกไฟล์ ตัวแก้ไขสมัยใหม่ส่วนใหญ่รองรับฟีเจอร์นี้ผ่านส่วนขยายหรือปลั๊กอิน
เพื่อรัน Co-op Translator โดยใช้ Poetry ในสภาพแวดล้อมของคุณ ให้ทำตามขั้นตอนดังนี้:
-
ไปยังไดเรกทอรีที่คุณต้องการทดสอบการแปล หรือสร้างโฟลเดอร์ชั่วคราวสำหรับการทดสอบ
-
รันคำสั่งต่อไปนี้ โดยเปลี่ยน
-l koเป็นรหัสภาษาที่คุณต้องการแปลเข้าไป ตัวเลือก-dคือโหมดดีบักpoetry run co-op-translator translate -l ko -d
Note
ตรวจสอบให้แน่ใจว่าสภาพแวดล้อม Poetry ของคุณถูกเปิดใช้งาน (poetry shell) ก่อนรันคำสั่งนี้
เรายินดีรับการมีส่วนร่วมที่เพิ่มการรองรับภาษาใหม่ ก่อนเปิด PR โปรดทำตามขั้นตอนด้านล่างเพื่อให้การตรวจสอบเป็นไปอย่างราบรื่น
-
เพิ่มภาษาลงในแมปปิ้งฟอนต์
- แก้ไขไฟล์
src/co_op_translator/fonts/font_language_mappings.yml - เพิ่มรายการโดยระบุ:
code: รหัสภาษาแบบ ISO (เช่นvi)name: ชื่อแสดงที่เข้าใจง่ายfont: ฟอนต์ที่รวมอยู่ในsrc/co_op_translator/fonts/ที่รองรับสคริปต์นั้นrtl:trueถ้าเป็นภาษาที่อ่านจากขวาไปซ้าย มิฉะนั้นfalse
- แก้ไขไฟล์
-
รวมไฟล์ฟอนต์ที่จำเป็น (ถ้ามี)
- หากต้องใช้ฟอนต์ใหม่ ให้ตรวจสอบความเข้ากันได้ของไลเซนส์สำหรับการแจกจ่ายแบบโอเพนซอร์ส
- เพิ่มไฟล์ฟอนต์ลงใน
src/co_op_translator/fonts/
-
ตรวจสอบในเครื่อง
- รันการแปลกับตัวอย่างเล็กๆ (Markdown, รูปภาพ และโน้ตบุ๊กตามความเหมาะสม)
- ตรวจสอบผลลัพธ์ว่ารันได้ถูกต้อง รวมถึงฟอนต์และการจัดวางแบบ RTL หากมี
-
อัปเดตเอกสาร
- ตรวจสอบให้แน่ใจว่าภาษาใหม่ปรากฏใน
getting_started/supported-languages.md - ไม่ต้องแก้ไข
getting_started/README_languages_template.mdเพราะสร้างจากรายการภาษาที่รองรับ
- ตรวจสอบให้แน่ใจว่าภาษาใหม่ปรากฏใน
-
เปิด PR
- อธิบายภาษาที่เพิ่มและข้อควรพิจารณาเรื่องฟอนต์/ไลเซนส์
- แนบภาพหน้าจอของผลลัพธ์ที่แสดงถ้าเป็นไปได้
ตัวอย่างรายการ YAML:
new_lang(code):
name: "New Language"
font: "NotoSans-Medium.ttf"
rtl: falseคุณสามารถทดสอบภาษาใหม่โดยรันคำสั่งนี้:
# สร้างและเปิดใช้งานสภาพแวดล้อมเสมือน
python -m venv .venv
# วินโดวส์
.venv\Scripts\activate
# แมคโอเอส/ลินุกซ์
source .venv/bin/activate
# ติดตั้งแพ็กเกจสำหรับการพัฒนา
pip install -e .
# รันการแปล
translate -l "new_lang"เพื่อให้ประวัติการคอมมิตของโปรเจกต์มีความสม่ำเสมอและชัดเจน เราใช้รูปแบบข้อความคอมมิตเฉพาะ สำหรับข้อความคอมมิตสุดท้าย เมื่อใช้กลยุทธ์ Squash and Merge
เมื่อ pull request (PR) ถูกผสาน คอมมิตแต่ละรายการจะถูกรวมเป็นคอมมิตเดียว ข้อความคอมมิตสุดท้ายควรเป็นไปตามรูปแบบด้านล่างเพื่อรักษาความสะอาดและความสม่ำเสมอของประวัติ
เราใช้รูปแบบข้อความคอมมิตดังนี้:
<type>: <description> (#<หมายเลข PR>)-
type: ระบุประเภทของคอมมิต เราใช้ประเภทดังนี้:
Docs: สำหรับการอัปเดตเอกสารBuild: สำหรับการเปลี่ยนแปลงที่เกี่ยวข้องกับระบบ build หรือ dependencies รวมถึงการอัปเดตไฟล์ config, workflow CI หรือ DockerfileCore: สำหรับการแก้ไขฟังก์ชันหลักหรือฟีเจอร์ของโปรเจกต์ โดยเฉพาะไฟล์ในไดเรกทอรีsrc/co_op_translator/core
-
description: สรุปสั้นๆ ของการเปลี่ยนแปลง
-
PR number: หมายเลข pull request ที่เกี่ยวข้องกับคอมมิตนี้
ตัวอย่าง:
Docs: Update installation instructions for clarity (#50)Core: Improve handling of image translation (#60)
Note
ปัจจุบัน prefix Docs, Core, และ Build จะถูกเพิ่มโดยอัตโนมัติในชื่อ PR ตามป้ายกำกับที่ใช้กับโค้ดที่แก้ไข ตราบใดที่ป้ายกำกับถูกต้อง คุณไม่จำเป็นต้องแก้ไขชื่อ PR ด้วยตนเอง เพียงตรวจสอบให้แน่ใจว่าทุกอย่างถูกต้องและ prefix ถูกสร้างขึ้นอย่างเหมาะสม
เราใช้ Squash and Merge เป็นกลยุทธ์เริ่มต้นสำหรับ pull requests วิธีนี้ช่วยให้ข้อความคอมมิตเป็นไปตามรูปแบบที่กำหนด แม้ว่าคอมมิตย่อยจะไม่เป็นไปตามรูปแบบก็ตาม
เหตุผล:
- ประวัติโปรเจกต์ที่สะอาดและเป็นเส้นตรง
- ความสม่ำเสมอของข้อความคอมมิต
- ลดเสียงรบกวนจากคอมมิตเล็กๆ (เช่น "fix typo")
เมื่อรวมโค้ด ให้แน่ใจว่าข้อความคอมมิตสุดท้ายเป็นไปตามรูปแบบที่อธิบายไว้ข้างต้น
ตัวอย่าง Squash and Merge ถ้า PR มีคอมมิตดังนี้:
fix typoupdate READMEadjust formatting
จะถูกรวมเป็น:
Docs: Improve documentation clarity and formatting (#65)
ส่วนนี้อธิบายวิธีง่ายที่สุดสำหรับผู้ดูแลในการปล่อยเวอร์ชันใหม่ของ Co-op Translator
- ตัดสินใจหมายเลขเวอร์ชันถัดไป (เราใช้ semantic versioning:
MAJOR.MINOR.PATCH) - แก้ไขไฟล์
pyproject.tomlและอัปเดตฟิลด์versionภายใต้[tool.poetry] - เปิด pull request ที่เปลี่ยนแปลงเฉพาะเวอร์ชัน (และไฟล์ lock/metadata ที่อัปเดตอัตโนมัติถ้ามี)
- หลังจากตรวจสอบแล้ว ใช้ Squash and Merge และตรวจสอบให้แน่ใจว่าข้อความคอมมิตสุดท้ายเป็นไปตามรูปแบบที่กำหนด
- ไปที่หน้ารีโป GitHub และเปิด Releases → Draft a new release
- สร้างแท็กใหม่ (เช่น
v0.13.0) จากสาขาmain - ตั้งชื่อ release ให้ตรงกับเวอร์ชัน (เช่น
v0.13.0) - คลิก Generate release notes เพื่อเติม changelog อัตโนมัติ
- แก้ไขข้อความตามต้องการ (เช่น เน้นภาษาที่รองรับใหม่หรือการเปลี่ยนแปลงสำคัญ)
- เผยแพร่ release
ข้อจำกัดความรับผิดชอบ:
เอกสารนี้ได้รับการแปลโดยใช้บริการแปลภาษาอัตโนมัติ Co-op Translator แม้เราจะพยายามให้ความถูกต้องสูงสุด แต่โปรดทราบว่าการแปลอัตโนมัติอาจมีข้อผิดพลาดหรือความไม่ถูกต้อง เอกสารต้นฉบับในภาษาต้นทางถือเป็นแหล่งข้อมูลที่เชื่อถือได้ สำหรับข้อมูลที่สำคัญ ขอแนะนำให้ใช้บริการแปลโดยผู้เชี่ยวชาญมนุษย์ เราไม่รับผิดชอบต่อความเข้าใจผิดหรือการตีความผิดใด ๆ ที่เกิดจากการใช้การแปลนี้