Локализацијата не е превод: Што навистина бара лансирање на втор јазик
Замена на текст со преведена датотека не е локализација. Еве што навистина пука кога лансирате втор јазик и како да го фатите пред лансирањето.
Во повеќето патеки на развој постои ставка што гласи „додади шпански“ или „лансирај на германски“, димензионирана како задача за содржина: испрати го текстот на преведувач, замени го, готово. Потоа производот се лансира и германските копчиња го преполнуваат својот контејнер, календарот за датум прикажува месец-ден-година на пазар што чита ден-месец-година, а страницата со цени тивко прикажува „$1.234,56“ како да е европска цена. Ниту едно од ова не е проблем со превод. Тоа е проблем со локализација, а двете постојано се мешаат бидејќи преводот е видливите 20% од работата, а локализацијата е невидливите 80%.
Преводот претвора зборови. Локализацијата го тера производот правилно да се однесува кон одреден пазар — форматирање, распоред, законски стандарди, културни претпоставки и техничката подлога што им овозможува на сите нив да варираат без да се разгранува базата на код. Третирањето на двете како иста задача е причината зошто толку многу производи што „поддржуваат пет јазици“ всушност поддржуваат пет речници обвиткани околу претпоставките на една култура.
Каде е вистинската работа
Проширувањето на текстот го крши интерфејсот со фиксна ширина. Англискиот е споредбено збиен јазик. Германскиот, финскиот и рускиот редовно се 30-40% подолги за исто значење; македонскиот и другите словенски јазици не заостануваат многу. Копче димензионирано да собере „Submit“ нема да собере „Потврди и продолжи“ или „Absenden und fortfahren“. Ако вашите компоненти имаат фиксни ширини или ги отсекуваат текстовите со три точки, вториот јазик не изгледа само поинаку — изгледа расипано, а тоа најмногу го погодува токму вашите главни повици на дејство.
Множината не е само наставка. Англискиот се снаоѓа со едно/многу. Многу јазици имаат три, четири или шест облици на множина со различни правила за тоа што се смета за „неколку“ наспроти „многу“. Преведен текст како "{count} ставка(и)" е англиски трик, не шема што ќе преживее судир со словенска или арапска граматика. Ако вашата i18n библиотека не поддржува ICU MessageFormat или еквивалент, на крајот ќе испраќате граматички погрешни реченици до секој корисник што не зборува англиски, повторливо, во секој текст во интерфејсот што зависи од број.
Датумите, броевите и валутата се податоци на локалот, не преведен текст. „12/09/2026“ значи 9 декември за Американец, а 12 септември за скоро секој друг. „1,234.56“ и „1.234,56“ се истиот број форматиран за две различни публики. Ова не се работи што преведувачот ги поправа во табела — треба да се генерираат со функции за форматирање свесни за локалот (Intl.DateTimeFormat, Intl.NumberFormat или еквивалентот во вашата рамка) секаде каде што се прикажува датум, цена или количина, вклучувајќи ги е-пораките и PDF-документите, кои тимовите доследно ги заборават.
URL-адресите и рутирањето бараат вистинска стратегија пред лансирање, не по него. Одлучете еднаш дали локалите живеат под подпатеки (/mk/...), поддомени или посебни домени, и дали URL-слаговите се преведуваат или остануваат заеднички. Заедничките слагови обично се вистинскиот избор — токму тие овозможуваат страница и нејзиниот превод чисто да се спарат за hreflang ознаките и преклопник на јазик што не води до 404. Враќање на ова по индексирањето на оригиналната URL структура од пребарувачите е скапо; направете го правилно во архитектурата, не во задача за миграција осумнаесет месеци подоцна.
Законските и усогласувачките стандарди се менуваат по пазар. Правилата за прикажување даноци, задолжителните известувања, механиката за согласност за колачиња, дури и она што се смета за прифатлив стандарден избор варираат според јурисдикција. Тек на наплата што е усогласен во САД може да биде активно неусогласен ако се лансира непроменет во ЕУ. Ова е локализациска работа која најчесто се прескокнува затоа што не се појавува во визуелна проверка — се појавува во писмо од регулатор.
Машинскиот превод е прв нацрт, не готов производ. Автоматскиот превод стана добар во граматика, а лош во ништо конкретно — што е токму проблемот, зашто грешките што ги прави се течни и самоуверени, а не очигледно погрешни. Мајчин говорник со контекст за производот треба да го прегледа текстот во контекст, не во табела, зашто значењето се менува со местото: збор што е неутрална ознака во листа може да звучи како команда или навреда на копче.
Што ова значи за опфатот
Ако локализацијата е навистина ставка во вашата патека на развој, димензионирајте ја како системска работа што и е: изберете i18n библиотека со вистинска поддршка за множина и форматирање пред да го напишете првиот преведен текст, одлучете ја вашата стратегија за URL и рутирање на ниво на архитектура, и предвидете буџет за преглед од мајчин говорник како повторлив трошок секогаш кога изворниот текст се менува — не еднократен чекор при лансирањето. Производ што лансира на еден јазик, а вториот го додава подоцна, треба да се гради како да вториот јазик доаѓа од првиот ден, зашто дополнителното вградување свесност за локал во фиксен текст и компоненти со фиксна ширина е драматично поскапо отколку да се вгради од почеток.
Тимовите што го прават ова правилно не испорачуваат „преведени“ производи. Тие испорачуваат производи што случајно се достапни на повеќе од еден јазик, а разликата е невидлива сѐ до денот кога германското копче на конкурентот ќе се преполни, а вашето нема.
PNK WORKS самата ја гради и одржува оваа страница на англиски и македонски, и истата инфраструктура ја носи кон производите на клиентите на кои им треба да работат на повеќе од еден пазар. Започнете проект.
Подготвени за соработка?
Започнете проект →