Już od kilku miesięcy zmagam się z tym pytaniem, ale nie byłem w sytuacji, w której musiałem zbadać wszystkie możliwe opcje. Teraz czuję, że nadszedł czas, aby poznać możliwości i stworzyć własne osobiste preferencje do wykorzystania w nadchodzących projektach.

Pozwólcie, że najpierw naszkicuję sytuację, której szukam

Zamierzam uaktualnić / przebudować system zarządzania treścią, którego używam już od dłuższego czasu. Jednak czuję, że wielojęzyczność jest wielkim ulepszeniem tego systemu. Wcześniej nie korzystałem z żadnych frameworków, ale zamierzam użyć Laraval4 do nadchodzącego projektu. Laravel wydaje się najlepszym wyborem czystszego sposobu na kodowanie PHP.Sidenote: Laraval4 should be no factor in your answer. Szukam ogólnych sposobów tłumaczenia niezależnych od platformy / frameworka.

Co należy przetłumaczyć

Ponieważ system, którego szukam, musi być jak najbardziej przyjazny dla użytkownika, metoda zarządzania tłumaczeniem powinna znajdować się wewnątrz CMS. Nie powinno być potrzeby uruchamiania połączenia FTP, aby zmodyfikować pliki tłumaczeń lub szablony html / php.

Ponadto szukam najłatwiejszego sposobu przetłumaczenia wielu tabel bazy danych bez konieczności tworzenia dodatkowych tabel.

Co sam wymyśliłem

Jak już sam szukałem, czytałem i próbowałem. Mam kilka opcji. Ale nadal nie czuję, że osiągnąłem metodę najlepszych praktyk dla tego, czego naprawdę szukam. W tej chwili wymyśliłem to, ale ta metoda ma również efekty uboczne.

PHP Parsed Templates: system szablonów powinien być analizowany przez PHP. W ten sposób mogę wstawić przetłumaczone parametry do HTML bez konieczności otwierania szablonów i modyfikowania ich. Poza tym, parsowane szablony PHP dają mi możliwość posiadania 1 szablonu dla całej witryny zamiast posiadania podfolderu dla każdego języka (który miałem wcześniej). Metodą osiągnięcia tego celu może być Smarty, TemplatePower, Laravel's Blade lub dowolny inny parser szablonów. Jak powiedziałem, powinno to być niezależne od pisemnego rozwiązania.Sterowane bazą danych: może nie muszę już o tym wspominać. Ale rozwiązanie powinno być oparte na bazie danych. CMS ma być obiektowo zorientowany i MVC, więc musiałbym pomyśleć o logicznej strukturze danych dla ciągów. Gdyby moje szablony były skonstruowane: templates / Controller / View.php być może ta struktura byłaby najbardziej sensowna:Controller.View.parameter. Tabela bazy danych miałaby długie pola z avalue pole. W szablonach możemy użyć metody sortowaniaecho __('Controller.View.welcome', array('name', 'Joshua')) a parametr zawieraWelcome, :name. Tak więc wynik jestWelcome, Joshua. Wydaje się to dobrym sposobem, aby to zrobić, ponieważ parametry takie jak: nazwa są łatwe do zrozumienia dla edytora.Niskie obciążenie bazy danych: Oczywiście powyższy system spowoduje obciążenie bazy danych, jeśli ciągi te są ładowane w podróży. Dlatego potrzebowałbym systemu buforowania, który ponownie renderuje pliki językowe, gdy tylko zostaną edytowane / zapisane w środowisku administracyjnym. Ponieważ pliki są generowane, potrzebny jest również dobry układ systemu plików. Myślę, że możemy iśćlanguages/en_EN/Controller/View.php lub .ini, cokolwiek najbardziej Ci odpowiada. Być może w końcu nawet .ini jest parsowane szybciej. Ten plik powinien zawierać dane w plikuformat parameter=value; . Myślę, że jest to najlepszy sposób na to, ponieważ każdy renderowany widok może zawierać własny plik językowy, jeśli istnieje. Parametry językowe powinny zostać załadowane do określonego widoku, a nie w zakresie globalnym, aby zapobiec wzajemnemu zastępowaniu parametrów.Tłumaczenie tabeli bazy danych: to w rzeczywistości najbardziej mnie martwi. Szukam sposobu na tworzenie tłumaczeń News / Pages / etc. jak najszybciej. Mając dwie tabele dla każdego modułu (na przykładNews iNews_translations) jest opcją, ale wydaje się, że dużo pracy wymaga dobrego systemu. Jedna z rzeczy, które wymyśliłem, opiera się na adata versioning System napisałem: jest jedna nazwa tabeli bazy danychTranslations, ta tabela ma unikalną kombinacjęlanguage, tablename iprimarykey. Na przykład: en_En / News / 1 (odnosząc się do angielskiej wersji elementu Wiadomości o ID = 1). Metoda ta ma jednak dwie ogromne wady: po pierwsze, ta tabela ma tendencję do wydłużania się wraz z dużą ilością danych w bazie danych, a po drugie, byłoby to bardzo trudne zadanie, aby użyć tej konfiguracji do przeszukiwania tabeli. Na przykład. szukanie śladu SEO pozycji byłoby pełnotekstowym wyszukiwaniem, które jest dość głupie. Ale z drugiej strony: jest to szybki sposób na tworzenie treści do przetłumaczenia w każdym stole bardzo szybko, ale nie wierzę w to, że ten pro-over jest przeciążony.Praca front-end: Również front-end będzie wymagał myślenia. Oczywiście przechowalibyśmy dostępne języki w bazie danych i (de) byli aktywni potrzebni. W ten sposób skrypt może wygenerować listę rozwijaną, aby wybrać język, a zaplecza może automatycznie zdecydować, jakie tłumaczenia mogą być wykonane przy użyciu CMS. Wybrany język (np. En_EN) zostanie następnie użyty podczas pobierania pliku językowego do widoku lub w celu uzyskania odpowiedniego tłumaczenia elementu treści na stronie internetowej.

