Mam do Was takie pytanie. Jak najbardziej elegancko zaprojektować wielojęzyczną stronę internetową w railsach? Mam stronę, która powinna być wyświetlana w kilku językach (polski, angielski, rosyjski, niemiecki). W PHP robiłem to tak, że w katalogu powiedzmy /lang umieszczałem pliki powiedzmy polish.php a w nim tablice z translacja powiedzmy:
$lang['hello'] = 'Hello World';
Później jakaś klasa (powiedzmy Translate) korzystała z plików z katalogu /lang w celu zwracania tekstu w odpowiednim języku. Teraz przechodzę z PHP na Ruby i tworzę właśnie moją pierwszą stronę w railsach. Jak najlepiej problem wielojęzyczności rozwiązać w rails? Helper, lib?
Oczywiście domyślam się, że nie ma złotego środka. W PHP też to można robić na kilka sposobów jak też proponuje np. Zend_Translate
–
Pozdrawiam
EDIT:
Bym zapomniał. Jak najlepiej (automat) ustawić routing, aby działało poprawnie:
/pl/controller/action/
i pl (język) może się oczywiście zmieniać w zależności od wersji językowej, którą wybierzemy.
Co do drugiego pytania. W Railsach 2.0 jest coś takiego jak namespace w routesach:
map.namespace(:pl) do |pl|
admin.resources :articles
end
Itd.
W routesach można używać bazy danych, więc możesz oczywiście pobrać listę języków i wygenerować wszystko automagicznie
map.namespace(:pl) do |pl|
pl.resources :articles
end
Pozwoliłem sobie poprawić
pamiętaj jednak, że musisz wtedy do sporej liczby named routers przekazywać dodatkowo parametr jezyka, badź napisać sobie jakąś łatkę Tak czy inaczej jest z tym sporo problemów.
Mam do Was takie pytanie. Jak najbardziej elegancko zaprojektować wielojęzyczną stronę internetową w railsach? Mam stronę, która powinna być wyświetlana w kilku językach (polski, angielski, rosyjski, niemiecki). W PHP robiłem to tak, że w katalogu powiedzmy /lang umieszczałem pliki powiedzmy polish.php a w nim tablice z translacja powiedzmy:[/quote]
Ja sobie chwale gettexta a dokladniej: http://www.yotabanana.com/hiki/ruby-gettext-howto-rails.html
Dziala to calkiem sprawnie. Maly note - aby przetlumaczyc komunikaty z railsow, musialem odpalac mongrela ze zmienna GETTEXT_PATH.
Mam jeszcze pytanie. Komunikaty w odpowiednich językach (polski, angielski) mam w plikach (np. pl.yml). Co w przypadku, gdy mam kilka stron w html, które w całości powinny być przetłumaczone np. jakieś faq, howto. Są to statyczne elementy strony (nie są to teksty takie jak artykuły, które trzymane są w bazie danych).
Tego typu teksty trzymam po prostu jako html w widoku. Jak najlepiej poradzić sobie z takimi widokami, z tym, że w kilku wersjach językowych?
Globalize http://www.globalize-rails.org/globalize/
Używam w swoim hobbystycznym projekcie http://bitspudlo.com/ i bardzo sobie chwalę. Doskonały plugin, tak bezboleśnie dodanej tak bogatej funkcjonalnści to jeszcze nigdzie nie widziałem (no może jeszcze poza ActiveScaffold).
Małe pytanie - czy tworząc nową aplikację, która będzie wielojęzyczna, można najpierw skupić się na stworzeniu jej w jednym języku, a dopiero później dodać tą funkcjonalność (np. przy pomocy globalize), czy może też trzeba już myśleć o tym od samego początku, żeby później nie było za dużo tej samej roboty?
Nie ma chyba jednej odpowiedzi na to pytanie. Musisz sam się zastanowić.
Zależy np. czy jest to projekt, który ma wystartować jako strona wielojęzykowa, czy może kiedyś w bliżej nieokreślonej przyszłości planowanie jest uruchomienie obcojęzycznych wersji. Jeżeli druga opcja to skup się na funkcjonalności a z lokalizacją poczekaj do momentu aż będzie potrzebna(bo może się okazać że nigdy nie będzie i narobisz się bez sensu:)).
W ramach kompromisu możesz napisać stub-a metody localize w ten sposób:
w AplicationController:
def localize(text)
return text
end
i w templatach
<%= localize('Witam') %>
a potem sobie dopiszesz kod odpowiedzialny za lokalizacje w metodzie localize.
Żmudnym procesem jest wyszukiwanie stringów poukrywanych w aplikacji, więc stosując ta metodę możesz tego uniknąć.
Z tego co przyjrzałem się globalize, to wystarczyłoby na początek po prostu zainstalować ten plugin, skonfigurować i używać metody .t przy stringach, a tłumaczeniem zająć się na samym końcu.
Nie znalazłem jednak jak przeskoczyć z development na production - jak utworzyć tabele *_globalize w bazie production i jak najprościej przenieść zawartość tłumaczonych stringów (w fazie tworzenia) do tej bazy.
Ktoś może podpowiedzieć?
[quote=morgoth]Nie znalazłem jednak jak przeskoczyć z development na production - jak utworzyć tabele *_globalize w bazie production i jak najprościej przenieść zawartość tłumaczonych stringów (w fazie tworzenia) do tej bazy.
Ktoś może podpowiedzieć?[/quote]
W naszym poprzednim projekcie po prostu zrobiliśmy dump tabel za pomocą pg_dump i wczytaliśmy je na produkcji. Szybko i po bólu
Podobnie warto w ten sposób utworzyć produkcyjny schemat bazy. Lepsze to niż uruchamianie kilkudziesięciu migracji, które często przy dłuższym developmencie mają zwyczaj ‘nie przechodzić’.
