[PHP] Talenselectie?

[UltimateB]

Ik wil een talenselectie gaan maken voor mijn website. Nu ben ik op 2 verschillende mogelijkheden gekomen en ik heb over allebei wel wat goeds te zeggen.

1e mogelijkheid is alle texten uit een MySQL db te halen. Op deze manier zal het makkelijk mogelijk zijn om meerdere talen in te voeren zonder dat er verder iets hoeft te gebeuren aan de HTML/PHP.

2e mogelijkheid is om alle paginas te vertalen en dan aan de hand van de taal de verschillende paginas op te halen. Dit zorgt misschien voor wat meer overzicht aangezien niet alle texten maar een stukje php zijn.

Wat denken jullie dat de beste methode is? En zijn er misschien ook nog andere manieren waarop dit te realiseren is?

[Shedman]

Je kunt ook nog text-files maken met de verschillende talen, die je dan aan de hand van een (sessie)variabele include in je pagina's.

Wat de beste methode is is denk ik heel persoonlijk.

[djluc]

http://nl3.php.net/gettext

[NMe]

Ik denk dat ini files een goede optie zijn, of beter: een PHP pagina waar je een aantal arrays maakt voor alle taalafhankelijke code. Kijkt maar eens hoe het in PHPBB gedaan wordt.

[NMe]

djluc schreef op 08 juni 2004 @ 23:43:
http://nl3.php.net/gettext

Is die niet afhankelijk van locale en daarom minder compatible?

[djluc]

NMe84 schreef op 08 juni 2004 @ 23:46:[...]Is die niet afhankelijk van locale en daarom minder compatible?

Ik heb er geen ervaring mee. Het is echter wel iets wat er speciaal voor bedoeld is en wat dus toch wel aardig zou moeten werken. In ieders geval iets om eens naar te kijken voor je zelf aan de slag gaat met het maken van iets dergelijks.

[llevering]

Ik werk zelf meestal met één of meerdere arrays, waarin alle teksten staan, maar dit zou ik alleen aanraden als je niet al teveel tekst op je pagina hebt staan. Bij lange teksten is een db oplossing beter. Alle pagina's echt dubbel maken zou ik niet doen, stel dat je wat aan je lay-out gaat veranderen, dan is dit (ok afhankelijk van hoe je het implementeert) waarschijnlijk meer werk.

[MisterData]

Ik zou templates gebruiken Zie dit topic: [rml][ php] vraagje voor gebruik templates[/rml]

[maartenba]

Voor kleine dingen doe ik het met een eenvoudige cookie en een if structuur:

code:

<?PHP
$lang = $_COOKIE['lang'];

if ($lang == 'nl') {
?>
Nederlandse teksten etc. hier
<?PHP
}
?>

Enkel ergens je cookie "lang" instellen, en per taal een if-blokje toevoegen aan je pagina's...

[Helmet]

Een combinatie van sessies, templates en arrays met talen erin is wat ik ooit gebruikt heb voor een project, dit werkt goed en snel

PHP:

$lang = array();
$lang['NL'] = array('total' => 'totaal:',
                   'months' => array('jan','feb','ma','apr',
                                     'mei','jun','jul','aug',
                                     'sep','okt','nov','dec'));

in je index bijvoorbeeld:

PHP:

session_start();
if (!isSet($_SESSION['language'])) { $_SESSION['language'] = 'NL'; }
if (isSet($_GET['lang']) && in_array($_GET['lang'],$lang)) { $_SESSION['language'] = $_GET['lang']; }
$l = $_SESSION['language'];
// Initialisatie van de template en zetten van een waarde uit
// de array
$tp = new Smarty();
$tp->assign('lang_total',$lang[$l]['total']);

offtopic:
800e post

[ Voor 233% gewijzigd door Helmet op 09-06-2004 09:01 . Reden: layout enzo ]

[Rac-On]

Als je een kleine webpagina hebt, kan je de pagina's gewoon een paar keer bouwen, in verschillende mapjes knikkeren en er 1 welkomsscherm voor zetten. Als je alles nets met stylesheets doet, is dit een redelijke oplossing.

