စနစ်တကျ ဘာသာပြန်ထားတဲ့ IT support နဲ့ knowledge base တစ်ခုက ticket အရေအတွက်ကို တကယ်လျှော့ပေးနိုင်ပါတယ်။ အကြောင်းကတော့ သုံးစွဲသူက လိုအပ်တဲ့ အကူအညီ ကို ပိုမြန်မြန် ရှာတွေ့နိုင်ပြီး ဘာလုပ်ရမလဲဆိုတာကို အဆင့်လိုက် သေချာနားလည်သွားလို့ပါ။ အဓိကကတော့ ရိုးရှင်းပြီး လုပ်ဆောင်ချက်အခြေပြုတဲ့ ဘာသာစကား, တသမတ်တည်းရှိတဲ့ ဝေါဟာရအသုံးပြုမှု, interface နဲ့ ကိုက်ညီမှု, နည်းပညာနဲ့ အသုံးပြုသူ အခြေအနေ နှစ်မျိုးလုံးကို ထည့်သွင်းစဉ်းစားထားတဲ့ ဘာသာပြန်ခြင်း ပါပဲ။ စကားလုံးတိုက်ရိုက် ဘာသာပြန်တာနဲ့ မလုံလောက်ပါ — အကြောင်းအရာက မှန်ကန်ရုံမက ပြဿနာကို တကယ် ဖြေရှင်းပေးနိုင်ရပါမယ်။
လက်တွေ့မှာတော့ သုံးစွဲသူရဲ့ ရည်ရွယ်ချက်ကို ဦးတည်ထားတဲ့ အကြောင်းအရာတွေက အကောင်းဆုံး အလုပ်လုပ်ပါတယ် — “ဒါကို ဘယ်လိုပြင်မလဲ”, “ဘယ်ခလုတ်ကို နှိပ်ရမလဲ”, “မအလုပ်လုပ်ရင် ဘာလုပ်ရမလဲ” စတဲ့ မေးခွန်းမျိုးတွေပါ။ အဲ့ဒီလို workflow တွေထဲမှာ SmartTranslate.ai လိုကိရိယာတွေက ပိုပြီး အရေးကြီးလာနေပါတယ်။ ဘာလို့လဲဆိုတော့ အဲဒါက လုပ်ငန်းကဏ္ဍ, အသံနေအသံထား, formal ဖြစ်မှုအဆင့်, နည်းပညာဆိုင်ရာ context တွေနဲ့ ကိုက်ညီအောင် ဘာသာပြန်နည်း ကို ညှိပေးနိုင်ပြီး document format ကိုလည်း ထိန်းသိမ်းပေးနိုင်လို့ပါ။
IT support မှာ ဘာသာပြန်အရည်အသွေးက ticket အရေအတွက်ကို ဘာကြောင့် သက်ရောက်သလဲ?
ကုမ္ပဏီတော်တော်များများက article တစ်ပုဒ်ကို ဘာသာပြန်တဲ့ tool ထဲထည့်၊ ဥပမာ အင်္ဂလိပ် ဘာသာပြန် သို့မဟုတ် ဂျာမန် ဘာသာပြန် နဲ့ ထုတ်ထားတဲ့ ရလဒ်ကို help center မှာတင်လိုက်ရင် ရပြီလို့ ထင်တတ်ပါတယ်။ ပြဿနာကတော့ သုံးစွဲသူက စာတမ်းကို ဘာသာစကားမှန်မမှန် စစ်ဖို့ ဖတ်တာမဟုတ်ပါဘူး။ သူက ပြဿနာကို အမြန်ဆုံး ဖြေရှင်းချင်တာပါ — access ပြန်ရချင်တယ်, service ကို configure လုပ်ချင်တယ်, error ကို ဖယ်ရှားချင်တယ်, setting ကိုပြောင်းချင်တယ်, သို့မဟုတ် system message ရဲ့ အဓိပ္ပာယ်ကို နားလည်ချင်တာပါ။
ဘာသာပြန်ခြင်းက အလွန် literal ဖြစ်နေရင်, interface နဲ့ မကိုက်ညီရင်, သို့မဟုတ် လုပ်ငန်းဆိုင်ရာ jargon တွေနဲ့ ပြည့်နေရင် သုံးစွဲသူကတော့:
- ခလုတ်နာမည်တွေ၊ function နာမည်တွေကို မမှတ်မိတော့ပါ,
- လုပ်ဆောင်ရမယ့် အဆင့်အစဉ်ကို မှားယွင်းနားလည်ပါမယ်,
- ဘယ် step က မဖြစ်မနေ လိုအပ်တာလဲ မသိတော့ပါ,
- error message ကို နားမလည်ပါ,
- ကိုယ်တိုင် ဖြေရှင်းတာကို လက်လွတ်ပြီး ticket တင်လိုက်ပါမယ်။
အဲဒါကြောင့် support အကြောင်းအရာတွေကို ဘာသာပြန်ရာမှာ user experience design ရဲ့ အစိတ်အပိုင်းတစ်ခုလိုပဲ သဘောထားရပါမယ်။ ကောင်းမွန်တဲ့ ဘာသာပြန်ခြင်းက ပြဿနာ ဖြေရှင်းချိန်ကို လျှော့ပေးပြီး ဖောက်သည် ဝန်ဆောင်မှု အဖွဲ့ရဲ့ အလုပ်ပမာဏကိုလည်း ကျစေကာ customer စိတ်ကျေနပ်မှုကို မြှင့်တင်ပေးပါတယ်။
ဘယ်လို support content တွေကို အရင်ဆုံး ဘာသာပြန်သင့်သလဲ?
အကူ ညီ ပေးတဲ့ content အားလုံးက ticket လျှော့ချရာမှာ သက်ရောက်မှု တူညီတာ မဟုတ်ပါဘူး။ Business impact ကို မြန်မြန်မြင်ချင်ရင် user self-service ကို အများဆုံး ကူညီပေးတဲ့ content တွေကနေ စတင်ပါ။
- ဝင်ရောက်ခြင်း, password reset, account access ဆိုင်ရာ help center article များ။
- အများဆုံး လုပ်ရလေ့ရှိတဲ့ tasks တွေအတွက် အဆင့်လိုက် လမ်းညွှန်ချက်များ။
- “ဒီ error ပေါ်လာရင် ဒီအဆင့်တွေကို လုပ်ပါ” ဆိုတဲ့ troubleshooting content များ။
- support macro နဲ့ message template များ။
- configuration, payment, security, integration ဆိုင်ရာ FAQ များ။
- အမှားမက်ဆေ့ချ်များနှင့် စနစ်သတိပေးချက်들을 ဘယ်လို ဘာသာ ပြန်ဆို မလဲ ဆိုတဲ့ type ရဲ့ content များ။
ဒီလို material တွေထဲမှာပဲ အင်္ဂလိပ်မှ မြန်မာသို့ တိကျတဲ့ ဘာသာပြန်ရန် လိုအပ်ချက် အများဆုံးပေါ်လာတတ်ပါတယ်။ ကုမ္ပဏီတော်တော်များများမှာတော့ အင်္ဂလိပ်မှ မြန်မာသို့ ဘာသာပြန်ခြင်း၊ ပိုလန်မှ ဂျာမန်သို့ ဘာသာပြန်ခြင်း၊ ပိုလန်မှ ရုရှားသို့ ဘာသာပြန်ခြင်း စတဲ့ workflow တွေကို တပြိုင်နက်တည်း လုပ်နေတတ်ပါတယ်။ အကြောင်းက product တစ်ခုတည်းကို နိုင်ငံအမျိုးမျိုးက customer တွေ သုံးနေလို့ပါ။
အရေးအကြီးဆုံးစည်းမျဉ်း: စကားလုံးမဟုတ်ဘဲ လုပ်ဆောင်ချက်ကို ဘာသာပြန်ပါ
IT support အတွက် content တွေကို action-oriented language နဲ့ ဘာသာပြန်သင့်ပါတယ်။ အဓိပ္ပာယ်ကတော့ သုံးစွဲသူက ဘာလုပ်ရမယ်ဆိုတာကို ချက်ချင်း သိရမယ်ဆိုတာပါ။ မကြာခဏတော့ article က ဘာသာစကားအရ မှန်နေပေမယ့် system ကို ရှင်းပြနေတာများပြီး လုပ်ဆောင်ရမယ့် အဆင့်ကို မပြောလို့ လက်တွေ့ မကူညီနိုင်တာတွေ ရှိပါတယ်။
နမူနာ နှစ်ခုကို နှိုင်းယှဉ်ကြည့်ပါ:
- အားနည်းတဲ့ပုံစံ: “အသုံးပြုသူ profile ရဲ့ security settings အပိုင်းမှာ multi-factor authentication configuration option ကို တွေ့နိုင်သည်।”
- ပိုကောင်းတဲ့ပုံစံ: “MFA ကို ဖွင့်ရန် Settings > Security သို့ ဝင်ပြီး Enable MFA ကို နှိပ်ပါ।”
အပြင်အဆင်က အသေးအဖွဲလို့ ထင်ရပေမယ့် technical support ရဲ့ မျက်နှာစာကနေကြည့်ရင် အရေးကြီးပါတယ်။ သုံးစွဲသူက စွမ်းဆောင်ရည်ဖော်ပြချက် မဟုတ်ဘဲ operation instruction ကို လိုအပ်တာပါ။
ဒါကြောင့် support content ကို ဘာသာပြန်ရာမှာ အပိုင်းတိုင်းက ဒီမေးခွန်းတွေထဲက တစ်ခုခုကို ဖြေဆိုနေရမယ်ဆိုတာ စောင့်ကြည့်သင့်ပါတယ်:
- ဘာလုပ်ရမလဲ?
- ဘယ်မှာ နှိပ်ရမလဲ?
- အလုပ်လုပ်နေပြီဆိုတာ ဘယ်လိုသိမလဲ?
- ဒီအဆင့် မအောင်မြင်ရင် ဘာလုပ်မလဲ?
အဆင့်လိုက် လမ်းညွှန်ချက်တွေကို တကယ် အသုံးဝင်အောင် ဘယ်လို ဘာသာပြန်မလဲ?
Procedural instructions တွေက knowledge base ရဲ့ အခြေခံပါ။ ကံမကောင်းစွာနဲ့ ဒီနေရာမှာပဲ တိုက်ရိုက် ဘာသာပြန်ခြင်းက အကုန်ကျ အများဆုံး ဖြစ်တတ်ပါတယ်။ ဘာသာပြန်ခြင်းဟာ မူရင်းစာရဲ့ sentence order ကိုပဲ မဟုတ်ဘဲ user ရဲ့ action logic ကိုလည်း ထိန်းပေးရပါမယ်။
1. တစ်ဆင့် = လုပ်ဆောင်ချက်တစ်ခု
တစ်ဝါကျထဲမှာ လုပ်ဆောင်ချက်များစွာကို မပေါင်းလိုက်ပါနဲ့၊ အမှားနားလည်နိုင်ရင် ပိုဆိုးပါတယ်။ “Settings ထဲဝင်ပြီး Integrations tab ကိုရွေးကာ activation ပြီးနောက် API key ကို ထည့်ပါ” လို့ ရေးမယ့်အစား အဆင့် ၃ ဆင့်အဖြစ် ခွဲရေးတာ ပိုရှင်းပါတယ်။
2. ကြိယာနဲ့ စတင်ပါ
support content မှာတော့ “နှိပ်ပါ”, “ရွေးပါ”, “ထည့်ပါ”, “ပြန်စတင်ပါ”, “စစ်ဆေးပါ” စတဲ့ ရှင်းလင်းတဲ့ အမိန့်တွေက အလုပ်ဖြစ်ပါတယ်။ ဒီလိုရေးခြင်းက ဖတ်ရလွယ်စေပြီး အမှားဖြစ်နိုင်ခြေကိုလည်း လျှော့ပေးပါတယ်။
3. မှန်ကန်တဲ့ အစဉ်ကို ထိန်းပါ
အင်္ဂလိပ်မှ မြန်မာသို့ ကောင်းကောင်း ဘာသာပြန်ထားတယ်ဆိုရင်တောင် မြန်မာဗားရှင်းမှာ အဆင့်အစဉ် logic ပြောင်းသွားရင် မှားယွင်းသွားနိုင်ပါတယ်။ IT မှာ အစဉ်အတိုင်း လုပ်ရတာက အလွန်အရေးကြီးပြီး တစ်ဆင့်ကျော်သွားတာနဲ့ နောက်အဆင့်တွေ မလုပ်နိုင်တော့ပါဘူး။
4. မျှော်လင့်ထားတဲ့ ရလဒ်ကို ထည့်ပါ
အရေးကြီးတဲ့ အဆင့်တစ်ခု ပြီးတိုင်း သုံးစွဲသူက ဘာမြင်ရမလဲဆိုတာ ရေးပေးပါ။ ဥပမာ — “ပြောင်းလဲမှုများ သိမ်းပြီးပါက status သည် Active ဟု ပြောင်းသွားသင့်သည်”။ ဒီလို အချက်က “ကောင်းကောင်းလုပ်လိုက်မိရဲ့လား မသိဘူး” ဆိုတဲ့ ထပ်ဆင့် ticket တွေကို လျှော့ပေးပါတယ်။
5. အရေးပေါ်လမ်းကြောင်းကို ထည့်သွင်းပါ
အကောင်းဆုံး support article တွေက အခြေခံညွှန်ကြားချက်နဲ့ မပြီးဆုံးပါဘူး။ “အဲဒါ မအလုပ်လုပ်ရင်” ဆိုတဲ့ အပိုင်းကို ထည့်ပြီး နောက်ထပ် troubleshooting အဆင့်တွေကို လမ်းညွှန်ပေးပါတယ်။
ဝေါဟာရ တသမတ်တည်းရှိမှု: မကြာခဏ လျစ်လျူရှုခံရတဲ့ ပြဿနာ
အဖွဲ့အစည်းတော်တော်များများမှာ function တစ်ခုတည်းကို ဝေါဟာရ သုံးမျိုးနဲ့ ဘာသာပြန်ထားတာ တွေ့ရတတ်ပါတယ်။ article တစ်ပုဒ်မှာ “admin panel”, နောက်တစ်ပုဒ်မှာ “administrator console”, တတိယတစ်ပုဒ်မှာ “admin dashboard” လို့ ရေးထားနိုင်ပါတယ်။ သုံးစွဲသူအတွက်တော့ အဲဒါက system ထဲက နေရာသုံးခုလိုပဲ မြင်သွားပါတယ်။
ဝေါဟာရ တသမတ်တည်းမရှိရင် ဖြစ်လာတာတွေက:
- instruction လုပ်ရာမှာ အမှားများလာခြင်း၊
- knowledge base ထဲမှာ content ရှာရခက်ခြင်း၊
- support ကို ထပ်ခါထပ်ခါ မေးမြန်းမှုများလာခြင်း၊
- product, customer service, marketing အဖွဲ့တွေကြား ရှုပ်ထွေးမှုဖြစ်ခြင်း။
ဒါကြောင့် အောက်ပါအရာတွေ ပါဝင်တဲ့ glossary တစ်ခု တည်ဆောက်ထားသင့်ပါတယ်:
- module နဲ့ function နာမည်များ၊
- system message တို့ရဲ့ ပုံသေ ဘာသာပြန်များ၊
- user role နာမည်များ၊
- instruction တွေမှာ သုံးမယ့် operational verb များ၊
- ရိုးရှင်းအောင် ပြောင်းသုံးသင့်သလား, ဘာသာမပြန်ဘဲ ထားသင့်သလားဆိုတဲ့ technical term များ။
ဒီနေရာမှာ profile နဲ့ context အလိုက် content ကို ဘာသာပြန်နိုင်တဲ့ solution တွေက အားသာချက်ရလာပါတယ်။ SmartTranslate.ai က လုပ်ငန်းကဏ္ဍ, style, tone တို့နဲ့ ကိုက်ညီအောင် translation ကို ညှိနိုင်တာကြောင့် help center article, support response, documentation အကြား တသမတ်တည်း ထိန်းထားဖို့ ပိုလွယ်စေပါတယ်။
နည်းပညာပိုင်းအရလား၊ ရိုးရှင်းအောင်လား? ပရိသတ်အလိုက် style ကို ဘယ်လိုရွေးမလဲ
အများဆုံး တွေ့ရတဲ့ အမှားတစ်ခုက material အားလုံးကို style တစ်မျိုးတည်းနဲ့ ရေးခြင်းပါပဲ။ တကယ်တော့ system administrator လိုအပ်တဲ့ ဘာသာစကားနဲ့ end user လိုအပ်တဲ့ ဘာသာစကား မတူပါဘူး။
ဘယ်အချိန်မှာ နည်းပညာပိုင်း style သုံးမလဲ?
- အကြောင်းအရာက admin, developer, သို့မဟုတ် IT team ကို ဦးတည်တဲ့အခါ၊
- configuration တိကျမှု အရေးကြီးတဲ့အခါ၊
- သုံးစွဲသူက specialized term တွေကို သိပြီးသားဖြစ်တဲ့အခါ၊
- integrations, API, logs, security policy စတာတွေကို ဖော်ပြတဲ့ document တွေမှာ။
ဘယ်အချိန်မှာ ရိုးရှင်းတဲ့ ဘာသာစကား သုံးမလဲ?
- ညွှန်ကြားချက်က နေ့စဉ်အသုံးပြုသူ လုပ်ရပ်တွေကို ရည်ညွှန်းတဲ့အခါ၊
- နည်းပညာမသိဘဲလည်း မြန်မြန် ဖြေရှင်းရမယ့်အခါ၊
- login, payment, account settings, ရိုးရှင်းတဲ့ error များအကြောင်း ပါဝင်တဲ့အခါ၊
- သုံးစွဲသူက အချိန်ဖိအား သို့မဟုတ် စိတ်ဖိစီးမှု အောက်မှာ ဖတ်နေရတဲ့အခါ။
နမူနာ:
- နည်းပညာပိုင်း style: “integration အတွက် ထုတ်ပေးထားသော token သည် သက်တမ်းမကုန်သေးကြောင်းနှင့် permission scope သည် အရင်းအမြစ်သို့ ရေးသားခွင့် ပါဝင်ကြောင်း စစ်ဆေးပါ。”
- ရိုးရှင်းသော style: “integration key က အလုပ်လုပ်နေသေးလား၊ data ကို သိမ်းနိုင်တဲ့ ခွင့်ပြုချက်ရှိသလား စစ်ဆေးပါ।”
နှစ်မျိုးလုံးက မှန်ကန်နိုင်ပေမယ့် ထိရောက်မှုက ပရိသတ်ပေါ် မူတည်ပါတယ်။ ဒီအချက်က အင်္ဂလိပ် ဘာသာပြန်, Deepl ဘာသာပြန် သို့မဟုတ် တခြား အလိုအလျောက် tool တွေကို သုံးနေချိန်မှာလည်း အရေးကြီးပါတယ်။ Engine တစ်ခုတည်းက ဘယ်သူအတွက် ဘာသာပြန်နေတာလဲဆိုတာ မသိနိုင်ပါဘူး။ အသုံးပြုသူ context နဲ့ လုပ်ငန်း context လိုအပ်ပါတယ်။
ခလုတ်နာမည်, interface element, system message တွေကို ဘယ်လို ဘာသာပြန်မလဲ?
ဒါက အမှားအများဆုံး ဖြစ်ပွားတဲ့ နေရာတစ်ခုပါ။ article က အင်္ဂလိပ်မှ မြန်မာသို့ ကောင်းကောင်း ဘာသာပြန်ထားတယ်ဆိုရင်တောင် “Preferences” လို့ ပြောပြီး app ထဲက button က “Settings” လို့ ရေးထားရင် အဓိပ္ပာယ်ပျောက်သွားပါတယ်။
အရေးကြီးတဲ့ စည်းမျဉ်းတွေက ရိုးရှင်းပါတယ်:
- သုံးစွဲသူ အင်တာဖေ့စ်မှာ မြင်ရတဲ့ နာမည်အတိအကျကို သုံးပါ။
- product က localized မဟုတ်ရင် original button နာမည်ကို ထားပါ။
- interface element နာမည်တွေကို quotation marks သို့မဟုတ် capital letter နဲ့ တသမတ်တည်း ထင်ရှားအောင်ပြပါ။
- label တစ်ခုတည်းကို ဘာသာပြန်ပုံ မျိုးစုံ မလုပ်ပါနဲ့။
- UI ပြောင်းလဲပြီးတိုင်း content ကို မွမ်းမံပါ။
အမှားနမူနာ:
- ဆောင်းပါး: “Confirm” ကို နှိပ်ပါ။
- Interface: “Apply” ဆိုတဲ့ ခလုတ်။
ဘာသာပြန်ထားခြင်းမရှိသည့် စနစ်မှာ ဒီလိုညွှန်ကြားချက်က ရှုပ်ထွေးမှု ဖြစ်စေနိုင်ပါတယ်။ ပိုမှန်ကန်တာက “Apply” ကို နှိပ်ပါ” လို့ ရေးတာပါ — interface မှာ ပြထားတဲ့ ခလုတ်နာမည်အတိအကျကိုပဲ သုံးပါ။ ထပ်မံရှင်းပြချင်ရင် အကူအညီ အဖြစ် ထည့်နိုင်ပါတယ် — “ပြောင်းလဲမှုများကို သိမ်းရန် Apply ကို နှိပ်ပါ”။
အလားတူပဲ error message တွေနဲ့လည်း ဒီလိုပါပဲ။ သုံးစွဲသူက စခရင်ပေါ်မှာ အင်္ဂလိပ်စာသား အတိအကျ မြင်နေရင် အဲဒီစာသားကို မပြောင်းဘဲ ကိုးကားပြီး အောက်မှာမှ မြန်မာလို အဓိပ္ပာယ်ဖော်ပြတာ ပိုကောင်းပါတယ်။ ဒါမှ knowledge base ထဲမှာ ပြဿနာကို ရှာဖွေရ ပိုလွယ်ပါမယ်။
Instruction တွေထဲက screenshot နဲ့ graphic တွေက ဘယ်လိုလဲ?
အဖွဲ့တော်တော်များများက article တစ်ပုဒ် ဘာသာပြန်တာဟာ စာသားနဲ့ပဲ မပြီးဘူးဆိုတာ မေ့တတ်ပါတယ်။ instruction ထဲမှာ အင်္ဂလိပ် interface ပါတဲ့ screenshot တွေရှိပြီး မြန်မာလို ဖော်ပြထားတဲ့ caption က အခြားနာမည်တွေကို ရည်ညွှန်းနေရင် သုံးစွဲသူက လမ်းပျောက်နိုင်ပါတယ်။
Screenshot နဲ့ အလုပ်လုပ်တဲ့အခါ နည်းဗျူဟာ သုံးမျိုးထဲက တစ်ခုကို ရွေးနိုင်ပါတယ်:
- မူရင်း screenshot တွေကို ထားပြီး text ကို လက်တွေ့ interface နာမည်တွေနဲ့ ကိုက်ညီအောင် ညှိပါ။
- product က localized interface ရှိရင် language version တစ်ခုစီအတွက် screenshot သီးသန့် ပြင်ဆင်ပါ။
- UI မကြာခဏ ပြောင်းလဲနေရင် screenshot အစား တိကျတဲ့ စာသားညွှန်ကြားချက်တွေကို ပိုအသုံးပြုပါ။
အကျိုးအရှိဆုံး စည်းမျဉ်းကတော့ screenshot ဟာ instruction ကို အတည်ပြုပေးရမယ်၊ အစားမထိုးသင့်ပါဘူး။ ပုံက မသစ်တော့ဘူး သို့မဟုတ် ဖုန်းမှာ မရှင်းဘူးဆိုရင်တောင် သုံးစွဲသူက ပြဿနာကို ဖြေရှင်းနိုင်ရမယ်။
layout, table, ရှုပ်ထွေးတဲ့ section တွေပါသော document များကို ဘာသာပြန်နေတယ်ဆိုရင် formatting ကို ထိန်းထားနိုင်မှုက အလွန်အရေးကြီးပါတယ်။ ဒီနေရာမှာ SmartTranslate.ai က document များ၏ structure နဲ့ formatting ကို ထိန်းသိမ်းရင်း ဘာသာပြန်နိုင်တာကြောင့် အထောက်အကူဖြစ်ပါတယ်။
How to organize workflow translations for IT support?
ထိရောက်တဲ့ process တစ်ခုက tlumacz z ang na pol ဆိုတဲ့ tool ထဲ တစ်ခါတည်းထည့်လိုက်တာမျိုး မဟုတ်ပါဘူး။ အမြန်နှုန်းနဲ့ quality control ကို ပေါင်းစပ်ထားတဲ့ ထပ်တလဲလဲ အသုံးပြုနိုင်တဲ့ workflow လိုအပ်ပါတယ်။
အဆင့် 1: အကြောင်းအရာကို ဦးစားပေး သတ်မှတ်ခြင်း
ticket data ကို လေ့လာပြီး ဘယ်ပြဿနာတွေက အများဆုံး ဖြစ်ပွားလဲ၊ ဘယ်နိုင်ငံတွေက လာလဲ၊ ဘယ် article တွေမှာ traffic မြင့်ပေမယ့် ပြဿနာ ဖြေရှင်းနှုန်း နိမ့်လဲဆိုတာ စိစစ်ပါ။
အဆင့် 2: မူရင်းစာကို ပြင်ဆင်ခြင်း
ဘာသာမပြန်မီ source text ကို ရိုးရှင်းအောင် လုပ်ပါ။ မရှင်းလင်းတာတွေ ဖယ်ရှားပါ၊ sentence တွေကို တိုအောင်လုပ်ပါ၊ အဆင့်တွေကို စနစ်တကျ စီပါ၊ လက်ရှိ UI နဲ့ ကိုက်ညီမှု ရှိမရှိ စစ်ပါ။
အဆင့် 3: Translation profile ကို ရွေးချယ်ခြင်း
admin များအတွက် documentation နဲ့ end user အတွက် FAQ တို့အတွက် မတူညီတဲ့ profile တွေလိုအပ်ပါတယ်။