[PHP] Site globaliseren*

[Verwijderd]

Ik zit met het volgende probleem....

Ik ben bezig met een website, deze moet gemaakt worden in twee talen.
Nou heb ik zelf een soort content management systeem gemaakt voor paginas waar
informatie opstaat en die aangepast kan worden.
Ik heb ook nog enkele formulieren die op de website moeten komen en daarvoor heb ik de volgende mogelijkheden denk ik tenminste:
- Afhankelijk van de gekozen taal de pagina met het formulier laden.
- Afhankelijk van de gekozen taal de text van het formulier weergeven.(bij elke tekst of melding een if statement)
- Alle teksten op het formulier uit een database lezen. (labels, meldingen, enz.)
- Of een combinatie

Ik ga er vanuit dat de teksten meldingen niet zullen veranderen op dit formulier. Ik ben nu erg benieuwd wat jullie de beste oplossing lijkt gezien de snelheid en overzichtelijkheid.

[Willem]

Dat is meer iets voor Programming & Webscripting

* Willem over schutting gooit

[whoami]

In welke taal maak je die website ?
Je zal toch wel zoiets hebben als resource-files.

[Verwijderd]

willem169 schreef op woensdag 05 oktober 2005 @ 11:27:
Dat is meer iets voor Programming & Webscripting

/me over schutting gooit

Daar stond hij ook in.....

[pjvandesande]

In wat voor taal word het geschreven? Wat is je eigen idee?

[Verwijderd]

De site moet komen in het engels en in het roemeens en maak ik
in PHP+mysql samen met gewone html
Wat bedoel je precies met resource files??

Ik denk zelf dat het lezen uit de database veel dataverkeer zal opleveren en dat de website traag zal worden. maar dit weet ik niet zeker

[ Voor 50% gewijzigd door Verwijderd op 05-10-2005 11:32 ]

[sjroorda]

Verwijderd schreef op woensdag 05 oktober 2005 @ 11:24:
Ik ben nu erg benieuwd wat jullie de beste oplossing lijkt gezien de snelheid en overzichtelijkheid.
- Alle teksten op het formulier uit een database lezen. (labels, meldingen, enz.)

Reden: je hoeft niet in de code te klooien, en die blijft dus overzichtelijker. Ook kan je zonder veel problemen een nieuwe taal toevoegen.
Eventueel kan je de DB-oplossing wijzigen/optimaliseren met lokale bestanden, arrays of iets in die richting.

In welke programmeertaal schrijf je de code?

[ Voor 5% gewijzigd door sjroorda op 05-10-2005 11:31 ]

[Barracuda_82]

Ik denk dat de eerste optie lastig is als je het formulier aan wil passen, dan moet je dat in alle includes doen. Een if-statement per tekstje is ook niet echt een goed idee en uit een database halen is ook onzinnig.

Het beste kun je met een soort language-files werken. Dit doe ik ook altijd in mijn modules. Aan het begin van je formulier include je een bestand (en dan afhankelijk welke taal word er een taalbestand ingeladen) en in dat bestand staan gewoon al je definities.

Het bestand met je formulier ziet er dan zo uit:

PHP:

include('language/nl.inc.php');
echo "bladiebla ". _TEXT_ ." blablabla";

En de language file ziet er dan zo uit:

PHP:

define("_TEXT_","dit is de tekst die ingevuld wordt");

Ik ben er maar even van uit gegaan dat je PHP gebruikt, maar dit kan natuurlijk wel in meer talen. Het gaat effe om het idee.

[Michali]

Een bestandje (XML?) waaruit je de woorden en zinnen haalt bijvoorbeeld.

[whoami]

Verwijderd schreef op woensdag 05 oktober 2005 @ 11:29:

Ik denk zelf dat het lezen uit de database veel dataverkeer zal opleveren en dat de website traag zal worden. maar dit weet ik niet zeker

Waarom denk je dat ?
Dat zal nogal meevallen imho. Per pagina een paar eenvoudige queries, mits goede indexen op de DB zou niet zo'n probleem moeten zijn, maar de beste oplossing is toch imho om met resource files te werken, al weet ik niet of PHP dit kent, of hoe zo iets dergelijks in PHP geimplementeerd is.

[ Voor 17% gewijzigd door whoami op 05-10-2005 11:37 ]

[RedHat]

