API ເອກະສານແປພາສາອັງກິດເປັນປອກຕຸຍການ | ຮັກສາໂຄງຮ່າງ | ຄູ່ມື

ຄວາມສັບສົນທີ່ເຊື່ອງໄວ້ຂອງການແປເອກະສານຜ່ານ API

ການລວມເອົາ API ແປເອກະສານພາສາອັງກິດເປັນປອກຕຸຍການເຂົ້າໃນແອັບພລິເຄຊັນຂອງທ່ານອາດຈະເບິ່ງຄືວ່າງ່າຍດາຍໃນຕອນທຳອິດ. ແນວໃດກໍ່ຕາມ, ຜູ້ພັດທະນາຈະພົບກັບອຸປະສັກດ້ານເຕັກນິກທີ່ສໍາຄັນຢ່າງວ່ອງໄວ ເຊິ່ງເກີນກວ່າການປ່ຽນແທນສາຍຕົວອັກສອນຂໍ້ຄວາມທໍາມະດາ.
ສິ່ງທ້າທາຍເຫຼົ່ານີ້ສາມາດທຳລາຍຄວາມສົມບູນຂອງເອກະສານ, ປະສົບການຂອງຜູ້ໃຊ້, ແລະ ຄວາມສໍາເລັດໂດຍລວມຂອງໂຄງການທ້ອງຖິ່ນຂອງທ່ານ ຖ້າບໍ່ໄດ້ຈັດການໂດຍບໍລິການສະເພາະ.

ຄວາມຫຍຸ້ງຍາກຫຼັກແມ່ນຢູ່ໃນໂຄງສ້າງທີ່ຊັບຊ້ອນຂອງຮູບແບບເອກະສານທີ່ທັນສະໄໝ. ໄຟລ໌ເຊັ່ນ DOCX, PDF, ແລະ PPTX ບໍ່ແມ່ນພຽງແຕ່ບ່ອນບັນຈຸຂໍ້ຄວາມເທົ່ານັ້ນ; ພວກມັນບັນຈຸຂໍ້ມູນໂຄງຮ່າງທີ່ລະອຽດ, ຮູບພາບທີ່ຝັງໄວ້, ຕາຕະລາງ, ແລະຮູບແບບຕົວອັກສອນສະເພາະ.
ວິທີການແປແບບບໍ່ມີຄວາມຄິດທີ່ສະກັດເອົາຂໍ້ຄວາມແລະໃສ່ຄືນໃໝ່ ເກືອບແນ່ນອນຈະທຳລາຍໂຄງສ້າງທາງດ້ານຮູບພາບ, ເຮັດໃຫ້ເອກະສານບໍ່ເປັນມືອາຊີບ ແລະ ມັກຈະໃຊ້ບໍ່ໄດ້.
ຂະບວນການນີ້ຮຽກຮ້ອງໃຫ້ມີເຄື່ອງຈັກທີ່ຊັບຊ້ອນທີ່ສາມາດແຍກວິເຄາະ, ແປ, ແລະ ສ້າງໂຄງສ້າງຮູບແບບເດີມຂອງເອກະສານຄືນໃໝ່ໄດ້ຢ່າງສົມບູນ.

ຮູບແບບໄຟລ໌ ແລະ ການຮັກສາໂຄງຮ່າງ

ໜຶ່ງໃນສິ່ງທ້າທາຍທີ່ສໍາຄັນທີ່ສຸດແມ່ນການຮັກສາໂຄງຮ່າງ ແລະ ຮູບແບບເດີມຂອງເອກະສານ. ຮູບແບບຕ່າງໆ ເຊັ່ນ PDF ແມ່ນຍາກທີ່ຈະຈັດການ, ດ້ວຍການໄຫຼວຽນຂອງຂໍ້ຄວາມ, ຕາຕະລາງ, ແລະ ຮູບພາບ vector ທີ່ຖືກຈັດຕໍາແໜ່ງດ້ວຍການປະສານງານແບບຢ່າງແທ້ຈິງ.
ເມື່ອແປຈາກພາສາອັງກິດເປັນປອກຕຸຍການ, ຄວາມຍາວຂອງປະໂຫຍກມັກຈະປ່ຽນແປງຢ່າງຫຼວງຫຼາຍ, ເຊິ່ງສາມາດເຮັດໃຫ້ຂໍ້ຄວາມລົ້ນຂອບເຂດທີ່ກໍານົດໄວ້.
API ທີ່ເຂັ້ມແຂງຕ້ອງຈັດຂໍ້ຄວາມຄືນໃໝ່ຢ່າງສະຫຼາດ, ປັບຂະໜາດພາຊະນະ, ແລະ ປັບໄລຍະຫ່າງເພື່ອຮອງຮັບຄວາມແຕກຕ່າງດ້ານພາສາ ໂດຍບໍ່ທໍາລາຍຄວາມຊື່ສັດທາງດ້ານຮູບພາບຂອງໄຟລ໌ຕົ້ນສະບັບ.

