បើអ្នកចង់ដឹងពីរបៀប បកប្រែកម្មវិធីទូរស័ព្ទ ដោយមិនធ្វើឲ្យ UX ខូច និយមន័យសំខាន់បំផុតគឺ៖ មិនមែនគ្រាន់តែបកប្រែ “ពាក្យ” ទេ តែបកប្រែ “បទពិសោធន៍” ទាំងមូលរបស់អ្នកប្រើ។ ការបកប្រែកម្មវិធីទូរស័ព្ទល្អ ត្រូវគិតពីបរិបទនៃអេក្រង់ ប្រវែងអត្ថបទ សម្លេងការទំនាក់ទំនង កម្រិតដែល interface អាចបង្ហាញបាន និងភាពខុសគ្នាតាមតំបន់។ ទើបបន្ទាប់ពីនោះ app localization ពិតៗ នឹងជួយគាំទ្រការលូតលាស់ផលិតផល ជាជាងបង្កឲ្យកើតកំហុស ធ្វើឲ្យអ្នកប្រើខកចិត្ត និងបន្ថយ conversion។
ហេតុអ្វីការបកប្រែធម្មតា មិនគ្រប់គ្រាន់សម្រាប់កម្មវិធីទូរស័ព្ទ?
នៅក្នុងកម្មវិធីទូរស័ព្ទ អត្ថបទមិនដែលដំណើរការដោយឯករាជ្យទេ។ រាល់សេចក្តីសរសេរ គឺជាផ្នែកមួយនៃ interface ដំណើរការ ដំណាក់កាលអ្នកប្រើធ្វើការសម្រេចចិត្ត ឬស្ថានភាពជាក់លាក់របស់ប្រព័ន្ធ។ ដូច្នេះ ការបកប្រែអេក្រង់កម្មវិធី មិនដូចការបកប្រែអត្ថបទទូទៅ ឬការបកប្រែអត្ថបទក្នុងអ៊ីមែល និងការពិពណ៌នាផលិតផលទេ។ នៅក្នុងកម្មវិធី អ្នកត្រូវគិតមិនត្រឹមតែ “អត្ថន័យ” ប៉ុណ្ណោះទេ តែថែមទាំងគិតថាវាត្រូវបង្ហាញនៅទីណា ប្រវែងឃ្លា តួនាទីរបស់វា និងរបៀបដែលវាបង្កអារម្មណ៍ចំពោះអ្នកប្រើ។
ឧទាហរណ៍? ប៊ូតុងខ្លី “Dalej” ជាភាសាអង់គ្លេសអាចក្លាយជា “Continue” ជាភាសាអាល្លឺម៉ង់ “Weiter” ហើយនៅបរិបទផ្សេង ក៏អាចសមជាងនឹង “Next”។ ពាក្យទាំងនេះមិនអាចយកមកជំនួសគ្នាដោយផ្ទាល់បានទេ។ ប្រសិនបើអេក្រង់ onboarding ត្រូវបង្កើតអារម្មណ៍ស្រាល និងងាយយល់ ពាក្យដែលផ្លូវការពេក អាចធ្វើឲ្យអ្នកប្រើមានអារម្មណ៍មិនស្រួល។ ហើយប្រសិនបើប៊ូតុងនោះទាក់ទងនឹងការបញ្ចប់ការទូទាត់ ការផ្តល់សេចក្តីជូនដំណឹងដែលទូទៅពេក អាចធ្វើឲ្យ conversion ធ្លាក់ចុះទៀត។
ការបកប្រែសារក្នុងកម្មវិធី ក៏ត្រូវគិតដូចគ្នា។ សារ error មិនអាច “ត្រឹមត្រូវតាមភាសា” តែប៉ុណ្ណោះបានទេ។ វាត្រូវតែមាន៖
- ពន្យល់ឲ្យច្បាស់ថាបញ្ហាគឺអ្វី
- ណែនាំដំណោះស្រាយ
- ស្របតាមសម្លេងម៉ាក (tone of voice) របស់អ្នក
- សមនឹងកន្លែងបង្ហាញក្នុង interface
- ងាយយល់សម្រាប់អ្នកប្រើនៅទីផ្សារនោះ
នៅទីនេះហើយ ដែលអ្នកនឹងឃើញភាពខុសគ្នារវាង “ការបកប្រែធម្មតា” និង “localization UX”។
localization UX ជាអ្វី ហើយខុសពីការបកប្រែដូចម្តេច?
localization UX គឺជាដំណើរការនៃការកែសម្រួលមាតិកា និងធាតុផ្សេងៗក្នុង interface ឲ្យសមទៅនឹងភាសា វប្បធម៌ ក្តីរំពឹង និងរបៀបសកម្មភាពរបស់អ្នកប្រើនៅទីផ្សារជាក់លាក់។ វាមិនត្រឹមតែពាក់ព័ន្ធនឹងពាក្យប៉ុណ្ណោះទេ តែពាក់ព័ន្ធនឹងរបៀបដែលសារ (communication) ដំណើរការ ទម្រង់កាលបរិច្ឆេទ និងលេខ ប្រភេទឯកតាវាស់ លំដាប់នៃព័ត៌មាន និងពេលខ្លះ រួមទាំង layout នៃធាតុនៅលើអេក្រង់ផងដែរ។
ដូច្នេះ localization កម្មវិធីទូរស័ព្ទទៅជាច្រើនភាសា គួរត្រូវរៀបចំជាផ្នែកមួយនៃដំណើរការផលិតផល (product process) មិនមែនជាជំហានចុងក្រោយ “ធ្វើឲ្យរួចលឿនៗ” មុនថ្ងៃចេញផ្សាយនោះទេ។
ភាពខុសគ្នាអាចសង្ខេបបានដូចនេះ៖
- ការបកប្រែធម្មតា ផ្តោតទៅលើការបកប្រែអត្ថន័យនៃអត្ថបទ
- app localization គិតពីរបៀបដែលអត្ថបទ “ដំណើរការ” នៅក្នុងផលិតផល
- localization UX ឈានបន្តទៀត ដោយធានាថា interface នៅតែមានភាព intuitive ស្របគ្នា និងប្រសិទ្ធភាព បន្ទាប់ពីប្តូរភាសា
ដូច្នេះ បើអ្នកកំពុងសួរថា “របៀបបកប្រែកម្មវិធីទូរស័ព្ទឲ្យត្រឹមត្រូវ” ត្រូវឆ្លើយថា៖ ត្រូវគិតពីបរិបទនៃការប្រើប្រាស់ មិនមែនគ្រាន់តែបញ្ជី string ទេ។
បញ្ហាទូទៅៗពេលបកប្រែកម្មវិធីទូរស័ព្ទ
ក្នុងការអនុវត្ត ភាគច្រើននៃកំហុស មិនមែនមកពីគុណភាពបកប្រែផ្ទាល់ទេ ប៉ុន្តែមកពីការខ្វះដំណើរការ (process)។ ខាងក្រោមនេះជាបញ្ហាដែលធ្វើឲ្យ UX ឈឺចាប់ជាញឹកញាប់ បន្ទាប់ពីដាក់បន្ថែមកំណែភាសាច្រើនៗ។
1. អត្ថបទបន្ទាប់ពីបកប្រែវែងពេក
នេះជាបញ្ហាដ៏បុរាណ។ ភាសានីមួយៗមានភាពខុសគ្នានៃប្រវែងឃ្លា។ ភាសាអង់គ្លេសភាគច្រើនខ្លីជាង ប៉ុន្តែភាសាអាល្លឺម៉ង់ បារាំង ឬរុស្ស៊ី អាចធ្វើឲ្យស្លាក (label) ចំណងជើង និងសារកាន់តែវែងយ៉ាងច្បាស់។ លទ្ធផលក៏ឆាប់ឃើញដូចគ្នា៖ អត្ថបទត្រូវកាត់ (cut) ធាតុត្រូវបិទគ្នា (overlap) layout ខូច និងការអានកាន់តែពិបាក។
ដូច្នេះ ការបកប្រែ microcopy គួរគិតពីចំនួនតួអក្សរ និងអាទិភាពនៃមាតិកា។ ជួនកាល “បកប្រែឲ្យខ្លី តែរក្សាតួនាទីដដែល” មានតម្លៃជាង “បកប្រែឲ្យត្រង់ (literal)” តាមពាក្យ។
2. ខ្វះបរិបទឲ្យអ្នកបកប្រែ
ពាក្យ string “Save” អាចមានន័យជា “រក្សាទុកការផ្លាស់ប្តូរ” “រក្សាទុកអាសយដ្ឋាន” ឬ “រក្សាទុក/ដកប្រាក់” ឬ “រក្សាបង្ហោះ (post) ដដែល”។ បើគ្មានបរិបទ វាងាយក្នុងការជ្រើសខុស។ ដូចគ្នាចំពោះពាក្យប្រភេទ “Skip”, “Close”, “Done”, “Apply” ឬ “Continue”។
ដូច្នេះ ការបកប្រែ interface កម្មវិធីគួរតែផ្អែកលើការពិពណ៌នាពីអេក្រង់ កំណត់ចំណាំ (comments) សម្រាប់ string ហើយល្អបំផុត គឺមានរូបភាពបង្ហាញបរិបទ (context screenshots) ឬប្រើ system key ដែលមានឈ្មោះច្បាស់លាស់។
3. សម្លេង (tone) នៃការទំនាក់ទំនងមិនស្របគ្នា
នៅផ្នែកមួយនៃកម្មវិធី ម៉ាកនិយាយទៅកាន់អ្នកប្រើដោយរបៀបស្រាលៗ ខណៈផ្នែកមួយទៀតនិយាយដោយទម្រង់ផ្លូវការ។ ហើយសារ error ក៏ស្តាប់ទៅដូចជាព័ត៌មានបច្ចេកទេស និងស្ងួត។ នេះជាផលប៉ះពាល់ដែលកើតពីការបកប្រែដោយគ្មានការកំណត់ voice & tone ឲ្យច្បាស់។ នៅក្នុងផលិតផលលើទូរស័ព្ទ ភាពខុសគ្នានេះលេចចេញច្បាស់ ព្រោះអ្នកប្រើអានសារខ្លីៗដោយយកចិត្តទុកដាក់ខ្លាំង។
ការបកប្រែសារក្នុងកម្មវិធីឲ្យល្អ ត្រូវការការសម្រេចចិត្តថាសម្លេងណាដែលត្រូវប្រើ៖ ប្រកបដោយវិជ្ជាជីវៈ (professional) មិត្តភាព (friendly) មានអារម្មណ៍ premium ស្ងៀម (neutral) សម្រាប់អ្នកជំនាញ (experts) ឬគ្រាន់តែជួយណែនាំ (supportive) ច្រើនជាង។
4. មិនយកចិត្តទុកដាក់លើភាពខុសគ្នាតាមតំបន់
ភាសាអេស្ប៉ាញនៅប្រទេសអេស្ប៉ាញ និងនៅម៉ិកស៊ិក ភាសាអង់គ្លេសនៅចក្រភពអង់គ្លេស និងអាមេរិក ភាសាព័រទុយហ្គាល់នៅអឺរ៉ុប និងប្រេស៊ីល — មិនមែនជាភាពខុសគ្នាតូចៗសម្រាប់ការតុបតែងទេ។ វាពាក់ព័ន្ធនឹងពាក្យសព្ទ ស្ទីល អត្តន័យឃ្លា (idioms) ការអនុវត្តតាមស្តង់ដារភាសា និងពេលខ្លះ របៀបដែលត្រូវហៅអ្នកប្រើ។ localization កម្មវិធីទៅជាច្រើនភាសា គួរតែគិតមិនត្រឹមតែភាសាទូទៅទេ ប៉ុន្តែគិតអំពី “variant” តាមតំបន់ផងដែរ។
ចំណុចនេះសំខាន់ជាពិសេសនៅលើ onboarding អេក្រង់ទូទាត់ ការជូនដំណឹង (notifications) និងផ្នែកជំនួយ (help) ព្រោះ nuance ទាំងនេះប៉ះពាល់ដល់ទំនុកចិត្ត និងភាពងាយយល់របស់អ្នកប្រើ។
5. ខ្វះការធ្វើតេស្ត បន្ទាប់ពីដាក់ចូល (implementation)
ទោះបីបកប្រែបានល្អបំផុតក៏ដោយ វាអាចបរាជ័យបាន ប្រសិនបើគ្មានអ្នកណាតេស្តវានៅក្នុង interface ពិត។ នៅឯកសារអ្វីៗមើលទៅត្រឹមត្រូវ ប៉ុន្តែពេលដាក់បញ្ចូល (implement) ប្រហែលជា ប៊ូតុងតូចពេក សារចេញក្រៅ modal ហើយ onboarding បាត់ចង្វាក់ (rhythm) ទៅវិញ។
ការធ្វើតេស្ត localization គួរតែជាភារកិច្ចស្រដៀងនឹងការធ្វើតេស្តមុខងារ (functional tests)។
តើធ្វើដូចម្តេចដើម្បីបកប្រែកម្មវិធីទូរស័ព្ទជាជំហានៗ?
ខាងក្រោមនេះជាដំណើរការដែលមានប្រយោជន៍ និងជួយធ្វើ localization កម្មវិធីទូរស័ព្ទ ដោយមិនធ្វើឲ្យ UX ខូច។
1. ចាប់ផ្តើមពីការត្រួតពិនិត្យ (audit) មាតិកាក្នុងកម្មវិធី
ដំបូងបង្អស់ សូមរៀបរាប់/ចងក្រងប្រភេទមាតិកាទាំងអស់៖
- label នៅជាប់ប៊ូតុង
- ចំណងជើងអេក្រង់
- placeholder និង form
- សារកំហុស
- push notifications
- onboarding
- tooltip និងការណែនាំ
- អេក្រង់ “empty states”
- មាតិកាប្រព័ន្ធ និងផ្នែកច្បាប់
ជំហាននេះអនុញ្ញាតឲ្យអ្នកមើលឃើញថា ផ្នែកណាដែលសំខាន់ខ្លាំងសម្រាប់ UX និងអាជីវកម្ម ហើយកន្លែងដែលអ្នកមិនអាចធ្វើការសម្រេចចិត្តបកប្រែដោយចៃដន្យបាន។
2. បែងចែកមាតិកាតាមមុខងារ មិនមែនតាមអេក្រង់តែប៉ុណ្ណោះ
ចំណុចនេះសំខាន់ណាស់។ Onboarding ត្រូវបកប្រែខុស Micro-instructions ខុស Transmaction messages ខុស ហើយកំហុសក៏ខុសដែរ។ រាល់ប្រភេទមានគោលបំណងផ្សេងគ្នា និងកម្រិតការអត់ឱនចំពោះប្រវែងអត្ថបទមិនដូចគ្នា។
ឧទាហរណ៍នៃការបែងចែក៖
- Navigation: ត្រូវខ្លី និងច្បាស់
- Microcopy គាំទ្រ: ត្រូវកាត់បន្ថយភាពមិនប្រាកដ និងនាំអ្នកប្រើឲ្យធ្វើបន្ត
- សារកំហុស: ត្រូវពន្យល់ និងជួយអ្នកចេញពីបញ្ហា
- Onboarding: ត្រូវបង្កើនតម្លៃផលិតផល និងលើកទឹកចិត្តឲ្យអ្នកប្រើចាប់ផ្តើម
វិធីនេះ ជួយឲ្យ microcopy មានភាពស្របគ្នា ហើយគាំទ្រគោលដៅផលិតផលបានល្អជាងមុន។
3. កំណត់ស្ទីល និង tone សម្រាប់ភាសានីមួយៗ
កុំសន្មតថា tone ដដែលអាចបកប្រែបាន 1:1 ទៅគ្រប់ទីផ្សារ។ ក្នុង localization មួយ ប្រហែលជាភាសាមួយនឹងទំនងជាស្រាលជាង ខណៈភាសាមួយទៀតត្រូវការភាពផ្លូវការជាង។ ចំណុចសំខាន់គឺអ្នកប្រើគួរតែមានអារម្មណ៍ថា កម្មវិធីកំពុងជួយគាំទ្រ ប្រកបដោយវិជ្ជាជីវៈ សាមញ្ញ ឬមានភាពពិសេស។
នៅទីនេះ profile សម្រាប់ការបកប្រែមានប្រយោជន៍។ SmartTranslate.ai អនុញ្ញាតឲ្យកំណត់ឧស្សាហកម្ម ស្ទីលនៃការនិយាយ tone ភាពផ្លូវការ និងកម្រិតនៃការកែសម្រួលតាមវប្បធម៌ ដូច្នេះការបកប្រែកម្មវិធីទូរស័ព្ទ មិនត្រឹមតែជាការបកប្រែបែបស្ទើរតែ (raw translation) ទេ ប៉ុន្តែឆ្លុះបញ្ចាំងពីអត្តចរិតផលិតផលបានពិតៗ។
4. ផ្តល់បរិបទសម្រាប់ string នីមួយៗ
បរិបទកាន់តែច្រើន កំហុសកាន់តែតិច។ best practices រួមមាន៖
- បន្ថែមការពិពណ៌នាអំពីមុខងារបស់អត្ថបទ
- ប្រាប់ថាសារនោះបង្ហាញនៅទីណា
- កំណត់ចំនួនតួអក្សរអតិបរមា
- បញ្ជាក់ persona ឬដំណាក់កាលនៃដំណើរអ្នកប្រើ
- សម្គាល់ថាតើអត្ថបទទាក់ទង error, success, instruction ឬ CTA
ចំណុចនេះសំខាន់ជាពិសេសពេលបកប្រែសារនៅក្នុងកម្មវិធី ព្រោះពាក្យតែមួយដែលជ្រើសខុស អាចផ្លាស់ប្តូររបៀបដែលអ្នកប្រើយល់ពី “អន្តរកម្មទាំងមូល” បាន។
5. រចនា interface ដោយគិតពីការកើនប្រវែងអត្ថបទ
ប្រសិនបើ design ដាក់ component ឲ្យតឹងខ្លាំង បញ្ហានឹងលេចឡើងភ្លាមៗ ពេលបន្ថែមភាសាបន្ថែមទៀត។ ទុកសំយោគ (margin) សម្រាប់ឃ្លាវែងៗ តេស្តជាមួយប្រវែងអត្ថបទច្រើនៗ ជៀសវាងការវាយអត្ថបទ “ជិតគែម” ហើយរៀបចំ responsive សម្រាប់មាតិកាដែលបាន localization ផងដែរ។
សម្រាប់ក្រុម design នេះ គឺជាច្បាប់សំខាន់មួយនៃ localization UX៖ interface គួរតែមានភាពរឹងមាំ និងទ្រាំបានជាមួយការប្រែប្រួលភាសា។
6. តេស្តការបកប្រែ លើឧបករណ៍ពិត មិនមែនតែឯកសារ
មុនពេលចេញផ្សាយ សូមដំណើរការកម្មវិធីក្នុងកំណែនីមួយៗ និងឆ្លងកាត់ផ្លូវ (user journeys) ដ៏សំខាន់ៗ។ សូមពិនិត្យ៖
- ការចុះឈ្មោះ
- ការចូលប្រើ (log in)
- reset លេខសម្ងាត់
- ការទិញ ឬការធ្វើឲ្យសកម្ម subscription
- ការស្វែងរក
- ការកំណត់គណនី
- notifications និង error
នៅជំហាននេះហើយ ដែលអ្នកនឹងឃើញថា ការបកប្រែ interface កម្មវិធីគាំទ្រការប្រើប្រាស់ល្អ (usability) ឬធ្វើឲ្យវាខ្សោយ។
គួរប្រុងប្រយ័ត្នអ្វីជាពិសេស ពេលបកប្រែ microcopy?
ការបកប្រែ microcopy គឺជាតំបន់ដែលពិបាកបំផុតមួយសម្រាប់ localization កម្មវិធីទូរស័ព្ទ។ ហេតុអ្វី? ព្រោះអត្ថបទខ្លីៗមានឥទ្ធិពលខ្លាំងលើការសម្រេចចិត្តរបស់អ្នកប្រើ។ ពាក្យមួយអាចបង្កើនទំនុកចិត្ត ឬធ្វើឲ្យអ្នកប្រើមានអារម្មណ៍មិនប្រាកដ។
microcopy ល្អក្នុងកម្មវិធីគួរតែ៖
- ខ្លី
- ច្បាស់
- មានប្រយោជន៍
- ស្របគ្នាជាមួយម៉ាក
- ដាក់ក្នុងបរិបទនៃសកម្មភាព
ឧទាហរណ៍៖
- ជំនួស “Błąd” ដែលស្ងួត អាចប្រើសារ “មិនអាចរក្សាទុកការផ្លាស់ប្តូរបានទេ។ សូមព្យាយាមម្ដងទៀត”
- ជំនួស “Kontynuuj” ដែលមិនច្បាស់ ពេលខ្លះ “ទៅកាន់ការទូទាត់” នឹងសមជាង
- ជំនួស “ទិន្នន័យមិនត្រឹមត្រូវ” ដែលផ្លូវការ ពេលខ្លះ “សូមពិនិត្យអ៊ីមែល និងព្យាយាមម្ដងទៀត” មានប្រយោជន៍ជាង
នៅក្នុងការអនុវត្ត ការបកប្រែ microcopy មិនត្រឹមតែរក្សាអត្ថន័យ ប៉ុន្តែត្រូវរក្សា “មុខងារ” ជាមុនសិន។ នេះហើយជាចំណុចស្នូលនៃ localization UX។
Onboarding និងសារកំហុស៖ ២ ផ្នែកដែលមិនគួរបកប្រែដោយស្វ័យប្រវត្តិ (ដោយគ្មានបរិបទ)
Onboarding លក់តម្លៃផលិតផល។ វាជាពេលវេលាដំបូង ដែលអ្នកប្រើសម្រេចថា កម្មវិធីនេះងាយយល់ និងមានប្រយោជន៍សម្រាប់គាត់ឬអត់។ ប្រសិនបើ onboarding បន្ទាប់ពីបកប្រែ ស្តាប់ទៅតឹងពេក វែងពេក ឬមិនធម្មជាតិ អ្នកប្រើអាចបាត់បង់កម្លាំងចិត្ត មុនពេលចាប់ផ្តើមប្រើប្រាស់ (activation)។
ចំណែកឯការបកប្រែសារក្នុងកម្មវិធី ជាពិសេស error ទាក់ទងនឹងកម្រិតភាពតានតឹង (frustration)។ អ្នកប្រើត្រូវការមិនត្រឹមតែដឹងថាមានអ្វីមិនដំណើរការ ប៉ុន្តែត្រូវការជំហានណែនាំឲ្យធ្វើបន្តភ្លាមៗ។ ដូច្នេះ សារកំហុសគួរត្រូវសរសេរ និងបកប្រែដោយប្រើគ្រោងសាមញ្ញៗ៖
- តើអ្វីកើតឡើង?
- ហេតុអ្វីអាចកើតឡើងបាន?
- ឥឡូវអ្នកប្រើអាចធ្វើអ្វីបន្តទៀត?
វិធីសាស្ត្រនេះកាត់បន្ថយការយល់ច្រឡំ ហើយធ្វើឲ្យ interface ទាំងមូលមានប្រសិទ្ធភាពជាងមុន។
Check-list៖ localization កម្មវិធីទូរស័ព្ទដោយមិនធ្វើឲ្យ UX ខូច
Check-list ខាងក្រោមនេះ នឹងជួយក្រុម product design និង development អនុវត្ត localization ទៅជាច្រើនភាសា ក្នុងរបៀបដែលមានសណ្តាប់ធ្នាប់។
សម្រាប់ក្រុម product
- កំណត់ទីផ្សារ និង variant ភាសាដែលមានអាទិភាព
- កំណត់គោលដៅនៃ localization៖ កំណើន activation, retention, conversion ឬបន្ថយចំនួន error
- កំណត់ tone of voice សម្រាប់ទីផ្សារនីមួយៗ
- រៀបចំ glossary នៃគោលគំនិតផលិតផលសំខាន់ៗ
- សម្គាល់មាតិកាដែលសំខាន់សម្រាប់ UX និងអាជីវកម្ម
សម្រាប់ក្រុម design
- រចនា component ឲ្យធន់នឹងអត្ថបទវែង
- ជៀសវាងការកំណត់ទទឹងប៊ូតុង និង label ឲ្យតឹងពេក
- តេស្តអេក្រង់ជាមួយ variant ភាសាដែលវែងជាង
- រក្សាលំដាប់សារៈសំខាន់ (information hierarchy) ស្របគ្នា ដោយមិនផ្អែកលើប្រវែងអត្ថបទ
- គិតពីទម្រង់កាលបរិច្ឆេទ រូបិយប័ណ្ណ និងលេខតាមតំបន់
សម្រាប់ក្រុម development
- ប្រើ localization keys ដែលអានងាយ
- បន្ថែម comment ទៅលើ string
- គាំទ្រ pluralization និង dynamic variables
- តេស្តការបំបែកបន្ទាត់ (line breaking) overflow និង truncation
- អនុវត្ត QA localization មុនពេលចេញផ្សាយ
សម្រាប់ក្រុមទាំងមូល
- កុំបកប្រែដោយគ្មានបរិបទ
- កុំសន្មតថា ភាសាមួយ = ទីផ្សារមួយ
- កុំចម្លង tone ពីអត្ថបទដើម 1:1 ដោយមិនកែសម្រួល
- ធ្វើបច្ចុប្បន្នភាព glossary និងច្បាប់ស្ទីលជាប្រចាំ
- ប្រមូល feedback ពីអ្នកប្រើនៅទីផ្សារនីមួយៗ
តើធ្វើតេស្តការបកប្រែកម្មវិធីទូរស័ព្ទ មុនពេលចេញផ្សាយយ៉ាងដូចម្តេច?
ការធ្វើតេស្តគួរតែរួមបញ្ចូលការត្រួតពិនិត្យជាច្រើនកម្រិត។ ការកែពិនិត្យអត្ថបទដោយ proofread ភាសាតែមួយ មិនគ្រប់គ្រាន់ទេ។
- QA ភាសា: ភាពត្រឹមត្រូវ ការសមជាតិ (naturalness) និងភាពស្របគ្នានៃពាក្យសព្ទ
- QA រូបរាង: ប្រវែងអត្ថបទ ការបំបែកបន្ទាត់ ធាតុបិទគ្នា
- QA មុខងារ: តើ dynamic variables និង format ដំណើរការត្រឹមត្រូវទេ
- QA បរិបទ: តើអត្ថបទសមនឹងដំណាក់កាលនៃដំណើរអ្នកប្រើឬអត់
- តេស្តជាមួយអ្នកប្រើ: ទោះបីជាអង្គុយសម្រាកខ្លីៗចំនួនតិចនៅទីផ្សារនោះ ក៏អាចផ្តល់ insight ដ៏មានតម្លៃ
វាមានប្រយោជន៍ក្នុងការធ្វើបញ្ជីអេក្រង់ និងសេណារីយ៉ូសំខាន់ៗ ហើយដើរតាមវារាល់ពេលមាន update ធំៗ។ ចំណុចនេះសំខាន់ជាពិសេស នៅពេលកម្មវិធីកំពុងរីកលូតលាស់លឿន ហើយបន្ថែមមុខងារថ្មីៗ។
SmartTranslate.ai អាចជួយអ្វីខ្លះ?
ពេលពង្រីកផលិតផល ភាពលំបាកមិនត្រឹមតែជាការបកប្រែកម្មវិធីទូរស័ព្ទប៉ុណ្ណោះទេ ប៉ុន្តែជាការរក្សាភាពស្របគ្នារវាងទីផ្សារ កំណែភាសា និងប្រភេទសារផងដែរ។ នេះហើយជាមូលហេតុដែលត្រូវមានឧបករណ៍ដែលយល់ពីបរិបទ ហើយអាចធ្វើការលើ profiles សម្រាប់ការបកប្រែ ជំនួសឲ្យបកប្រែដោយចៃដន្យ។
SmartTranslate.ai គាំទ្រ localization កម្មវិធីទូរស័ព្ទតាមរយៈការកែសម្រួលការបកប្រែឲ្យសមទៅនឹងឧស្សាហកម្ម ស្ទីលនៃការនិយាយ tone ភាពផ្លូវការ និងកម្រិតនៃការកែសម្រួលតាមវប្បធម៌។ នេះសំខាន់ ពេលផលិតផលត្រូវនិយាយខុសគ្នាក្នុង onboarding ខុសគ្នា លើអេក្រង់ទូទាត់ខុសគ្នា និងខុសគ្នានៅផ្នែកជំនួយ (help)។
អត្ថប្រយោជន៍បន្ថែមគឺការគាំទ្រភាសាច្រើន និង variant តាមតំបន់ ដែលមានសារៈសំខាន់ពេលពង្រីកទៅកាន់ទីផ្សារដែលត្រូវការភាពច្បាស់លាស់ ដូចជា en-us និង en-gb ឬ es-es និង es-mx។ SmartTranslate.ai ក៏គាំទ្រការបកប្រែអត្ថបទ និងឯកសារ ដោយរក្សាទម្រង់ (formatting) ដើម្បីធ្វើការងាយលើឯកសារដែលនាំចេញពីប្រព័ន្ធផលិតផល (product systems) ឯកសារ UX writing និង list នៃ string ផងដែរ។
ដូច្នេះ ប្រសិនបើអ្នកណានិយាយថា SmartTranslate “jak przetłumaczyć aplikację mobilną” ឬ SmartTranslate “localizacja aplikacji mobilnej” សម្រាប់អ្នក សេចក្តីឆ្លើយគឺសាមញ្ញ៖ ចាប់ផ្តើមពីការរៀបចំបរិបទឲ្យបានត្រឹមត្រូវ រៀបចំ profiles សម្រាប់ការបកប្រែ និងធ្វើតេស្តនៅក្នុង interface ពិត។ ទើបជាការរួមបញ្ចូលបែបនេះ ទើបផ្តល់លទ្ធផលដែលមិនធ្វើឲ្យ UX ខូច។
សេចក្តីសន្និដ្ឋាន
ការបកប្រែកម្មវិធីទូរស័ព្ទល្អ គឺជាដំណើរការរចនា (product/design process) មិនមែនគ្រាន់តែជាដំណើរការភាសាទេ។ បើអ្នកចង់ចូលទីផ្សារថ្មី ដោយមិនបាត់បង់គុណភាពនៃបទពិសោធន៍អ្នកប្រើ អ្នកត្រូវគិតពី localization តាំងពីដំបូង៖ ពីការត្រួតពិនិត្យមាតិកា (audit) ទៅការកំណត់ tone of voice និងការរចនា component ដែលធន់នឹងការប្រែប្រួលភាសា រហូតដល់ការធ្វើតេស្តនៅក្នុងកម្មវិធីដែលកំពុងដំណើរការ។
Localization កម្មវិធីទូរស័ព្ទទៅជាច្រើនភាសា ដំណើរការល្អបំផុត នៅពេល product design development និងក្រុមទទួលខុសត្រូវលើមាតិកា សហការគ្នាតាំងពីដំបូង។ ពេលនោះ ការបកប្រែ interface កម្មវិធី មិនមែនជាការបន្ថែមនៅចុងក្រោយក្នុង roadmap ទេ ប៉ុន្តែជាធាតុមួយនៃផលិតផល ដែលពិតៗជួយដល់ការលូតលាស់ ទំនុកចិត្ត និងភាពងាយស្រួលរបស់អ្នកប្រើ។
FAQ
តើបកប្រែកម្មវិធីទូរស័ព្ទដោយរបៀបណា ដើម្បីឲ្យអត្ថបទមិនបំផ្លាញ layout?
ត្រូវរៀបចំ interface ឲ្យមាន “កន្លែងទុក” សម្រាប់ឃ្លាវែងៗ កំណត់កម្រិតចំនួនតួអក្សរ និងធ្វើតេស្តការបកប្រែដែលបានត្រៀមរួចលើឧបករណ៍ពិត។ ការបកប្រែតែប៉ុណ្ណោះ ដោយមិនគ្រប់គ្រងប្រវែងអត្ថបទ ជាញឹកញាប់ធ្វើឲ្យបញ្ហាកើតឡើងនៅ UX។
តើអ្វីខុសគ្នារវាងការបកប្រែកម្មវិធីទូរស័ព្ទ និង localization កម្មវិធីទូរស័ព្ទ?
ការបកប្រែ ផ្តោតលើការបកប្រែអត្ថន័យ ខណៈ localization កម្មវិធីទូរស័ព្ទ ក៏គិតពីបរិបទនៃការប្រើប្រាស់ tone of voice ភាពខុសគ្នាតាមវប្បធម៌ ទម្រង់តាមតំបន់ និងរបៀបដែល interface ដំណើរការបន្ទាប់ពីប្តូរភាសា។
ហេតុអ្វីបានជា microcopy សំខាន់ខ្លាំង?
ព្រោះ microcopy ប៉ះពាល់ដោយផ្ទាល់ដល់ការសម្រេចចិត្តរបស់អ្នកប្រើ។ សារខ្លីៗនៅលើប៊ូតុង ក្នុង form ឬ error ជួយនាំអ្នកប្រើឆ្លងកាត់កម្មវិធី ដូច្នេះវាត្រូវតែច្បាស់ ធម្មជាតិ និងសមនឹងស្ថានការណ៍។
តើឧបករណ៍ណាអាចជួយសម្រួល localization កម្មវិធីទៅជាច្រើនភាសា?
មានឧបករណ៍ដែលយល់ពីបរិបទ ស្ទីល និង variant តាមតំបន់ ហើយអាចបកប្រែបានទាំងអត្ថបទតែមួយ និងឯកសារ។ ក្នុងគំរូនេះ SmartTranslate.ai សមស្របជាពិសេស ពេលអ្នកចង់បានភាពស្របគ្នានៃការទំនាក់ទំនងរបស់ផលិតផលនៅគ្រប់ទីផ្សារ រួមទាំងការគាំទ្រ multi language app in flutter, multi language app android និង multi-language approach ទូទៅៗ ដូចជា app_localizations និង app_localizations dart not generated ប្រសិនបើអ្នកអភិវឌ្ឍលើក្របខណ្ឌ (framework) ទាំងនោះ។
សម្រាប់សេចក្តីណែនាំទូទៅស្តីពីការអនុវត្តបច្ចេកទេសក្នុងការសម្គាល់/ចាត់ចែងទិន្នន័យ និង schema សម្រាប់ម៉ាស៊ីនស្វែងរក អ្នកអាចយោងទៅកាន់ Schema.org។