Kilka uwag:
1. Tłumaczenia
Kto będzie tłumaczył? Osoby, które są również połączone z witryną? Biuro tłumaczeń? Używając Gettext będziesz pracować z plikami 'pot' (.po). Pliki te zawierają identyfikator wiadomości i ciąg wiadomości (tłumaczenie). Przykład:
msgid "A string to be translated would go here"
msgstr ""Teraz wygląda to dobrze i zrozumiałe dla każdego, kto musi to przetłumaczyć. Ale co się dzieje, gdy używasz słów kluczowych, jak sugeruje Mike, zamiast pełnych zdań? Jeśli ktoś musi przetłumaczyć msgid o nazwie „address_home”, nie ma pojęcia, czy powinien to być nagłówek „Adres domowy”, czy całe zdanie. W takim przypadku upewnij się, że dodałeś komentarze do pliku tuż przed wywołaniem funkcji gettext, na przykład:
/// This is a comment that will be included in the pot file for the translators
gettext("ready_for_lost_episode");
Korzystanie z xgettext --add-comments=/// podczas tworzenia plików .po doda te komentarze. Jednak nie sądzę, aby Gettext był używany w ten sposób. Ponadto, jeśli chcesz dodawać komentarze za pomocą co tekst, który chcesz wyświetlić, a) prawdopodobnie popełnisz błąd, b) cały skrypt i tak zostanie wypełniony tekstami, tylko w formie komentarzy, c) komentarze muszą być umieszczone bezpośrednio nad Gettext funkcji, co nie zawsze jest wygodne, w zależności od pozycji funkcji w kodzie.
2. Konserwacja
Gdy Twoja witryna rozrośnie się (jeszcze dalej), a wraz z nią pliki językowe, utrzymanie różnych tłumaczeń w ten sposób może być dość trudne. Za każdym razem, gdy dodajesz tekst, musisz utworzyć nowe pliki, wysłać je do tłumaczy, otrzymać z powrotem pliki, upewnić się, że struktura jest nadal nienaruszona (chłodni tłumacze zawsze chętnie przetłumaczą również składnię, dzięki czemu cały plik bezużyteczne :))) i zakończ importowanie nowych tłumaczeń. Oczywiście jest to wykonalne, ale pamiętaj o możliwych problemach w tym zakresie z dużymi witrynami i wieloma różnymi językami.
Inna opcja:połącz drugą i trzecią alternatywę:
Osobiście uważam, że bardziej przydatne jest zarządzanie tłumaczeniem za pomocą (prostego) CMS, przechowywanie zmiennych i tłumaczeń w bazie danych oraz samodzielne eksportowanie odpowiednich tekstów do plików językowych:
- dodaj zmienne do bazy danych (np.:id, strona, zmienna);
- dodaj tłumaczenia do tych zmiennych (np.:id, varId, język, tłumaczenie);
- wybierz odpowiednie zmienne i tłumaczenia, zapisz je do pliku;
- dołącz odpowiedni plik językowy do swojej witryny;
- utwórz własną funkcję do wyświetlania tekstu zmiennych:
text('var'); a może coś w stylu __('faq','register','lost_password_text');
Punkt 3 może być tak prosty, jak wybranie wszystkich odpowiednich zmiennych i tłumaczeń z bazy danych, umieszczenie ich w tablicy i zapisanie zserializowanej tablicy do pliku.
Zalety:
-
Utrzymanie. W przypadku dużych projektów utrzymanie tekstów może być dużo łatwiejsze. Możesz grupować zmienne według stron, sekcji lub innych części w witrynie, po prostu dodając do bazy danych kolumnę, która definiuje, do której części witryny należy ta zmienna. W ten sposób możesz szybko wyświetlić listę wszystkich zmiennych używanych m.in. stronę z najczęściej zadawanymi pytaniami.
-
Tłumaczenie. Możesz wyświetlić zmienną ze wszystkimi tłumaczeniami wszystkich różnych języków na jednej stronie. Może to być przydatne dla osób, które potrafią tłumaczyć teksty na wiele języków jednocześnie. Przydatne może być również obejrzenie innych tłumaczeń, aby wyczuć kontekst, tak aby tłumaczenie było jak najlepsze. Możesz również przeszukać bazę danych, aby dowiedzieć się, co zostało przetłumaczone, a co nie. Może dodać znaczniki czasu, aby śledzić możliwe nieaktualne tłumaczenia.
-
Dostęp. To zależy od tego, kto będzie tłumaczył. Możesz otoczyć CMS prostym loginem, aby w razie potrzeby przyznać dostęp osobom z biura tłumaczeń i zezwolić im tylko na zmianę niektórych języków lub nawet niektórych części witryny. Jeśli nie jest to możliwe, nadal możesz wyprowadzić dane do pliku, który można ręcznie przetłumaczyć i zaimportować później (chociaż może to powodować te same problemy, co wspomniano wcześniej). Możesz dodać jedno z tłumaczeń, które już tam są (angielski lub inny język główny) jako kontekst dla tłumacza.
Podsumowując, myślę, że w ten sposób odkryjesz, że będziesz mieć znacznie większą kontrolę nad tłumaczeniami, zwłaszcza na dłuższą metę. Nie mogę powiedzieć nic o szybkości ani wydajności tego podejścia w porównaniu z natywną funkcją gettext. Ale w zależności od rozmiaru plików językowych nie sądzę, że będzie to duża różnica. Jeśli pogrupujesz zmienne według strony lub sekcji, zawsze możesz uwzględnić tylko wymagane części.