Templatesets een optie?

[Verwijderd]

Het lijkt me inderdaad een mooi oplossing barracuda....

Afhankelijk van de geselecteerde taal een bestand includen waarin dan die teksten staan. Denk inderdaad dat dit de snelste makkelijkste en overzichtelijkste oplossing is.

In plaats van define zou ik toch ook wel een variabele kunnen gebruiken denk ik??
Wat zijn templatesets precies??

Bedank voor de reacties tot nu toe!

[ Voor 5% gewijzigd door Verwijderd op 05-10-2005 11:47 ]

[Startups]

Verwijderd schreef op woensdag 05 oktober 2005 @ 11:43:
Het lijkt me inderdaad een mooi oplossing barracuda....

Afhankelijk van de geselecteerde taal een bestand includen waarin dan die teksten staan. Denk inderdaad dat dit de snelste makkelijkste en overzichtelijkste oplossing is.

In plaats van define zou ik toch ook wel een variabele kunnen gebruiken denk ik??

Bedank voor de reacties tot nu toe!

Je kunt ook $var gebruiken maar define is net wat netter als de inhoud niet veranderd.
http://nl3.php.net/define

[Verwijderd]

De taalafhankelijke zaken in een database opslaan kan prima volgens mij. In php heb ik dat eens gedaan bij een redelijk complexe website die veel aan verandering onderhevig is. De klant kan zelf talen toevoegen en alle termen en pagina's aanpassen. Ik maakte dan wel onderscheid tussen termen, dwz korte teksten, en hele pagina's. Dit waren gewoon twee tabellen in de database en iedere tuple had een unieke naam in het engels. Deze unieke naam gaf je mee als string aan een bepaalde methode en je kreeg de juiste zaken terug in je voorkeur taal van je sessie. Natuurlijk leidt dit tot misschien wel 20 database aanroepen per pagina, wat enorm lijkt. Maar mijn ervaring is dat het bijzonder snel werkte, wat mij doet vermoeden dat er het nodige gecached wordt. Ik had nog in mijn hoofd om handmatig een proxy in te bouwen en de 100 meest gebruikte termen weg te schrijven naar het geheugen, maar ik heb het maar zo gelaten omdat ik nog geen snelheidsproblemen ondervind.

Persoonlijk vind ik deze aanpak veel prettiger werken omdat je als er een term veranderd of bijkomt oid dit gewoon op 1 pagina in je back-office-systeem kan wijzigen voor alle talen. Ook heb je regelmatig dat je niet alle termen hoeft te vertalen, of er nog geen zin in hebt ofzoiets, dan laat je het gewoon leeg, dan zorg je dat je zelfgeschreven methode hiervoor automatisch een andere taal laat zien in dat geval. En mijn ervaring is dat dat vrij veel voorkomt. Op die manier kan je je website ook sneller met content vullen, sommige vertalingen blijven nog wat achter bij andere, maar dat leidt niet tot problemen voor je scripts of voor je gebruikers (afgezien dat een Duitser hier en daar nog wat Engelse termen tegen kan komen, die nog niet vertaald zijn)

