Drukowana wersja tematu

Napisany przez: Ociu 1.04.2006, 18:29:19

Witam,
Od jakiegoś czasu piszę duży projekt i doszedłem do wybierania języku. Chciałbym poznać Wasze zdanie jak ma działać taki system wielojęzykowości strony. Pobuszowałem po internecie i oto, co wymyśliłem.

• Pliki.
  Trzymamy pliki językowe w plikach. Każdy język ma osobny katalog, każdy ma pliki o takiej samej nazwie jak reszta języków, w plikach tablice o takich samych kluczach. Wybieramy odpowiedni język, include odpowiedniego pliku i print.
• Teksty w bazie danych.
  Tworzymy dwa obiekty. Jeden (może być traktowany jako filter) pobiera dane z bazy danych i przerzuca je do klasy o nazwie np. LangWrapper. Używając magicznych metod __get() pobieramy tekst z klasy i __set() gdy nie ma potrzebnego tekstu należy do stworzyć
• http://opt.openpb.net/docs/pl/doku.php?id=features:i18n

Napisany przez: pEbE 1.04.2006, 20:31:20

Myślę ze dobrym rozwiązaniem są pliki. Stosuje sie je w wielu cmsach i projektach.
Tłumaczenia w bazie danych to według mnie zaśmiecanie db i w dodatku majac wiele jezykow robi sie syf i przedluza sie czas wyszukiwania.
Tutaj nalezy zadac pytanie jak stworzyc taki plik. Czy ma byc to plik php w ktorym definiuje się zmienne/stałe czy zwykły plik tekstowy typu

Napisany przez: Strzałek 2.04.2006, 09:19:58

jeżeli w projekcie masz zamiar używać OPT, to ja na twoim miejscu użył bym opt'owego i18n ;]

Napisany przez: sf 2.04.2006, 09:59:36

Smarty: {config_load file="text.conf" section=$language} no i posprzątane

Napisany przez: NuLL 7.04.2006, 00:59:47

Ja korzystam z modifiera SMARTY

[HTML] pobierz, plaintext 
{"Jakis_tam_komunikat"|lang:"admin"}
[HTML] pobierz, plaintext 

Napisany przez: TomASS 7.04.2006, 07:27:19

A ja się bawię "słownikiem" - mam plik lang_pl.php, lang_en.php itp..... w bazie trzymam dla jakiego użytkownika jaki plik załadować (oczywiście to może później sobie zrobić). W plikach tych mam tablicę $Lang:

[PHP] pobierz, plaintext 
<?php
$Lang['Enter'] = 'Wejście';
$Lang['Exit'] = 'Wyjście';
.
.
.
?>
[PHP] pobierz, plaintext 

Napisany przez: eMartio 7.04.2006, 10:15:48

Ja z kolei napisałem sobie plugin do Smartego. Templejty tworzę normalnie, używając naszego narodowego języka. Mam również plik XML, który nazywa się identycznie jak nazwa szablonu czy też modułu szablonu i zawiera tłumaczenia tekstów z templejta w wielu językach.

Np.:

Moduł szablonu: menu.mod.tpl

Napisany przez: Vengeance 9.04.2006, 17:09:41

I ma taką wadę, że języki są różne i różną mają gramatyke... twoim sposobem czesto zdażyć się może, że nie da się w prosty sposób przetłumaczyć danego zdania.

Napisany przez: Fipaj 9.04.2006, 18:36:07

http://developer.gnome.org/projects/gtp/translate-gnome/x22.html - pliki .po i ich dekoder napisany przez Bastiona to całkiem dobre rozwiązanie.

Fajnie też rozwiązał to NuLL, ale pliki .PO są bardzo popularne, istnieje też wiele programów służących do ich edycji, co upraszcza tworzenie nowych wersji językowych. gTranslator i KBabel, for example.

Napisany przez: 3rdeye 12.04.2006, 15:10:53

[PHP] pobierz, plaintext 
<?php
$Lang['Enter'] = 'Wejście';
$Lang['Exit'] = 'Wyjście';
.
.
.
?>
[PHP] pobierz, plaintext 

Napisany przez: splatch 12.04.2006, 19:49:35

Ja ze swojej strony mogę polecić draft i18n z Mojavi 4, całość prezentuje się iście interesująco.. niestety w chwili obecnej serwer Mojavi leży..

Napisany przez: yavaho 12.04.2006, 20:15:15

Ja mam strony wielojezykowe zrobione na podstawie bazy danych i dosłownie zero tekstu w kodzie html. Struktura plikow php wyglada podobnie jak bym smarty zastosowal.
Jeden minus to ze jest duzo zapytan do bazy i moze stanowic obciazenie przy wiekszym serwisie. Ale wtedy juz prosto mozna zastosowac cachowanie stron.

Napisany przez: Ace 13.04.2006, 08:45:23

Ja osobiscie korzystam z plikow ini. Plik jezykowy globalny, + pomniejsze pliki jezykowe np: do konkretnego modulu. W Smarty korzystam z postfilter ktory podmienia odpowiednie ciagi znakow na wartosci np: [lang:mod_news,dodaj] na "Dodaj newsa"

Napisany przez: dtb 13.04.2006, 14:54:21

ja wczytuje zawartosc pliku ini dla wybranego jezyka do tablicy (parse_ini_file) a potem po prostu:
{$lang[costam][costam]}

Napisany przez: krzemian 16.04.2006, 13:53:05

Moim zdaniem prawda znowu leży po środku - wydaje mi się, że pliki są bardzo dobrym rozwiązaniem, jeśli chodzi o teksty formularzy itp. Jednak co, jeśli ktoś będzie chciał tłumaczyć całe artykuły, znajdujące się w bazie? Wtedy najlepszym rozwiązaniem byłoby połączenie systemu pliki+baza.
Wydaje mi się, że można by stworzyć tabele osobno dla każdego języka, np. en_articles, pl_articles itp., bo trzymanie tych danych w jednej tabeli nie miałoby raczej najmniejszego sensu, skoro i tak są one wykorzystywane naprzemiennie, a nie razem.

PS. Nie jedźcie po mnie za bardzo, bo ostatnio w php coś pisałem chyba z pół roku temu:) I wesołych świąt wam życzę.

Napisany przez: NoiseMc 16.04.2006, 15:33:53

[SQL] pobierz, plaintext 
ID | Tytul | Tresc | Lang
[SQL] pobierz, plaintext 

[SQL] pobierz, plaintext 
SELECT * 
FROM tabela
 WHERE Lang=$_GET['lang']
[SQL] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
{$Translation.StronaGlowna}
?>
[PHP] pobierz, plaintext 

Napisany przez: krzemian 16.04.2006, 17:07:31

Teraz tak myślę i doszedłem do wniosku, że twoj podejście jest chyba lepsze od mojego (jeśli chodzi o trzymanie w bazie, bo xml i pliki to dla mnie to samo - wszystko zależy od możliwości serwera itp) - zakładając, że chcę dodać kolejny język, przy twoim podejściu mogę (przynajmniej teoretycznie) dodać go z poziomu panelu, nie grzebiąc w strukturze baz.

Napisany przez: Jabol 16.04.2006, 21:23:09

A co wy na to (suma kilku pomysłów):

