i18n Is Broken: Stop Writing Translation Keys

Ang internasyunal naisasyon (madalas pinaikling i18n), lokalisasyon (l10n), at suportang multilingguwal ay tumutukoy lahat sa iisang ideya: ang pag-aangkop ng produkto mo para magamit ito ng mga tao sa sarili nilang wika.

Ang i18n ay Ginagawa Pa rin na Para Bang 2005

Sa bandang huli, napagtatanto ng bawat negosyo na kailangan nilang suportahan ang maraming wika. Sa puntong iyon, ang product team ay iuurong ang sandalan na parang mekaniko, hihigop ng hangin sa pagitan ng mga ngipin, at sasabihing, “Ilang page ba ’yan? Hindi bababa sa apat na sprint.”

Hindi nagbago ang pinagbabatayang paraan ng pagpapatupad namin ng i18n sa loob ng 20 taon. Karamihan sa mga “best practice” ng i18n ay nabuo pa bago ang mga modernong arkitekturang pang-web, at lahat ng sumunod ay simpleng idinugtong lang sa ibabaw ng mga ito.

Ang i18n lang ang bahagi ng modernong web development na kailangan pa ring mag-export ng mga file at magpadala sa isang tao. Itinuturing na modernong setup na ito kung sa halip na i-email ang mga iyon, ina-upload mo sila sa pamamagitan ng API.

Sa mundong may mga CI pipeline at mga deploy na sinusukat sa minuto imbes na araw, malamang dapat pasalamatan natin na hindi na tayo kailangang mag-fax ng kahit ano.

Bakit Parang Sirang-sira ang i18n

Napakabilis ng naging takbo ng modernong web development.

We have:

• mga component na nire-render sa server
• streaming UI
• edge runtimes
• continuous deployment
• Mga kasangkapang AI-native

Gayunman, ang mga workflow ng internationalisation ay parang sa ibang panahon pa rin ang dating.

Kahit ang maliliit na application, mabilis na napapadpad sa sabayang paghawak ng:

• mga translation key
• Mga file ng JSON para sa pagsasalin
• manual translation pipelines
• nakahiwalay na frontend laban sa backend na lokalisation logic
• translation management tools

Hindi nagtatakda ang mga developer na bumuo ng mga sistemang ganito. Napapadpad lang sila rito, dahil natitisod ang mga developer na hindi pamilyar sa kung paano lubhang magkaiba ang estruktura ng mga pangungusap sa iba’t ibang wika sa karaniwang mga hadlang ng i18n… at napipilitan na lang tanggapin ang status quo na itinakda 20 taon na ang nakalipas.

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

Hindi Kasya ang Modernong UI sa Loob ng Mga Translation String

Consider a simple UI:

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

This is easy to understand. It is simple.

Sa isang punto, nagpasya tayong i-internationalise ito. Kaya, kinukuha natin ang teksto at inililipat sa translation file:

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

And we reference that in our 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, may English text na tayo ngayon sa code natin, at sa translation file natin? Oo. Iba-iba ang inilalapat na “pintura” ng iba’t ibang i18n library, pero ang pagsubok na isalin ang tekstong bahagyang na-format na sa pamamagitan ng pagkuha nito at ilagay sa isang JSON file na madaling basahin ng tao ay isang labang talo na.

Nakabalangkas ang modernong UI, pero ang mga translation system ay nakatayo sa pundasyon ng mga flat string.

Kapag pumasok na ang markup, mga variable, at dynamic na content, nagsisimulang tumagas ang abstraction.

Dynamic and User-Generated Content Break Traditional i18n

Things get even harder when content is not static.

Balikan natin ang halimbawang ito:

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

Galing ang string na ’yan sa API. Paano natin gagawin ’yan bilang translation key?

Spoiler: hindi mo kailangang gawin ’yon. Ngayon, kailangan na ring suportahan ng backend mo ang internationalisation.

Kailangan na ngayong pamahalaan ng backend mo ang:

• the original semantic data
• mga naisaling variant
• fallback logic
• pagtukoy sa locale

Bigla ring kailangan ng mga tagasalin ng access sa mga backend system.

And the problem only grows when user-generated content enters the picture.

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

Ipinagpapalagay ng mga tradisyonal na i18n pipeline na kontrolado ng mga developer ang lahat ng teksto. Palaki nang palaki, hindi na lang talaga ito totoo.

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

Magulo pa rin ang Pag-detect ng Locale

Even determining which language a user wants is surprisingly complicated.

Browsers send language preferences through the Accept-Language header:

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

This tells the server:

1. Mas gusto ang British English
2. Then any form of English
3. Tapos, kahit anong anyo ng French

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

