Witam.

Natknąłem się na problem przechowywania zlokalizowanych tekstów. Mam kilka propozycji:

1. Tworzenie tabel, np. dla cms_gallery - cms_gallery_text_pl, cms_gallery_text_de
2. Wstawienie w treści strony specjalnych tagów: {langt:pl}Cośtam{/lang}{lang:en}Whatever{/lang}{lang:de}Scheiße {/lang}
3. W tabeli tworzyć pola photo_text_lang_pl, photo_text_lang_de

1. Nawet ciekawe, JOIN załatwia sprawę (odpowienio spreparowany). 2 wydaje mi się być troszkę niewydajne. 3 totalna amatorka.

Jestem ciekaw jak Wy rozwiązaliście to w swoich aplikacjach. Przypominam, że chodzi o teksty w bazach danych (np. artykuły) a nie lokalizacje tekstów typu: Menu, Strona główna.

Pozdrawiam.

Luźno oparte na Joomla CMS 1.0.15 i komponencie JoomFish

A. Rozdziel teksty na treść i etykiety
- artykuł, tytuł, nazwa pozycji menu, nagłówki pól strony -> to treść
- teskty: "czytaj całość" , "komentarze", "Załóż konto", "Autor", "Data dodania", "Nie masz uprawnień ..." -> to etykiety

teksty trzymaj w bazie etykiety w plikach

B. W momencie rozpoznania języka inkludujesz odpowiedni plik etykiet dla danego języka, w kodzie używasz tylko zmiennych językowych. W pewnych okolicznościach możesz trzymać etykiety w plikach ini i uzywać dostępnego dla php5 parsowania plików ini

C. Rozbudowujesz zapytanie o treści tak, żeby w momencie rozpoznaia języka innego niz podstawowy pytał o translację w odpowiedniej tabeli
- wszystkie translacje w jednej tabeli, bazując na unikalnych ID elementów oryginalnych (to pozwoli na optymalne uzycie joina) oraz opatrzone polem 'type' gdzie będziesz trzymać sobie informacje co to jest (artykuł, element menu, plik z opisem, fotka z opisem), obowiązkowe pole 'lang'
- warto dodać stan translacji (0/1) zeby dopuścic do stanu w którym masz cos przetłumaczone ale tego nie używasz (jeszcze)

Odpowiednio formując joina pytasz zawsze o konkretny typ i tylko o translacje dopuszczone do publikacji, oczywiście tylko z danego języka. Oczywiście trzeba sobie samemu wykombinować co w przypadku braku translacji (tekst domyślny/ element oryginalny).

1. nieskalowalne
2. obrzydnie Ci po pierwszych 15 minutach edycji, paskudne obciążenie przy parsowaniu
3. Blisko, blisko, tyle, że w jednej tabeli tak jak opisałem wcześniej

W podanym rozwiązaniu możesz sam zadecydować które pola są tłumaczalne a które nie co umożliwi nawet wyświetlania innych grafik czy plików downloadu w zależności od wybranego języka, oraz dobrą obsługę elementów nieistniejących dla danego języka.

Jeżeli masz tabele niezunifikowane (tzn, artykuły mają 'title' a fotki 'header' i niewiele jest wspólnych pól różnych elementów) oraz,
jeżeli masz niewiele typów danych (artykuły, fotki, pliki), możesz zastosować osobne tabele translacji dla każdego typu.

Temat: Wielojezykowosc

Ja polecam 1 rozwiązanie, tylko tworzyć osobnej tabeli dla każdego langa a dać pola które będzie przechowywało język. I później zapytaniem "... WHERE pole = 'pl'..." itp.

@Moli, właśnie chciałem da to jako kolejną propozycję. Chyba wybiorę takie rozwiązanie.
@.radex, czytaj uważnie topic.
@rybik, Dokładnie, teksty to teksty, a labele to labele. To zagadnienie dotyczyło tylko tekstów.

EOT.

To jak już Cię odesłano to zamykam.
Tak się składa, że wątek, który podał Ci ~.radex tyczy się zagadnienia, które Ty opisujesz