Voor grotere sites zou ik voor een db oplossing gaan. Zelf gebruik ik een db met alle stukken tekst, en aan het begin van de pagina haal ik alle tekst voor die pagina in de gewenste taal op, en zet ze in een array. Gedurende de code zie je dus regelmatig

PHP:

<?= $texten[welkom] ?>

[NMe]

rac-on schreef op 09 juni 2004 @ 09:01:
Als je een kleine webpagina hebt, kan je de pagina's gewoon een paar keer bouwen, in verschillende mapjes knikkeren en er 1 welkomsscherm voor zetten. Als je alles nets met stylesheets doet, is dit een redelijke oplossing.

Voor grotere sites zou ik voor een db oplossing gaan. Zelf gebruik ik een db met alle stukken tekst, en aan het begin van de pagina haal ik alle tekst voor die pagina in de gewenste taal op, en zet ze in een array. Gedurende de code zie je dus regelmatig

PHP:

<?= $texten[welkom] ?>

Waarom zou je die talen in een DB zetten als je een simpele PHP pagina kan maken waarom die arrays gedefiniëerd worden, en die je dan simpelweg alleen maar hoeft te includen? Bestandsnamen als NL_nl.lang.php maken het dan sowieso heel makkelijk.

[drm]

Voor de korte steekzinnen die je op een site gebruikt gebruik ik een class die eigenlijk gettext nadoet, met een klein beetje meer functionaliteit. Gettext levert inderdaad met locales nog wel eens wat gedonder op en ik vond het destijds handiger om zelf even wat te schrijven dan elke keer te blijven klooien met die locale-toestanden.

Dan moet je denken aan dingen als "Verzenden", "Terug", etc etc.

NMe84:
Waarom zou je die talen in een DB zetten als je een simpele PHP pagina kan maken waarom die arrays gedefiniëerd worden, en die je dan simpelweg alleen maar hoeft te includen? Bestandsnamen als NL_nl.lang.php maken het dan sowieso heel makkelijk.

Voor pagina's (inhoudelijk) gebruik ik liever een database.

Er zijn dan natuurlijk ook weer meerdere mogelijkheden. bijvoorbeeld een paginatabel die ongeveer het volgende weergeeft:

code:

nederlands
  + home
      +  pagina a
      +  pagina b
      +  pagina c
engels
  + home
      +  pagina a
      +  pagina c

Dit vind ik zelf niet zo handig, omdat je dan pagina's (waar vaak hetzelfde in staat) meerdere keren aan moet maken enzo. Het voordeel is dat je heel goed twee inhoudelijk verschillende "sites" kunt maken. Denk dan aan pagina's die bijvoorbeeld voor landen buiten nederland wel interessant zijn, maar voor 't binnenland niet.

Mijn voorkeur heeft echter de volgende benadering:
[list]• tabel page
page_id
parent_page_id
name
• tabel locale
locale_id
locale_abbr
name
• tabel page_locale
page_id
locale_id
title
content
etc...

De tabel page_locale fungeert dan als koppeltabel tussen page en locale. De title en content-velden zijn dus attributen bij die relatie. Dat moet je zo zien: "Als je deze taal beschikbaar maakt (koppeling tussen pagina en locale) moet je deze attributen erbij geven (title en content in die taal)". Daar ben je iets minder flexibel dan bij die hierboven, maar het is veel beter onderhoudbaar.

[Verwijderd]

Toevallig ben ik bezig met mijn cms voor een talen selectie. Wat heb ik gedaan

Heb volgende tabellen


PAGES

page_id (int) primary auto increase

CONTENT
Hier komt de content voor elk pagina.

content_id (int) primary auto increase

page_id (int)

content (text)

language_id (int)

LANGUAGES
(Hier zitten alle talen die je kan gebruiken)

language_id (int) primary auto increase

language_name(int)

Ik roep een pagina vb

code:

index.php?page=1&language_id=1

Met mysql zeg ik dan

