Lost in Translation: aplicații Access multi-limbă la runtime

Cu mult înainte ca "i18n" să fie un checkbox în orice framework, să livrezi o singură aplicație pe care un operator o putea comuta între limbi la runtime era muncă serioasă. Articolul acesta, scris pentru Smart Access în 2004, arată cum am făcut-o în Microsoft Access: un singur fișier compilat, fiecare limbă stând într-un tabel și toată interfața reetichetată din mers când utilizatorul schimbă o setare.

Abordarea rezistă în timp. În loc să compilezi un build separat per limbă, toate string-urile de interfață stau într-un tabel tblTranslateInterface indexat după codul de limbă. O clasă mică de traducere parcurge formularele, rapoartele și CommandBar-urile deschise și înlocuiește caption-ul, tooltip-ul și textul din bara de stare al fiecărui control. Meniurile sunt partea grea, fiindcă controalele CommandBar nu au un nume unic, așa că le-am indexat după proprietatea Tag și am căutat recursiv. Schimbarea limbii active reetichetează imediat fiecare formular deschis, iar fiecare formular deschis ulterior preia limba nouă pe măsură ce se încarcă.

Ce datează articolul e stack-ul: DAO, Access 97 până la 2002, VBA. Ce nu datează e ideea. Ține textul traductibil în afara binarului, condu interfața din date, comută la runtime. Exact asta face site-ul acesta azi, două decenii mai târziu, pe .NET 10 și Blazor: comutatorul RO/EN re-randează toată interfața din conținut, fără rebuild și fără redeploy.

Articolul integral, cu tot codul și baza de date exemplu, a fost republicat de Microsoft și e încă online:

Citește "Lost in Translation" pe Microsoft Learn

Publicat inițial în Smart Access, iulie 2004, Pinnacle Publishing.