• parsing quality weights
• pag-normalize ng mga locale (en, en-GB, en-US)
• pagtutugma ng mga sinusuportahang wika
• pag-handle ng fallback logic
• pagsunod sa malinaw na pag-override ng user

Many frameworks leave most of this logic up to developers.

Kahit ang simpleng pag-detect ng locale ay madalas nauuwi sa custom na code ng application.

Ang Pagpapalit ng Wika ay Isang Huling Isipin Na Lang

Translation infrastructure is only half the problem.

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

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

• mga language switcher
• locale routing
• cookie persistence
• URL canonicalisation
• mga hreflang tag para sa SEO

Mukhang maliit lang ang mga detalyeng ito, pero mabilis silang nagiging malaking bahagi ng kailangang ikabit-kabit sa application, lalo na kung hindi ka pamilyar sa lahat ng masalimuot na aspeto ng i18n. Hindi karamihan sa mga kumpanya at developer ay pamilyar dito.

The Shortcut: Automatic Website Translation

Dahil sa lahat ng kumplikasyong ito, may ilang team na kumakapit sa mga automatic website translation tool. Nangangako ang mga platform na ito na awtomatikong isasalin ang site mo nang kaunting pagsisikap lang.

Maraming kumpanya ang gumagawa ng mas sopistikado pang mga bersyon ng ideyang ito. Sa kasamaang-palad, nagdadala sila ng ibang set ng mga problema:

• translations often happen client-side
• Nasisira ang SEO
• dynamically loaded content cannot be translated without a flicker of incorrect language
• nawawala ang kontrol ng developer

Kadalasan, ang resulta ay isang site na teknikal na sumusuporta sa maraming wika pero nagbibigay ng kapansin-pansing mas masamang karanasan, at isang black box para sa mga developer na gamitin.

Paano Natin Napunta Dito

Nagsimula tayo sa isang napakasimple at napakaganda:

<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, putul-putol na pipeline, magkahiwalay na backend at frontend localisation layer, at external na translation tooling.

Napakakomplikado ng mga modernong web app. Pero ang mga i18n tool ay inaasahan pa rin ang mga workflow na para sa ibang panahon, parang Ferrari na may hand crank para paandarin ang makina.

Muling Pag-iisip sa Modelo

Paano kaya kung mas ganito ang hitsura ng internationalisation?

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

No translation keys.

No JSON dictionaries.

Walang mga manual na pipeline.

Text lang.

Isang Ibang Paraan

This idea is the foundation behind 18ways.

Itinuturing ng 18ways ang pagsasalin bilang isang optimisadong runtime concern. Ang pagkuha ng translation key at pamamahala ng mga translation file ay problema para sa mga makina, hindi para sa mga tao.

Minamarkahan lang ng mga developer ang tekstong gusto nilang ipasalin.

Sa likod ng mga eksena, ang 18ways:

• extracts the strings
• generates translations using AI
• caches the results
• direktang nagseserbisyo ng naisaling HTML mula sa server

Nananatiling SSR-friendly at SEO-safe ang lahat.

Mga Saling May Konteksto

Nawawala ang konteksto sa mga tradisyonal na i18n system.

Maaaring makakita ang isang translator ng ganito:

home

But what does that mean?

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

• Haus - isang bahay
• Startseite - ang homepage
• Start - a navigation label
• zum Anfang - bumalik sa simula

Kung kailangan mong isalin ang “home” sa Aleman, ano ang mas gugustuhin mong makita? Isang hiwalay na string, o ang pahinang talagang kinaroroonan nito?

Nahirapang pagdugtungin ng mga translation system na nakikita lang ang magkakahiwalay na string ang mga pagkakaibang ito.

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

Sinusuri ng aming mga backend agent ang mga salin habang lumalabas ang mga ito sa totoong mga page at ino-optimize para sa:

• context
• consistency
• mga hadlang sa layout
• kalidad ng salin

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

Empowering Human Translators

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

18ways provides translators with the same context-aware environment our AI agents use.

Sa halip na mag-edit ng mga JSON file, diretsong nirerepaso ng mga tagasalin ang teksto laban sa UI kung saan ito lumalabas.

Malaki nitong pinapabuti ang katumpakan ng salin at kahusayan ng workflow.

What Better i18n Looks Like

Internationalisation does not need another layer of translation keys, string files, and pipeline glue.

Nasa mga modernong application na ang istruktura, konteksto, at runtime na impormasyon na kailangan natin para magawa ito nang mas mahusay.

Dapat itayo ang susunod na henerasyon ng i18n para sa mga app na server-rendered, dynamic na content, AI-native na workflows, at mga human translator na magkatabi ang trabaho.

Iyan ang direksiyong tinatahak ng 18ways.