code:

select * from CONTENT where page_id=$page AND language_id=$language_id

dit is nog de simpele versie hoor. In de praktijk doe ik nog veel meer erbij. Want eigenlijk wil je zoiets aanroepen

code:

index.php?page=1&language=en

Dan moet je dus eerst in LANGUAGES de language_id opzoeken en dan pas

code:

select * from CONTENT where page_id=$page AND language_id=$language_id

uitvoeren

Dus per pagina heb je verschillende content.

[drm]

ThaLyric:
Dan moet je dus eerst in LANGUAGES de language_id opzoeken en dan pas

code:

select * from CONTENT where page_id=$page AND language_id=$language_id

uitvoeren

't Is voor jou denk ik wel handig om eens te kijken naar JOINS, want dit kan namelijk gewoon in 1 query *klikkerdeklik*

[Verwijderd]

Missschien moet hij ook eens kijken naar gevaren met SQL Injection attacks...

[Verwijderd]

drm schreef op 09 juni 2004 @ 15:32:
[...]
't Is voor jou denk ik wel handig om eens te kijken naar JOINS, want dit kan namelijk gewoon in 1 query *klikkerdeklik*

Hehe .. ja .. klopt ... zoals ik al zei ... dit was nog maar de simpele uitleg. Zelf gebruik ik ook ook join om zeg maar

code:

index.php?page=1&lang=en

goed te verwerken.

[UltimateB]

Hmm, wordt het niet gigantisch langzaam als je een php pagina hebt die alle stukken text in een array zet?

Hmm, misschien een idee eens een testje te timen en kijken wat sneller is

[Verwijderd]

Verwijderd schreef op 09 juni 2004 @ 10:40:
Toevallig ben ik bezig met mijn cms voor een talen selectie.

...

Dus per pagina heb je verschillende content.

Hoe onderhoudt je dat eigenlijk visueel voor de gebruiker? is hij simultaan de talen aan het bijwerken, of moet hij per taal steeds dezelfde aanpassing maken?

[NMe]

Ultimateb schreef op 09 juni 2004 @ 17:08:
Hmm, wordt het niet gigantisch langzaam als je een php pagina hebt die alle stukken text in een array zet?

Hmm, misschien een idee eens een testje te timen en kijken wat sneller is

PHP is juist lekker snel met arrays en strings, ik denk dat een query op een (grote) database meer tijd in beslag neemt. Maar beide methodes zullen bij de gemiddelde pagina echt niet meer dan een halve seconde in beslag nemen.

[Verwijderd]

Verwijderd schreef op 09 juni 2004 @ 20:32:
[...]


Hoe onderhoudt je dat eigenlijk visueel voor de gebruiker? is hij simultaan de talen aan het bijwerken, of moet hij per taal steeds dezelfde aanpassing maken?

jah ... daar ben ik nog niet over uit ;-) .... de engine is er al klaar voor ... nu alleen de backend van de cms ...

[Verwijderd]

Verwijderd schreef op 09 juni 2004 @ 22:11:
[...]


jah ... daar ben ik nog niet over uit ;-) .... de engine is er al klaar voor ... nu alleen de backend van de cms ...

Ik vondt het maar een kvtwerkje omdat als ik klanten artikelen liet toevoegen in 1 taal die andere talen dan NULL tekst hadden. Dus dan voegde ik daar de waarden in van de geselecteerde taal, en gaf dan een -ingevoegd type afhankelijke- popup voor, die vanuit een wijzigingen-tabel kon zien wat aangepast moest worden, en of de wijziging nog moest/verplicht was. bovendien was het admin gedeelte ook taal selecteerbaar, dus je kon hem op zn nl bewerken en dan kreeg je popups voor alles behalve nl, maar je zou ook vanuit het duits kunnen werken en dan nl popups krijgen.

Maar goed, ik vondt het geen mooi systeem, maar dat was het beste dat ik toen kon bendenken, daarom ben ik benieuwd wat er hier uit komt...

[ Voor 3% gewijzigd door Verwijderd op 10-06-2004 08:51 ]

