Sira ang i18n: Tigilan ang Pagsulat ng mga Translation Key

Ang Internationalisation (madalas pinaiikli bilang i18n), localisation (l10n), at multilingual support ay tumutukoy sa iisang ideya: ang pag-aangkop ng iyong produkto para magamit ito ng mga tao sa sarili nilang wika.

Ang i18n ay ginagawa pa rin na parang 2005 pa lang.

Sa kalaunan, napagtatanto ng bawat negosyo na kailangan nilang suportahan ang maraming wika. Sa puntong iyon, ang product team ay napapaatras na parang mekaniko, sumisipsip ng hangin sa pagitan ng kanilang mga ngipin, at nagsasabing, “Ilang page ba ang pinag-uusapan natin? Hindi bababa sa apat na sprint ’yan.”

Hindi nagbago ang pinagbabatayang paraan ng pagpapatupad namin ng i18n sa loob ng 20 taon. Karamihan sa mga “best practices” ng i18n ay nabuo pa bago ang mga modernong arkitektura ng web, at ang lahat ng sumunod dito ay simpleng isinandal na lamang sa ibabaw ng mga iyon.

Ang I18n ang tanging bahagi ng modernong web development na kailangan pa ring mag-export ng mga file at ipadala ang mga ito sa isang tao. Itinuturing itong modernong setup kung sa halip na i-email ang mga ito, ia-upload mo ang mga ito sa pamamagitan ng API.

Sa isang mundo ng CI pipelines at mga deploy na sinusukat sa loob ng ilang minuto imbes na mga araw, marahil ay dapat nating ituring ang ating sarili na masuwerte dahil hindi na natin kailangang mag-fax ng kahit ano.

Bakit Mukhang Sira ang i18n

Ang modernong pag-develop ng web ay napakabilis ng naging pag-usad.

Mayroon tayo:

• mga component na ni-render sa server
• UI para sa streaming
• mga edge runtime
• tuloy-tuloy na pagde-deploy
• Mga tool na likas na AI

Gayunman, pakiramdam pa rin na ang mga workflow ng internationalisation ay para bang kabilang sa ibang panahon.

Kahit ang mga relatibong maliliit na aplikasyon ay mabilis na napapadpad sa pag-juggle ng:

• mga susi ng pagsasalin
• Mga JSON na file ng pagsasalin
• mga manual na pipeline ng pagsasalin
• nakahiwalay na lohika ng localization para sa frontend at backend
• mga kasangkapan sa pamamahala ng pagsasalin

Hindi sinasadyang magtayo ang mga developer ng mga sistemang ganito. Napapahamak lang sila rito, dahil sa mga karaniwang hadlang sa i18n na bumibitag sa mga developer na hindi pamilyar sa kung paano lubos na naiiba ang pagbuo ng mga pangungusap sa iba’t ibang wika… at sa huli’y napipilitang tanggapin ang status quo na itinakda 20 taon na ang nakalipas.

Sa paglipas ng panahon, ang internationalisation ay nagiging isa sa mga pinakakumplikadong bahagi ng stack.

Hindi Kasya ang Makabagong UI sa Loob ng Mga String ng Pagsasalin

Isaalang-alang ang isang simpleng UI:

<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

Madaling maintindihan ito. Ito ay simple.

Sa isang punto, nagpasya kaming i-internationalise ito. Kaya, kinuha namin ang teksto at inilagay sa isang translation file:

{
  "mainPage": {
    "greeting": "Hello world",
    "cta": "<0>Click here</0> to view your <1>{{description}}</1>"
  }
}

At tinutukoy namin iyan sa aming code:

<h1>{t('mainPage.greeting')}</h1>
<p>
  <Trans key="mainPage.cta">
    <a href="#/">Click here</a> to view your <b>{{ description: serverResponse.productDescription }}</b>
  </Trans>
</p>

Pero, sandali, mayroon na tayong English text sa code natin, at sa translation file natin? Oo. Iba-iba ang inilalagay na pintura ng mga i18n library sa mga ito, pero ang pagsubok na isalin ang tekstong bahagyang naka-format na sa pamamagitan ng paghiwalay nito at ilagay sa isang human-readable JSON file ay isang laban na tiyak na matatalo.

Ang modernong UI ay nakaayos nang maayos, ngunit ang mga sistema ng pagsasalin ay binuo sa pundasyon ng mga payak na string.