edit: Ik bedenk me nu ik het zo lees, dat ik er teveel van uitga dat je die globalize files handmatig aanpast, en dat ze daarom te statisch zijn. Maar uiteraard kan je dit ook in je back-office-systeem op de zelfde manier integreren zoals ik hierboven beschrijf, met deze verandering dat je alles naar een platte tekst file wegschrijft ipv naar een database. Ofwel, mijn verhaal eromheen doet er niet zoveel toe. Het gaat nog steeds om de vraag wat goedkoper is met de opbouw van de pagina's door de webserver: Of een bepaalde tekstfile inlezen en alle variabelen zetten, of voor iedere vertaling een database aanroep. Het lijkt erop dat er toch stevig gecached wordt zodat je dit verschil nauwelijks kan meten met kleine hoeveelheden aan termen en pagina's. Feit blijft dat je met de database aanroep makkelijk een fall-back language kan instellen voor de termen die nog niet vertaald zijn. Voor grote stukken tekst (pagina's zeg maar), lijkt me zowiezo de database meer geschikt.

[ Voor 23% gewijzigd door Verwijderd op 05-10-2005 12:10 ]

[googhum]

Het includen of werken met bestanden is een makkelijke oplossing die snel gerealiseerd kan worden. Let wel dat je nu je data in een bestand plaatst en niet in een database. Om nu dus de waarde van "_TEXT_" aan te passen moet je het bestand wijzigen. Hiervoor moet je de language file downloaden aanpassen en uploaden naar de server, iets wat minder wenselijk is dan werken met een database. Wanneer dit geen intranetsite wordt en je de waarde van je variable makkelijk wil aanpassen zou ik kijken naar een database driven CMS.
Suc6 in iedergeval.

<edit>
Ok, verhaal hierboven van alcatrez is net ff duidelijker (en sneller met typen).
Als je waarde dus regelmatig veranderen en je wil dit niet zelf doen zal je dus met een database moeten werken
</edit>

[ Voor 18% gewijzigd door googhum op 05-10-2005 12:04 ]

[Barracuda_82]

Verwijderd schreef op woensdag 05 oktober 2005 @ 11:43:
Het lijkt me inderdaad een mooi oplossing barracuda....

Afhankelijk van de geselecteerde taal een bestand includen waarin dan die teksten staan. Denk inderdaad dat dit de snelste makkelijkste en overzichtelijkste oplossing is.

In plaats van define zou ik toch ook wel een variabele kunnen gebruiken denk ik??
Wat zijn templatesets precies??

Bedank voor de reacties tot nu toe!

Let wel op dat je netjes met prefixes of underscores ofzo werkt, zodat je code een beetje duidelijk blijft. Ikzelf doe de variabelen die gedefined zijn altijd met hoofdletters en een underscore voor en achter de naam.

[Brakkie]

gettext is daar toch voor bedoeld.

[Startups]

googhum schreef op woensdag 05 oktober 2005 @ 12:00:
Het includen of werken met bestanden is een makkelijke oplossing die snel gerealiseerd kan worden. Let wel dat je nu je data in een bestand plaatst en niet in een database. Om nu dus de waarde van "_TEXT_" aan te passen moet je het bestand wijzigen. Hiervoor moet je de language file downloaden aanpassen en uploaden naar de server, iets wat minder wenselijk is dan werken met een database. Wanneer dit geen intranetsite wordt en je de waarde van je variable makkelijk wil aanpassen zou ik kijken naar een database driven CMS.
Suc6 in iedergeval.

<edit>
Ok, verhaal hierboven van alcatrez is net ff duidelijker (en sneller met typen).
Als je waarde dus regelmatig veranderen en je wil dit niet zelf doen zal je dus met een database moeten werken
</edit>

Je kunt ook naar een file wegschrijven, en daar een admin om heen bouwen.
Als deze texten misschien 1x per maand aangepast moeten worden, kan dat ook gewoon perfect met een file.
Als je een nieuwssite hebt is dat natuurlijk iets anders.

[qless]

Ik doe het in mijn CMS ook via defines. Voordeel is dus dat je makkelijk nieuwe talen kan (laten) toevoegen door een language file te bakken.
Normaal gezien wijzigen dergelijk talen ook niet dagelijks.

Teksten die door gebruikers worden ingevoerd zijn zowieso al taal afhankelijk en worden dus netjes zoals alle content in een DB gepropt.

[Verwijderd]

De grote teksten op de website wil ik gewoon vanuit een database laden en beheren met mijn gemaakte cms systeem. Alleen labels en meldingen bij bijvoorbeeld formulieren die veranderen eigenlijk nooit.
Ik denk dat ik er dus voor kies om een php file te includen met alle labelteksten en berichten voor de gebruiken en daarbuiten het cms ga gebruiken voor de informatie die getoont zal worden.

[Verwijderd]

ik zelf ben ook bezig geweest met en soort gelijk iets. Wat ik deed was het volgende:
bij het bezoeken van een site werd een taal gekozen. en in een cookie gezet.
Op iedre pagian werd die taal keuze uit de cookie gehaald en bij de taal horende taal file geinclude waar korte stukjes tekst in stonden.
de inhoud avn die file zag er zo uit:

PHP:

<?php
$row_string = array ( 

 'AANTAL' => "Aantal", 

'AANTALSTUKS' => "Aantal stuks", 

'ACHTER' => "achter"};
?>

op de pagina dan de juiste taal file inlezen en om iets wer te geven

PHP:

echo $row_string['AANTAL'];

Dit werkt erg goed. En de groote stukken tekst stonden opgeslagen in een database. Werkt echt perfect en super snel.

[Verwijderd]

Waarom gebruiken jullie niet gewoon het standaard i18n systeem van PHP? Dat lijkt me een stuk makkelijker en onderhoudbaarder dan allemaal eigen brouwsels gaan zitten te bakken.

Het gemak van een standaard systeem is ook dat je je resource bundles gewoon naar een vertaal bureau toe kunt sturen, die ze dan voor je vertalen. Zo'n vertaal bureau standaardiseerd meestal op een bekend formaat en gaan absoluut niet op web pages zelf zitten te vertalen.

Een ander voordeel van het standaard systeem is dat je ook veel betere tool support hebt. Tools laten keys in verschillende talen onder of naast elkaar zien, en geven warnings als bepaalde keys in bepaalde talen missen. Vaak kun je ook je keys hierargisch laten weergeven (in de plain tekst versie van de bundle zijn de keys gewoon namen als "core.login.password.error", waarbij de tool alle keys dan via de puntjes in een tree kan weergeven. Super handig als je met 1000'en keys werkt!

[RwD]

Brakkie schreef op woensdag 05 oktober 2005 @ 12:06:
gettext is daar toch voor bedoeld.

Werkt gettext niet met .po en .mo bestanden ipv een database?? (Ik kan me vergissen, maar alle keren dat ik er mee in aanraking kwam stonden de verschillende talen in deze bestanden)

[Bosmonster]

Verwijderd schreef op woensdag 05 oktober 2005 @ 21:22:
Waarom gebruiken jullie niet gewoon het standaard i18n systeem van PHP? Dat lijkt me een stuk makkelijker en onderhoudbaarder dan allemaal eigen brouwsels gaan zitten te bakken.

Het gemak van een standaard systeem is ook dat je je resource bundles gewoon naar een vertaal bureau toe kunt sturen, die ze dan voor je vertalen. Zo'n vertaal bureau standaardiseerd meestal op een bekend formaat en gaan absoluut niet op web pages zelf zitten te vertalen.

Een ander voordeel van het standaard systeem is dat je ook veel betere tool support hebt. Tools laten keys in verschillende talen onder of naast elkaar zien, en geven warnings als bepaalde keys in bepaalde talen missen. Vaak kun je ook je keys hierargisch laten weergeven (in de plain tekst versie van de bundle zijn de keys gewoon namen als "core.login.password.error", waarbij de tool alle keys dan via de puntjes in een tree kan weergeven. Super handig als je met 1000'en keys werkt!

Omdat het gettext gebeuren een extensie is die vaak niet enabled is en erg ingewikkeld werkt als je alleen maar een paar strings wil vervangen.

Je kunt in 10 minuten een eigen gettext achtige functionaliteit maken, gebruikmakend van de standaard php ini-reader bijvoorbeeld. Die bestanden kunnen ook eenvoudig naar vertaalbureau's.

[Brakkie]

RwD schreef op donderdag 06 oktober 2005 @ 09:00:
[...]
Werkt gettext niet met .po en .mo bestanden ipv een database?? (Ik kan me vergissen, maar alle keren dat ik er mee in aanraking kwam stonden de verschillende talen in deze bestanden)

Ja, dat klopt. Ik heb er zelf nog nooit echt gebruik van gemaakt maar ik heb me laten vertellen dat het de snelste optie is omdat het met binaire bestanden werkt.

[BCC]

Bosmonster schreef op donderdag 06 oktober 2005 @ 09:22:
[...]
Omdat het gettext gebeuren een extensie is die vaak niet enabled is en erg ingewikkeld werkt als je alleen maar een paar strings wil vervangen.

Je kunt in 10 minuten een eigen gettext achtige functionaliteit maken, gebruikmakend van de standaard php ini-reader bijvoorbeeld. Die bestanden kunnen ook eenvoudig naar vertaalbureau's.

Prima, maar als de site nog groter wordt, loop je weer tegen problemen aan zoals versiebeheer van vertaalbestanden en andere gramatica's in andere talen.
Als je gelijk met gettext begint, heb je hier later allemaal fijne tools voor.

[ Voor 6% gewijzigd door BCC op 06-10-2005 09:38 ]

[Janoz]

Mwah, daar loop je al een stuk sneller tegenaan. Wat dacht je van form validatie?

Het invullen van {0} is verplicht.
vs.
{0} is required.

of

{0} moet tussen {1} en {2} liggen.

Het lijkt me niet handig om met range1,range2,range3 labels te gaan werken om elk stukje tussenliggende tekst te gaan benoemen.

In welke taal maak je die website ?
Je zal toch wel zoiets hebben als resource-files.

We hebben het hier over php, niet over een fatsoenlijke j2ee of .net omgeving .

[RwD]

over gettext
Je kunt de klant toch niet gaan vragen om de .po bestanden aan te passen en te compileren?? Ik werk zelf op winXP pro en heb er moeite voor moeten doen om het compileren voor mekaar te krijgen. Laat staan leren hoe de .po bestanden in elkaar steken.

[ Voor 5% gewijzigd door RwD op 06-10-2005 09:51 ]

[Brakkie]

RwD schreef op donderdag 06 oktober 2005 @ 09:50:
over gettext
Je kunt de klant toch niet gaan vragen om de .po bestanden aan te passen en te compileren??

Zou het erg lastig zijn om daarvoor een gui te bouwen in je CMS.

[ Voor 3% gewijzigd door Brakkie op 06-10-2005 09:56 ]

[Bosmonster]

RwD schreef op donderdag 06 oktober 2005 @ 09:50:
over gettext
Je kunt de klant toch niet gaan vragen om de .po bestanden aan te passen en te compileren?? Ik werk zelf op winXP pro en heb er moeite voor moeten doen om het compileren voor mekaar te krijgen. Laat staan leren hoe de .po bestanden in elkaar steken.

Vertalingen zijn sowieso niet iets waar je een klant mee wilt opzadelen neem ik aan. Templates en bijbehorende vertaaldocumenten (of het nou een eigen systeem is of via gettext) is iets dat wij in ieder geval niet bij klanten neerleggen.

Alle dynamische content waar een klant wel mee werkt heeft eigen taalversies ingebouwd.

[ReLexEd]

Om .po-bestanden te maken/bewerken heb je niet al te veel nodig hoor....

Ik gebruik zelf deze, om m'n Drupal te vertalen....

Kun je gewoon voor diverse OS-en binnenhalen, en offline de boel laten bewerken...
Als je een zelfde import-mechanisme als in Drupal gebruikt, kun je de wijzigingen laten doorvoeren, door de .po te uploaden naar de site, en klaar ben je....

Al is de mogelijkheid om de boel via de DB te doen natuurlijk net iets gebruikersvriendelijker....

Persoonlijk zou ik als ik iets van scratch af aan zou maken, voor de DEFINE' in een include-methode gaan, en hier een stukje admin omheen bouwen, dat de file inleest, en deze kan parsen, en weer wegschrijft bij wijzigingen...

Dat lijkt me namelijk de meest resource-vriendelijke optie, en je belast je database er niet mee.

Iemand anders nog een briljante visie op het geheel?

[Bosmonster]

Vertaalbestanden zijn meestal bestanden die je op moet sturen naar een vertaalbureau. Ik zou dus (als ik zelf iets moet maken ) liever uitgaan van een eigen formaat, of het ini formaat.

Bij het inlezen kun je het geparste document gewoon cachen natuurlijk voor wat tijdwinst.

DEFINE's vind ik persoonlijk een niet zo handige manier. Je hebt er mogelijk honderden/duizenden nodig. Gezien het gebrek aan namespaces zou ik het liever in een objectje wrappen (welke je kunt serializen om te cachen).

[Verwijderd]

Ik persoonlijk niet voor iets zelf maken gaan. Voor een project van ons hebben we er ook even naar gekeken, voornamelijk omdat er mensen waren die de {0} etc syntax niet mooi vonden, maar uiteindelijk is een standaard oplossing toch beter.

Het grote voordeel is dan namelijk dat als er nieuwe programmeurs op je project komen, deze veel sneller met je systeem kunnen werken (ze hoeven niet allemaal home-grown methodieken te leren), ten tweede profiteer je automatisch en gratisch mee van verbeteringen die PHP zelf doorvoert in het i18n systeem, en als laatste is het gewoon zonde om weer het wiel opnieuw uit te vinden voor iets wat al lang al in de standaard zit en al weet ik veel hoevel jaren wordt gebruikt.