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

Cu mult înainte ca "i18n" să fie un checkbox în orice framework, livrarea unei singure aplicații 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ă compilați un build separat per limbă, toate string-urile de interfață stau într-un tabel tblTranslateInterface având drept cheie codul de limbă. O clasă mică de traducere parcurge formularele și CommandBar-urile deschise și înlocuiește caption-ul, tooltip-ul și textul din bara de stare al fiecărui control. Rapoartele fac excepție: unul deja deschis în Preview e o imagine metafile, deci se traduce doar închizându-l și redeschizându-l. Meniurile sunt partea grea, fiindcă controalele CommandBar nu au un nume unic, așa că le-am identificat 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ă.

S-a învechit stack-ul: DAO, Access 97 până la 2002, VBA. Ideea nu. Țineți textul traductibil în afara binarului, conduceți interfața din date, comutați la runtime. Site-ul acesta face același lucru două decenii mai târziu, pe .NET 10 și Blazor, dar doar pe jumătate: articolele, studiile de caz și serviciile sunt markdown citit de pe disc la rulare, în timp ce eticheta de interfață stă tot într-un tabel de string-uri compilat în binar. Varianta din 2004 era cea mai riguroasă dintre cele două.

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

Citiți "Lost in Translation" pe Microsoft Learn

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