Kapag pumasok na sa usapan ang markup, mga variable, at dynamic na nilalaman, nagsisimulang mag-leak ang abstraction.

Dinamik at User-Generated na Nilalaman ay Sumisira sa Tradisyunal na i18n

Mas nagiging mahirap pa ang mga bagay kapag hindi static ang content.

Kunin muli ang halimbawang ito:

<b>{serverResponse.productDescription}</b>

Nagmula sa isang API ang string na iyon. Paano natin gagawin iyong translation key?

Paunang sabat: hindi mo kailangan. Ngayon, kailangan na ring suportahan ng backend mo ang internationalisation.

Ang iyong backend ay dapat na ngayong mamahala sa:

• ang orihinal na semantikong datos
• mga isinaling baryante
• lohika ng pag-backup
• pagtukoy ng lokasyon

Biglang kailangan din ng mga tagasalin ng access sa mga backend system.

At lalo lang lumalala ang problema kapag pumasok na sa usapan ang content na ginawa ng mga user.

Mga review. Mga komento. Mga listing sa marketplace. Mga forum.

Ang mga tradisyunal na i18n pipeline ay ipinagpapalagay na kontrolado ng mga developer ang lahat ng teksto. Parami nang parami, hindi na lang ito totoo.

Ang katotohanang nagsimula nang mag-eksperimento ang mga kumpanyang tulad ng Amazon sa mga isinaling review ng user noong 2026 ay maraming sinasabi tungkol sa kung gaano kabagal umunlad ang i18n ecosystem.

Magu­lo pa rin ang Pagtukoy sa Lokasyon

Kahit ang pagtukoy kung anong wika ang gusto ng isang user ay nakapagtatakang komplikado.

Ipinapadala ng mga browser ang mga kagustuhan sa wika sa pamamagitan ng Accept-Language header:

Accept-Language: en-GB,en;q=0.9,fr;q=0.8

Ito ay nagsasabi sa server:

1. Mas gusto ang British English
2. Kung ganoon, anumang anyo ng Ingles
3. Kung gayon, anumang anyo ng Pranses

Sa praktika, ang maayos na pagpapatupad nito ay kinapapalooban ng:

• pagsusuri ng mga quality weight
• pag-normalize ng mga locale (en, en-GB, en-US)
• pagtutugma ng mga suportadong wika
• paghawak ng fallback na lohika
• paggalang sa tahasang mga override ng user

Maraming framework ang iniiwan ang karamihan sa lohikang ito sa mga developer.

Kahit ang pinakapayak na pagtukoy ng locale ay madalas nagiging custom na code ng application.

Ang Paglipat ng Wika ay Isang Pagkatapos-isip

Ang imprastraktura ng pagsasalin ay kalahati lang ng problema.

Kailangan pa rin ng mga user ng paraan para makapagpalit ng wika.

Karamihan sa mga i18n library ay nagbibigay ng translation layer ngunit iniiwan sa developer ang natitirang bahagi ng problema:

• mga tagapagpalit ng wika
• pag-ruta ng lokal
• pagpapanatili ng cookie
• Canonicalisation ng URL
• mga tag na hreflang para sa SEO

Ang mga detalyeng ito ay mukhang maliliit, pero mabilis silang nagiging malaking bahagi ng kailangang asikasuhin sa aplikasyon, lalo na kung hindi ka pamilyar sa lahat ng kumplikadong aspeto ng i18n. Karamihan sa mga kumpanya at developer ay hindi.

Ang Shortcut: Awtomatikong Pagsasalin ng Website

Dahil sa lahat ng komplikasyong ito, may ilang team na lumilipat sa mga awtomatikong tool sa pagsasalin ng website. Ipinapangako ng mga platform na ito na awtomatiko nilang isasalin ang iyong site nang kaunting pagsisikap lang.

Ilang kumpanya ang bumubuo ng mas sopistikadong mga bersyon ng ideyang ito. Sa kasamaang-palad, nagdadala sila ng ibang hanay ng mga problema:

• madalas na nangyayari ang mga pagsasalin sa panig ng kliyente
• Mga sirang SEO
• ang content na dynamic na na-load ay hindi maikakalinang isalin nang hindi nagkakaroon ng sandaling paglitaw ng maling wika
• nawawala ang kontrol ng developer

Ang resulta ay kadalasang isang site na teknikal na sumusuporta sa maraming wika ngunit naghahatid ng kapansin-pansing mas mahina na karanasan, at isang black box para sa mga developer na trabahuhin.