[Basszje]

Ik ben hier laatst ook al mee bezig geweest hiermee en er is weinig concreets te vinden op het internet behalve bovenstaande oplossing die voor mij allemaal net niet afdoende waren.

Ik heb een applicatie met een duizental teksten voor de interface die vaak herhalend is per interface ( denk aan een save button enzo). Die wil ik dan ook niet tig keer opnieuw gaan vertalen en intypen. ( zeker niet als je 10 talen oid hebt )

Ik heb een systeem bedacht wat in de database een table heeft die de pure taal per taal regelt. Oftewel de 'bibliotheek' van aanwezige vertalingen.

Daarnaast heb ik een tabel die de instellingen voor elke pagina regelt. Deze bewaart in een array (verreweg het snelste ophalen / 1 query per pagina ) alle vertalingen voor een bepaalde pagina.

Indien een nieuwe pagina aangeroepen wordt deze automatisch in de database toegevoegd en gaat de applicatie kijken of er vertalingen voor bepaalde strings aanwezig zijn. Dit kost eenmaling een paar seconden.

In de scripting zelf staat alleen maar een functie call per tekst in de trant van :
Language->GetText("Blaap");

code:

CREATE TABLE `tbl_language_interface` (
  `LANGIF_ID` int(11) NOT NULL auto_increment,
  `SCRIPT_ID` int(11) default NULL,
  `SCRIPT_NAME` varchar(100) default NULL,
  `LANGUAGE_ID` int(11) default NULL,
  `LANG_ARRAY` text,
  PRIMARY KEY  (`LANGIF_ID`)
) TYPE=MyISAM;

CREATE TABLE `tbl_pure_language` (
  `PURELANG_ID` int(11) NOT NULL auto_increment,
  `FIRST_LETTER` char(1) default NULL,
  `LANGUAGE_ID` int(11) default NULL,
  `TEXT` text,
  `PURE_TEXT` varchar(50) default NULL,
  `NOTUSEDTEST` int(11) default '0',
  PRIMARY KEY  (`PURELANG_ID`)
) TYPE=MyISAM;

Let niet op het kleine letter gebruik, dat doet de testomgeving ( mysql - windows ) automatisch.

Dus het gaat ongeveer op deze wijze :
Pagina laadt taal object en check aanwezigheid in de db( eerste tabel)
Voegt de pagina toe of laadt de objecten
Bij iedere gettext -> kijken in geladen array of tekst bestaat.
if not -> kijk in pure language
als hij daar bestaat, voeg toe aan huidige language_interface array
als hij niet bestaat, geef melding.

En so on. Works like a charm

[Verwijderd]

Heb het nu zo opgelost.

Bij de overzicht van pagina's heb je ergens boven in de keuze tussen verschillende talen. Afhankelijk welk taal je gekozen heb, zal je de titel van die document zien in de overzicht. Dus voorbeeld (taal is Nederlands) van een overicht van pagina's

- Welkom bij
- Profiel

en als ik dan op English klik dan wordt de overzicht opnieuw opgebouwd maar dan met de Engelse titles dus :

- Welcome
- Profile


Als je een nieuw pagina aanmaakt bijvoorbeeld in NL en je slaat deze op, dan zal er een EN versie aangemaakt worden met dezelfde waardes als NL, alleen de actief waarde van de pagina staat uit. Actief waarde is een veld, waarmee je aangeeft of de pagina actief staat.

Dus bijvoorbeeld

code:

?page=2&lang=1

zal pagina 2 opzoeken met lang_id is 1 (dat is NL).

als ik dan

code:

?page=2&lang=2

doe, dan zal het systeem zeggen dat de pagina niet bestaat. Dus de bezoeker kan het niet zien, maar de gebruiker van de CMS wel.

[Verwijderd]

Basszje schreef op 10 juni 2004 @ 09:55:
Ik ben hier laatst ook al mee bezig geweest hiermee en er is weinig concreets te vinden op het internet behalve bovenstaande oplossing die voor mij allemaal net niet afdoende waren.