ຍິ່ງໄປກວ່ານັ້ນ, ອົງປະກອບຕ່າງໆເຊັ່ນ: ຫົວຂໍ້, ທ້າຍຂໍ້ຄວາມ, ຕາຕະລາງ, ແລະ ກ່ອງຂໍ້ຄວາມ ຕ້ອງຖືກລະບຸ ແລະ ເນື້ອໃນຂອງພວກມັນຕ້ອງຖືກແປຕາມບໍລິບົດ. ການແປພຽງແຕ່ເນື້ອໃນຫຼັກຂອງຂໍ້ຄວາມແມ່ນບໍ່ພຽງພໍສໍາລັບການສ້າງເອກະສານທີ່ຖືກຈັດທ້ອງຖິ່ນແບບມືອາຊີບ.
API ຕ້ອງແຍກວິເຄາະຮູບແບບວັດຖຸເອກະສານທັງໝົດ, ແປອົງປະກອບຂໍ້ຄວາມແຕ່ລະອັນ, ແລະ ຈາກນັ້ນປະກອບໄຟລ໌ຄືນໃໝ່ຢ່າງສົມບູນ.
ນີ້ຮັບປະກັນວ່າເອກະສານປອກຕຸຍການສຸດທ້າຍແມ່ນກະຈົກແທ້ຂອງແຫຼ່ງພາສາອັງກິດ, ບໍ່ພຽງແຕ່ໃນເນື້ອໃນເທົ່ານັ້ນ ແຕ່ໃນການນໍາສະເໜີແບບມືອາຊີບ.

ການເຂົ້າລະຫັດຕົວອັກສອນ ແລະ ຕົວອັກສອນພິເສດ

ການຈັດການການເຂົ້າລະຫັດຕົວອັກສອນຢ່າງຖືກຕ້ອງແມ່ນອີກດ້ານໜຶ່ງທີ່ສຳຄັນ, ໂດຍສະເພາະສຳລັບພາສາເຊັ່ນ ປອກຕຸຍການ. ພາສາປອກຕຸຍການໃຊ້ເຄື່ອງໝາຍ diacritics ແລະ ຕົວອັກສອນພິເສດຕ່າງໆ, ເຊັ່ນ: cedilla (ç) ແລະ ສະຫຼະທີ່ມີສຽງສູງຕ່າງໆ (á, â, à, ã, é, ê, í, ó, ô, õ, ú).
ຖ້າ API ຫຼື ລະຫັດການເຊື່ອມໂຍງຂອງທ່ານຈັດການການເຂົ້າລະຫັດຕົວອັກສອນບໍ່ຖືກຕ້ອງ, ທ່ານຈະຈົບລົງດ້ວຍຂໍ້ຄວາມທີ່ເສຍຫາຍຢ່າງຫຼີກລ່ຽງບໍ່ໄດ້, ເຊິ່ງມັກຈະຖືກສະແດງເປັນ mojibake (ເຊັ່ນ: ຮູບສີ່ຫຼ່ຽມເພັດສີດໍາທີ່ມີເຄື່ອງໝາຍຄໍາຖາມ).
ອັນນີ້ບໍ່ພຽງແຕ່ເຮັດໃຫ້ເອກະສານອ່ານບໍ່ໄດ້ເທົ່ານັ້ນ ແຕ່ຍັງທໍາລາຍຄວາມເຊື່ອຖືຂອງແອັບພລິເຄຊັນຂອງທ່ານ ແລະ ຄຸນນະພາບຂອງການແປທີ່ຮັບຮູ້ຢ່າງຮ້າຍແຮງ.

API ການແປທີ່ເຊື່ອຖືໄດ້ຕ້ອງຈັດການການແປງການເຂົ້າລະຫັດທັງໝົດໂດຍທຳມະຊາດ, ໂດຍທົ່ວໄປແມ່ນການນໍາມາດຕະຖານ UTF-8 ຕະຫຼອດຂະບວນການ. ມັນຕ້ອງສາມາດອ່ານໄຟລ໌ແຫຼ່ງໄດ້ໂດຍບໍ່ຄໍານຶງເຖິງການເຂົ້າລະຫັດເບື້ອງຕົ້ນຂອງມັນ, ປະມວນຜົນເນື້ອໃນຢ່າງຖືກຕ້ອງ, ແລະ ສົ່ງອອກໄຟລ໌ທີ່ຖືກແປດ້ວຍການເຂົ້າລະຫັດທີ່ຖືກຕ້ອງສໍາລັບຕົວອັກສອນປອກຕຸຍການທັງໝົດ.
ຜູ້ພັດທະນາບໍ່ຄວນຕ້ອງເປັນຫ່ວງກ່ຽວກັບ character sets ແລະ byte order marks.
API ຄວນສະຫຼຸບຄວາມສັບສົນນີ້ອອກໄປ, ໃຫ້ປະສົບການທີ່ລຽບງ່າຍຈາກການອັບໂຫລດໄຟລ໌ໄປຫາການດາວໂຫຼດທີ່ຖືກແປ.

ຄວາມສາມາດໃນການຂະຫຍາຍ ແລະ ການປະມວນຜົນແບບ Asynchronous