[PHP] pobierz, plaintext 
<?php
   function array_path_insert(&$array, $sep, $path, $value)
   {
	   $path_el = http://www.php.net/split($sep, $path);
 
	   $arr_ref =& $array;
 
	   for($i = 0; $i < http://www.php.net/sizeof($path_el); $i++)
	   {
		   $arr_ref =& $arr_ref[$path_el[$i]];
	   }
 
	   $arr_ref = $value;
   }
 
$trans=http://www.php.net/array();
 
foreach(http://www.php.net/file("translations/{$lang}.txt") as $line)
{
  $chunks=http://www.php.net/explode("=", $line);
  http://www.php.net/define("TXT_".http://www.php.net/array_shift($chunks), http://www.php.net/implode("=", $chunks));
  /* define("TXT_".array_shift($chunks), eval(implode("=", $chunks))); // tak jakby chciać tutaj włożyć jakąś logikę */
  /* define("TXT_".array_shift($chunks), str_replace('\n', "\n", implode("=", $chunks))); // tutaj jakby nie chcieć interpretować wszystkiego */
  /* można też zrobić preg_replace z tablicami */
  /* XXX: Ależ mi nachodzi pomysłów. Dla tablicowców-smartowców następna wersja. (funkcje znalazłem w komentarzach do manuala) */
  array_path_insert($trans, '.', http://www.php.net/array_shift($chunks), http://www.php.net/implode("=", $chunks));
}
$smarty->cośtam('lang', $trans);
?>
[PHP] pobierz, plaintext 

Napisany przez: Bora 17.04.2006, 14:11:06

Napisany przez: Fipaj 17.04.2006, 14:24:45

A co, jeśli w tłumaczonym tekście wystąpi znak "=" bądź przełamanie linii?

Napisany przez: Ociu 17.04.2006, 15:28:25

Jabol: Muszę się zgodzić z Borą, wygląd pliku jest podobny do plików INI,a wprowadzenie tego w życie jest bardzije zamotane niż INI. Mój skrypt jest tylko silnikiem (albo słowo ostatnio bardzo popularne - frameworkiem) i nie ja go będe dalej rozwijał. Parse_ini_file jest w php4, pod które skrypt (niestety)...

Pewnie zaraz padnie pytanie: "Po co ten temat ?". Szukam jakieś alternatywy dla plików ini i wielkich tablic.

pozdrawiam

Napisany przez: sf 18.04.2006, 17:56:26

Napisany przez: Jabol 18.04.2006, 18:01:58

Napisany przez: Prph 26.04.2006, 11:57:49

Witam,

Kilka dni temu pisalem klase opbsugujaca jezyk w moim frameworku. Wyglada to tak:

Klasa Language :

__construct($sLanguage = null)
1. jezeli podano w parametrze jezyk, ustaw go.
2. jezeli nie podano go, a ustnieje ciastko z nazwa jezyka (tlumaczenie strony w czasie trwania sesji), to zastosuja taki jezyk
3. w innym przypadku stosuj dod`myslny.

__get() dzieki ktorej w prtosty sposob korzysta,my z jezyka.

W pliku english.php mam tablice:

$aLanguage['main_menu_custam'] = 'SuperTurboMegaGigaUltraString ';

W aplikacji odwoluje sie do tego tak:

$oLanguage->main_menu_custam;

W szablonach wpisuje: {$LANGUAGE.MAIN_MENU_CUSTAM}.

Dziala :]

Napisany przez: Neotion 27.04.2006, 07:20:49

Przepraszam będe pisał bez shifta bo siedze w szkole

w każdym razie:
wg. mnie najlepszym rozwiązaniem jest to które już oferuje pewien mod do php (nie pamiętam niestsety nazwy ale jest nawet jego opis gdzieś w manualu):
polega on na korzystaniu z tablic zawierających całe tłumaczenia stringów i wywoływanie tłumaczeń np poprzez funkcję

[PHP] pobierz, plaintext 
<?php
_("Tłumacz mnie");
?>
[PHP] pobierz, plaintext 

Napisany przez: Bastion 27.04.2006, 07:35:10

takie wlasnie (podobne) rozwiaznie jest w klasie Babel, ktory korzysta z plikow .po / .mo z gettexta. nie trzeba pisac zadnego programu w c++, wystarczy skorzytac z progmau gettext

xgettext example01.php -L php -o pl_PL.po --keyword=_r --keyword=_p

i wycina do pliku po wszystkie ciagi tekstowe poprzedzone funkcja _r i _p

Napisany przez: sadu 27.04.2006, 10:47:56

moze pomoze:

http://www.tutorialized.com/tutorial/Multi-Language-System/12488

pozdro

Napisany przez: Seth 5.05.2006, 13:20:27

Odkopuje temat bo zastanawiam sie nad tym w jaki spsob, zgrabnie pobierac dane z tablicy z jezykami wewnatrz obiektu.

Moja tablica wyglada mnie wiecej tak:

[PHP] pobierz, plaintext 
<?php
$lang['pl_PL'] = http://www.php.net/array(
	  'app' => http://www.php.net/array(
		 'title' => 'Test'
	  )
   );
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
$landSetting = 'pl_PL';
 
require_once($landSetting . '.lang.php');
 
$foo = new Foo($lang[$landSetting]);
 
class Foo {
   var $_lang = null;
 
 
   function Foo(&$lang) {
	  $this->_lang = &$lang;
   }
}
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
Lang::getMsg('app.title', 'pl_PL')
?>
[PHP] pobierz, plaintext 

Napisany przez: splatch 5.05.2006, 21:36:48

Bardzo przydatny temat dla wszystkich którzy odwiedziają ten wątek: http://forum.mojavi.org/index.php?showtopic=1502&st=0

Są tam diagramy które ilustrują istotę działania. Polecam uwadze wszystkich.

Napisany przez: AveNET 20.05.2006, 09:54:11

Mam taką tablicę

[PHP] pobierz, plaintext 
<?php
 
$lang=http://www.php.net/array (
 
'Ave' => 'Łukasz Peroń',
'JK' => 'Jan Kowalski',
 
);
 
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
http://www.php.net/echo $lang['Ave'];
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
{%Ave%}
?>
[PHP] pobierz, plaintext 

Napisany przez: DeyV 20.05.2006, 21:20:50

Napisany przez: g00fy 1.06.2006, 20:23:06

a co powiedzie o languagefactory::GetLang()
a pozniej w miejscach w tpl <? $lang->get('id_slowa');?>
?

Napisany przez: nasty_psycho 4.06.2006, 19:22:50

Moim zdaniem, (ja tak zrobilem w moim programie ktory teraz pisze), w pliku php, zrobic array :
Angielskie:

[PHP] pobierz, plaintext 
<?php
$cp_Lang = http://www.php.net/array(
	"ok" => "OK",
	"yes" => "Yes",
	"no" => "No",
	"user not found" => "User not found");
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
$cp_Lang = http://www.php.net/array(
	"ok" => "OK",
	"yes" => "Tak",
	"no" => "Nie",
	"user not found" => "U?ytkownik nie istnieje");
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
function _($string) {
 
		$string = http://www.php.net/trim(http://www.php.net/strtolower($string));
		$language = $_CFG['system_language'];
		require_once("i18n/lang.$language.php");
 
		if(!http://www.php.net/empty($cp_Lang[$string])) {
			return $cp_Lang[$string];
		} else {
			return $string;
		}
 
	}
?>
[PHP] pobierz, plaintext 

Napisany przez: DooBLER 3.12.2006, 09:13:15

Witam
Odgrzeję kotleta...

Piszę średniej wielkości aplikację i także stanąłem przed problemem wielojęzyczności.

Miałem zamiar rozwiązać to przy pomocy plików językowych zawierających tablice z całymi "zdaniami"

Jednak po przeczytaniu tego tematu zainteresowałem się plikami .po/.mo (zwłaszcza, że miałem z nimi już do czynienia przy okazji tłumaczenia jakiejś gry...)

I teraz mam prośbę do kogoś kto kożysta z tego sposobu tłumaczenia w php.
Proszę o jakieś fragmęty kodu jak się używa tych plików.

I jescze nasówa mi się pytanie czy na serwerze nie musi być coś doinstalowywane żeby obsługa tych plików była możliwa, bo jeśli tak to niestety ten sposób lokalizacji odpada

Pozdrawiam

Napisany przez: NuLL 3.12.2006, 12:55:27

http://forum.php.pl/index.php?showtopic=42371&hl=babel

Napisany przez: cicik 3.12.2006, 17:03:29

Można też skorzystać z TMX, zunifikowany opis XMLowy.

Napisany przez: Sh4dow 4.12.2006, 10:55:20

Nie wiem czy ktoś wogóle o tym słyszał czy używał, ale ja osobiscie pracuje z gettextem. Bardzo szybki, duzo narzedzi okienkowych, z webowymi jest gorzej, chociaz sam juz napisałem cos takiego ale jest jeszcze w wersji wczesnych beta, jesli nie masz tlumaczenia dla klucza, to pokazuje ci sie klucz, niby wymaga od uzytkownika zeby klucze byly pelnymi zdaniami, ale chociaz szablony dla widoku sa czytelniejsze. Problemy: trzeba przygotowywac pliki poprzez kompliacje.
Jeszcze jeden blad to to ze serverrobi cache plikow skompilowanych i przy czestej edycji nie widac poprawek. Ale sa sposoby na obejscie tego problemu

Napisany przez: DeyV 7.12.2006, 23:18:16

Właśnie o gettext była mowa, gdy wspominaliśmy o Babel oraz plikach .mo i .po

Napisany przez: pawkow 21.03.2007, 20:27:11

Problem multijęzykowości rozwiązałem w prosty sposób. Mam taką strukturę katalogów:

Napisany przez: mike_mech 21.03.2007, 20:30:23

Cytat(pawkow @ 21.03.2007, 20:27:11 )

Napisany przez: pawkow 21.03.2007, 21:16:19

musiałbyś poprawić tylko jeden plik, czy się mylę ?

Napisany przez: Zeman 3.04.2007, 21:34:22

Korzystam z autorskiego edytora i 2 pluginów multijezykowych:

1. pierwszy pozwala mi pisać w kodzie php coś takiego

[PHP] pobierz, plaintext 
<?php
http://www.php.net/echo('{*pl:To jest komputer**eng:This is computer*}');
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
http://www.php.net/echo(''.lang_const_1.'');
?>
[PHP] pobierz, plaintext 

Napisany przez: Diabl0 4.04.2007, 01:17:23

Widzę że prawie każdy skupił się tylko na jednej (IMHO prostszej) stronie medalu jakim są teksty stałe. Tutaj w zasadzie pomysły są 2/3 (tablice, pliki ini i pokrewne własne formaty i ewentualnie i18n) różniące się tylko sposobem implementacji. Mnie natomiast interesuje ta ciekawsza strona medalu jaką jest:

Jak rozwiązujecie kwestie wielu języków w bazach danych.

Jak do tego podchodzicie robiąc projekt z założenia 2-językowy (np. pl i en) oraz jak to rozwiązujecie mając w planie pełną wielojęzykowość bez z góry określonej liczby języków. Interesuje mnie nie tylko jak kształtujecie samą bazę ale także typowe odwołania do niej.


W przypadku projektów 2-językowych korzystam głównie z typowej konstrukcji wielokolumnowej:

id | date | title_pl | title_en | content_pl | content_en

dorzucając do niej ewentualnie pole boolean valid_{$lang} określające czy dany język występuje w danym rekordzie.
Użycie w kodzie dość banalne:
$SQL = 'SELECT title_' . $_USER['lang'] . ', content_'' . $_USER['lang'] itd

Natomiast w przypadku projektów wielojęzykowych mam zawsze dylemat jak konstruować bazę danych.

Napisany przez: Sedziwoj 4.04.2007, 01:31:24

Czy mi się wydaje czy to jest jeden 'artykuł' -> wiele wersji? Bo takie określenie podsuwa od razu sposób rozwiązania.
czyli tabele wiążącą 'artykuł' z treścią, coś w stylu:
artykul_id|tresc_id|jezyk_id
(czy coś podobnego, bo język można przecież określić na zbiorze, ale z drugiej strony może być w tabeli języków nazwa skrótowa jak i cała, też ułatwi sprawdzenie jakie języki obsługuje)

Ale to tak na z marszu piszę, do tego mam nikłe doświadczenie, więc lepiej niech ktoś lepszy w tych sprawach skomentuje...

Napisany przez: Athlan 4.04.2007, 07:05:59

Moim zdaniem baza danych w zupełności odpada, bez sensu, przy dużych iloścach informacji czas działania aplikacji zwrasta, a nie o to chodzi. U mnie wszystkie pliki językowe siedzą w plikach:

/Application/Languages/Polish/Polish.Language.php - domyślny plik języka polskiego
/Application/Languages/Polish/Subgrupa_Polish.Language.php - inny plik języka polskiego, przykład:
/Application/Languages/Polish/Register_Polish.Language.php

Budowa takiego pliku jest następująca:

[PHP] pobierz, plaintext 
<?php
 
final class fr_Vlang extends VlangPattern
{
	public $foo = 'C’est le foo.';
 
  public $change_id = 'Polski';
  public $change_sr = 'FR';
 
	public $entry_add_true = 'L’entrée a été ajoutée avec succes! Afficher?';
	public $entry_add_false = 'Erreur de base de données, entrée non ajoutée!';
	public $entry_add_false_text = 'Copiez ici le code a ajouter!';
	public $entry_add_false_token = 'L’identifiant d’autorisation est erroné!';
  public $entry_link = 'Voici le lien vers votre entrée:';
  public $entry_connection_lost = 'Impossible d’accéder au serveur, réessayez.';
 
// itd itd itd...
 
}
?>
[PHP] pobierz, plaintext 

Napisany przez: Sedziwoj 4.04.2007, 10:02:09

Cytat(Athlan @ 4.04.2007, 08:05:59 )

Napisany przez: Zeman 4.04.2007, 11:11:42

Cytat(Diabl0 @ 4.04.2007, 02:17:23 )

Napisany przez: Kayne 4.04.2007, 14:29:46

Hm... Jest trochę prostsze rozwiązanie, z którego ja korzystam. Może i jest przez to więcej rekordów w bazie danych... no ale cóż

Ogólnie koncepcja jest prosta. Mamy tabelę articles:

id | date | title | body | author |lang

Pole lang jest polem CHAR (2) w którym mamy podane np.: pl, en, fr...

Czyli pobranie artykułu po angielsku to po prostu:

[PHP] pobierz, plaintext 
<?php
$test = http://www.php.net/mysql_query('SELECT * FROM articles WHERE lang='en');
?>
[PHP] pobierz, plaintext 

Napisany przez: bela 4.04.2007, 16:52:29

rozwiazanie powyzej jest fajne, ale ma jedna wade: dane w bazie sie powtarzaja

ja uzywam symfony i rozwiazania z tamtego frameworka, czyli mamy dwie tabele w jednej sa dane, ktore sie nie zmieniaja np id uzytkownika, data utworzenia a w drugiej teksty powiazane za pomoca klucza obcego i dodatkowo pole z jezykiem

Napisany przez: Kayne 6.04.2007, 11:48:54

No, powtarzają się, ale jest to bardzo łatwe do zaimplementowania. Odpowiednia budowa tabel w bazie danych a będzie śmigać aż miło

Napisany przez: empathon 9.04.2007, 16:01:43

Ja podobnie jak ~bela używam symfony i uważam tamto rozwiązanie za optymalne. Zarówno pod względem przechowywania elementów interface i treści w bazie danych. Polecam zapoznanie się z tym jak jest to tam http://www.symfony-project.com/book/trunk/13-I18n-and-L10n

Napisany przez: bela 9.04.2007, 19:52:04

jezeli ktos sie zdecyduje na symfony, to radze pobierac przez metode doSelectWithI18n, bo samo doSelect nie pobiera danych z jezykow i za kazdym razem wali selecta.

Napisany przez: cicik 12.04.2007, 21:45:21

Od jakiegoś czasu zastanawiam się na wielojęzykowością w moich projektach i patrząc na potrzeby moich klientów widzę cztery mechanizmy opisujące ich oczekiwania:

1. Klient chce mieć TYLKO z góry określoną liczbę języków.
W takich wypadkach robię po prostu jak kolega wyżej zaproponował, czyli kolumny w tabeli: tytul_pl, tytul_en etc.

2. Klient chce mieć stronę w kilku językach ale one generalnie są niezależne (różne działy etc.).
Wtedy po prostu robię kilka stron, którymi da się administrować z jednego panelu.

3. Klient chce mieć jedną stronę w kilku językach, każdy artykuł w różnych wersjach językowych.
Internauta przełącza się pomiędzy wersjami za pomocą linków (np. chorągiewek z flagami).
W bazie jest to zapisywane jako relacja n do n pomiędzy artykułami i językami gdzie w relacji łączącej jest zapisany tytuł i treść artykułu w odpowiednim języku.

4. Klient chce mieć stronę generalnie w jednym języku (menu etc.) ale poszczególne artykuły w kilku wersjach wyświetlanych na jednej stronie.
Baza jest podobna do tej z pkt. 3.

Przypadek 1. jest szczególną formą jednego z pozostałych.

Napisany przez: faster 30.04.2007, 00:15:28

Cytat(bela @ 4.04.2007, 17:52:29 )

Napisany przez: Siner 13.05.2007, 16:19:31

Ostatnio zastanawiam się nad wyglądem linków wielojęzykowej strony.
Z jednej strony ciekawym rozwiązaniem było by budowanie strony na zasadzie: "example.com/kontakt/" - dla polskiej wersji językowej, a "example.com/contact/" - w przypadku anglojezycznej wersji. Ale co w przypadku gdy np po niemiecku kontakt pisze się tak samo jak po polsku, można zawsze wczytywać język przeglądarki w takim wypadku i zapisywać go do sesji, ale czy to nie będzie "przyrost formy nad treścią"?

Dodatkowa sprawa to zapisywanie jak mają wyglądać linki w danym języku, pobieranie z bazy danych bądź pliku zawsze trochę zmniejszy trochę szybkość
No i jak na takie rzeczy reagują wyszukiwarki, bo zmniejsza to chyba to skuteczność trafności wyników.
Macie jakieś inne ciekawe sposoby na budowanie odnośników na stronach wielojęzykowych?

Napisany przez: Nitryt14 13.05.2007, 17:23:59

Mam podobny problem jezykowy przy tworzeniu strony moich rodzicow.
Maja biuro projektowe, a na stronce chcą miec dane kontaktowe oraz opisy wraz ze zdjąciami budynków przez nich zaprojektowanych.

Wymyśliłem nastepujace rozwiazanie:
- dane stale takie jak dane kontaktowe, wszystkie podpisy (menu, strona główna etc.) przechowywał bym w plikach lang_xx.php
- a dane zmienne (opisy budynków, zdjęć etc.) dodawał bym do bazy danych przy czym każdy język... i tu sie pojawia problem czy lepiej żeby miał osobną baze (np. sim_pl etc.) czy wystarczy osobna tabela (np. opisy_pl etc.)

chyba ze by było jakieś jeszcze lepsze rozwiązanie.

Napisany przez: kubarek 13.05.2007, 20:02:42

moja idea:

[PHP] pobierz, plaintext 
<?php
class language
{
   
   function __construct($language='pl'){
	  $this->language=$language;
	  $this->get_data();
   }
 
   function __get($id){
	  return $this->data[$id];
   }
 
   function get_data(){
	  /* funkcja jakoś pobierze dane językowe, np z bazy danych mysql */
	  /* mogą być to dane zapisane już jako tablica w pliku php */
	  http://www.php.net/mysql_query(); 
	  include 'plik_z_jezykiem_'.$this->language.'.php';
	  /* etc. */
	  $this->data=...
   }
 
}
 
$l='pl';
 
$lang=new language($l);
 
http://www.php.net/echo $lang->10;
http://www.php.net/echo $lang->1337;
?>
[PHP] pobierz, plaintext 

Napisany przez: eai 14.05.2007, 09:41:24

Mój sposób wygląda tak:
Plik Global_Lang.php:

[PHP] pobierz, plaintext 
<?php
 
	$glang[] = 'polish';
	$glang[] = 'english';
	$glang[] = 'spanish';
 
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
 
	$interface['val1'] = null;
	$interface['val2'] = null;
	$interface['val3'] = null;
	//... itd są to indexy które muszą występować w każdym pliku językowym w tym folde
rze
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
 
	$lang['val1'] = 'czesc';
	$lang['val2'] = 'czas';
	$lang['val3'] = 'zegnaj';
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?php
 
	$lang['val1'] = 'hello';
	$lang['val2'] = 'time';
	$lang['val3'] = 'goodbye';
?>
[PHP] pobierz, plaintext 

Napisany przez: Sedziwoj 14.05.2007, 09:51:22

A mnie tak ciągle zastanawia, dlaczego artykuły/newsy itp. idą z id języka do bazy danych, a już np. nazwy działów lecą do plików?
Przecież to są informacje które można modyfikować, jak jeszcze założymy że tych elementów nie można przez panel admina ruszać to można by było podciągnąć pod statyczne elementy, ale przy możliwości dodania języka?

Ale może niech ktoś, kto ma jakieś pojęcie o tym wypowie, bo ja sobie tak gdybam i tylko jedna rzecz przychodzi mi do głowy, która może determinować wybór, aby za każdym razem nie pobierało danych z bazy.
Tylko że baza ma służyć do przechowywania i sprawnej dystrybucji danych...

Napisany przez: siemakuba 14.05.2007, 15:17:27

Pojawił się w tym wątku pomysł, aby trzymać dane zależnie od języków w odpowiednich tabelach, przykładowo:

• Łatwiej dodać język, zakładając, że system wie, które z tabel są "wrażliwe na język" - wystarczy zrobić skrypt kopiujący strukturę tych tabel i zmieniający ich nazwę
• Do obsługi danych używam klas modeli opartych na wzorcu ActiveRecord. Aby pobrać dane z tabeli articles o id=10 robię tak:

  [PHP] pobierz, plaintext 
  <?php
  $this->ArticlesModel->FinById(10);
  ?>
  [PHP] pobierz, plaintext 

  Przy nazwach tabel z dodanym oznaczeniem języka, konieczne by było posiadanie modelu dla każdej tabeli, lub co wydaje mi się prostsze i oczywiste, zbudowanie jakiegoś Factory dla tych modeli - w momencie, kiedy tworzę model, sprawdzam czy jest to tabela wrażliwa językowo i wtedy uruchamiam fabrykę. Dzięki temu, zawsze do danych o artykułach dostanę się przez $this->ArticlesModel (nie potrzebuję mieć, ArticlesPl_Model czy ArticlesDe_Model). Również przy dodaniu języka nie interesuje mnie budowa nowego modelu - factory zrobi to za mnie.
• Może być to również słuszne z punktu widzenia danych na stronie. Przy rozwiązaniu takim: tabela articles (title_pl, title_en, title_de,...) przy wyświetlaniu danych pobierałbym przy wybranym angielskim title_en. A co jeżeli te informacje nie zostały uzupełnione? Mam puste dane? Czy może pokazuję po polsku? Przy wielu tabelach dane te są niezależne od siebie, i taki problem się nie rodzi, a przynajmniej można sobie darować dodatkowe warunki sprawdzające czy mam odpowiednie dane w takim języku (bo rekord dla tych danych zostanie utworzony jeżeli zostaną one dodane w jakimkolwiek języku)

Napisany przez: Sedziwoj 14.05.2007, 19:39:55

Ja bym szybciej jedną tabele `article` i w niej kolumny:
id|lang_id|... PRIMARY KEY (id,lang_id)
bo obie są unikalnym identyfikatorem, zakładając że mam powiązania miedzy artykułami w różnych językach.
A wybieranie to z automatu dodawany jeden warunek, jak nie ma rekordu z takimi warunkami to nie ma, a nie tworzy bóg wie ile tabel.

Napisany przez: siemakuba 15.05.2007, 09:56:56

@Sedziwoj - masz oczywiście rację, zdaje się, że trochę się zapędziłem :)
Jedna tabela z oznaczeniem języka dla każdego rekordu to faktycznie bardziej elegenackie rozwiązanie.

pozdr.

Napisany przez: Black-Berry 24.12.2007, 00:23:58

Dawno nie pisałem na forum dlatego pozdrawiam i witam wszystkich. Sporo siedziałem nad tym tematem i chciałbym pokazać swój sposób i prośić o ewentualny komentarz:

1. Tabela bazy sql "languages" zawiera pola: ID | name | short . Można ona pomiescić dowolną liczbę języków.

2. Przy starcie strony wybierany jest język o ID=1 który jest językiem głównym. Jego parametry zapisane są w sesji: $_SESSION["language"]="polish" $_SESSION["language_id"] = 1 $_SESSION["language_short"] = "pl". Teraz możemy dla całego serwisu wykożystywać te zmienne. Czasem przydają się wszystkie 3.

3. Kliknięcie na flagę języka zmajdującej się gdzieś na witrynie powodujemy zmianę tych 3 zmiennych.

4. Ładowane są odpowiednie pliki które zawierają definicje sztywne np: define( "_COM_NEWSLETTER_TITLE", "Newsletter" ); Zeby wszystko działało gładko każdy komponent ma swój plik z tłumaczeniem np "russian_newsletter.php". Każdy plik zawiera w nazwie język tak żeby przypadkiem sobie nie nadpisać przy wysyłaniu na serwer róznych plików językowych.

5. Każda tabela z tekstami wprowadzanymi do bazy zawiera pole "language" identyfikujący język. Nie tworzę osobnych tabel dla innych języków, dzięki temu przy dodaniu nowego języka nie muszę tworzyc nowych tabel dla każdego komponentu.

==================
6. Zauważyłem, że taki system pozwala na dużo ciekawych rozwiązań np:
--- Można używać języka o ID=1 jako języka głównego a resztę jako reference. Wtedy przy odpowiedniej konfiguracji serwisu jeśli jakieś tłumaczenie nie istnieje łąduje się język główny i informacja, że wyświetlony został język natywny.
--- Można wysłać do tłumacza cały folder lub plik z tłumaczeniami sztywnymi.
--- Zmienną $_SESSION["language_short"] dobrze wykożystuje się do obrazków. Serwis może dla róznych języków załadować np "logo_pl.jpg" lub "logo_en.jpg"

Napisany przez: Nattfarinn 27.12.2007, 11:18:32

A ja się zastanawiam nad sensownością innego rozwiązania wielojęzykowości. Generalnie jeśli chodzi o treści statyczne (czy to formularze, czy proste zwroty na stronach wbudowane w szablon), to rozwiązanie na poziomie plików (sposób dowolny) wydaje się najsensowniejsze. Jeśli jednak chodzi o wielojęzykowość treści podlegających ciągłym zmianom takich jak na przykład artykuły, wiadomości i tym podobne sprawy, rozwiązanie praktycznie musi leżeć po stronie bazy danych.

Myślałem jednak nad rozwiązaniem tego w następujący sposób (to tylko czyste spekulacje, bo nie próbowałem tego wprowadzać w życie).

Tabela odpowiadająca za artykuły (w sensie produkty, bo przykładem będzie wielojęzykowość na potrzeby e-commerce) przechowywane w bazie wg. pewnego bliżej nieokreślonego, przykładowego schematu (typy pól nieistotne):

Tabela: products

Napisany przez: acztery 4.02.2008, 21:53:48

ja stosuję metodę zapisu do bazy każdy element ma swój prefix językowy na tej podstawię identyfikuję wszystko.

Napisany przez: Strzałek 1.03.2008, 12:07:43

W http://phpdoctrine.org/ jest plugin do i18n. Wielojęzykowość staje się wtedy bardzo przyjemna.

http://www.phpdoctrine.org/documentation/manual/0_10?one-page#plugins:internationalization-with-i18n

Napisany przez: Sh4dow 4.03.2008, 10:43:03

a jak w tym doctrine wyglada to tłumacznie ? Osobne tabele ? Bo przy jednej jezykowosci jakos to widze przy powiedzmy 6-10 prawdopodobnie zaczely by sie schody z iloscia rekordow, a nie mowiac juz o wiecej ilosci rekordow powiedzmy z wiadomosciami, opisami, cechami przedmiotow/produktow.
No i czy to by uwzglednialo powtarzajace sie frazy.

Pytam tak bo szukam jakiegos dobrego rozwiazania wielojezykowego i jedynie na chwile obecna gettext jakos dziala, ale to tez ma swoje ograniczenia.

Napisany przez: Strzałek 14.03.2008, 13:08:25

Przykład z dokumentacji doctrine:

news:
id | content

news_translation:
id | title | lang

W tym przypadku dla newsów będą tytuły w różnych językach. A używając doctrine wyciąga sie je tak:

[PHP] pobierz, plaintext 
<?php
//po wykonaniu wcześniejszego Doctrine_Query
 
http://www.php.net/echo $items[0]->Translation['PL']->title; // 'Witaj Świecie'
?>
[PHP] pobierz, plaintext 

Napisany przez: lusiek 22.05.2008, 09:10:58

(sorry za odkop)

Nie można po prostu użyć prefixów w bazie danych? np.
tabela

pl.news
en.news

w PHP:

[PHP] pobierz, plaintext 
<?php
//[...]
 
$lang_prefix = ('pl');
 
 
$sql="SELECT * FROM ".$lang_prefix."news ORDER BY dodano DESC";
//[...]
?>
[PHP] pobierz, plaintext 

Napisany przez: empathon 22.05.2008, 12:00:40

Cytat(lusiek @ 22.05.2008, 10:10:58 )

[PHP] pobierz, plaintext 
<?php
//[...]
 
$lang_prefix = ('pl');
$sql="SELECT * FROM ".$lang_prefix."news ORDER BY dodano DESC";
//[...]
?>
[PHP] pobierz, plaintext 

Napisany przez: radex_p 23.05.2008, 17:52:07

Mam jeden prosty i sprawdzony sposób.

[PHP] pobierz, plaintext 
<?php
http://www.php.net/echo __('Witaj Świecie!');
?>
[PHP] pobierz, plaintext 

Napisany przez: Sedziwoj 23.05.2008, 19:10:41

@radex_p
Co innego tłumaczenie statycznych rzeczy, co innego dynamicznie dodawanych.

Napisany przez: radex_p 23.05.2008, 19:52:53

Co masz na myśli? Te tablice z tłumaczeniami są (o ile dobrze zrozumiałem) statyczne.

EDIT:

Chyba już wiem, co miałeś na myśli. Napisałem "przyporządkowuje". __() nie dodaje tłumaczenia, tylko zwraca tłumaczenie stringa zawartego w argumencie.

Napisany przez: Crozin 23.05.2008, 21:01:49

@radex_p - myślę, że chodziło o np. artykuł dodawany do serwisu. Który tłumaczysz na polski, angielski czy niderlandzki.

Napisany przez: radex_p 24.05.2008, 08:40:48

aaaaa..... Teraz już rozumiem

Napisany przez: Sedziwoj 24.05.2008, 10:25:24

Dokładnie, bo można rozgraniczyć na dwa rodzaje, jeden to to co jest właściwie raz tworzone, czyli komunikaty, teksty np. "Dodaj komentarz" itp. co jest przez nas robione, drugie to są rzeczy dodawane dynamicznie, czyli artykuły, wiadomości czy co tam w aplikacji zaoferujemy. Te drugie są w bazie danych więc, oczywiste jest że wszystkie wersje językowe tam muszą być.
Co do pierwszych, no to już jak widać różne opinie, ja do opisu statusów wykorzystuję bazę danych, bo i tak muszą być w bazie przez FK. Co do tekstów, to można zrobić tak jak już było nieraz podane, przez funkcję, ale tak na prawdę skąd ona bierze te dane, to już inna sprawa, ważne jest że w kodzie widzimy tekst jaki ma się pojawić a nie jakiś jego znacznik.
Można by dyskutować, a co jak nie będzie działać baza danych? Ale tak na prawdę to jak nie działa, to już cała strona też, więc tylko komunikat o niemożliwości połączenia z bazą musi być w pliku zapisany.

Napisany przez: joohn 29.05.2008, 11:32:28

Obecnie korzystam z Symfony i podoba mi sie jak to tam jest rozwiązane.
Przypomne:
Teksty statyczne - XML i funkcja __('tekst')
Teksty dynamiczne - dwie tabele, np. products (id, symbol, item_number) i products_i18n(id,lang,name,description)

Jedyny minus Symfony to jeżeli brak tłumaczenia dla danego obiektu (np. nazwy produktu), wyświetlany jest pusty string, a w mojej aplikacji chciałbym żeby jeśli np. brak tłumaczenia polskiego, było wyświetlane tłumaczenie angielskie domyślnie. Oczywiście da się tak zrobić modyfikując propelowy generator, no ale znów generuje to dodatkowe zapytania do bazy.

Swojego czasu napisałem własny ORM który wykorzystał rozwiązanie jakiego tu jeszcze nikt nie zaproponował
Miałem tabele w bazie danych:
strings
id (int)
lang
content (varchar255)
texts
id (int)
lang
content(text)

gdzie id i lang były kluczem głównym. Jeżeli w którejkolwiek innej tabeli miał być content zależny od języka, oznaczałem to tak:

products
id
symbol
string_name (int)
text_description (int)

ORM w momencie pobierania obiektu z bazy danych, przed przygotowanie query, jeżeli napotkał pola z prefixem "string_" bądź "text_" robił joina z odpowiednia tabela strings bądż texts. Podobnie przy zapisie i uaktualnieniu danych.

Co sądzicie o takim rozwiązaniu? Jego zaleta to taka, że nie muszę projektować dodatkowych tabel _i18n, wystarczy że wszystkie pola zależne od języka będę oznaczał jako string_ bądż text_. Wada to oczywiście dodatkowy join w każdym zapytaniu (ale w symfony jest to samo), koniecznosc napisania wlasnego orm badz zmodyfikowania istniejacego, no i tak jak wcześniej napisałem, problem gdy chcemy korzystać z degradacji języka (czyli nie ma polskiego to angielski, nie ma angielskiego to niemiecki itp)

Napisany przez: Sedziwoj 29.05.2008, 14:18:48

@joohn
Wada, to że wszystkie teksty są wrzucone do jednego worka, czyli tak na prawdę nie wiemy co to jest, tylko tyle że jakieś teksty.

Napisany przez: rzymek01 29.05.2008, 20:01:46

Witam!

Podsumowując, moim zdaniem optymalnym rozwiązaniem:
dla elementów stałych jest utworzenie przykładowej klasy Language:

• każdy język podzielony na części (moduły, sekcje odpowiadające skryptowi)
• format zapisu: php bądź ini
• wynikowo klasa wczytuje odpowiedni język z odpowiednią częścią/częściami, tzn. np. dla części newsów nie wczytuje langów dla części download

• możemy ograniczyć się do jednej tabeli (plus tabela lang, czytaj dalej)
• tabela, która w swoich kolumnach posiada wszystkie niezbędne info
  

  [SQL] pobierz, plaintext 
  [b]artykuly[/b]
  id | autor_id | lang_id | tytul | zawartosc | ogladany | komentarzy | ocena | ... 
  -------------------------------------------------------------------------------------
  1  |    476   |    1    | PHP 6 | content.. |    23    |      9     |   5   | ...
  [SQL] pobierz, plaintext 

  
  
• w takim układzie do wyświetlenia przykładowo listy artykułów pl wystarczy dodać do where,np. lang=1 (gdzie 1 to np. pl):
  

  [SQL] pobierz, plaintext 
  SELECT tytul, ogladany, ocena FROM artykuly WHERE lang = 1
  [SQL] pobierz, plaintext 

  
  
• przy tym rozwiązaniu każdy artykuł ma swoje komentarze (artykuł pl -> komentarze pl)

• potrzebujemy dwóch tabeli (plus tabela lang, czytaj dalej)
• tabela główna, która nie zawiera treści artykułu, lecz inne info na jego temat
  

  [SQL] pobierz, plaintext 
  [b]artykuly[/b]
  id | ogladany | komentarzy | ocena | ...
  -----------------------------------------------------------------------------------------------
  1  |    23    |      9     |   5   | ...
  [SQL] pobierz, plaintext 

  
  
• tabela zawierająca treść artykułów w różnych wersjach językowych
  

  [SQL] pobierz, plaintext 
  [b]artykuly_lang[/b]
  ... | art_id | lang_id | tytul | zawartosc | ...
  -----------------------------------------------------------------------------------------------
  ... |    1   |    1    | PHP 6 | content.. | ...
  [SQL] pobierz, plaintext 

  
  
• przy tym rozwiązaniu komentarze dla każdego artykułu są zbiorcze (czyli mogą występować komenty w różnych językach)

[SQL] pobierz, plaintext 
[b]lang[/b]
id | short_name | name
--------------------------
1  |      pl    | Polski
[SQL] pobierz, plaintext 

Napisany przez: Sedziwoj 30.05.2008, 08:44:00

@rzymek01
Jak masz kolumnę lang, to niech to będzie integer, po co męczyć bazę stringiem, do tego najlepiej lang_id, i tabela gdzie jest id|short_name|name czyli skrócona nazwa języka np. PL i pełna Polski.

Napisany przez: rzymek01 30.05.2008, 13:39:42

racja, mój błąd

nie chciałem już mieszać, bo na początku chciałem zrobić lang_id

Napisany przez: Blodo 6.07.2008, 05:56:10

Kolejny odkop no ale..

Ja uzywam dwoch tabel: jedna dla tzw. metadata czyli ID, kategoria; druga dla samych tlumaczen. Przypisuje im jezyk za pomoca lang_id w drugiej tabeli, I wyciagam z bazy za pomoca JOINa. Ogolnie ten skrypt co mam automatycznie wybiera jezyk przegladarki dla uzytkownika, lub - jezeli nie ma takiego jezyka w systemie - wybiera jezyk domyslny (angielski).

Zakladajac ze w bazie danych nie zawsze bedzie tlumaczenie dla kazdego artykulu w jezyku uzywanym w tym momencie przez uzytkownika, jak moznaby sformulowac zapytanie do SQLa tak aby przy wyciaganiu artykulow dla danej kategorii wyciagalo wszystkie artykuly w wersji jezykowej uzytkownika lub w wersji jezyka domyslnego jezeli poprzednie sie nie powiodlo? Poki co moim rozwiazaniem jest SELECT na wszystkie lang_id, i potem sprawdzanie co wyswietlic a co nie za pomoca PHP, ale to troche badziewne rozwiazanie IMO. Ktos sie natknal na taki problem?

Napisany przez: Sedziwoj 7.07.2008, 08:00:55

@Blodo
Może coś w tym stylu:

[SQL] pobierz, plaintext 
SELECT * FROM base_data AS b LEFT JOIN lang_data AS l ON ( l.base_data_id = b.id AND l.lang_id = x) LEFT JOIN lang_data AS l2 ON (l2.lang_id = y AND l.id IS NULL);
[SQL] pobierz, plaintext 

Napisany przez: Blodo 7.07.2008, 23:24:09

Hmm, dobry pomysl. Co prawda trzeba w php potem sprawdzic ktore pole z tabeli nie jest "NULL", no ale i tak lepiej niz bylo. Dzieki ci za to.

Napisany przez: Sedziwoj 7.07.2008, 23:58:30

Cytat(Blodo @ 8.07.2008, 00:24:09 )

Napisany przez: Albitos 19.08.2008, 15:17:06

Wybaczcie, że odgrzewam temat. Baardzo długo zastanawiałem się nad rozwiązaniem wielojęzykowości w moich skryptach. Końcowo doszedłem do wniosku, że idealnym rozwiązaniem będzie wykorzystanie systemu wbudowanego w OPT oraz kilku ciekawych ulepszeń. Po pierwsze, wszystkie stałe językowe przechowywane są w kategoriach niezależnych od czegokolwiek. Grupujesz jak chcesz, potem wczytujesz te grupy. Wczytanie jednej stałej z grupy powoduje wczytanie wszystkich z danej grupy.

Załóżmy, że mamy takie grupy:

• navigation
• contact
• home
• global

Napisany przez: tomek_swat 12.10.2008, 20:13:47

mam pytanie jak sobie radzicie z wersją językową przechwyconych wyjątków, w każdej klasie jest:

[PHP] pobierz, plaintext 
<?php
throw new exception (..)
?>
[PHP] pobierz, plaintext 

Napisany przez: Crozin 12.10.2008, 21:15:54

Ale w jakim celu tłumaczyć wyjątki? One są raczej informacją dla programu/skryptu, a nie użytkownika.

Możesz:
1) Przeklazać już odpowiednio przetłumaczony wyjątek:

[PHP] pobierz, plaintext 
<?
throw new Exception(myTransolator('invalidABCDE'));
?>
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
<?
class MyException extends Exception{
  public function __construct($msg = '', $code = 0){
    $this->msg = myTranslate($msg);
    $this->code = $code;
  }
}
?>
[PHP] pobierz, plaintext 

Napisany przez: tomek_swat 13.10.2008, 11:43:50

załóżmy, że mam klasę Config, która jest Singletonem i pobiera z pliku .ini wersję jęzkową systemu
jezyk = "pl" i w zależności od tego klasa Lang, parsuję odpowieni plik .ini z folderu gdzie znajdują się odpowiednie wersję językowe
co jeśli w pliku settings.php parsowanym przez klasę Config, użytkownik wpiszę język, który nie jest uwzględniony w folderze w którym znajdują się wersję językowe? pozostaję wypluć wyjątek, tu właśnie pojawia się w problem w jakim on ma być języku i jak ten język zaimplementować w klasie Lang i Config?
pzdr

Napisany przez: Sedziwoj 13.10.2008, 15:23:27

Nie zawsze wyjątki są najlepsze, powinieneś sprawdzić czy dany język istnieje jeśli nie to ustawiany jest domyślny. Jeśli gdzieś w serwisie jest użyte coś, czego nie ma w pliku językowym to jest błąd, i taka informacja też nie musi być rozpowszechniana po prostu wymuszenie przez moduł językowy załadowania informacji o błędzie/braku informacji, to już jest statyczna informacja niezależna od błędu, no i log dla nas aby dojść co się sypnęło.

Napisany przez: test_next 2.07.2009, 10:12:06

Witam,
tak pobieżnie przeglądając odpowiedzi nie widziałem sposobu z definiowaniem zmiennych językowych jako stałe np. define('HELLO_WORLD","Hello world"); echo HELLO_WORLD. Co o tym sądzicie?
Pozdrawiam

Napisany przez: erix 2.07.2009, 10:27:14

Mało przenośne. Co w sytuacji, gdy np. stała konfiguracyjna będzie nosiła tę samą nazwę jak językowa?

Poza tym, wg Twojego schematu idealny byłby http://pl.php.net/gettext.

Napisany przez: test_next 2.07.2009, 11:12:29

tak tylko aplikacja ma być przenośna, a gettext nie wszędzie jest zainstalowany.
No i jeszcze wchodzi w grę licencja tego typu rozwiązań - odpada GPL.

Napisany przez: viking 2.07.2009, 11:23:21

To zainteresuj się Zend Framework (i zanim napiszesz coś o gettext przeczytaj dokładnie dokumentację).

Napisany przez: test_next 2.07.2009, 11:51:36

To include GNU gettext support in your PHP build you must add the option --with-gettext[=DIR]
przeczytałem i ?

Napisany przez: bim2 2.07.2009, 11:54:13

Nie miałem siły przeglądać całego watku, ale moim zdaniem najlepszym wyjściem jest podany 3 posty wyżej przez erixa sposób. http://pl.php.net/gettext Oczywiście jakaś nakładka na to co by zapamiętała jakie frazy używam w systemie i generacja pliku .po A później już z górki :]

Przez 2 lata używałem zwykłych zmiennych includowanych do klasy języków i metodą get() pobierania ich. Ale to nie jest wyjście. Ciężko się połapać w tym wszystkim.

Napisany przez: viking 2.07.2009, 11:56:40

Cytat(test_next @ 2.07.2009, 12:51:36 )

Napisany przez: test_next 2.07.2009, 12:02:54

viking: ok, ale aplikacja jest dosyć rozbudowana i nie ma już sensu przenosić jej na zend'a...

Napisany przez: Crozin 2.07.2009, 12:56:10

Zapewne da się ten komponent "wyciąć" z niego i stosować osobno.

Napisany przez: erix 2.07.2009, 14:18:37

Napisany przez: bim2 2.07.2009, 19:05:16

Wordpress jest najlepszym przykładem. Ja także nie używam gettext(), jedynie się na tym wzoruje. Poszukać w google wystarczy "i18n php" i wyskoczy wiele różnych rozwiązań. Nawet na tym forum jakieś znalazłem

Napisany przez: viking 3.07.2009, 06:19:05

Ewentualnie w PHP 5.3 jest coś takiego http://pl2.php.net/manual/en/class.messageformatter.php

Napisany przez: bim2 3.07.2009, 10:08:04

Tyle, że na php 5.3 na serwerach troche trzeba poczekać Kolega robił update php wczoraj, ale na trójkę się nakłonić nie dał... nie wiem czemu ;/ ("bo wyszła dzisiaj")

Napisany przez: erix 3.07.2009, 12:22:11

Dziwisz się? Osobiście np. Fx-a zaktualizuje za może miesiąc; obie paczki są jeszcze za świeże, nie zostały wystarczająco przetestowane.

Wyjdzie 5.3.1, będzie można się nieco pobujać. [; Ale nie zmieni to faktu, że w ogóle na edycję 5.3 trzeba jeszcze poczekać co najmniej pół roku.

Napisany przez: omeck 7.07.2009, 00:52:47

Tak, do zalet gettext należy to, że jest lekki, szybki praktycznie ogólno dostępny... ale przekonaj klienta, żeby pobrał sobie z serwera pliczek z tłumaczeniami, pobrał i zainstalował sobie dodatkowe oprogramowanie np. poedit, wyedytował, a następnie wysyłał na serwer. Można też zrobić interfejs do aplikacji i generować np poprzez jakiś panel admina... jest jendno 'ale' - generowanie plików z tlumaczeniami, co wiąże się z dostepem do poleceń systemowych na serwerze... chyba malo ogolno dostępne, prawda? :-)
Dodatkowo: http://us2.php.net/manual/en/ref.gettext.php#50424 ;-)

Osobiście szczęśliwie korzystam z Zend_Translate oraz pliczków CSV - lekkie, proste, szybkie, wygodne i można bez zadnych przeszkód napisac do tego gui :-)

Napisany przez: Pr0100 7.07.2009, 02:07:41

Napisany przez: omeck 7.07.2009, 11:42:48

Cytat(Pr0100 @ 7.07.2009, 03:07:41 )

http://packages.debian.org/search?keywords=php5-cgi&searchon=names&suite=all&section=all

dziwisz się mu?

Napisany przez: erix 7.07.2009, 22:02:33

Napisany przez: omeck 7.07.2009, 23:26:29

Cytat(erix @ 7.07.2009, 23:02:33 )

Serwery, których admini wiedzą, co to znaczy suPHP + jail dla procesu, nie mają zablokowanych poleceń systemowych.

Napisany przez: erix 8.07.2009, 11:55:59

Jakoś we wszystkich hostingach, z którymi mam do czynienia, polecenia systemowe nie są zablokowane.

Więc śmiem twierdzić, że to nie jest promil.

Napisany przez: witul 11.07.2009, 02:13:36

A ja stosuje podzial na baze i pliki:
np w cmsie zrobilem sobie ze jezyk jest subdomena serwisump, en.domena.pl czy de.domena.pl.
Szablony stron, teksty i inne elementy pisane sa osobno pod kazdy jezyk.
A jesli chodzi o statyczne teksty typu "Zapisz", "To pole jest wymagane" - wiadomo, pliki.

Napisany przez: jolam 20.08.2009, 10:39:40

Chciałam się poradzić w jednej sprawie dotyczącej spraw wielojęzykowości. Mam stronę w kilku językach, ale podstrony w tych językach niewiele różnią się od siebie. Strona zawiera głównie grafiki. To czy lepiej tłumaczyć fraz na tej stronie czy całą stronę. To znaczy, czy lepiej w kodzie tej strony, między grafikami mieć np $lang['tlumaczonytekst'], czy trzymać w bazie treść strony dla każdego języka i ładować odpowiednią stronę w zależności od wyboru usera? Teraz stosuje pierwsze rozwiązanie ale może tabela kolumnami textid, contentpl, contenten? Czy powinnam zastosować drugie rozwiązanie czy pozostac przy pierwszym?

pozdrawiam Jola

Zapomniałam napisać wprost, przy tej mojej metodzie z jedna stroną i tłumaczeniem fraz mam dużo małych zapytań do bazy. Gdybym zmieniła metodę to miałabym jedno duże zapytanie. Ale musiałabym mieć dwie treści i modyfikacje wprowadzać dwa razy i pamiętać o nich. Co lepsze?

Napisany przez: erix 20.08.2009, 11:53:20

A przeczytałaś cały wątek?

Napisany przez: rzymek01 20.08.2009, 11:57:10

W Twoim przypadku 1. sposób wydaje się lepszy, tylko od razu pobieraj wszystkie langi (dużo ich na pewno nie masz) albo zapisuj je w pliku (lub plikach jak chcesz podzielić na moduły)

Napisany przez: jolam 20.08.2009, 12:01:02

Oczywiście, że przeczytałam ten wątek, co za pytanie. Chcę się jedynie upewnić. Sposób 1 wydaje mi się wygodniejszy, dlatego go wybrałam. Ale obawiałam się o wydajność. Bo to kilka/kilkanaście zapytań do bazy, zamiast jednego dużego.

pozdrawiam Jola

Napisany przez: GregoryW 17.09.2009, 17:05:59

Korzystał ktoś kiedyś ze Smarty Multilanguage? Jeśli tak - jaką to ma wydajność?

Dzięki za info

Napisany przez: nospor 7.10.2009, 08:34:01

Pytanko/dylemat:

Zaznaczam od razu, że nie chodzi mi o artykuły/newsy. Chodzi mi o komunikaty w stylu: "dane zapisano", "Dodaj komentarz" etc.

Do tej pory miałem to w plikach .ini i było wszystko ok. Stanąłem jednak przed problemem, gdzie będę musiał dać klientowi możliwość edycji tych danych w panelu serwisu. Babranie się tu w edycję plików i do tego sensownie to grupować już nie jest takie fajne i przyjemne jak wówczas, gdyby to było wszystko bazie.
Do tego dochodzi problem, że ja mogę uaktualniać moduły i wraz z modułem mogą się uaktualnić pliki z tekstami. Jeśli klient by coś już zmodyfikował to ja przy aktualizacji bym mu to nadpisał.

A więc możliwe dwa rozwiązania:
1) pliki .ini
piszę jakiś systemik do aktualizacji danych. minusem będzie to, że gorzej się go będzie pisało niż dla DB
gdy klient zmodyfikuje jakiś zestaw danych, tworzony jest dodatkowy plik .ini z jego zmianami.
Gdy system będzie musiał odczytać jakiś tekst, szuka go najpierw w plikach zmodyfikowanych a jeśli tam go nie będzie, szuka w moich oryginalnych.
Jak widać trochę latania przy pobraniu tekstu tu będzie. Powiedzmy że bym zastosował cache to może by było znośnie.

2) tłumaczenia w bazie
O optymalność się nie martwie bo bym cacheowal.
Napisanie systemiku do edycji - w miarę proste.
Gdy ja dostarcze aktualizacje modułu z nowymi tekstami to wystarczy wykonać parę insertów i po sprawie - nic nikomu nie nadpiszę.
Minus - całe zarządzanie mam już na plikach .ini i bym musiał do bazy wrzucić wszystkie tłumaczenia jakie do tej pory mam.


Co Wy sądzicie o tym? Mieliście już do czynienia z taką właśnie sytuacją, że trzeba dać klientowi narzędzie do modyfikacji tekstów i mieć na uwadze kolejne aktualizacjie oprogramowania wraz z tekstami?

Napisany przez: vokiel 7.10.2009, 09:43:27

Jeszcze nie miałem takiej konieczności, jednak IMHO łatwiej byłoby w bazie.

• Przy dodawaniu nowych wpisów, nie ma ryzyka, że nadpisze się już istniejące.
• Ewentualne zmiany większej ilości wpisów są szybsze i łatwiejsze.
• Dochodzi możliwość kontroli co kto zmienił, szybkiego wyszukania wpisów edytowanych przez klienta.
• Dzięki powyższemu, w trakcie aktualizacji można wyświetlić wpisy, które były edytowane przez klienta, i zestawić mu je z propozycjami tymi od aktualizacji.
• Nie wiem, czy będziesz potrzebował, ale w przypadku zdalnych poprawek, dostęp do db jest według mnie wygodniejszy niż wysyłanie plików via @, czy przez ftp.
• Może się chyba zdarzyć, że aktualizacja rozszerzy dany wpis o coś nowego, wtedy poprzednia zmiana klienta nie będzie już aktualna i zestawienie mu danych, które mogą wymagać poprawy, lub po prostu zaakceptowania nowej wersji byłoby wygodne.

Napisany przez: nospor 8.10.2009, 10:41:08

Rozpisałeś mi tutaj zaawansowany system w DB: akceptacja, zestawienia.... aż tak bardzo nie chciałem szaleć
No nie rozwiałeś moich wątpliwości. To teoria, z której zdaję sobie sprawę. Mam nadzieję, że ktoś praktycznie miał z tym do czynienia.

edit:
dobra, robie na bazie. na plikach już mam to trzeba zadbac o nowe doświadczenia

Napisany przez: nasty 9.10.2009, 02:19:28

A może zastosuj bazę i zrób małego bota co Ci wrzuci wszystko z tych .ini do bazy?

Napisany przez: nospor 9.10.2009, 19:04:28

juz przepisałem ręcznie

Napisany przez: bim2 11.10.2009, 20:19:02

Wszyscy się zastanawiają jak robić tłumaczenie, ale najprościej moim zdaniem zrobić podobnie jak ma wordpress. Sam tworzyłem teraz czterojęzyczny serwis i wychodzi, że najprościej jest dać np. w templatkach

Napisany przez: cojack 12.10.2009, 15:45:42

Dla statycznych tekstów najlepiej jest użyć gettext. A dla trzymanych w bazie to l18n

Napisany przez: bim2 13.10.2009, 14:23:49

Hmm, ja miast gettext korzystam z własnego sytemu z racji tego, że były problemy z tym gettext. Cachowało mi jakimś cudem plik i nie było możliwośći wgrania najnowszwego pliku. Co do danych typu newsy, mam kolumnę lang i później w zapytaniach where :langW: tzn. where lang = 'pl'

Napisany przez: cojack 13.10.2009, 15:45:56

Dokładnie, to żadna sztuczka ta wielojęzyczność. Mi tam gettext działa bez problemu, tylko to trochę upierdliwe jest z tymi tłumaczeniami ;p trzeba się opisać jak głupi

Napisany przez: Crozin 14.10.2009, 14:26:43

@bim2: chyba osobną tabelę łączoną w relacji 1-1 (z id oraz językiem), a nie samą kolumnę

Napisany przez: bim2 14.10.2009, 16:08:10

No tak. Zależy co masz. Jak mam stronę statyczną gdzie występuje tylko Tytuł i Treść to mam jedną tabelę, bo tytuł też tłumaczymy A id takie samo.

Napisany przez: jmail 14.10.2009, 16:18:12

nie wiem czy ktoś już to pisał :F

ja mam różne języki zapisane w tablicach php i je wrzucam do templatki tak jak pozostałe zmienne. Kwestia pobrania odpowiedniego pliku językowego

Napisany przez: bim2 14.10.2009, 20:58:38

jmail także tak miałem, ale po n serwisach to jest niewydajne w trakcie pisania tego. Musisz dodać sobie do tablicy wpis, później w templatkach {$lang.user} Tylko nie wiesz ci kryje się pod user jakbyś chciał coś zmienić/dodać.

Gettext jest najlepszym wyjściem i radzę Ci się na to przerzucić.

Napisany przez: jmail 14.10.2009, 21:05:19

no jak tam kto uważa. dla mnie to jest wygodne i wydajne nie miałem jakoś probolemów do tej pory i jakoś tam działało ale przejrzę to co proponujesz i zobaczymy

Napisany przez: marcio 22.10.2009, 22:53:05

Ok przeczytalem caly watek wywnioskowalem troche z niego tworzac wlasny "Fw" mysle ze przyda sie standartowa implementacja wielojezykowosci.

Dla stalych tresci zrobie to porostu tak:

Mam komponent news i jego opis autor,data,tresc i tytul i katalog jego widokow czyli:

[PHP] pobierz, plaintext 
 
$err['pl']['badpwd'] = 'Zle haslo';
 
$err['eng']['badpwd'] = 'Bad login';
 
[PHP] pobierz, plaintext 

[PHP] pobierz, plaintext 
 
if(blad podczac logowania) $view -> AddVar('error', $lang -> errors[$lang -> getLang()]['badpwd']);
 
[PHP] pobierz, plaintext 

Napisany przez: bim2 23.10.2009, 20:56:24

Ja byłbym nadal za i18n, nawet dla błędów czyli $lang->get('Wrong login.');

Napisany przez: marcio 23.10.2009, 22:32:06

Czyli jak i gdzie zapisywac bledy?

Bo nie rozumiem.

Napisany przez: bim2 24.10.2009, 10:55:48

Nigdzie. Piszesz błąd jaki wystapił a tłumaczenie działa na zasadzie tłumaczenia całych fraz. Tj. ja mam w bazie danych tabelę langs z kolumnami hash|pl|en|pt|es Hash to md5 frazy, a reszty się chyba łatwo domyślić. Wszędzie piszę domyślnie po polsku czyli jak mam błąd to robię

[PHP] pobierz, plaintext 
 
$form->addError($lang->get('Niepoprawne hasło.'));
[PHP] pobierz, plaintext 

Napisany przez: marcio 24.10.2009, 12:44:14

Wole to trzymac w plikach i zrobic tak jak ja to rozpisalem.

P.S ale dzieki za nastepna metode

Napisany przez: bim2 24.10.2009, 13:28:31

Po 5 zleceniach odechciewa się szukania języków po plikach, sprawdzania poprawiania. Po przerzuceniu się na ten sposób odczujesz wielką ulgę Naprawdę, przestaw się już teraz będzie mniej problemów później :]

Napisany przez: marcio 24.10.2009, 14:01:15

Kazdy komponent/plugin bedzie mial katalog errors a w nim plik z o nazwie takiej samej jak nazwa komponentu/pluginu dane bede zapisywane tak jak podalem wyzej wiec na to samo wychodzi czy pliki czy baza jeden kit.

Tak samo biblioteka tez bedzie mogla miec wlasne bledy w roznych jezykach jesli zajdzie taka potrzeba np lib do upload'u/download'u

Napisany przez: bim2 24.10.2009, 14:22:18

Pomyśl, że chcesz później dodać kolejny język i dać możliwość grupie tłumaczy tłumaczenia tego. Jak to rozwiążesz?

Napisany przez: marcio 24.10.2009, 15:04:41

Dam im plik z errors i do tego pliki widokow a dane dynamiczne jak news'y etc.... to wiadomo.

Napisany przez: bim2 24.10.2009, 15:20:09

Taaak, rozdziel to dla kilku tłumaczy Nie będzie tak łatwo. Zresztą przy n modułach kopiuj sobie wszystkie pliki itd.

Napisany przez: marcio 24.10.2009, 15:30:23

Mysle ze przy latwych stronach metoda moze sie sprawdzic jak nie zawsze bede mogl zmienic implementacje klasy language i tyle

Napisany przez: Crozin 24.10.2009, 15:39:52

Trochę zeszliście Panowie z tematu...

A co do tematu jak tym zarządzać, to... nie ma tematu - przygotowanie prostej aplikacji, która udostępniłaby jakiś w miarę przyjazny tłumaczowi interface to kwestia powiedzmy godzin, by było to w miarę dopracowane.

Jeżeli natomiast chodzi o format przechowywania danych w plikach tekstowych to wartym rozpatrzenia formatem jest oparty o XML XLIFF. Z własnego doświadczenia niewiele mogę powiedzieć o współpracy z tłumaczami przy wykorzystaniu tego formatu, ale ponoć istnieje trochę gotowych aplikacji do operowania na tym i inne firmy chętnie z tego korzystają.

Napisany przez: nowy_pehapowiec 12.01.2010, 18:15:56

Nie wiem na ile moje pytanie pasuje do reszty postów wątku ale:

Czyli lepiej tworzyć adresy z oznaczeniem języka jako subdomena czy nie?

www.strona.com/en/super/hiper/podstrona
czy
www.en.strona.com/super/hiper/podstrona



pozdro

Napisany przez: marcio 12.01.2010, 23:53:28

Co do subdomen czy ogolnie jezyka w url wiem jedno jest to o tyle lepsze ze poprzez url uwzgledniamy odrazu jezyk strony dla user'a bez zadnego wybierania tzn jak wysle link strony php.pl koledze ten nie zna jezyka pl wiec musi wybrac jezyk poprzez podanie mu adresu w stylu www.php.pl/index.php/en/ lub www.en.php.pl user nie musi juz nic zmieniac.

Wedlug mnie zalezy tez ile subdomen masz do dyspozycji i ile jezykow chcesz zaimplementowac.

Jednak sam wyslucham opini innych by wiedziec w czym jeszcze moze sie przydac.

Napisany przez: nowy_pehapowiec 13.01.2010, 06:06:22

Język w ogóle nie musi być widoczny w adresie. Dla użytkownika nie będzie to miało znaczenia, bo przed wyświetleniem czegokolwiek trzeba sprawdzić jakie języki akceptuje przeglądarka usera, w jakiej kolejności itd. A jak był na naszej stronie to odczytujemy jego ciasteczko. Czyli ten sam adres pokaże stronę w różnych językach w zależności od użytkownika. Ale myślę, że dla google lepiej rozróżniać język w adresie. Choć mechanizm pozostaje ten sam: użytkownik trafia na stronę strona.com i tam jest przekierowywany na np strona.com/pl/. Ale właśnie czy lepiej język do adres dodac jako subdomenę czy po nazwie domeny? Co o tym myślicie?

Napisany przez: bim2 25.04.2010, 11:50:43

Ja jestem za subdomenami, ale tylko ze względów estetycznych. Nie widzę różnicy między pl.strona.com en.strona.com a strona.com/pl/ strona.com/en/

Napisany przez: Crozin 25.04.2010, 13:20:35

Napisany przez: melkorm 25.04.2010, 15:48:40

Język powinien być w adresie,a moim zdaniem najlepiej jak jest w subdomenie, szczególnie dla wyszukiwarek : szukamy na angielskim google mamy en.adresstrony.xx a na polskim pl.adresstrony.xx itp więc moim zdaniem jest to największa przewaga tego typu rozwiązania + indeksowanie treści, google będzie miało ten sam adres przy zmianie treści więc zaindeksuje tą treść raz (w przypadku braku języka w adresie).

P.S. Nie jestem w tym specjalistą i to są tylko moje luźne spostrzeżenia
P.S. Szczerze chciałbym usłyszeć pogląd specjalisty od pozycjonowania na temat : "Językowość, a wyszukiwarka."

Napisany przez: nowy_pehapowiec 26.04.2010, 09:16:28

A może jednak w ogóle nie uwzględniać języka w adresie strony? Wystarczyłoby sprawdzić jaki jest język przeglądarki i na podstawie tego poprzez sesje albo ciasteczka automatycznie wyświetlać treść w odpowiednim języku. I też user nie musi nigdzie klikać, chyba, że zechce. Wtedy wszystkie linki przychodzące byłyby do jednej strony a nie byłyby rozdzielone na dwie strony o różnych adresach. Ale co z indeksacją strony? Czy google będzie raz indeksować dla en a raz dla pl?

pozdro

Napisany przez: Riklaunim 26.04.2010, 15:20:25

Będzie zmienna treść co jest trochę bez sensu. Można wykorzystać język przeglądarki, ale nie jest do pewne rozwiązanie. Najlepsze to dwie oddzielne pod/strony - łatwe zarządzanie i obie z nich mogą mieć różną zawartość.

Napisany przez: nowy_pehapowiec 26.04.2010, 15:47:53

Riklaunim treści przecież mogą być różne. W bazie mogą być pole z treścią w kilku językach. A i szablony i style mogą być ładowane różne dla różnych języków. I to nawet dobrze działa, ale ma ten minus zmiennej treści, o czym pisałeś. Czy wiesz jak google indeksuje taką stronę?

pozdrawiam

Napisany przez: Riklaunim 27.04.2010, 18:09:36

Cytat(nowy_pehapowiec @ 26.04.2010, 16:47:53 )

Napisany przez: nowy_pehapowiec 27.04.2010, 18:40:58

Tego chciałem się dowiedzieć, czy da się dobrze taką stronę zaindeksować -jeśli nie to sprawa jest oczywista. Ale chyba dla domyślnego języka nie ma potrzeby tworzenia subdomeny?
strona.com - dla poslkiej strony
en.strona.com - dla angielskiej
fr.strona.com - dla francuskiej

pozdro

Napisany przez: jareeny 30.04.2010, 18:38:54

według mnie, sprawdzać język przeglądarki można wtedy, kiedy się chce na wejściu ustawić domyślny język strony czyli:

język przeglądarki: polski, treść domyślna: polska
język przeglądarki: angielski - redirect na en.site.pl
język: chiński - redirect ch.site.pl

no a jeżeli domyślny język nie byłby polski no to

język przeglądarki: polski - redirect pl.site.com

obojętnie

Napisany przez: kuzdo 10.07.2010, 20:46:25

Witam,

Trochę odgrzebię temat, ale mam problem ze zrozumieniem pewnej rzeczy... Były tutaj podawane sposoby zapisywania dynamicznych treści do bazy i jedną z nich była jedna tabela z kolumną lang, w której był określony język wpisu... Co w przypadku, gdy użytkownik wejdzie w taki wpis, zobaczy, że jest też jego polska wersja i będzie chciał się na nią przełączyć, bo np. zna jako tako polski, a może być tam więcej informacji? ID takich wpisów jest inny, a subdomeny nie wchodzą w grę...

Pozdrawiam.

Napisany przez: vokiel 10.07.2010, 21:00:15

@kuzdo
Tu nie ma problemu. Masz np taka strukturę tabeli:

[HTML] pobierz, plaintext 
<http://december.com/html/4/element/a.html href="wpis.php?id=2">zobacz wpis w en</http://december.com/html/4/element/a.html>
<http://december.com/html/4/element/a.html href="wpis.php?id=3">zobacz wpis w ru</http://december.com/html/4/element/a.html>
[HTML] pobierz, plaintext 

Napisany przez: eai 10.07.2010, 21:01:52

Dlaczego? PrimaryKey to może być para kluczy. ID i LANG.

Napisany przez: soomal 17.10.2010, 00:46:05

Rozważał ktoś na tych 8 stronach czy w wielu językach lepiej stosować nadmiarowe dane w tabelach czy normalizacje i podział na dwie tabele?
Chodzi mi o sytuację, gdy jakiś zasób ma cechy wspólne dla wielu wersji (np. grafika, przypisanie do kategorii, parametry systemowe) oraz różne (tytuł, opis, itd.).
Normalizacja w tym przypadku wydaje się mieć dużo wad: JOIN przy każdym zapytaniu, ograniczone stosowanie indeksów, jednak w cms firmy, w której pracuje tak właśnie sa zaimplementowane wersje językowe (!?)

Napisany przez: Dyktus 8.08.2011, 16:36:24

Wiem, że ostatnia odpowiedź była w zeszłym roku, lecz nie chcę zaśmiecać forum.

Skorzystałem z opisanych tu sposobów tzn. mam plik załóżmy pl.php

Napisany przez: nospor 8.08.2011, 16:39:30

str_replace()

Napisany przez: dreaken 14.08.2011, 10:19:53

Do maili najlepiej zrobić sobie specjalny systemik który będzie obsługiwał do nich szablony, a w szablonie maila użyć systemu językowego to nie problem.

Napisany przez: dstp 26.01.2012, 12:23:41

przekopałem cały temat, ale nie znalazłem odpowiedzi na swoje pytanie.. piszę prosty sklep internetowy i stanąłem przy wrzucania produktów z panelu administracyjnego. Mam kilka języków w sklepie i chciałbym, żeby do każdego produktu można było dodać opis i cenę w innym języku. Myślałem, żeby dodać kolumnę do tabeli "LANG", coś takiego:

id | cat | name | desc | price | LANG

i przy dodawaniu produktu wrzucać tyle rekordów ile jest języków, tylko w ostatniej kolumnie zmieniać LANG

chyba, że znacie jakieś lepsze rozwiązanie

Napisany przez: Adi32 15.06.2012, 10:58:36

Witajcie.

Przekopałem się przez temat i kilka razy padła odpowiedź na moje pytanie ale może jednak coś się zmieniło gdyż temat dawno zamarł.

Stworzyłem w miarę uniwersalny sklep w którym admin (owner) ma możliwość dodawania dowolnej ilości języków, treści stałych jak i opisów produktów, newsów itp i jest to rozwiązane wydaje mi się w najlepszy możliwy sposób.

Ogólne teksty na stronie:

Tabela jezyk = id | nazwa | skrot
Tabela fraza = id_jezyk | fraza // id jezyk 0 to opis frazy w języku polskim

Dla produktów, kategorii i newsów jest

Tabela produkt id,nazwa i inne | id_jezyk

Użytkownik ma domyślny język w sesji.
Tabele związane z językiem są cachowane więc baza nie jęczy.

Dzięki temu wszystko dzieje się szybko. Admin ma możliwość zmieniać tłumaczenia przez CMS dla każdego języka i frazy.
Jeżeli chodzi o produkty to rozwiązania są 2:
1 - dla innego języka inny produkt
2 - produkt ten sam ale opis, nazwa, cena (waluta, vat) z tabeli łączonej

ale to już zależy od klienta, mam zrobione 2 opcje łatwo przełączalne.

Co o tym myślicie?

Napisany przez: erix 25.07.2012, 08:46:27

A jak rozwiązujesz tłumaczenie treści z bazy? Tzn. produkty i opisy w innych językach.

Bo cache cachem, ale nieskończonej pojemności też nie ma.

Napisany przez: Regz 22.10.2015, 07:44:08

Ostatnio napisałem na szybkości coś takiego co do samego wyboru języka, może komuś się przyda

[PHP] pobierz, plaintext 
	$langs_array = ['pl', 'en', 'fr'];
	$default_lang = 'pl';
 
	if(http://www.php.net/isset($_SESSION['SESSION_LANG'])):
		if(!http://www.php.net/in_array($_SESSION['SESSION_LANG'], $langs_array)):
			$_SESSION['SESSION_LANG'] = $default_lang;
		endif;
	else:
		$input = http://www.php.net/strtolower($_SERVER['HTTP_ACCEPT_LANGUAGE']);
 
		$pattern = '/;q=([0-1]{0,1}.\d{0,4})/i';
 
		$user_languages = [];
 
		foreach(http://www.php.net/explode(',', $input) as $lang):
			$user_languages[] = http://www.php.net/preg_replace($pattern,'',$lang);
		endforeach;
 
		http://www.php.net/unset($input, $pattern, $lang);
 
		$selected_language = '';
 
		foreach($user_languages as $lang):
			if(http://www.php.net/in_array($lang, $langs_array)):
				$selected_language = $lang;
				break;
			endif;
		endforeach;
 
		if(http://www.php.net/empty($selected_language)):
			$_SESSION['SESSION_LANG'] = $default_lang;
		else:
			$_SESSION['SESSION_LANG'] = $selected_language;
		endif;
 
		http://www.php.net/unset($user_languages, $selected_language);
	endif;
 
	$lang = filter_input(INPUT_GET, 'lang');
 
	if(!http://www.php.net/empty($lang)):
		if(http://www.php.net/in_array($lang, $langs_array)):
			$_SESSION['SESSION_LANG'] = $lang;
		else:
			$_SESSION['SESSION_LANG'] = $default_lang;
		endif;
	endif;
 
	include $_SESSION['SESSION_LANG'] . '/index.php';
 
	http://www.php.net/unset($lang);
 
[PHP] pobierz, plaintext