Ik heb een applicatie met een duizental teksten voor de interface die vaak herhalend is per interface ( denk aan een save button enzo). Die wil ik dan ook niet tig keer opnieuw gaan vertalen en intypen. ( zeker niet als je 10 talen oid hebt )

Ik heb een systeem bedacht wat in de database een table heeft die de pure taal per taal regelt. Oftewel de 'bibliotheek' van aanwezige vertalingen.

Daarnaast heb ik een tabel die de instellingen voor elke pagina regelt. Deze bewaart in een array (verreweg het snelste ophalen / 1 query per pagina ) alle vertalingen voor een bepaalde pagina.

Indien een nieuwe pagina aangeroepen wordt deze automatisch in de database toegevoegd en gaat de applicatie kijken of er vertalingen voor bepaalde strings aanwezig zijn. Dit kost eenmaling een paar seconden.

In de scripting zelf staat alleen maar een functie call per tekst in de trant van :
Language->GetText("Blaap");

...

Dus het gaat ongeveer op deze wijze :
Pagina laadt taal object en check aanwezigheid in de db( eerste tabel)
Voegt de pagina toe of laadt de objecten
Bij iedere gettext -> kijken in geladen array of tekst bestaat.
if not -> kijk in pure language
als hij daar bestaat, voeg toe aan huidige language_interface array
als hij niet bestaat, geef melding.

En so on. Works like a charm

Ow, dat is ongeveer hoe mijn systeem ook werkt, maar het vervelende is dus dat ik een winkelwagen meertalig moest doen en dat de artikelen dus ook meertalige teksten hebben. Als je dan een artikel toevoegd kan het niet op actief totdat je alle talen toe hebt gevoegd enz...

Viel niet mee.

[Basszje]

Alle lossen onderdelen, dus afgezien van de interface waren al voorzien van een aparte taal-text tabel, dus dat werkt op een andere manier bij mij

[Verwijderd]

Basszje schreef op 10 juni 2004 @ 11:10:
Alle lossen onderdelen, dus afgezien van de interface waren al voorzien van een aparte taal-text tabel, dus dat werkt op een andere manier bij mij

Ik heb niet gezegd hoe ik het in de db geregeld heb, ik heb alleen verteld hoe ik controleerde dat de data in de verschillende taal tabellen in orde bleef...

Maar dit gaat dus over het inwendige van het systeem. Ik ben wel benieuwd naar de interface voor de admin. Hoe werkt dat ongeveer ??

Hoe voegt hij iets toe, hoe doe je dat voor de andere talen waarin hij dus nog geen tekst heeft geplaatst. enz....

[Basszje]

Verwijderd schreef op 10 juni 2004 @ 11:16:
[...]
Maar dit gaat dus over het inwendige van het systeem. Ik ben wel benieuwd naar de interface voor de admin. Hoe werkt dat ongeveer ??

Hoe voegt hij iets toe, hoe doe je dat voor de andere talen waarin hij dus nog geen tekst heeft geplaatst. enz....

Je kan onder een speciaal admin account inloggen op het systeem. Dan krijg je een selectie balk om je taal mee te kunnen veranderen ( page refresht, wordt getoond in andere taal)

Onder de interface zelf komen een aantal textbalkjes waar de gevonden velden in staan met de eventuele vertaling ( of leeg ). Invullen op save rammen en je hebt voor een taal die interface veranderd. Eens in de zoveel uur draait er een cron die een bepaalde verandere tekst voor het hele systeem doorvoeren

[Banpei]

Basszje schreef op 10 juni 2004 @ 09:55:
Dus het gaat ongeveer op deze wijze :
Pagina laadt taal object en check aanwezigheid in de db( eerste tabel)
Voegt de pagina toe of laadt de objecten
Bij iedere gettext -> kijken in geladen array of tekst bestaat.
if not -> kijk in pure language
als hij daar bestaat, voeg toe aan huidige language_interface array
als hij niet bestaat, geef melding.

En so on. Works like a charm