ການແປເອກະສານແມ່ນວຽກງານທີ່ໃຊ້ຊັບພະຍາກອນຫຼາຍ ເຊິ່ງບໍ່ສາມາດສໍາເລັດໄດ້ພາຍໃນຂໍ້ຈໍາກັດດ້ານເວລາຂອງການຮ້ອງຂໍ HTTP ແບບ synchronous ມາດຕະຖານ. ການແປ PDF ທີ່ມີຫຼາຍໜ້າ, ຊັບຊ້ອນ ສາມາດໃຊ້ເວລາຫຼາຍວິນາທີ ຫຼື ແມ້ກະທັ້ງນາທີ, ເຊິ່ງເປັນເວລາດົນເກີນໄປສຳລັບລູກຄ້າທີ່ຈະລໍຖ້າການຕອບສະໜອງ.
ການພະຍາຍາມຈັດການນີ້ແບບ synchronously ຈະນໍາໄປສູ່ການໝົດເວລາຂອງການຮ້ອງຂໍ, ຜູ້ໃຊ້ທີ່ບໍ່ພໍໃຈ, ແລະ ການເຊື່ອມໂຍງທີ່ບໍ່ຫນ້າເຊື່ອຖື.
ໂຄງສ້າງທີ່ສາມາດຂະຫຍາຍໄດ້ຮຽກຮ້ອງໃຫ້ມີຮູບແບບການປະມວນຜົນແບບ asynchronous ເພື່ອຈັດການວຽກງານທີ່ໃຊ້ເວລາດົນເຫຼົ່ານີ້ຢ່າງມີປະສິດທິພາບ ແລະ ເຊື່ອຖືໄດ້.

ວິທີການແບບ asynchronous ນີ້ໂດຍທົ່ວໄປແມ່ນກ່ຽວຂ້ອງກັບຂະບວນການເຮັດວຽກຫຼາຍຂັ້ນຕອນ. ຜູ້ພັດທະນາອັບໂຫລດເອກະສານກ່ອນ, ແລະ API ຈະສົ່ງຄືນຕົວລະບຸວຽກ ຫຼື ເອກະສານທັນທີ.
ຈາກນັ້ນ, ຜູ້ພັດທະນາສາມາດໃຊ້ຕົວລະບຸນີ້ເພື່ອສອບຖາມຈຸດສິ້ນສຸດສະຖານະເປັນໄລຍະ ຫຼື, ໃນລະບົບທີ່ກ້າວໜ້າກວ່າ, ໄດ້ຮັບການແຈ້ງເຕືອນ webhook ເມື່ອການແປສຳເລັດ.
ອັນນີ້ໄດ້ແຍກການຮ້ອງຂໍເບື້ອງຕົ້ນອອກຈາກຜົນໄດ້ຮັບສຸດທ້າຍ, ສ້າງລະບົບທີ່ບໍ່ມີການຂັດຂວາງ ເຊິ່ງມີຄວາມຢືດຢຸ່ນ ແລະ ສາມາດຂະຫຍາຍໄດ້ຫຼາຍຂຶ້ນສຳລັບການຈັດການການປະມວນຜົນເປັນຊຸດ ຫຼື ໄຟລ໌ຂະໜາດໃຫຍ່.

ແນະນຳ Doctranslate API ສຳລັບການແປທີ່ລຽບງ່າຍ

Doctranslate API ແມ່ນບໍລິການ RESTful ທີ່ຖືກອອກແບບສະເພາະເພື່ອແກ້ໄຂສິ່ງທ້າທາຍທີ່ຊັບຊ້ອນເຫຼົ່ານີ້, ໃຫ້ຜູ້ພັດທະນາມີເຄື່ອງມືທີ່ມີປະສິດທິພາບສໍາລັບການລວມເອົາ API ແປເອກະສານພາສາອັງກິດເປັນປອກຕຸຍການ. ມັນສະຫຼຸບຄວາມຫຍຸ້ງຍາກໃນການແຍກວິເຄາະໄຟລ໌, ການຮັກສາໂຄງຮ່າງ, ແລະ ການປະມວນຜົນແບບ asynchronous ອອກໄປ, ເຮັດໃຫ້ທ່ານສາມາດສຸມໃສ່ເຫດຜົນຫຼັກຂອງແອັບພລິເຄຊັນຂອງທ່ານ.
ດ້ວຍຊຸດຈຸດສິ້ນສຸດທີ່ງ່າຍດາຍ ແຕ່ເຂັ້ມແຂງ, ທ່ານສາມາດອັດຕະໂນມັດຂະບວນການເຮັດວຽກການຈັດທ້ອງຖິ່ນເອກະສານທັງໝົດຂອງທ່ານດ້ວຍຄວາມພະຍາຍາມໜ້ອຍທີ່ສຸດ.
ສໍາລັບຜູ້ພັດທະນາທີ່ຊອກຫາວິທີແກ້ໄຂທີ່ສົມບູນແບບ, ທ່ານສາມາດ ບັນລຸການແປເອກະສານທີ່ບໍ່ມີຂໍ້ຜິດພາດ ໃນຂະນະທີ່ຮັກສາຮູບແບບເດີມ ໂດຍໃຊ້ແພລດຟອມທີ່ມີປະສິດທິພາບຂອງ Doctranslate.

