Wat is een beetje de best practice omtrent multilanguage websites. Hoe ziet zo een database model eruit bijvoorbeeld?
Krijg ik voor elke taal een andere tabel met een language_id? dus bijv.
Persoonlijk gebruik ik altijd php bestanden bij multi-laguage. En dan een php bestand per taal. Afhankelijk van de gewenste taal include ik het gewenste php-bestand.
Persoonlijk gebruik ik altijd php bestanden bij multi-laguage. En dan een php bestand per taal. Afhankelijk van de gewenste taal include ik het gewenste php-bestand.
En als je een webshop hebt, en de producten in meerdere talen wilt aanprijzen?
De messages zijn het probleem niet. @Pipo de statische dingen als welkom en hallo meneer Jansen vertaal ik uiteraard al vooraf in een language file.
@Wouter
Het gaat er mij meer om wanneer een gebruiker dan in de backend tekst toevoegt in een bepaalde taal dat die dan kan kiezen sla op als Frans en dat wanneer een bezoeker op de website komt met een franse locale of zelf een franse taal kiest dan moet de tekst in het Frans tevoorschijn komen. De tekst is dus heel dynamisch en wordt op die manier dus toegevoegd. Maar feitelijk wat jij hierboven dus zegt is dat niet hetzelfde als ik in mijn voorbeeld heb gebruikt?
Dus het gaat niet om een meertalige interface (met een knop Cancel/Annuleren/Abbrechen bijvoorbeeld), maar om afzonderlijke berichten die een bepaalde kunnen hebben, bijvoorbeeld Nederlands bij een bericht van meneer Jansen en Engels bij een ander bericht van Mrs. Jones?
@ward het gaat wel degelijk om een meertalige interface. Voor de statische tekst die de gebruiker zelf niet aan kan/mag passen zoals de knoppen die kan ik in language files zetten.
Ik zoek een oplossing om de content die de klant zelf kan toevoegen bijv. een blog post om deze in verschillende talen te kunnen opslaan. Ik vraag me eigenlijk gewoon af hoe ziet zo een constructie er in grote lijnen uit in de database?
In de basis heb je dan een dubbele primaire sleutel: een voor een globaal unieke ID en een voor de taal. Met twee controls in drie talen krijg je zoiets.
Ik gebruik hier zelf altijd GUID's in de vorm van leesbare constanten, omdat je anders bij het bouwen van views, controls en GUI-widgets maar moet raden dat een knop Annuleren ID 1325 heeft en een of andere foutmelding ID 41358. Leesbare constanten met logische prefixes werken beter.
Voor "vrije teksten" uit een CMS kun je een vergelijkbare opzet aanhouden: eerst een nieuwe GUID uitreiken en daaraan vervolgens content in verschillende talen toevoegen.
Verder helpt het als je wat beslissingsregels toevoegt, bijvoorbeeld "gebruik de Engels string als de Nederlandse vertaling ontbreekt".
