Zeznania programisty

Zdarzyło mi się napisać aplikacje WWW, która miała działać w wielu krajach, w wielu językach. Potrzebowałem systemu tłumaczeń. Mówiąc systemu mam na myśli systematyczne podejścia do sprawy tłumaczeń. Tłumaczenia w mojej aplikacji są częścią jej biznesu. Najprościej zrozumieć to na przykładzie. Jest sobie hotel który ma opis. Ten opis może być przetłumaczony na wiele języków. Do systemu można wprowadzić nowe hotele a każdy z nich będzie miał inne tłumaczenie. Wyobraźmy sobie tabelkę hotel. Ma ona trzy pola: identyfikator, nazwa i opis. Opis to coś co trzeba przetłumaczyć. Ale jak to zrobić?

create table hotel(
  primary key int id,
  varchar nazwa,
  varchar opis
)

Istnieje wiele sposobów rozwiązania tego problemu. Do głowy przychodzą mi takie:

• W systemie tworzymy tabelę hotel zawierającą kolumnę opis dla każdego z dostępnych języków. Będzie to wyglądać mniej więcej tak:

  table hotel(
    primary key int id,
    varchar nazwa,
    varchar opis_en, 
    varchar opis_de, 
    varchar opis_pl
  )
  

  Przedstawione rozwiązanie powinno działać bardzo szybko, jednak ma wadę – dodanie kolejnego języka do wymaga modyfikacji bazy danych – a to jest brzydkie.
• Dla każdej wersji językowej tworzymy osobną tabelę zawierającą pola, które trzeba przetłumaczyć. Wygląda to mniej więcej tak:

  table hotel(
    primary key int id,
    varchar nazwa,
  )
  table hotel_en(
    primary key int id,
    varchar opis
  )
  table hotel_pl(
    primary key int id,
    varchar opis
  )
  

  To rozwiązanie będzie działać szybko. Dodanie nowego języka będzie wymagać modyfikacji bazy danych. Oczywiście, korzystając z tego lub z poprzedniego rozwiązania warto napisać program, który będzie tłumaczył zapytania SQL i pobierał dane z odpowiednich tabel językowych. Obydwa te rozwiązania będą działać szybko jednak moim zdaniem nie są one ładne.
• Znam jeszcze coś takiego:

  table hotel(
    primary key int id,
    varchar nazwa
  )
  table hotel_tłumaczenia(
    primary key int id,
    int identyfikator_języka,
    varchar opis
  )
  

  To rozwiązanie jest lepsze od poprzednich tym, że wprowadzenie do systemu nowego języka nie będzie wymagało zmiany w strukturze danych.
• Ja najbardziej lubiłem jednak tworzenie tablicy słownikowej. W uproszczeniu wygląda to tak:

  table słownik (
    primary key int identyfikator_tłumaczonego_tekstu,
    int identyfikator_języka,
    varchar tłumaczenie
  )
  table hotel(
    primary key int id,
    varchar nazwa,
    identyfikator_tłumaczonego_tekstu opis
  )
  

  To rozwiązanie jest o tyle fajne, że proste. Nie wymaga modyfikacji struktury bazy danych w momencie dodania nowego języka. Łatwo też pisać zapytania SQL, które pobierają teksty w wybranym języku. Niestety, to rozwiązanie jest wolniejsze, szczególnie wtedy gdy tabelka hotel ma wiele pól które chcemy przetłumaczyć.

Myślę, że można wymyślić jeszcze wiele innych rozwiązań tego problemu. Schemat myślenia można przenieś ze świata relacji do języków programowania obiektowego. Można zrobić też coś takiego:

@Entity
class Hotel{
  @Id
  private Long id;
 
  private String nazwa;

  @Tłumaczenie
  private String opis;
}

Tak to nowa JAVA. Dzięki adnotacjom możemy programować wielowymiarowo. Więc dlaczego by nie stworzyć dla naszej aplikacji nowego wymiaru – wymiaru tłumaczeń??? Ja właśnie to robię. Tworzę bibliotekę Java, która programistom będzie dostarczać wygodnego narzędzia rozwiązującego problem tłumaczeń. Tłumaczenia, nie będą już częścią aplikacji. Będą jej nowym wymiarem. Zainteresowanych zapraszam do projektu: JPA Translator