API ຂອງພວກເຮົາຖືກສ້າງຂຶ້ນບົນພື້ນຖານຂອງຫຼັກການສໍາຄັນຫຼາຍຢ່າງທີ່ຖືກອອກແບບມາສໍາລັບປະສິດທິພາບຂອງຜູ້ພັດທະນາ ແລະ ຄວາມຫນ້າເຊື່ອຖືລະດັບວິສາຫະກິດ. ພວກເຮົາສະເໜີ ການຮອງຮັບຮູບແບບໄຟລ໌ຢ່າງກວ້າງຂວາງ, ລວມທັງຮູບແບບທີ່ຊັບຊ້ອນເຊັ່ນ DOCX, PDF, PPTX, XLSX, ແລະ ອື່ນໆ, ຮັບປະກັນວ່າທ່ານສາມາດຈັດການເອກະສານໃດໆທີ່ຜູ້ໃຊ້ຂອງທ່ານສະໜອງໃຫ້.
ຫຼັກຂອງບໍລິການຂອງພວກເຮົາແມ່ນ ເຄື່ອງຈັກຮັກສາໂຄງຮ່າງທີ່ທັນສະໄໝ ທີ່ຮັບປະກັນວ່າເອກະສານປອກຕຸຍການທີ່ຖືກແປແມ່ນຄືກັນກັບແຫຼ່ງພາສາອັງກິດຢ່າງເຫັນໄດ້ຊັດ.
ທັງໝົດນີ້ແມ່ນຖືກສົ່ງຜ່ານ ໂຄງສ້າງແບບ asynchronous ຢ່າງຄົບຖ້ວນ ທີ່ໃຫ້ການຕອບສະໜອງ JSON ສໍາລັບການເຊື່ອມໂຍງໄດ້ງ່າຍ ແລະ ສາມາດຂະຫຍາຍໄດ້ເພື່ອຕອບສະໜອງຄວາມຕ້ອງການໃດໆ.

ຄູ່ມືຂັ້ນຕອນຕໍ່ຂັ້ນຕອນໃນການລວມເອົາ API ແປເອກະສານພາສາອັງກິດເປັນປອກຕຸຍການ

ຄູ່ມືນີ້ໃຫ້ການເດີນທາງຕົວຈິງຂອງການແປເອກະສານຈາກພາສາອັງກິດເປັນປອກຕຸຍການໂດຍໃຊ້ Doctranslate API. ພວກເຮົາຈະກວມເອົາຂະບວນການທັງໝົດ, ຕັ້ງແຕ່ການກວດສອບຄວາມຖືກຕ້ອງ ແລະ ການອັບໂຫລດໄຟລ໌ ຈົນເຖິງການກວດສອບສະຖານະການແປ ແລະ ການດາວໂຫລດຜົນໄດ້ຮັບສຸດທ້າຍ.
ການປະຕິບັດຕາມຂັ້ນຕອນເຫຼົ່ານີ້ຈະຊ່ວຍໃຫ້ທ່ານສ້າງຄຸນສົມບັດການແປເອກະສານທີ່ເຂັ້ມແຂງ ແລະ ອັດຕະໂນມັດພາຍໃນແອັບພລິເຄຊັນຂອງທ່ານ.
ຂະບວນການຖືກອອກແບບໃຫ້ມີເຫດຜົນ ແລະ ກົງໄປກົງມາສຳລັບຜູ້ພັດທະນາຄົນໃດກໍ່ຕາມທີ່ຄຸ້ນເຄີຍກັບການບໍລິໂພກ REST APIs.

ຂັ້ນຕອນທີ 1: ການກວດສອບຄວາມຖືກຕ້ອງ ແລະ ການຕັ້ງຄ່າ

ກ່ອນທີ່ຈະໂທຫາ API ໃດໆ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ຮັບຄີ API ສະເພາະຂອງທ່ານ. ທ່ານສາມາດຊອກຫາຄີນີ້ໄດ້ໃນແຜງຄວບຄຸມຜູ້ພັດທະນາ Doctranslate ຂອງທ່ານ ຫຼັງຈາກລົງທະບຽນສໍາລັບບັນຊີ.
ຄີນີ້ແມ່ນຂໍ້ມູນປະຈໍາຕົວຂອງທ່ານສໍາລັບການເຂົ້າເຖິງ API ແລະຕ້ອງຖືກລວມຢູ່ໃນສ່ວນຫົວຂອງທຸກໆການຮ້ອງຂໍທີ່ທ່ານເຮັດ.
ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຮັກສາຄີນີ້ເປັນຄວາມລັບ ແລະ ປອດໄພ, ປະຕິບັດຕໍ່ມັນຄືກັບລະຫັດຜ່ານອື່ນໆ ຫຼື ຂໍ້ມູນປະຈໍາຕົວທີ່ລະອຽດອ່ອນໃນລະບົບຂອງທ່ານ.

ການກວດສອບຄວາມຖືກຕ້ອງແມ່ນຈັດການຜ່ານສ່ວນຫົວ HTTP ແບບກຳນົດເອງ: X-API-Key. ທ່ານຈະຕ້ອງຜ່ານຄີ API ຂອງທ່ານໃນສ່ວນຫົວນີ້ສໍາລັບທຸກໆການຮ້ອງຂໍໄປຫາຈຸດສິ້ນສຸດທີ່ຖືກປົກປ້ອງ.
ການບໍ່ສະໜອງຄີທີ່ຖືກຕ້ອງຈະເຮັດໃຫ້ເກີດການຕອບສະໜອງຂໍ້ຜິດພາດ 401 Unauthorized ຈາກເຊີບເວີ.
ພວກເຮົາແນະນໍາໃຫ້ເກັບຮັກສາຄີ API ຂອງທ່ານໄວ້ໃນຕົວແປສະພາບແວດລ້ອມທີ່ປອດໄພ ຫຼື ບໍລິການຈັດການຄວາມລັບ ແທນທີ່ຈະໃສ່ລະຫັດມັນໂດຍກົງເຂົ້າໃນລະຫັດແຫຼ່ງຂອງແອັບພລິເຄຊັນຂອງທ່ານ.

ຂັ້ນຕອນທີ 2: ການອັບໂຫຼດເອກະສານຂອງທ່ານສຳລັບການແປ

