Pewnego popołudnia kiedy jak co dzień wracałem z pracy w mojej głowie zrodziła się wizja problemu wdrażania systemu stworzonego przez programistów z jednego kraju u klientów w innych krajach.

Wyobraź sobie hipotetyczną sytuację, w której
twój system bądź aplikacja ma działać w Wielkiej Brytani, w Niemczech i we Francji. Łącznie w kilkudziesięciu miejscach. Miejscowi wdrożeniowcy, generalnie znają tylko swój ojczysty język i odrobinę angielszczyzny. Podczas wdrożeń mogą i tak naprawdę przeważnie pojawiają się problemy. Kiedy wdrożeniowiec nie zna języka obcego na tyle by właściwie zinterpretować otrzymany komunikat i podjąć właściwą akcję to właśnie do Ciebie skieruje swój mail czy telefon. Spora część tych problemów to błahostki, które można rozwiązać po prostu rozumiejąc komunikat. Efekt końcowy ? Opóźnienia we wdrożeniu, mnóstwo telefonów, ciągle powtarzające się wyjaśnienia.

Nie wiem jak Ty, ale ja po kilkunastu takich telefonach czy e-mail’ach miałbym dość. A gdyby tak komunikaty były zinternacjonalizowane (tzn. pojawiały się w takim języku jaki jest potrzebny) ? Pewnie ilość telefonów od razu spadłaby i mógłbyś robić co do Ciebie należy.

Aktualna wersja jest na tyle elastyczna, że pozwala w dowolnym kraju wybrać dowolny z obsługiwanych języków.

Co zmieniło się od strony pisania kodu ?

Do tej pory rzucało się po prostu wyjątek:

throw new ServiceException (‘nazwa usługi’, ‘wersja usługi’, jakiś kod błędu, ‘treść komunikatu’);

A teraz ? Bardzo podobnie.

throw new ServiceException(‘nazwa usługi’, ‘wersja usługi’

, stała_określająca_ID_wyjątku

, tablica_zmiennych_uzytych_w_łańcuchu);

Co tak naprawdę się zmieniło ?

Zmieniło się podejście. Wyszedłem z założenia, że programista MUSI przewidzieć wszystkie sytuacje wyjątkowe. Skoro tak, to każdy z takich wyjątków może mieć swój unikalny identyfikator. To właśnie z tym identyfikatorem wyjątku powiązana jest określona treść. Podsystem komunikatów wykrywa język i kodowanie klienta. Możliwe jest także wymuszenie innych ustawień. Kiedy wyłapujemy wyjątki klauzulą catch, mamy już właściwą treść w odpowiednim języku.

Zobacz strukturę klas:

Jedyną dodatkową czynnością, którą trzeba wykonać dodatkowo jest przygotowanie treści komunikatu w wymaganych językach i w różnych standardach kodowania właściwych danem językom.

Komunikaty mogą mieć dynamiczne pola o dowolnych nazwach. Spójrz! Jeśli komunikaty mają postać:

„Błąd dostępu. Konto {$ACCOUNT_NAME} zostało zablokowane.”

„Access error. Account {$ACCOUNT_NAME} was disabled.”

to ostatnim parametrem w ServiceException będzie tablica (użycie $ _REQUEST[„LOGIN_NAME”] jest przykładowe):

array(„ACCOUNT_NAME” => $ _REQUEST[„LOGIN_NAME”]);

Dziś minął miesiąc i zakończyłem refaktoryzację z pełnym sukcesem. Testy wypadły pomyślnie. Jednak, aby w pełni wykorzystać nowe możliwości wielojęzyczności kilka miejsc systemu musi także zostać poddane pewnym modyfikacjom.

Jakie plany rozwojowe ?

Rozwinąć ten system tak, aby połączyć go z systemem FAQ. Dzięki temu ilość telefonów męczących programistów PHP spadnie bardzo znacząco.

Zupełnie dalszą przyszłością jest napisanie biblioteki dll / bpl z tą funkcjonalnością dla C++.

Tags: PHP