ຖ້າຢາກຮູ້ວິທີການ ແປແອັບມືຖື ໃຫ້ບໍ່ທຳລາຍ UX, ກົດເກນທີ່ສຳຄັນທີ່ສຸດຄື: ຢ່າແປແຕ່ຄຳຄຳດຽວ—ແຕ່ຕ້ອງແປ “ປະສົບການ” ທັງຫມົດຂອງຜູ້ໃຊ້. ການແປແອັບທີ່ດີ ຈະຕ້ອງນຳໃຊ້ບໍລິບົດຂອງໜ້າຈໍ, ຄວາມຍາວຂອງຂໍ້ຄວາມ, ນ້ຳສຽງ (tone) ການສື່ສານ, ຂໍ້ຈຳກັດຂອງ interface ແລະ ຄວາມແຕກຕ່າງຂອງແຕ່ລະພາກພື້ນ/ພາສາ. ຈຶ່ງຈະເປັນ ການໂລແຄຊັນສໍາລັບ UX (localization ສໍາລັບ ux ui) ທີ່ຊ່ວຍໃຫ້ເປັນການເຕີບໂຕຂອງຜະລິດຕະພັນແບບຈິງ—ບໍ່ແມ່ນສ້າງຂໍ້ຜິດພາດ, ຄວາມຫຍຸ້ງຍາກ ແລະ ການແປງຕ່ຳ (conversion).
ເປັນຫຍັງ “ການແປທົ່ວໄປ” ຈຶ່ງບໍ່ພໍໃນແອັບມືຖື?
ໃນແອັບມືຖື, ຂໍ້ຄວາມບໍ່ເຄີຍ “ຢືນຢູ່ໃນຄວາມເປົ່າ”. ທຸກສ່ວນຂອງຂໍ້ຄວາມແມ່ນສ່ວນໜຶ່ງຂອງ interface, ຂັ້ນຕອນ (process), ການຕັດສິນຂອງຜູ້ໃຊ້ ຫຼື ສະຖານະຈຳເພາະຂອງລະບົບ. ດັ່ງນັ້ນການ ແປແບບ interface ຂອງແອັບ ຈຶ່ງບໍ່ເຫມືອນກັບການແປບົດຄວາມ, ອີເມວ ຫຼື ຄຳອະທິບາຍສິນຄ້າ. ໃນແອັບມືຖື ບໍ່ແມ່ນແຕ່ເບິ່ງແຄ່ຄວາມໝາຍ—ແຕ່ລວມເຖິງ ບ່ອນທີ່ຈະສະແດງ, ຄວາມຍາວຂອງປະໂຫຍກ, ບົດບາດຂອງມັນ ແລະ ອາລົມ/ຄວາມຮູ້ສຶກທີ່ຜູ້ໃຊ້ຮັບ.
ຕົວຢ່າງ? ປຸ່ມສັ້ນໆ “Dalej” ຖ້າເປັນພາສາອັງກິດອາດຈະກາຍເປັນ “Continue”, ສ່ວນເຢຍລະມັນ “Weiter”, ແຕ່ໃນບາງບໍລິບົບອາດເໝາະກວ່າ “Next”. ຕົວແປຼດແບບນີ້ບໍ່ໄດ້ທົດແທນກັນໄດ້. ຖ້າໜ້າ onboarding ຕ້ອງການສ້າງຄວາມບາງເບົາ ແລະ ຄວາມງ່າຍດາຍ, ຄຳທີ່ເປັນທາງການເກີນໄປອາດຈະເຮັດໃຫ້ຜູ້ໃຊ້ຮູ້ສຶກຜິດ. ແລະຖ້າປຸ່ມນັ້ນແມ່ນເກີ່ຍກ່ຽວກັບການຢືນຢັນການຊຳລະ, ຂໍ້ຄວາມທົ່ວໄປເກີນໄປກໍອາດຈະທຳໃຫ້ conversion ຫຼຸດລົງແບບແປກໆໄດ້.
ກໍຄືກັນກັບການແປຂໍ້ຄວາມໃນແອັບ. ຂໍ້ຄວາມໃດໆກໍບໍ່ຄວນແຕ່ “ຖືກຕ້ອງດ້ານພາສາ”. ມັນຄວນຈະ:
- ອະທິບາຍບັນຫາໃຫ້ເຂົ້າໃຈຊັດ,
- ແນະນຳວິທີແກ້/ຂັ້ນຕອນຕໍ່ໄປ,
- ເໝາະກັບນ້ຳສຽງຂອງແບຣນ (brand tone),
- ພໍດີກັບ interface (ບໍ່ລົ້ນ ຫຼື ບັງຕາ),
- ເຂົ້າໃຈງ່າຍສຳລັບຜູ້ໃຊ້ໃນແຕ່ລະຕະຫຼາດ.
ແນວນີ້ແຫຼະ ຄືຄວາມແຕກຕ່າງລະຫວ່າງການແປທົ່ວໄປ ແລະ ການໂລແຄຊັນສໍາລັບ UX.
ການໂລແຄຊັນ UX ແມ່ນຫຍັງ ແລະ ຕ່າງຈາກການແປແນວໃດ?
ການໂລແຄຊັນ UX ແມ່ນຂະບວນການປັບເນື້ອຫາ ແລະ ອົງປະກອບຂອງ interface ໃຫ້ເຂົ້າກັບພາສາ, ວັດທະນທຳ, ຄວາມຄາດຫວັງ ແລະ ພຶດຕິກຳຂອງຜູ້ໃຊ້ໃນແຕ່ລະຕະຫຼາດ. ມັນບໍ່ແມ່ນພຽງແຕ່ຄຳສັບ—ແຕ່ລວມເຖິງ “ລອກິກ” ຂອງການສື່ສານ, ຮູບແບບວັນທີ/ເລກ, ໜ່ວຍການວັດ, ລຳດັບຂໍ້ມູນ ແລະ ບາງຄັ້ງຍັງຮວມເຖິງ layout ຂອງອົງປະກອບໃນໜ້າຈໍ.
ດັ່ງນັ້ນການ ໂລແຄຊັນການນຳໃຊ້ແອັບມືຖື ໄປຫາຫຼາຍພາສາ ຄວນວາງແຜນເປັນສ່ວນໜຶ່ງຂອງຂະບວນການພັດທະນາ (product process), ບໍ່ແມ່ນ “ແກ້ກັນທ້າຍສຸດ” ກ່ອນປ່ອຍຕົວ.
ສາມາດສະຫຼຸບແບບງ່າຍໆ:
- ການແປທົ່ວໄປ ເນັ້ນໃສ່ການແປຄວາມໝາຍຂອງຂໍ້ຄວາມ.
- ການໂລແຄຊັນແອັບມືຖື ຄຳນຶງເຖິງວ່າຂໍ້ຄວາມ “ເຮັດວຽກ” ໃຫ້ແອັບຢ່າງໃດໃນຜະລິດຕະພັນ.
- UX localization ກ້າວຕໍ່ໄປອີກນິດ ແລະ ຮັບປະກັນວ່າ ທັງໝົດຂອງ interface ຍັງຄົງ intuitive, ສອດຄ່ອງ ແລະ ມີປະສິດທິພາບ ຫຼັງຈາກປ່ຽນພາສາ.
ສະນັ້ນ ຖ້າທ່ານກຳລັງສົນໃຈ “ຈະແປແອັບມືຖືແນວໃດໃຫ້ຖືກຕ້ອງ?”, ຄຳຕອບກໍຄື: ຕ້ອງແປຕາມ “ບ່ອນທີ່ໃຊ້/ບໍລິບົດ” ຂອງຜູ້ໃຊ້, ບໍ່ແມ່ນແຕ່ເປັນລາຍຊື່ string ຢ່າງດຽວ.
ບັນຫາທີ່ພົບຫຼາຍໃນການແປແອັບມືຖື
ໃນພາກປະຕິບັດ, ຄວາມຜິດພາດສ່ວນໃຫຍ່ບໍ່ແມ່ນມາຈາກຄຸນນະພາບການແປເທົ່ານັ້ນ—ແຕ່ເປັນເພາະຂາດ “ຂະບວນການ”. ນີ້ແຫຼະຄືບັນຫາທີ່ມັກທຳລາຍ UX ຫຼັງຈາກທີ່ມີຫຼາຍຮຸ່ນ/ຫຼາຍພາສາຖືກປ່ອຍອອກໄປ.
1. ຂໍ້ຄວາມຫຼັງແປຍາວເກີນໄປ
ນີ້ແມ່ນບັນຫາຄລາສສິກ. ພາສາແຕ່ລະອັນມີຄວາມຍາວຂອງປະໂຫຍກບໍ່ເທົ່າກັນ. ພາສາອັງກິດມັກຈະສັ້ນກວ່າພາສາກາງ/ພາສາໂພລັອນ, ແຕ່ພາສາເຢຍລະມັນ, ຝຣັ່ງ ຫຼື ລັດເຊຍອາດຈະທຳໃຫ້ label, ຫົວຂໍ້ ແລະ ຂໍ້ຄວາມສື່ສານຍາວຂຶ້ນຢ່າງຊັດເຈນ. ຜົນກໍງ່າຍ: ຂໍ້ຄວາມຖືກຕັດທ້າຍ, ອົງປະກອບຊົນກັນ, layout ສະດຸດ ແລະ ອ່ານຍາກຂຶ້ນ.
ດັ່ງນັ້ນ ການແປ microcopy ຄວນຄຳນຶງເຖິງຂໍ້ຈຳກັດດ້ານຈຳນວນຕົວອັກສອນ (characters) ແລະ ຄວາມສຳຄັນຂອງເນື້ອຫາ. ບາງຄັ້ງ “ການແປທີ່ດີທີ່ສຸດ” ບໍ່ແມ່ນການຕົງຄຳຕາມຄວາມໝາຍເກົ່າຫຼາຍສຸດ—ແຕ່ເປັນສະບັບທີ່ສັ້ນກວ່າ, ອ່ານເຂົ້າໃຈງ່າຍກວ່າ ແລະ ຮັກສາໜ້າທີ່ຂອງເນື້ອຫາເດີມ.
2. ຂາດບໍລິບົດໃຫ້ນັກແປ
String “Save” ສາມາດໝາຍໄດ້ຫຼາຍຢ່າງ: ບັນທຶກການປ່ຽນແປງ, ດຶງເອົາເງິນ, ບັນທຶກທີ່ຢູ່ ຫຼື ການຮັກສາໂພສ. ຖ້າຂາດບໍລິບົດ ຈຶ່ງເລືອກຄວາມໝາຍຜິດງ່າຍ. ກໍຄືກັນກັບຄຳແນວ “Skip”, “Close”, “Done”, “Apply” ຫຼື “Continue”.
ດັ່ງນັ້ນ ການແປ interface ຂອງແອັບ ຄວນອີງຕາມຄຳອະທິບາຍໜ້າຈໍ, ຄຳເຫັນກຳກັບ string ແລະ ທີ່ດີທີ່ສຸດ ຄືການໃຫ້ screenshot ຂອງບໍລິບົດ ຫຼື ລະບົບ key ທີ່ຕັ້ງຊື່ແຈ້ງເຈນ.
3. ນ້ຳສຽງການສື່ສານບໍ່ສອດຄ່ອງ
ໃນບາງສ່ວນຂອງແອັບ ແບຣນເວົ້າກັບຜູ້ໃຊ້ແບບສະບາຍໆ ແຕ່ອີກສ່ວນເວົ້າແບບທາງການ ແລະ ຂໍ້ຄວາມ error ກໍຟັງແບບ technical ແລະ ແຫ້ງ. ນີ້ແມ່ນຜົນທີ່ມັກຈະເກີດຈາກການແປທີ່ບໍ່ມີ voice & tone ທີ່ກຳນົດຊັດ. ໃນຜະລິດຕະພັນມືຖື ຈຸດນີ້ຈະຊັດເຈນຂຶ້ນ ເພາະຜູ້ໃຊ້ອ່ານຂໍ້ຄວາມສັ້ນໆຢ່າງຕັ້ງໃຈ.
ການແປຂໍ້ຄວາມໃນແອັບທີ່ດີ ຕ້ອງຕັດສິນໃຫ້ໄດ້ວ່າຈະໃຫ້ນ້ຳສຽງແນວໃດ: ມືອາຊີບ, ເປັນມິດ, premium, ກາງໆ, ນຳແນວຂອງຜູ້ເຊີຍຊ່ຽວຊານ (expert) ຫຼື ແນວຊ່ອຍເຫຼືອ/สนับสนุนຫຼາຍຂຶ້ນ.
4. ມອງຂ້າມຄວາມແຕກຕ່າງດ້ານພາກພື້ນ (regional variants)
ພາສາສະເປນໃນສະເປນ ແລະ ເມັກຊິໂກ, ພາສາອັງກິດ UK ແລະ US, ພາສາປອກຕຸຍອອງເອີຣົບ ແລະ ບຣາຊິນ—ບໍ່ແມ່ນແຕ່ຄວາມແຕກຕ່າງ “ເປັນຄວາມງາມ” ເທົ່ານັ້ນ. ມັນກະທົບຕໍ່ຄຳສັບ, ສະໄຕລ໌, idiom/ສຳນວນພາສາ, ມາດຕະຖານພາສາ ແລະ ບາງຄັ້ງຍັງກະທົບວິທີເອີ້ນຜູ້ໃຊ້. ການໂລແຄຊັນແອັບຫຼາຍພາສາຄວນນຳໃຊ້ບໍ່ແຕ່ພາສາເທົ່ານັ້ນ—ແຕ່ຕ້ອງຄຳນຶງເຖິງຂອບເຂດ/ຊະນິດພາກພື້ນຂອງພາສານັ້ນດ້ວຍ.
ສຳຄັນເປັນພິເສດໃນ onboarding, ໜ້າຈໍການຊຳລະ, ການແຈ້ງເຕືອນ (notifications) ແລະ ພາກຊ່ວຍເຫຼືອ (help) ເພາະລາຍລະອຽດເຫຼົ່ານີ້ສົ່ງຜົນຕໍ່ຄວາມເຊື່ອໃຈ ແລະ ຄວາມເຂົ້າໃຈ.
5. ບໍ່ມີການທົດສອບຫຼັງເຂົ້າ production
ແມ້ແຕ່ການແປແອັບມືຖືທີ່ດີທີ່ສຸດ ກໍອາດລົ້ມເຫຼວໄດ້ ຖ້າບໍ່ມີໃຜລອງກວດເທິງ interface ໃນຂອງຈິງ. ໃນໄຟລ໌ ທຸກຢ່າງອາດດູດີ, ແຕ່ພໍນຳໄປປະຍຸກໃຊ້ແທ້ໆ ກໍເຫັນວ່າປຸ່ມແຄບເກີນ, ຂໍ້ຄວາມເຂົ້າໄປລົ້ນ modal ຫຼື onboarding ເສຍ “ຈັງຫວະ” ທີ່ຄວນຈະມີ.
ການທົດສອບທີ່ກ່ຽວກັບ localization ຄວນຈະບໍ່ເລັກນ້ອຍກວ່າການທົດສອບຟັງຊັນ (functional tests).
ຈະແປແອັບມືຖືແບບຄົບຂັ້ນຕອນ (step by step) ແນວໃດ?
ດ້ານລຸ່ມນີ້ແມ່ນຂັ້ນຕອນທີ່ນຳໃຊ້ໄດ້ຈິງ ເພື່ອດຳເນີນ localization ສຳລັບແອັບມືຖືໂດຍບໍ່ທຳລາຍ UX.
1. ເລີ່ມຈາກການສຳຫຼວດ (audit) ເນື້ອຫາໃນແອັບ
ຂັ້ນຕອນທຳອິດ ຄື ຈັດລະບົບເນື້ອຫາທັງໝົດ:
- label ຂອງປຸ່ມ,
- ຫົວຂໍ້ໜ້າຈໍ,
- placeholder ແລະ ຟອມ (forms),
- ຂໍ້ຄວາມ error,
- push notifications,
- onboarding,
- tooltip ແລະ ຄຳແນະນຳ,
- ໜ້າສະຖານະ “ບໍ່ມີຂໍ້ມູນ” (empty states),
- ເນື້ອຫາລະບົບ (system) ແລະ ຂໍ້ກຳນົດ/ກົດລະບຽບ (legal).
ຂັ້ນຕອນນີ້ຊ່ວຍໃຫ້ເຫັນວ່າສ່ວນໃດສຳຄັນຕໍ່ UX ແລະການທຸລະກິດ (business) ແລະ ບ່ອນໃດບໍ່ຄວນປະຫຼ່ອຍໂອກາດໃຫ້ການຕັດສິນດ້ານພາສາແບບບໍ່ລະວັງ.
2. ແບ່ງເນື້ອຫາຕາມ “ຫນ້າທີ່” ບໍ່ແມ່ນຕາມ “ໜ້າຈໍ” ແຕ່ຢ່າງດຽວ
ສຳຄັນຫຼາຍ. ການແປ onboarding ຈະບໍ່ເຫມືອນ micro-instructions, ການແປຂໍ້ຄວາມ transacational ຈະຕ່າງ ແລະ error ຍັງຕ່າງອີກ. ແຕ່ລະປະເພດມີເປົ້າໝາຍຂອງຄົນລະແບບ ແລະ ມີຄວາມທົນທໍ່ຄວາມຍາວຂອງຂໍ້ຄວາມບໍ່ເທົ່າກັນ.
ຕົວຢ່າງການແບ່ງ:
- Navigation: ຕ້ອງສັ້ນ ແລະ ຊັດເຈນ.
- Microcopy ທີ່ຊ່ວຍນຳ: ຕ້ອງຫຼຸດຄວາມບໍ່ມັ້ນໃຈ ແລະ ນຳຜູ້ໃຊ້.
- ຂໍ້ຄວາມ error: ຕ້ອງອະທິບາຍ ແລະ ຊ່ວຍໃຫ້ອອກຈາກບັນຫາໄດ້.
- Onboarding: ຕ້ອງສ້າງຄຸນຄ່າຂອງຜະລິດຕະພັນ ແລະ ຊຸກຍູ້ໃຫ້ລອງໃຊ້.
ດ້ວຍການແບ່ງແນວນີ້ ການແປ microcopy ຈະສອດຄ່ອງກວ່າ ແລະ ຊ່ວຍໃຫ້ເປົ້າໝາຍຂອງ product ດີຂຶ້ນ.
3. ກຳນົດສະໄຕລ໌ ແລະ tone ສຳລັບແຕ່ລະພາສາ
ຢ່າຄິດວ່າ tone ດຽວຈະປັບ 1:1 ໄປທຸກຕະຫຼາດໄດ້. ໃນ localization ໜຶ່ງ ສະໄຕລ໌ອາດຈະເບົາກວ່າ ແຕ່ໃນອີກບ່ອນອາດຈະເປັນທາງການກວ່າ. ສິ່ງສຳຄັນຄື ຜູ້ໃຊ້ຄວນຮູ້ສຶກວ່າມີການຊ່ວຍເຫຼືອ, ເປັນມືອາຊີບ, ງ່າຍດາຍ ຫຼື ເອກະລັກ/ພິເສດ (exclusivity).
ໃນຈຸດນີ້ ມີ profile ສຳລັບການແປຊ່ວຍໄດ້. SmartTranslate.ai ສາມາດກຳນົດອຸດສາຫະກຳ, ສະໄຕລ໌ການເວົ້າ, tone, ລະດັບຄວາມເປັນທາງການ ແລະ ລະດັບການປັບເຂົ້າກັບວັດທະນະທຳ. ດັ່ງນັ້ນ ການແປແອັບມືຖືຈະບໍ່ຢຸດຢູ່ທີ່ການແປດິບ—ແຕ່ສະທ້ອນຄຸນລັກສະນະຂອງ product ແທ້ໆ.
4. ໃຫ້ບໍລິບົດກັບແຕ່ລະ string
ຍິ່ງມີບໍລິບົດຫຼາຍ, ກໍຍິ່ງມີໂອກາດຜິດພາດໜ້ອຍ. ຄວນເຮັດດັ່ງນີ້:
- ເພີ່ມຄຳອະທິບາຍວ່າຂໍ້ຄວາມນີ້ເຮັດໜ້າທີ່ຫຍັງ,
- ບອກວ່າຂໍ້ຄວາມຈະປາກົດຢູ່ບ່ອນໃດ,
- ລະບຸຈຳນວນຕົວອັກສອນສູງສຸດ,
- ລະບຸ persona ຫຼື ຂັ້ນຕອນໃນ journey ຂອງຜູ້ໃຊ້,
- ຊີ້ວ່າເນື້ອຫາແມ່ນ error, success, ຄຳແນະນຳ ຫຼື CTA.
ນີ້ສຳຄັນເປັນພິເສດໃນການແປຂໍ້ຄວາມ error ເພາະ ຄຳທີ່ເລືອກຜິດ 1 ຄຳ ສາມາດປ່ຽນຄວາມຮູ້ສຶກຂອງທັງປະຕິສຳພັນໄດ້.
5. ອອກແບບ interface ໂດຍຄຳນຶງເຖິງການຂະຫຍາຍຄວາມຍາວຂອງຂໍ້ຄວາມ
ຖ້າອອກແບບວາງໄວ້ແນ່ນອນແບບອົງປະກອບແຄບເກີນ, ບັນຫາຈະເກີດຂຶ້ນທັນທີຫຼັງເພີ່ມພາສາເພີ່ມ. ຄວນເຜື່ອສະໄລ (margin) ໃຫ້ກັບປະໂຫຍກທີ່ຍາວ, ທົດລອງຫຼາຍຄວາມຍາວ, ຫຼີກລ້ຽງການພິມ “ໃຫ້ພໍດີກັບຂອບ” ແບບພໍດີພໍດີ ແລະ ວາງແຜນ responsive ສຳລັບເນື້ອຫາທີ່ໂລແຄຊັນແລ້ວດ້ວຍ.
ສຳລັບທີມ design, ນີ້ແມ່ນໜຶ່ງໃນກົດເກນຫຼັກຂອງ UX localization: interface ຄວນທົນທານຕໍ່ຄວາມແຕກຕ່າງຂອງພາສາ.
6. ທົດສອບການແປໃນເຄື່ອງຈິງ ບໍ່ແມ່ນແຕ່ໃນໄຟລ໌
ກ່ອນປ່ອຍອອກ ລອງເປີດແອັບໃນທຸກພາສາ ແລະ ຜ່ານເສັ້ນທາງທີ່ສຳຄັນຂອງຜູ້ໃຊ້. ກວດເຊັ່ນ:
- ການລົງທະບຽນ,
- ການເຂົ້າສູ່ລະບົບ,
- reset ລະຫັດຜ່ານ,
- ການຊື້ ຫຼື ການເປີດใช้งານ subscription,
- ການຄົ້ນຫາ,
- ຕັ້ງຄ່າບັນຊີ,
- notifications ແລະ error.
ຂັ້ນຕອນນີ້ແຫຼະ ຈະບອກໄດ້ເລີຍວ່າການແປ interface ສະໜັບຄວາມໃຊ້ງານ (usability) ຫຼື ທຳລາຍມັນ.
ຕ້ອງໃສ່ໃຈເປັນພິເສດຕອນແປ microcopy ບໍ?
ການແປ microcopy ແມ່ນຂົງເຂດທີ່ຍາກທີ່ສຸດໜຶ່ງຂອງ localization ແອັບມືຖື. ເພາະວ່າ ຂໍ້ຄວາມສັ້ນໆມີອິດທິພົນຕໍ່ການຕັດສິນຂອງຜູ້ໃຊ້ແບບຮຸນແຮງ. 1 ຄຳ ສາມາດເພີ່ມຄວາມເຊື່ອໃຈ ຫຼື ສ້າງຄວາມບໍ່ມັ້ນໃຈໄດ້.
microcopy ທີ່ດີໃນແອັບ ຄວນຈະ:
- ສັ້ນ,
- ຊັດເຈນ,
- ຊ່ວຍເຫຼືອ,
- ສອດຄ່ອງກັບແບຣນ,
- ຢູ່ໃນບໍລິບົດການກະທຳ (context) ຂອງຜູ້ໃຊ້.
ຕົວຢ່າງ:
- ຈາກ “Błąd” ແຫ້ງໆ ຄວນປ່ຽນເປັນ “ບັນທຶກການປ່ຽນແປງບໍ່ສຳເລັດ ລອງໃໝ່ອີກຄັ້ງ”.
- ຈາກ “Kontynuuj” ທີ່ບໍ່ແຈ້ງ ບາງຄັ້ງ “ໄປຫາການຊຳລະ” ຈະເໝາະກວ່າ.
- ຈາກ “Wprowadzono nieprawidłowe dane” ທີ່ເປັນທາງການເກີນໄປ ຂໍ້ຄວາມ “ກວດສອບອີເມວ ແລະ ລອງອີກຄັ້ງ” ອາດຈະໃຊ້ງານກວ່າ.
ໃນທາງປະຕິບັດ, ການແປ microcopy ຄວນຮັກສາບໍ່ພຽງແຕ່ຄວາມໝາຍ—ແຕ່ສຳຄັນສຸດຄື ຮັກສາໜ້າທີ່ຂອງມັນ. ນີ້ແຫຼະ ແກນກາງຂອງ UX localization.
Onboarding ແລະ ຂໍ້ຄວາມ error: 2 ພື້ນທີ່ທີ່ຫ້າມແປແບບອັດຕະໂນມັດໂດຍຂາດບໍລິບົດ
Onboarding ເປັນພາກສ່ວນຂາຍຄຸນຄ່າຂອງ product. ນີ້ແມ່ນຈຸດທຳອິດທີ່ຜູ້ໃຊ້ຈະຕັດສິນວ່າ ແອັບນີ້ ຂ້ອຍເຂົ້າໃຈງ່າຍ ແລະ ມີປະໂຫຍດແທ້ບໍ? ຖ້າ onboarding ຫຼັງແປອອກມາແລ້ວດູຕິດຂັດເກີນໄປ, ຍາວເກີນ ຫຼື ບໍ່ສົມຄວນ, ຜູ້ໃຊ້ອາດຈະເສຍແຮງຈູງໃຈກ່ອນຈະເປີດໃຊ້ງານຈິງ.
ສ່ວນການແປຂໍ້ຄວາມໃນແອັບ—ໂດຍສະເພາະ error—ຈະກະທົບໂດຍກົງໃຫ້ຄວາມຫງຸດຫງິດພຸ້ນໄດ້. ຜູ້ໃຊ້ບໍ່ພຽງຕ້ອງຮູ້ວ່າ “ມີບັນຫາ” ແຕ່ຕ້ອງມີຄຳແນະນຳໄວໆວ່າຈາກນີ້ຄວນເຮັດຫຍັງ. ດັ່ງນັ້ນ error message ຄວນຂຽນ ແລະ ແປຕາມໂຄງຮ່າງທີ່ງ່າຍ:
- ເກີດຫຍັງຂຶ້ນ?
- ເປັນໄປໄດ້ແນວໃດ ແລະ ເຫດໃດຈຶ່ງເກີດ?
- ຕອນນີ້ຜູ້ໃຊ້ຄວນເຮັດຫຍັງຕໍ່?
ວິທີນີ້ຈະຫຼຸດຄວາມບໍ່ເຂົ້າໃຈ ແລະ ຊ່ວຍໃຫ້ interface ທັງຊຸດມີປະສິດທິຜົນຂຶ້ນ.
Checklista: localization ແອັບມືຖື ໂດຍບໍ່ທຳລາຍ UX
checklist ຂ້າງລຸ່ມນີ້ ຈະຊ່ວຍໃຫ້ product, design ແລະ development team ດຳເນີນ localization ຫຼາຍພາສາໄດ້ຢ່າງເປັນລະບົບ—ແລະປ້ອງກັນບັນຫາທີ່ມັກເກີດ.
ສຳລັບທີມ product
- ກຳນົດ priority ຂອງຕະຫຼາດ ແລະ ສຳນຽງພາສາພາກພື້ນ.
- ລະບຸເປົ້າໝາຍຂອງ localization: ເພີ່ມ active/activation, retenci, conversion ຫຼື ຫຼຸດຈຳນວນ error.
- ຕັ້ງ tone of voice ສຳລັບແຕ່ລະຕະຫຼາດ.
- ກຽມ glossary ຂອງຄຳສຳຄັນທາງ product.
- ໃຫ້ຊີ້ວ່າເນື້ອຫາສ່ວນໃດສຳຄັນຕໍ່ UX ແລະທຸລະກິດ.
ສຳລັບທີມ design
- ອອກແບບ component ໃຫ້ຮັບມືກັບຂໍ້ຄວາມທີ່ຍາວຂຶ້ນ.
- ຫຼີກລ້ຽງການກຳນົດຄວາມກວ້າງປຸ່ມ/label ແບບຕາຍຕົວ.
- ທົດສອບໜ້າຈໍກັບຕົວແປພາສາທີ່ຍາວກວ່າ.
- ຮັກສາລຳດັບຄວາມສຳຄັນ (information hierarchy) ເຖິງແມ່ນຂໍ້ຄວາມຈະຍາວຫຼາຍ.
- ຄຳນຶງຮູບແບບວັນທີ, ສະກຸນເງິນ ແລະ ເລກຂອງທ້ອງຖິ່ນ.
ສຳລັບທີມ development
- ໃຊ້ localization keys ທີ່ອ່ານງ່າຍ.
- ເພີ່ມ comment ສຳລັບ string.
- ຮອງຮັບ pluralization ແລະ dynamic variables.
- ທົດສອບ line breaking, overflow ແລະ truncation.
- ດຳເນີນ QA ກ່ຽວກັບ localization ກ່ອນປ່ອຍ.
ສຳລັບທີມທັງໝົດ
- ຢ່າແປໂດຍຂາດບໍລິບົດ.
- ຢ່າສົມມຸດວ່າ 1 ພາສາ = 1 ຕະຫຼາດ.
- ຢ່າ copy tone ຂອງຕົ້ນສະບັບ 1:1 ໂດຍບໍ່ປັບ.
- ອັບເດດ glossary ແລະ ກົດລະບຽບສະໄຕລ໌ເປັນປົກກະຕິ.
- ເກັບກຳ feedback ຈາກຜູ້ໃຊ້ໃນຕະຫຼາດຈິງ.
ຈະທົດສອບການແປແອັບມືຖືກ່ອນປ່ອຍແນວໃດ?
ການທົດສອບຄວນລວມຫຼາຍລະດັບ. ການ proofread ພາສາຢ່າງດຽວບໍ່ພໍ.
- QA ດ້ານພາສາ: ຖືກຕ້ອງ, ຟັງສະໜາມ, ສອດຄ່ອງກັບຄຳສັບ.
- QA ດ້ານພາບ/visual: ຄວາມຍາວຂອງຂໍ້ຄວາມ, line breaking, ອົງປະກອບຊົນກັນ.
- QA ດ້ານຟັງຊັນ: dynamic variables ແລະ ຮູບແບບຈັດຮູບ (format) ເຮັດວຽກຖືກຕ້ອງ.
- QA ດ້ານບໍລິບົດ (contextual): ຂໍ້ຄວາມເໝາະກັບຂັ້ນຕອນໃນ journey ຂອງຜູ້ໃຊ້ບໍ?
- ທົດສອບກັບຜູ້ໃຊ້: ເຖິງຈະເຮັດແຕ່ສອງສາມ session ສັ້ນໆໃນຕະຫຼາດນັ້ນກໍໄດ້ insight ທີ່ມີຄ່າ.
ຄວນສ້າງລາຍຊື່ໜ້າຈໍ ແລະ ສະຖານະທີ່ສຳຄັນ (critical scenarios) ແລະ ທົດທຸກຄັ້ງຫຼັງຈາກ update ໃຫຍ່. ນີ້ສຳຄັນເປັນພິເສດ ເມື່ອແອັບກຳລັງເຕີບໄວ ແລະ ມີຟັງຊັນໃໝ່ເພີ່ມ.
SmartTranslate.ai ຊ່ວຍໄດ້ແນວໃດ?
ເມື່ອ scale product ຂຶ້ນ, ຄວາມທ້າທາຍບໍ່ແມ່ນແຕ່ “ການແປແອັບມືຖື” ເທົ່ານັ້ນ—ແຕ່ຍັງຕ້ອງຮັກສາຄວາມສອດຄ່ອງລະຫວ່າງຕະຫຼາດ, ຮຸ່ນພາສາ ແລະ ປະເພດຂໍ້ຄວາມ. ທີ່ນີ້ແຫຼະຄວາມໝາຍຂອງ tool ທີ່ເຂົ້າໃຈ context ແລະ ຊ່ວຍໃຫ້ເຮັດວຽກຜ່ານ translation profiles ແທນທີ່ຈະເຮັດແບບແປໂດຍບໍ່ມີລະບົບ.
SmartTranslate.ai ສະໜັບການ localization ສຳລັບແອັບມືຖື ໂດຍປັບແປໃຫ້ເໝາະກັບອຸດສາຫະກຳ, ສະໄຕລ໌ການເວົ້າ, tone, ລະດັບຄວາມເປັນທາງການ ແລະ ລະດັບການປັບເຂົ້າກັບວັດທະນະທຳ. ເປັນເລື່ອງສຳຄັນເມື່ອ product ຕ້ອງສື່ສານແຕກຕ່າງກັນ: onboarding ແບບໜຶ່ງ, ໜ້າຈໍການຊຳລະອີກແບບ, ແລະ ພາກ help ອີກແບບ.
ຈຸດເດັ່ນອີກຢ່າງ ຄື ຮອງຮັບຫຼາຍພາສາ ແລະສຳນຽງພາກພື້ນ, ເຊິ່ງເປັນປັດໄຈສຳຄັນໃນການຂະຫຍາຍໄປຕະຫຼາດທີ່ຕ້ອງການການຈັບຄູ່ໃຫ້ລະອຽດ ເຊັ່ນ en-us ແລະ en-gb ຫຼື es-es ແລະ es-mx. SmartTranslate.ai ຍັງຮອງຮັບການແປຂໍ້ຄວາມ ແລະ ເອກະສານ ໂດຍຮັກສາຮູບແບບ (formatting) ເພື່ອຊ່ວຍງານຢູ່ໃນໄຟລ໌ທີ່ສົ່ງອອກຈາກ product systems, ເອກະສານ UX writing documentation ຫຼື ລາຍຊື່ string.
ສະນັ້ນ ຖ້າມີໃຜພິມຄຳຄ້າຍກັບ SmartTranslate ຈະແປແອັບມືຖືແນວໃດ ຫຼື SmartTranslate localization ແອັບມືຖື, ຄຳຕອບກໍງ່າຍ: ຄວນເລີ່ມຈາກການຈັດລະບົບບໍລິບົດ, ກຽມ translation profiles ແລະ ທົດສອບໃນ interface ຕົວຈິງ. ເພາະແບບນີ້ແຫຼະ ຈຶ່ງເກີດຜົນທີ່ບໍ່ທຳລາຍ UX.
ສະຫຼຸບ
ການແປແອັບມືຖືທີ່ດີ ແມ່ນຂະບວນການອອກແບບ (process) ບໍ່ແມ່ນພາກສ່ວນດ້ານພາສາແບບດຽວ. ຖ້າທ່ານຢາກເຂົ້າສູ່ຕະຫຼາດໃໝ່ໂດຍບໍ່ເສຍຄຸນນະພາບປະສົບການຜູ້ໃຊ້, ຕ້ອງຄິດເລື່ອງ localization ແຕ່ຕົ້ນ: ຈາກ audit ເນື້ອຫາ, tone of voice, ການອອກແບບ component ທີ່ທົນທານ ໄປຈົນເຖິງການທົດສອບໃນແອັບທີ່ໃຊ້ງານໄດ້ຈິງ.
ການ localization ແອັບມືຖື ໄປຫາຫຼາຍພາສາ ຈະດີທີ່ສຸດ ເມື່ອ product, design, development ແລະ ທີມທີ່ຮັບຜິດຊອບເນື້ອຫາ ຮ່ວມມືກັນຕັ້ງແຕ່ຕົ້ນ. ດັ່ງນັ້ນ ການແປ interface ບໍ່ແມ່ນພາກເພີ່ມໃນທ້າຍ roadmap—ແຕ່ເປັນສ່ວນຂອງ product ທີ່ຊ່ວຍຂະຫຍາຍໂຕ, ສ້າງຄວາມເຊື່ອໃຈ ແລະ ເຮັດໃຫ້ຜູ້ໃຊ້ໃຊ້ງານໄດ້ສະດວກແທ້.
FAQ
ຈະແປແອັບມືຖືແນວໃດ ໃຫ້ຂໍ້ຄວາມບໍ່ທຳລາຍ layout?
ຕ້ອງອອກແບບ interface ໃຫ້ມີຊ່ອງເຜື່ອສຳລັບປະໂຫຍກທີ່ຍາວ, ກຳນົດຂອບເຂດດ້ານຈຳນວນຕົວອັກສອນ ແລະ ທົດສອບການແປໃນເຄື່ອງຈິງ. ການແປແບບຢ່າງດຽວໂດຍບໍ່ຄວບຄຸມຄວາມຍາວຂອງຂໍ້ຄວາມ ມັກນຳໄປສູ່ບັນຫາດ້ານ UX.
ການແປແອັບມືຖື ຕ່າງຈາກ app localization meaning ຫຼື localization ແອັບມືຖືແນວໃດ?
ການແປເນັ້ນໃສ່ການຖ່າຍຄວາມໝາຍ, ແຕ່ app localization ຕ້ອງຄຳນຶງບໍລິບົດການໃຊ້, tone ຂອງແບຣນ, ຄວາມແຕກຕ່າງດ້ານວັດທະນະທຳ, ຮູບແບບຂອງທ້ອງຖິ່ນ ແລະ ພຶດຕິກຳຂອງ interface ຫຼັງຈາກປ່ຽນພາສາ.
ເປັນຫຍັງ microcopy ຈຶ່ງສຳຄັນຫຼາຍ?
ເພາະວ່າ microcopy ມີຜົນຕໍ່ການຕັດສິນຂອງຜູ້ໃຊ້ໂດຍກົງ. ຂໍ້ຄວາມສັ້ນໆຢູ່ປຸ່ມ, ໃນຟອມ ຫຼື error ຈະນຳຜູ້ໃຊ້ຜ່ານແອັບ ດັ່ງນັ້ນມັນຕ້ອງຊັດເຈນ, ຟັງສະໜາມ ແລະ ເໝາະກັບສະຖານະຈິງ.
ມີ tool ອັນໃດທີ່ຊ່ວຍໃຫ້ການ localization ແອັບຫຼາຍພາສາງ່າຍຂຶ້ນ?
ມີ tool ທີ່ຮອງຮັບບໍລິບົດ (context), ສະໄຕລ໌ ແລະ ສຳນຽງພາກພື້ນ ແລະ ສາມາດແປໄດ້ທັງໄຟລ໌ ແລະ ຂໍ້ຄວາມລາຍບຸກຄົນ. ໃນຮູບແບບນີ້ SmartTranslate.ai ເໝາະຫຼາຍ ເພາະຖ້າທ່ານຕ້ອງການຄວາມສອດຄ່ອງຂອງການສື່ສານ product ໃນຫຼາຍຕະຫຼາດ.