ຂັ້ນຕອນທໍາອິດໃນຂະບວນການເຮັດວຽກການແປແມ່ນການອັບໂຫລດເອກະສານແຫຼ່ງຂອງທ່ານໄປທີ່ Doctranslate API. ອັນນີ້ແມ່ນເຮັດໂດຍການສົ່ງຄໍາຮ້ອງຂໍ POST ໄປຫາຈຸດສິ້ນສຸດ /v3/documents.
ການຮ້ອງຂໍຕ້ອງຖືກຈັດຮູບແບບເປັນ multipart/form-data ແລະລວມເອົາໄຟລ໌ນັ້ນເອງ ພ້ອມກັບພາລາມິເຕີທີ່ລະບຸພາສາແຫຼ່ງ ແລະ ພາສາເປົ້າໝາຍ.
ໃນກໍລະນີຂອງພວກເຮົາ, ພາສາແຫຼ່ງແມ່ນພາສາອັງກິດ (en) ແລະ ພາສາເປົ້າໝາຍແມ່ນປອກຕຸຍການ (pt).

ຊ່ອງຂໍ້ມູນແບບຟອມທີ່ຈໍາເປັນແມ່ນ file, source_lang, ແລະ target_lang. API ຈະປະມວນຜົນການອັບໂຫລດ ແລະ, ເມື່ອສໍາເລັດ, ຕອບສະຫນອງດ້ວຍວັດຖຸ JSON ທີ່ມີ document_id ທີ່ເປັນເອກະລັກ.
ID ນີ້ແມ່ນຄີໃນການຈັດການເອກະສານສະເພາະນີ້ຕະຫຼອດວົງຈອນຊີວິດການແປທີ່ເຫຼືອຂອງມັນ.
ທ່ານຕ້ອງເກັບຮັກສາ document_id ນີ້ ເພາະວ່າທ່ານຈະຕ້ອງການມັນສໍາລັບຂັ້ນຕອນຕໍ່ໄປຂອງການເລີ່ມຕົ້ນການແປ ແລະ ການກວດສອບສະຖານະຂອງມັນ.

ຂັ້ນຕອນທີ 3: ການເລີ່ມຕົ້ນວຽກງານການແປ

ເມື່ອເອກະສານຂອງທ່ານຖືກອັບໂຫລດສຳເລັດແລ້ວ, ທ່ານມີ document_id. ແນວໃດກໍ່ຕາມ, ຂະບວນການແປບໍ່ໄດ້ເລີ່ມຕົ້ນໂດຍອັດຕະໂນມັດ.
ທ່ານຕ້ອງກະຕຸ້ນມັນຢ່າງຊັດເຈນໂດຍການສົ່ງຄໍາຮ້ອງຂໍ POST ໄປຫາຈຸດສິ້ນສຸດ /v3/documents/{document_id}/translate, ແທນທີ່ {document_id} ດ້ວຍ ID ທີ່ທ່ານໄດ້ຮັບໃນຂັ້ນຕອນກ່ອນໜ້າ.
ການອອກແບບນີ້ໃຫ້ທ່ານມີການຄວບຄຸມຫຼາຍຂຶ້ນຕໍ່ກັບຂະບວນການເຮັດວຽກຂອງທ່ານ, ຊ່ວຍໃຫ້ທ່ານສາມາດອັບໂຫລດເອກະສານເປັນຊຸດກ່ອນທີ່ຈະຕັດສິນໃຈວ່າຈະເລີ່ມຕົ້ນວຽກງານການແປເມື່ອໃດ.

ຈຸດສິ້ນສຸດນີ້ບໍ່ຮຽກຮ້ອງໃຫ້ມີເນື້ອໃນການຮ້ອງຂໍ; document ID ໃນ URL ແມ່ນພຽງພໍທີ່ຈະລະບຸວຽກງານ. API ຈະຕອບສະຫນອງດ້ວຍຂໍ້ຄວາມຢືນຢັນ, ແລະສະຖານະການແປຈະປ່ຽນເປັນ processing.
ການແປຕົວຈິງເກີດຂຶ້ນແບບ asynchronously ໃນພື້ນຫຼັງ, ເຮັດໃຫ້ແອັບພລິເຄຊັນຂອງທ່ານສາມາດດໍາເນີນການກັບວຽກງານອື່ນໆໄດ້ໂດຍບໍ່ຕ້ອງລໍຖ້າ.
ການດໍາເນີນງານທີ່ບໍ່ມີການຂັດຂວາງນີ້ແມ່ນສໍາຄັນສໍາລັບການສ້າງແອັບພລິເຄຊັນທີ່ຕອບສະໜອງໄດ້ ແລະ ສາມາດຂະຫຍາຍໄດ້.

ຂັ້ນຕອນທີ 4: ການກວດສອບສະຖານະ ແລະ ການດາວໂຫຼດຜົນໄດ້ຮັບ