Tak więc są. Moje pomysły do ​​tej pory. Nie zawierają jeszcze opcji lokalizacji dat itp., Ale ponieważ mój serwer obsługuje PHP5.3.2 +, najlepszym rozwiązaniem jest użycie rozszerzenia intl, jak wyjaśniono tutaj:http://devzone.zend.com/1500/internationalization-in-php-53/ - ale byłoby to przydatne w późniejszym stadium rozwoju. Na razie głównym problemem jest to, jak mieć najlepsze praktyki tłumaczenia treści na stronie internetowej.

Poza wszystkim, co tu wyjaśniłem, wciąż mam inną rzecz, której jeszcze nie zdecydowałem, wygląda na proste pytanie, ale w rzeczywistości daje mi to ból głowy:

Tłumaczenie URL? Czy powinniśmy to zrobić czy nie? iw jaki sposób?

Więc .. jeśli mam ten adres URL:http://www.domain.com/about-us a angielski jest moim domyślnym językiem. Jeśli ten adres URL zostanie przetłumaczony nahttp://www.domain.com/over-ons kiedy wybieram holenderski jako mój język? Lub powinniśmy pójść prostą drogą i po prostu zmienić zawartość strony widocznej na/about. Ostatnia rzecz nie wydaje się prawidłową opcją, ponieważ generowałoby wiele wersji tego samego adresu URL, a indeksowanie treści zakończy się niepowodzeniem.

Inną opcją jest użyciehttp://www.domain.com/nl/about-us zamiast. Generuje co najmniej unikalny adres URL dla każdej treści. Łatwiej byłoby też na przykład przejść do innego językahttp://www.domain.com/en/about-us a podany adres URL jest łatwiejszy do zrozumienia zarówno dla użytkowników Google, jak i użytkowników. Korzystając z tej opcji, co robimy z domyślnymi językami? Czy domyślny język powinien usunąć domyślnie wybrany język? Więc przekierowaniehttp://www.domain.com/en/about-us dohttp://www.domain.com/about-us ... Moim zdaniem jest to najlepsze rozwiązanie, ponieważ gdy CMS jest skonfigurowany tylko dla jednego języka, nie ma potrzeby, aby ten identyfikator języka był podany w adresie URL.

Trzecia opcja to kombinacja obu opcji: użycie opcji „Bez języka do identyfikacji” -URL (http://www.domain.com/about-us) dla głównego języka. I użyj adresu URL z przetłumaczonym kodem SEO dla podjęć:http://www.domain.com/nl/over-ons & http://www.domain.com/de/uber-uns

Mam nadzieję, że moje pytanie sprawi, że twoje głowy pękną, na pewno złamały moje! Pomogło mi to już teraz rozwiązać problem. Dałem mi możliwość zapoznania się z metodami, których użyłem wcześniej i pomysłem, jaki mam na nadchodzący CMS.

Chciałbym już podziękować za poświęcenie czasu na przeczytanie tego tekstu!

// Edit #1:

Zapomniałem wspomnieć: funkcja __ () jest aliasem do tłumaczenia danego ciągu. W ramach tej metody oczywiście powinna istnieć jakaś metoda awaryjna, w której domyślny tekst jest ładowany, gdy nie ma jeszcze dostępnych tłumaczeń. Jeśli brakuje tłumaczenia, należy je wstawić lub plik tłumaczenia powinien zostać zregenerowany.