Home > Java, JPA, SQL > Tłumaczenia w aplikacji na wiele sposobów

Tłumaczenia w aplikacji na wiele sposobów

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
Categories: Java, JPA, SQL Tags:
  1. Bonifacy
    December 4th, 2007 at 16:41 | #1

    Dobre, już mi się podoba.

  2. Demonstenes
    December 6th, 2007 at 13:04 | #2

    :) superowy wpis – wlasnie tworze slownik, ale jako, ze w php, to skorzystam z 3 metody :)

  3. gilthanas
    December 28th, 2007 at 14:00 | #3

    rozwiazanie wszystkie tlumaczenia w jednej tabeli jest wygodne w malych serwisach. jezeli jednak robisz duzy sysytem rozwiazanie to moze zabic ci cala aplikacje. poszukiwania w tabeli ktora ma kilka milionow rekordow bywaja zabojcze, zwlaszcza jezeli chcesz trzymac w bazie historie. rozwiazanie moze byc jeszcze jedno: podzielenie systemu tlumaczen na kilka czesci np. kazdy schemat bazy bedzie posiadal wlasne tlumaczenia.
    system tlumaczen moze tez w tym momencie byc bardziej elastyczny, np. czesc tlumaczen jest wersjonowana a czesc jest nastawiona na szybkie dzialanie i zbedne rzeczy sa wylaczone. dla naprawde duzych systemow najlepszym rozwiazaniem byloby stosowanie tabeli tlumaczen osobno dla kazdej tabeli.

  4. Antoni Jakubiak
    December 28th, 2007 at 14:13 | #4

    :)
    Tak, ale wiele zależy od działania indeksów w bazie.

  5. Cypo
    January 8th, 2008 at 03:38 | #5

    Jest jeszcze jedno wyjście, ale raczej nie nadaje się do stworzenia aplikacji nim zarządzającej. Ja akurat w systemie CMS używam
    page (
    page_id int,
    lang_id int references lang(lang_id),
    opis text,
    primary key(page_id, lang_id)
    );
    i oczywiście tabela z językami.

  6. Antoni Jakubiak
    January 8th, 2008 at 09:08 | #6

    Twoje rozwiązanie jest dobre, ale tylko dla stron bez personalizacji. Jeżeli na stronie znajdzie się moduł, który będzie miał inną treść w zależności od czasu lub od internauty – to takie rozwiązanie nie zadziała.

  1. No trackbacks yet.

Subscribe without commenting