ເນື່ອງຈາກວ່າຂະບວນການແປແມ່ນແບບ asynchronous, ທ່ານຈໍາເປັນຕ້ອງມີວິທີການກວດສອບຄວາມຄືບໜ້າຂອງມັນ. ທ່ານສາມາດເຮັດໄດ້ໂດຍການສອບຖາມຈຸດສິ້ນສຸດສະຖານະດ້ວຍການຮ້ອງຂໍ GET ໄປຫາ /v3/documents/{document_id}.
ການຕອບສະໜອງ JSON ຈາກຈຸດສິ້ນສຸດນີ້ຈະລວມມີຊ່ອງຂໍ້ມູນ status, ເຊິ່ງຈະຊີ້ບອກສະຖານະປັດຈຸບັນຂອງວຽກງານ, ເຊັ່ນ: uploaded, processing, ຫຼື done.
ທ່ານຄວນຈັດຕັ້ງປະຕິບັດກົນໄກການສອບຖາມໃນແອັບພລິເຄຊັນຂອງທ່ານທີ່ກວດສອບຈຸດສິ້ນສຸດນີ້ເປັນໄລຍະຈົນກ່ວາສະຖານະກາຍເປັນ done.

ເມື່ອສະຖານະແມ່ນ done, ເອກະສານທີ່ຖືກແປແມ່ນພ້ອມສໍາລັບການດາວໂຫລດ. ເພື່ອດຶງເອົາມັນ, ທ່ານສົ່ງການຮ້ອງຂໍ GET ສຸດທ້າຍໄປຫາຈຸດສິ້ນສຸດການດາວໂຫຼດ: /v3/documents/{document_id}/download.
API ຈະຕອບສະໜອງດ້ວຍສະຕຣີມໄຟລ໌ binary ຂອງເອກະສານປອກຕຸຍການທີ່ຖືກແປ, ຮັກສາຊື່ໄຟລ໌ຕົ້ນສະບັບ.
ແອັບພລິເຄຊັນຂອງທ່ານຄວນຖືກຕັ້ງຄ່າເພື່ອຈັດການສະຕຣີມໄຟລ໌ນີ້, ບໍ່ວ່າຈະໂດຍການບັນທຶກມັນໄວ້ໃນແຜ່ນ ຫຼື ສົ່ງຕໍ່ໃຫ້ຜູ້ໃຊ້ສຸດທ້າຍ.

ຕົວຢ່າງລະຫັດ Python ທີ່ສົມບູນ

ນີ້ແມ່ນສະຄຣິບ Python ທີ່ສົມບູນທີ່ສະແດງໃຫ້ເຫັນຂະບວນການເຮັດວຽກທັງໝົດໂດຍໃຊ້ຫ້ອງສະໝຸດ requests ທີ່ນິຍົມ. ຕົວຢ່າງນີ້ກວມເອົາການອັບໂຫລດໄຟລ໌, ການເລີ່ມຕົ້ນການແປ, ການສອບຖາມສໍາລັບການສໍາເລັດ, ແລະ ການດາວໂຫລດຜົນໄດ້ຮັບສຸດທ້າຍ.
ຢ່າລືມປ່ຽນແທນ 'YOUR_API_KEY' ແລະ 'path/to/your/document.docx' ດ້ວຍຄີ API ຕົວຈິງ ແລະ ເສັ້ນທາງໄຟລ໌ຂອງທ່ານ.
ລະຫັດນີ້ສະໜອງແມ່ແບບຕົວຈິງທີ່ທ່ານສາມາດປັບຕົວ ແລະ ລວມເຂົ້າໃນໂຄງການຂອງທ່ານໂດຍກົງ.

import requests
import time
import os

# Configuration
API_KEY = os.getenv('DOCTRANSLATE_API_KEY', 'YOUR_API_KEY')
BASE_URL = 'https://developer.doctranslate.io/v3'
FILE_PATH = 'path/to/your/document.docx' # e.g., './english_report.docx'
SOURCE_LANG = 'en'
TARGET_LANG = 'pt'

headers = {
    'X-API-Key': API_KEY
}

def upload_document():
    """Uploads the document to the API."""
    print(f"Uploading {os.path.basename(FILE_PATH)}...")
    with open(FILE_PATH, 'rb') as f:
        files = {'file': (os.path.basename(FILE_PATH), f)}
        data = {'source_lang': SOURCE_LANG, 'target_lang': TARGET_LANG}
        response = requests.post(f"{BASE_URL}/documents", headers=headers, files=files, data=data)
        response.raise_for_status() # Raises an exception for bad status codes
        document_id = response.json().get('document_id')
        print(f"Document uploaded successfully. ID: {document_id}")
        return document_id

def start_translation(document_id):
    """Starts the translation process for the given document ID."""
    print(f"Starting translation for document {document_id}...")
    url = f"{BASE_URL}/documents/{document_id}/translate"
    response = requests.post(url, headers=headers)
    response.raise_for_status()
    print("Translation job initiated.")

def poll_translation_status(document_id):
    """Polls the API until the translation is complete."""
    print("Polling for translation status...")
    url = f"{BASE_URL}/documents/{document_id}"
    while True:
        response = requests.get(url, headers=headers)
        response.raise_for_status()
        status = response.json().get('status')
        print(f"Current status: {status}")
        if status == 'done':
            print("Translation complete!")
            break
        elif status == 'error':
            raise Exception("Translation failed with an error.")
        time.sleep(5) # Wait for 5 seconds before polling again

def download_translated_document(document_id):
    """Downloads the final translated document."""
    print(f"Downloading translated document for ID: {document_id}")
    url = f"{BASE_URL}/documents/{document_id}/download"
    response = requests.get(url, headers=headers, stream=True)
    response.raise_for_status()

    # Construct a new filename for the translated document
    original_filename = os.path.basename(FILE_PATH)
    name, ext = os.path.splitext(original_filename)
    translated_filename = f"{name}_{TARGET_LANG}{ext}"

    with open(translated_filename, 'wb') as f:
        for chunk in response.iter_content(chunk_size=8192):
            f.write(chunk)
    print(f"Translated document saved as {translated_filename}")