Paano Nagsimula Tayong Dito

Nagsimula kami sa isang bagay na napakaganda at simple:

<h1>Hello world!</h1>
<p>
  <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
</p>

At nauwi sa mga translation key, mga JSON dictionary, pira-pirasong pipeline, magkahiwalay na backend at frontend na mga layer ng lokalisasyon, at panlabas na translation tooling.

Ang mga modernong web app ay napakasopistikadong mga sistema. Gayunman, ang i18n tooling ay umaasa sa mga workflow na idinisenyo para sa ibang panahon, parang Ferrari na may hand crank para paandarin ang makina.

Muling Pag-isipan ang Modelo

Paano kung mas ganito ang hitsura ng internasyonal na pag-aangkop?

<h1><T>Hello world!</T></h1>
<p>
  <T>
    <a href="#/">Click here</a> to view your <b>{serverResponse.productDescription}</b>
  </T>
</p>

Walang mga susi ng pagsasalin.

Walang JSON na mga diksyunaryo.

Walang manual na pipelines.

Pangunahing teksto lang.

Isang Iba’t Ibang Lapit

Ang ideyang ito ang pundasyon ng 18ways.

Tinitingnan ng 18ways ang pagsasalin bilang isang na-optimize na usaping pang-runtime. Ang pagkuha ng mga translation key at pamamahala ng mga translation file ay problemang para sa mga makina, hindi para sa mga tao.

Minamarkahan lang ng mga developer ang tekstong gusto nilang isalin.

Sa likod ng mga eksena, 18ways:

• ina-extract ang mga string
• gumagawa ng mga salin gamit ang AI
• ineiimbak ang mga resulta
• nagse-serve ng isinaling HTML nang direkta mula sa server

Nanatiling SSR-friendly at SEO-safe ang lahat.

Mga Salin na Batay sa Konteksto

Nawawala ng konteksto ang mga tradisyunal na i18n system.

Maaaring makita ng isang tagasalin ang ganito:

home

Pero ano ang ibig sabihin niyan?

Sa German, ang mga kahulugang ito ay nangangailangan ng ganap na magkakaibang mga salita:

• Bahay - isang bahay
• Startseite - ang homepage
• Simula - isang label sa pag-navigate
• sa simula - bumalik sa simula

Kung kailangan mong isalin ang “home” sa German, alin ang mas gugustuhin mong makita? Isang hiwalay na string, o ang pahina kung saan talaga ito lumilitaw?

Ang mga sistema ng pagsasalin na nakikita lamang ang hiwa-hiwalay na mga string ay nahihirapan sa mga pagkakaibang ito.

Sinusuri ng 18ways ang mga salin sa konteksto ng aktuwal na UI.

Sinusuri ng aming mga backend agent ang mga salin habang lumalabas ang mga ito sa mga aktuwal na pahina at ino-optimize ang para sa:

• konteksto
• konsistensi
• mga limitasyon sa layout
• kalidad ng pagsasalin

Para sa sinumang pamilyar sa mga German compound noun, huwag mag-alala, kasama rin ang pagtukoy sa overflow.

Pagpapalakas sa mga Tagasalin ng Tao

Lahat ng nakakatulong sa AI na makagawa ng mas mahuhusay na salin ay nakakatulong din sa mga human translator.

Nagbibigay ang 18ways ng kaparehong context-aware na kapaligiran sa mga tagasalin na ginagamit ng aming mga AI agent.

Sa halip na mag-edit ng mga JSON file, nire-review ng mga tagasalin ang text nang direkta laban sa UI kung saan ito lumalabas.

Malaki nitong pinabubuti ang katumpakan ng pagsasalin at ang kahusayan ng daloy ng trabaho.

Ano ang Mas Magandang Mukha ng i18n

Hindi kailangan ng internasyunalisasyon ng isa pang patong ng mga translation key, mga string file, at pipeline glue.

Ang mga modernong application ay mayroon nang estruktura, konteksto, at runtime na impormasyong kailangan natin para magawa ito nang mas maayos.

Ang susunod na henerasyon ng i18n ay dapat itayo para sa mga app na naka-render sa server, dynamic na content, mga AI-native na workflow, at mga human translator na nagtutulungan nang magkatabi.

Iyan ang direksyong tinatahak ng 18ways.