Ziet er goed uit. Puike oplossing imo. Dat ondervangt het probleem dat we al eerder geconstateerd hadden bij dat je in gettext alles zou moeten definieeren en op deze manier veel vertalingen centraal kan houden.

offtopic:
Kan ik me kont niet keren, of jullie gooien gelijk mijn mooie xml-interface overboord!

[Verwijderd]

Basszje schreef op 10 juni 2004 @ 11:22:
[...]


Je kan onder een speciaal admin account inloggen op het systeem. Dan krijg je een selectie balk om je taal mee te kunnen veranderen ( page refresht, wordt getoond in andere taal)

Onder de interface zelf komen een aantal textbalkjes waar de gevonden velden in staan met de eventuele vertaling ( of leeg ). Invullen op save rammen en je hebt voor een taal die interface veranderd. Eens in de zoveel uur draait er een cron die een bepaalde verandere tekst voor het hele systeem doorvoeren

Euh, maar hoe wordt er dan vertaald naar de andere talen?

Mijn probleem was dat ik identieke pagina's moest hebben voor alle talen, hierin (kan wel maar) mag geen verschil zitten behalve de gebruikte taal (waarbij de inhoud afhankelijk van de schrijver dan wel kan verschillen, maar in principe is iedere pagina in iedere taal te zien)

Zoals jij het zegt kan dus een website in 1 taal over iets heel anders gaan dan in een andere taal, met heel andere content. Bij mij mag dat niet... (omdat het tenslotte een presentatie van een fysieke winkel is)
Of snap ik het cron gedeelte verkeerd??

[Basszje]

Een pagina blijft gewoon hetzelfde met dezelfde tekstvelden. Wat een vertaler daar dan in zit hebt je uiteraard geen controle over . De teksten worden gewoon gepositioneerd op een layout en dan wordt het object aangeroepen die altijd probeert om het veld met een bep. naam aan te roepen en in de gekozen taal te laten zien.

Dat cron gedeelte is alleen bedoeld om de DB consistent te houden. Bijvoorbeeld als jij het woord 'Save' veranderd in 1 script, wordt dat in eerst instantie ook ALLEEN op dat script doorgevoerd. Dit komt omdat het doorvoeren in de gehele applicatie veel te zwaar is om op te gaan wachten. Dat is dus later een 'synchronisatie' slag.

[Verwijderd]

indeed ... vertaen moet je zelf doen ....

[Verwijderd]

Ik heb zelf een kleine 'parser' geschreven om de gewenste vertaling van een 'element' uit een xml-file te halen , just plain and simple ... als je de code wil, laat dan maar iets weten.

Voor high load gebruik zul je nog wel wat caching moeten inbouwen, dit had ik zelf echter niet nodig.

[UltimateB]

IK heb het na zorgvuldig uitzoeken als volgt opgelost:

Een tabel met daarin de talen met een eventueel plaatje voor die talen.

Een tabel met daarin alle elementen die deel uitmaken van de standaard inhoud van de site (categorie namen, knoppen, titels, andere extra texten). Deze haal ik op naar een sessie variabele met ongeveer de volgende layout:

$_SESSION['language']['ui']['element']

Ik wil vervolgens nog een tabel maken met daarin de vertalingen voor de verschillende andere zaken, dingen die dus makkelijk bijgevoegd moeten kunnen worden, denk aan, nieuwsberichten, product info en titels, actie omschrijvingen en andere zaken die regelmatig toegevoegd worden.

Deze zal ik 'on demand' invoegen in de sessie variabele en weghaal als de info niet meer nodig is. Dit doe ik omdat ik anders binnen de kortste keren op de max grootte van de var zit en dat wil ik niet. Ik zat te denken het onder te brengen in $_SESSION['language']['dynamics']['element'] of misschien $_SESSION['language']['dynamics']['type']['element']. DIt omdat bijvoorbeeld een vertaling van de inhoudt van een acite altijd te zien is in een van de informatie panelen aan de zijkant van de site.

Wat vinden jullie hiervan?