if __name__ == '__main__':
    if API_KEY == 'YOUR_API_KEY':
        print("Please set your API key.")
    elif not os.path.exists(FILE_PATH):
        print(f"File not found at {FILE_PATH}")
    else:
        try:
            doc_id = upload_document()
            start_translation(doc_id)
            poll_translation_status(doc_id)
            download_translated_document(doc_id)
        except requests.exceptions.HTTPError as e:
            print(f"An HTTP error occurred: {e.response.status_code} {e.response.text}")
        except Exception as e:
            print(f"An error occurred: {e}")


ຂໍ້ພິຈາລະນາສຳຄັນສຳລັບການແປພາສາປອກຕຸຍການ
ໃນຂະນະທີ່ API ທີ່ມີປະສິດທິພາບຈັດການກັບວຽກງານດ້ານເຕັກນິກ, ຜູ້ພັດທະນາຄວນຮູ້ເຖິງຄວາມແຕກຕ່າງດ້ານພາສາບາງຢ່າງຂອງພາສາປອກຕຸຍການເພື່ອຮັບປະກັນຜົນຜະລິດທີ່ມີຄຸນນະພາບສູງສຸດ. ຂໍ້ພິຈາລະນາເຫຼົ່ານີ້ສາມາດຊ່ວຍໃນການກໍານົດຄວາມຄາດຫວັງຂອງຜູ້ໃຊ້ ແລະ ໃນການປະຕິບັດການຮັບປະກັນຄຸນນະພາບຂອງເອກະສານທີ່ຖືກແປ.
 ຄວາມເຂົ້າໃຈລາຍລະອຽດເຫຼົ່ານີ້ຊ່ວຍເຊື່ອມຕໍ່ຊ່ອງຫວ່າງລະຫວ່າງການແປທີ່ຖືກຕ້ອງທາງດ້ານເຕັກນິກ ແລະ ການແປທີ່ສອດຄ່ອງກັບວັດທະນະທໍາ.
 ຄວາມຮູ້ນີ້ຍົກລະດັບແອັບພລິເຄຊັນຂອງທ່ານຈາກເຄື່ອງມືງ່າຍດາຍໄປສູ່ການແກ້ໄຂທີ່ຊັບຊ້ອນ.
ຄຳວ່າ ‘ເຈົ້າ’ ແບບທາງການ ແລະ ບໍ່ເປັນທາງການ (Tu ທຽບກັບ Você)
ພາສາປອກຕຸຍການມີຄຳສັບທີ່ແຕກຕ່າງກັນສຳລັບ ‘ເຈົ້າ’, ເຊິ່ງສາມາດບົ່ງບອກເຖິງລະດັບຄວາມເປັນທາງການທີ່ແຕກຕ່າງກັນ ແລະ ປ່ຽນແປງໄປຕາມພາກພື້ນ. ໃນປະເທດບຣາຊິນ, ‘você’ ຖືກໃຊ້ຢ່າງກວ້າງຂວາງສຳລັບທັງບໍລິບົດທີ່ເປັນທາງການ ແລະ ບໍ່ເປັນທາງການ, ໃນຂະນະທີ່ ‘tu’ ຖືກໃຊ້ໃນບາງພາກພື້ນສະເພາະ.
 ໃນປະເທດປອກຕຸຍການ, ‘tu’ ແມ່ນຄຳສັບທົ່ວໄປທີ່ບໍ່ເປັນທາງການ, ແລະ ‘você’ ແມ່ນສະຫງວນໄວ້ສໍາລັບສະຖານະການທີ່ເປັນທາງການຫຼາຍຂຶ້ນ.
 ໃນຂະນະທີ່ເຄື່ອງຈັກແປພາສາທີ່ທັນສະໄໝນັບມື້ນັບຮູ້ເຖິງບໍລິບົດ, ສໍານຽງຂອງຂໍ້ຄວາມພາສາອັງກິດແຫຼ່ງຂອງທ່ານສາມາດມີອິດທິພົນຕໍ່ຮູບແບບໃດທີ່ຖືກເລືອກ, ສົ່ງຜົນກະທົບຕໍ່ວິທີການທີ່ຜູ້ເວົ້າພາສາເດີມຮັບຮູ້ເອກະສານສຸດທ້າຍ.
ຄຳນາມ ແລະ ຄຳຄຸນນາມທີ່ມີເພດ
ເຊັ່ນດຽວກັນກັບພາສາ Romance ອື່ນໆ, ພາສາປອກຕຸຍການມີເພດໄວຍາກອນສໍາລັບຄໍານາມ, ຊຶ່ງຫມາຍຄວາມວ່າຄໍານາມຖືກຈັດປະເພດເປັນເພດຊາຍ ຫຼື ເພດຍິງ. ອັນນີ້ສົ່ງຜົນກະທົບຕໍ່ຄໍານໍາໜ້າ (o/a) ແລະ ຄຳຄຸນນາມທີ່ປັບປຸງພວກມັນ, ເຊິ່ງຕ້ອງເຫັນດີໃນເພດ ແລະ ຈຳນວນ.
 ປະໂຫຍກພາສາອັງກິດເຊັ່ນ “The new system is fast” ຮຽກຮ້ອງໃຫ້ຜູ້ແປຮູ້ເພດຂອງ “system” (o sistema, ເພດຊາຍ) ເພື່ອສ້າງ “O novo sistema é rápido” ຢ່າງຖືກຕ້ອງ.
 The Doctranslate API is trained on vast datasets to handle these grammatical rules correctly, but it’s a key area to check during quality control, especially for user-facing marketing or technical materials.
