Paano tukuyin ang saklaw ng integrasyon ng pagsasalin sa kasalukuyang business app
Planuhin ang pagsasalin sa inyong business app. Tukuyin ang nilalaman, mga wika, pagsusuri, tuntunin sa datos, paghawak sa pagpalya at acceptance test bago humingi ng panukalang presyo.
Magsimula sa isang buong gawain na kailangang gawin ng inyong team sa ibang wika. Pagkatapos, tukuyin kung paano papasok ang pagsasalin sa gawaing iyon. Mas malinaw na batayan ito para sa pagtatantya ng isang software supplier kaysa sa kahilingang magdagdag ng button para sa pagsasalin.
Dapat isama sa saklaw ng proyekto ang teksto, ang mga tao, ang datos at ang resulta. Dapat din nitong ipaliwanag kung ano ang mangyayari kapag pumalya ang pagsasalin. Gamitin ang mga hakbang sa ibaba para ihanda ang saklaw na iyon bago pumili ng teknikal na paraan.
Pumili ng isang workflow para sa unang release
Isulat kung saan nanggagaling ang orihinal na teksto at kung saan dapat mapunta ang aprubadong salin. Halimbawa, maaaring kailangang basahin ng isang empleyado sa support ang papasok na mensahe at maghanda ng sagot sa wika ng customer. Halimbawang requirement ito, hindi ulat tungkol sa isang installation ng Vavus.
Ilista ang bawat hakbang: buksan ang mensahe, humiling ng salin, basahin ang orihinal katabi ng resulta, i-edit ang sagot at aprubahan ito para maipadala. Pagpasyahan kung awtomatikong magsisimula ang pagsasalin o kapag pinili lang ito ng isang empleyado.
Panatilihing maliit ang unang release. Mas madaling subukan ang isang screen at isang malinaw na gawain sa negosyo kaysa sa bawat text field ng isang application.
Tukuyin ang pangangailangan sa nilalaman at wika
Gumawa ng listahan ng mga field na kailangang isalin. Paghiwalayin ang maiikling label, malayang teksto, dokumento at pananalita. Maaaring magkaiba ang pagproseso at pagsubok na kailangan ng mga ito. Ilista rin ang mga field na hindi dapat magbago, gaya ng order number at product code.
Tukuyin ang source at target na wika, kasama ang anumang rehiyonal na variant. Itala ang karaniwang haba ng teksto at ang inaasahang dami kada araw. Itanong kung aling mga kombinasyon ng wika at input format ang sinusuportahan ng iminumungkahing serbisyo.
Maaaring mahalaga ang konteksto sa maiikling teksto. Halimbawa, sinusuportahan ng text API ng DeepL ang isang context parameter na maaaring makaimpluwensya sa salin nang hindi isinasalin ang konteksto mismo. Sinasabi rin ng dokumentasyon nito na hindi nagbabahagi ng konteksto ang magkakahiwalay na text entry sa iisang request. [1] Dapat sabihin ng inyong saklaw kung saan manggagaling ang kapaki-pakinabang na konteksto.
Tukuyin ang terminolohiya at ang pagsusuri ng tao
Tipunin ang mga terminong madalas gamitin ng inyong negosyo. Isama ang mga gustong salin, pangalan ng produkto at mga salitang hindi dapat baguhin. Magtalaga ng isang tao na mag-aalaga sa listahang ito.
Sinusuportahan ng ilang serbisyo sa pagsasalin ang mga glossary. Inilalarawan ng Google Cloud Translation ang glossary nito bilang custom na diksyunaryo para sa pare-parehong terminolohiya ng isang larangan. [2] Suriin ang feature para sa eksaktong mga pares ng wika at serbisyong pinili ninyo. Hindi pinapatunayan ng glossary na tama ang buong mensahe.
Pagpasyahan kung aling mga output ang nangangailangan ng kwalipikadong tagasuri ng wika. Bigyan ang tagasuri ng access sa orihinal na teksto. Magtakda ng malinaw na hakbang ng pag-apruba bago ipadala o ilathala ang tekstong para sa customer.
Magtakda ng mga tuntunin sa datos at access
Ilarawan kung anong impormasyon ang hinahawakan ng workflow. Gumamit ng mga artipisyal na halimbawa sa mga unang pagsubok. Iwasang kopyahin ang totoong mga record ng customer sa isang trial para lang makita kung gumagana ang isang button.
Itanong kung saan ipoproseso ang teksto, ano ang iimbakin ng application, sino ang makakabasa nito at kailan ito buburahin. Isama sa usapang ito ang mga log at backup. Kumpirmahin ang kasalukuyang mga tuntunin ng provider at ang mga kontrol na available sa napiling plan.
Hindi nagiging pribado o offline ang isang panlabas na serbisyo sa pagsasalin dahil lang sa custom na interface. Kung kailangan ng inyong proyekto ang lokal na pagproseso, sabihin ang requirement na iyon sa simula pa lang at subukan ang buong daloy ng datos batay rito.
Magplano para sa pagkaantala at mga error
Isulat ang inaasahang oras ng pagtugon at ang dapat gawin ng staff kapag hindi available ang serbisyo. Dapat magpakita ang application ng malinaw na status, gaya ng naghihintay, handa nang suriin o pumalya. Panatilihin ang orihinal na teksto.
Hilingin sa developer na ihiwalay ang pansamantalang pagpalya sa mga error na nangangailangan ng pagbabago. Halimbawa, nakadokumento sa DeepL ang pag-uulit ng request pagkalipas ng ilang sandali para sa mga rate-limit error, habang ibang tugon ang kailangan kapag naubos na ang quota. [3] Hindi dapat magdulot ang mga inuulit na request ng dobleng aksyon sa negosyo, gaya ng dalawang beses na pagpapadala ng iisang sagot.
Pagkasunduan ang mga usage alert at kung sino ang may hawak ng suporta. Isama ang singil sa serbisyo, maintenance at mga pagbabago sa hinaharap kapag inihahambing ang gastos ng proyekto.
Isulat ang mga acceptance test bago ang development
Pumili ng mga kumakatawang halimbawa para sa bawat kinakailangang pares ng wika. Isama ang mahahabang mensahe, di-pangkaraniwang character, kulang na field at mga termino mula sa inyong aprubadong listahan. Subukan ang buong gawain, mula sa orihinal na record hanggang sa naka-save o naipadalang resulta.
Magtakda ng pamantayan sa pagpasa na masusuri ng mga tao: hindi nagbabago ang mga product code, hindi maipapadala ang hindi aprubadong salin, nakikita ang pumalyang request at makakabalik ang tagasuri sa orihinal. Ipasuri sa kwalipikadong tagasuri ang kahulugan at tono. Itala ang mga depekto at ulitin ang parehong mga pagsubok pagkatapos ng mga pagbabago.
Maghanda ng malinaw na kahilingan para sa panukalang presyo
Ipadala ang workflow, mga sample na field, mga pares ng wika, tinatayang dami, mga tuntunin sa datos at mga acceptance test. Markahan ang bawat item kung kailangan ito sa paglulunsad o puwede sa susunod na release. Hilingin nang nakasulat ang mga palagay at ang mga hindi kasama.
Nag-aalok ang Vavus ng nakasulat na pagtukoy ng saklaw para sa mga custom na proyekto. [4] Gamitin ang pahina ng panukalang presyo para ilarawan ang inyong kasalukuyang application at ang gawaing gusto ninyong pahusayin. Dapat kumpirmahin sa saklaw ng inyong proyekto ang iminumungkahing integrasyon, deployment at pagsubok.
Humingi ng nakasulat na panukalang presyo