ການຈັດການກັບສໍານວນ
ສໍານວນແມ່ນສິ່ງທ້າທາຍທົ່ວໄປໃນໂຄງການແປໃດໆ. ປະໂຫຍກເຊັ່ນ “it’s raining cats and dogs” ບໍ່ສາມາດຖືກແປຕາມຕົວອັກສອນເປັນພາສາປອກຕຸຍການໂດຍບໍ່ເຮັດໃຫ້ເກີດຄວາມສັບສົນ.
 ເຄື່ອງຈັກແປທີ່ມີຄຸນນະພາບສູງຕ້ອງຮັບຮູ້ລັກສະນະສໍານວນຂອງປະໂຫຍກ ແລະ ທົດແທນມັນດ້ວຍສໍານວນປອກຕຸຍການທີ່ທຽບເທົ່າ, ເຊັ່ນ “está chovendo canivetes” (ມັນກຳລັງຝົນຕົກມີດພັບ).
 ໃນຂະນະທີ່ຕົວແບບພື້ນຖານຂອງ API ຂອງພວກເຮົາແມ່ນມີຄວາມຊໍານິຊໍານານໃນການເຮັດສິ່ງນີ້, ຜູ້ພັດທະນາທີ່ລວມເອົາການແປສຳລັບເນື້ອໃນທີ່ສ້າງສັນ ຫຼື ການຕະຫຼາດຄວນລະມັດລະວັງພາສາສໍານວນທີ່ໜັກແໜ້ນ ແລະ ພິຈາລະນາຂັ້ນຕອນການທົບທວນຂອງມະນຸດສໍາລັບເອກະສານທີ່ສໍາຄັນ.
ບົດສະຫຼຸບ ແລະ ຂັ້ນຕອນຕໍ່ໄປ
ການລວມເອົາ API ແປເອກະສານພາສາອັງກິດເປັນປອກຕຸຍການທີ່ມີຄຸນນະພາບສູງແມ່ນເປັນຂັ້ນຕອນການປ່ຽນແປງສໍາລັບແອັບພລິເຄຊັນໃດໆທີ່ຊອກຫາເພື່ອຂະຫຍາຍການເຂົ້າເຖິງຂອງມັນ. ໃນຂະນະທີ່ວຽກງານດັ່ງກ່າວເຕັມໄປດ້ວຍສິ່ງທ້າທາຍດ້ານເຕັກນິກ ເຊັ່ນ: ການຮັກສາໂຄງຮ່າງ ແລະ ການປະມວນຜົນແບບ asynchronous, the Doctranslate API ໃຫ້ວິທີແກ້ໄຂທີ່ເຂັ້ມແຂງ ແລະ ເປັນມິດກັບຜູ້ພັດທະນາ.
 ໂດຍການສະຫຼຸບຄວາມສັບສົນນີ້, ມັນຊ່ວຍໃຫ້ທ່ານສາມາດຈັດຕັ້ງປະຕິບັດຄຸນສົມບັດການຈັດທ້ອງຖິ່ນທີ່ມີປະສິດທິພາບຢ່າງວ່ອງໄວ ແລະ ເຊື່ອຖືໄດ້.
 ຄູ່ມືນີ້ໄດ້ພາທ່ານຜ່ານຂະບວນການລວມເອົາທັງໝົດ, ຕັ້ງແຕ່ຄວາມເຂົ້າໃຈບັນຫາຫຼັກໄປສູ່ການຈັດຕັ້ງປະຕິບັດຂະບວນການເຮັດວຽກທີ່ສົມບູນດ້ວຍຕົວຢ່າງລະຫັດຕົວຈິງ.
ຕອນນີ້ທ່ານມີຄວາມຮູ້ໃນການອັດຕະໂນມັດການແປເອກະສານຂອງທ່ານ, ຮັກສາຮູບແບບທີ່ສໍາຄັນ ແລະ ຈັດການຄວາມແຕກຕ່າງທາງດ້ານພາສາຂອງປອກຕຸຍການ. ພວກເຮົາຊຸກຍູ້ໃຫ້ທ່ານສໍາຫຼວດ API ຕື່ມອີກ ແລະ ເບິ່ງວ່າມັນສາມາດປັບປຸງຄວາມພະຍາຍາມໃນການສາກົນຂອງທ່ານໄດ້ແນວໃດ.
 ຂັ້ນຕອນຕໍ່ໄປແມ່ນເພື່ອເອົາຄີ API ຂອງທ່ານ ແລະ ເລີ່ມຕົ້ນການສ້າງ.
 ສໍາລັບກໍລະນີການນໍາໃຊ້ທີ່ກ້າວຫນ້າກວ່າ, ເອກະສານອ້າງອີງຈຸດສິ້ນສຸດລາຍລະອຽດ, ແລະ ຂໍ້ມູນເພີ່ມເຕີມ, ກະລຸນາເບິ່ງເອກະສານ API ຢ່າງເປັນທາງການຂອງພວກເຮົາ.