[WEB] Localisatie van websites

[maartenba]

Omdat we momenteel bezig zijn met een project in verschillende talen, wou ik even een discussie starten over de verschillende mogelijkheden rond opslaan en weergeven van vertalingen op websites. In de search was er niet meteen veel over te vinden... Dit leek me een nuttig onderwerp om eens over te brainstormen.

Voor statische sites werken we meestal op een van volgende manieren:
- In DreamWeaver de tekst in taal A tussen 2 PHP tags (if language == A ...), die voor taal B tussen zulke tags, die voor taal C tussen deze tags, ...
- Aparte tekstbestanden met de juiste tekst in de juiste taal voor de juiste pagina

Voor een dynamische sites waar enkele korte woordjes op dienden vertaald te worden, hebben we een database aangelegd in de zin van "pagina | woord | taal | vertaling". Dit werkte ook redelijk vlot.

Maar wat is nu de juiste manier voor complexe sites die in meerdere talen dienen te komen?
Niet alleen de taal van de interface is anders, ook de taal van de (dynamische) content is anders.
Voorzie je per taal een andere database? Voorzie je per veld een vertalingsveld er taal?

Je kan eventueel ook weer aparte tabellen gaan gebruiken met vertalingen, maar dan krijg je in je database weer van die complexe JOINs...

[chem]

Je zou eens moeten kijken naar gettext van GNU - die voorziet in genoeg tools voor de meeste oplossingen.

Daarnaast moet je kijken naar realtime vertaling, of statische (buffered) vertaling - elke keer de juiste woorden opzoeken kan tijdrovend zijn en vaak slecht leesbaar.

Wat dat laatste betreft kan sprintf() wel een oplossing bieden, maar het blijven extra functioncalls terwijl er vaak weinig veranderd (pluraliteit daargelaten).

[Verwijderd]

Je kunt met relatief eenvoudige database wijzigingen localisatie brengen. Als je nu een relatie hebt liggen van domein -> pagina -> artikel dan plaats je daar een niveau tussen van domein -> culture -> pagina -> artikel. Zo kun je onder een domein meerdere cultures bijhouden. Als je deze culture vervolgens linked aan een locale configuratie voor de cultuur ben je in principe al klaar

[6K]

ik weet niet of je de beschikking hebt over .Net en ermee kunt werken, maar daarin zijn ook mogelijke bronbestanden te definiëren per culture (en een default natuurlijk), deze worden dan in de assembly meegenomen.

[maartenba]

6K schreef op 04 oktober 2004 @ 11:16:
ik weet niet of je de beschikking hebt over .Net en ermee kunt werken, maar daarin zijn ook mogelijke bronbestanden te definiëren per culture (en een default natuurlijk), deze worden dan in de assembly meegenomen.

Yes, die ken ik en zijn uitermate handig Maar niet iedereen gebruikt .net...


Veronderstel even dat je, laat ons zeggen, zoekertjes gaat aanbieden. Je wil dat elk zoekertje in X talen (uitbreidbaar) wordt weergegeven.

Ga je dan voor een database als: zoekertje (id, tekst_nl, tekst_en, ...)
Of liever voor: zoekertje (id, taal, tekst)
Of andere alternatieven?

[ Voor 41% gewijzigd door maartenba op 04-10-2004 11:19 ]

[alienfruit]

Nou ik zal dan gewoon gaan voor een koppeltabel ( locale_id, item_id ) waaraan je een taal kopelt aan een item_id vervolgens koppel je een artikel/tekst aan je zoekertje en voila!

[chem]

Een koppeltabel heeft de voorkeur. Bij je JOIN geef je meteen aan welke vertaling je wil hebben (of meerdere) zodat het nog rap blijft ook.

[MTWZZ]

Ik heb het zelf opgelost door content gewoon in een aparte dir te plaatsen:
/content_<lang>/sectie/artikel
Makkelijk zat. Zeker als je met apache een Alias /nl /content_nl doet oid.

[Verwijderd]

MTWZZ schreef op 04 oktober 2004 @ 19:50:
Ik heb het zelf opgelost door content gewoon in een aparte dir te plaatsen:
/content_<lang>/sectie/artikel
Makkelijk zat. Zeker als je met apache een Alias /nl /content_nl doet oid.

En wat als je een site hebt waarbij pagina's dynamisch worden gegenereerd aan de hand van data uit bijvoorbeeld een relationele database of een of andere XML bron?

[UltimateB]

Ik heb persoonlijk mijn site onderverdeeld in verschillende groepen die vertaald moeten kunnen worden en deze in aparte tabellen gezet. Je hebt:

- de interface (komt steeds weer terug)
- statische paginas (niet helemaal statisch als je ze kan vertalen )
- producten
- nieuws / links / downloads

Aan de bovenkant van mijn index.php heb ik een functie staan die bij wijziging van de taal opnieuw alle variabelen voor de interface inlaad en opslaat in een sessie variabele. Voor producten / nieuws / downloads / etc haal ik de gegevens op door middel van een left join. Op deze manier hoeft er alleen een sql query veranderd te worden om te zorgen dat er andere taal ingeladen wordt.

Ik heb uiteindelijk gekozen voor deze constructie aangezien mij dit het makkelijkste te implementeren leek.

Je krijgt dan dus eigenlijk voor alle text in de site zaken als:

PHP:

<button><?=$_SESSION['language']['ui']['buttonBestel'];?></button>

Just my two cents.

[ Voor 6% gewijzigd door UltimateB op 04-10-2004 20:30 ]

[Janoz]

Ikzelf ben op dit moment met een uitgebreide site bezig voor een op europeesche schaal werkend bedrijf. Ik maak echter geen gebruik van php maar j2ee icm struts. Hierin zit al een hele berg i18n ingebouwd. De meeste 'statische' termen komen bij mij uit message resources. Dit zijn eigenlijk gewoon property bestanden met een language postfix (messages_nl.properties, messages_en.properties). De message bundels zorgen dan automatisch voor de juiste labels.

Oom ook een taalswitch mogenlijk te maken heb ik een filter gemaakt die de ingestelde taal aanpast aan een aantal eisen. Zonder dit filter zou er worden gewerkt met de accept language header van de browser, maar met dit filter is een language get parameter of een cookie overrulend. Doordat dit in een filter gebeurt hoef ik in de rest van mijn applicatie geen rekening met taal keuze te houden en kan ik er gewoon vanuit gaan dat de in het response object opgeslagen taal de door de gebruiker gekozen taal is.

Bij dynamische content is wat ingewikkelder. In de admin tool kunnen meerdere taalversies van items ingevoerd worden, maar vaak is de redactie niet in alle gebruikte talen vaardig genoeg. Lokale vertalingen wil je het liefst door mensen doen die die taal goed beheersen. UIteindelijk hebben we ervoor gekozen om een engelse versie verplicht te stellen en dit als tweede keuze te gebruiken. Zodra een item niet in de voorkeurstaal aanwezig is, wordt deze in het engels weergegeven. Hierdoor is alle content voor iedereen iig beschikbaar. Nadeel is wel dat dan de site in twee talen wordt weergegeven, maar dat nadeel woog niet op tegen het dan maar weglaten. Dat laatste vinden vooral aandeelhouders niet zo prettig .

[Verwijderd]

Janoz schreef op 04 oktober 2004 @ 20:43:

Puur geinteresseerd maar ligt de structuur voor een culture ook meteen voor andere cultures vast? Ik heb daar een tijdje op gestudeerd, en zag dat oa Smartsite dit wel doet, maar dat het eigenlijk heel onhandig is gezien het feit dat je dan de andere taal verplicht dezelfde structuur te gebruiken

[chem]

Verwijderd schreef op 04 oktober 2004 @ 20:48:
[...]


Puur geinteresseerd maar ligt de structuur voor een culture ook meteen voor andere cultures vast? Ik heb daar een tijdje op gestudeerd, en zag dat oa Smartsite dit wel doet, maar dat het eigenlijk heel onhandig is gezien het feit dat je dan de andere taal verplicht dezelfde structuur te gebruiken

Je bedoelt de structuur van een zin?

Wij doen gettext in combinatie met sprintf om de volgorde van de vars aan te passen; tevens kent gettext een plural onderscheid (een zin voor enkelvoud en meervoud) zodat je al een heel end bent.

Daarbij bieden de meeste interfaces geen aanzienlijk grotere ruimte voor teksten/buttons waardoor je toch aan vrijwel gelijk zinnen (qua lengte) zit.

[Verwijderd]

Nee de structuur van bijv. de presentatielaag. Dus

code:

startpagina
  -- produkten
  -- nieuws
  -- contact
      -- formulier

homepage
  -- products
  -- news
  -- contact
      -- form

In dit geval kun je in een administratie interface direct zeggen translate to $language. Het houd in dat je op object niveau meerdere cultures kunt definieneren, maar dat je wel bent gebonden aan een vaste structuur voor alle cultures. In organisaties praktisch niet haalbaar wegens vertalingen.

Ga je echter op branches definieren dan ben je wel vrijer, maar heeft zonder tussenkomst van een soort van linking, de structuur van cultures geen kennis van de structure van andere cultures.

[Janoz]

Localizen gaat puur op tekst. Alle labeltjes worden vervangen met termen in de gekozen taal. De site is trouwens ook geen applicatie, maar gewoon een 'informatie ontsluiter', en dan vooral een waarbij het vooral om de looks draait (hebben wij niet bedacht, maar een paar zweverige belgen . Wij hoeven alleen hun mooie plaatje te laten werken)

[lordgandalf]

is XML niet hiervoor goed te gebruiken ??
een klasgenoot voor mij maakt gewoon een een bestand aan met de vertalingen
dus gewoon $zoeken in het bestand en.inc.php is search en in nl.inc.php is het zoeken

[maartenba]

Momenteel denk ik aan dit, omdat het vrij eenvoudig is, zowel qua implementatie als voor de vertalers (met het zoekertjes voorbeeld):

zoekertje (id, taal, tekst), en dan per zoekertje x-aantal talen maken.
interface (paginaid, taal, element, waarde), voor de vertaling van de interface.

[chem]

Verwijderd schreef op 04 oktober 2004 @ 21:56:
Nee de structuur van bijv. de presentatielaag. Dus

code:

startpagina
  -- produkten
  -- nieuws
  -- contact
      -- formulier

homepage
  -- products
  -- news
  -- contact
      -- form

In dit geval kun je in een administratie interface direct zeggen translate to $language. Het houd in dat je op object niveau meerdere cultures kunt definieneren, maar dat je wel bent gebonden aan een vaste structuur voor alle cultures. In organisaties praktisch niet haalbaar wegens vertalingen.

Ga je echter op branches definieren dan ben je wel vrijer, maar heeft zonder tussenkomst van een soort van linking, de structuur van cultures geen kennis van de structure van andere cultures.

You lost me here

Kan je dit toelichten / beter uitleggen?

[Verwijderd]

Ik heb die losse keys gewoon inderdaad via xml gedaan Dat is gewoon een stuk beter te onderhouden Waar je wel op moet letten is dat je geen zinnen gaat vormen uit losse vertaalde woorden. Een zinsopbouw kan per cultuur verschillen en het is daarom vereist dat je zinnen per zin vertaald, en niet per woord.

[Verwijderd]

chem schreef op 05 oktober 2004 @ 10:51:

Ok

Je hebt een website, die wil je multilingual aan de frontend hebben. Nu heb je twee keuzes.

1: Elk object bestaat uit een afsplitsing in meerdere culturen. Object artikel met ID 1, heeft dan een engelse, en een nederlandse stroming. Multilingual op object niveau dus.

2: Je houdt per culture een aparte branch na. Wil je een engelse vertaling? Dan betekend dit een nieuw artikel in de engelse taal.


Voordeel aanpak 1:
Je kunt als je in de backend in de nederlandse taal bezig bent, makkelijk zeggen op het artikel object "translate to english". Immers heb je direct het object te pakken, op de exact dezelfde plek in de hierarchie. Nadeel, dit betekend dat je die hierarchie voor alle cultures gelijk moet houden. Tevens is www.domein.nl?page=1 bereikbaar zowel Engels als Nederlands, evt. op basis van de gedetecteerde browser language. Iemand die in google dus je pagina bezoekt, krijgt hem in zijn of haar taal voorgeschoteld. Of dat wenselijk is alla.


Voordeel aanpak 2:
Je kunt per culture een aparte structuur aanhouden, iets wat toch meestal door organisaties wordt gedaan. Niet ieder object kan in een andere cultuur worden vertaald. Nadeel is dat de engelse versie van artikel A, geen enkele relatie heeft met de nederlandse versie van artikel A. Ze zitten in een aparte branch, en daarom kun je ook moeilijk zeggen "translate to english" want het doelartikel is niet bekend. In beide branches kan het immers zijn dat het pad niet gelijk is naar het artikel. Dus, betekend dit dat je handmatig artikel A ENG, moet linken aan artikel A NL.

Het is wat wazig uit te leggen, maar ik ben hier ook 2 weken mee bezig geweest om uit te zoeken.

[ Voor 9% gewijzigd door Verwijderd op 05-10-2004 11:02 ]

[MTWZZ]

Verwijderd schreef op 04 oktober 2004 @ 20:21:
[...]

En wat als je een site hebt waarbij pagina's dynamisch worden gegenereerd aan de hand van data uit bijvoorbeeld een relationele database of een of andere XML bron?

In die fysieke directories staan XML bestanden ;-)
Die Alias is naar /index.php die er /nl of /en uitstript en op basis daarvan content uit de respectievelijke directories haalt.

offtopic:
sorry voor de late replay

[Verwijderd]

Zo dus Wellicht snapt de TS het dan een beetje

[chem]

Verwijderd schreef op 05 oktober 2004 @ 11:00:
[...]

Voordeel aanpak 2:
Je kunt per culture een aparte structuur aanhouden, iets wat toch meestal door organisaties wordt gedaan. Niet ieder object kan in een andere cultuur worden vertaald. Nadeel is dat de engelse versie van artikel A, geen enkele relatie heeft met de nederlandse versie van artikel A. Ze zitten in een aparte branch, en daarom kun je ook moeilijk zeggen "translate to english" want het doelartikel is niet bekend. In beide branches kan het immers zijn dat het pad niet gelijk is naar het artikel. Dus, betekend dit dat je handmatig artikel A ENG, moet linken aan artikel A NL.

Dus; je krijgt een site met meerdere 'bomen'/talen (0-punten) waar toch onderling relaties gelegd kunnen worden?
Zeg dat dan

[Verwijderd]

euhm.. ja soms moet je het idiot proof uitleggen

[Suepahfly]

Verwijderd schreef op 06 oktober 2004 @ 14:36:
Zo dus Wellicht snapt de TS het dan een beetje

[afbeelding]

Mja, das eigenlijk best wel makkelijk. Zo kan je met meerde applicaties de zelfde bron bestanden gebruiken.

Zelf in PHP deed ik het altijd met defines.
Je maakt per taal een bestand waar je te vertalen strings in zet.
In de bron van je applicatie include je het juiste bestand.

Voordeel is de relatief lage overhead t.o.v. in database gedefinieerde vertalingen.
Nadeel is dat het alleen binnen PHP werkt en alleen binnen je eigen applicatie.

Ik moet zeggen dat ik de xml oplossing mooier vind.

[Verwijderd]

Om eerlijk te zijn snap ik vrij weinig van de XML documentstructuur die Gordijnstok laat zien. Het lijkt mij niet zo erg handig. Ik zou zelf eerder kiezen voor een structuur als:

code:

<label id="file">Bestand</label>

Dat lijkt me beter te verwerken.

Maar het principe is natuurlijk redelijk eenvoudig. Het komt er in vrijwel elke situatie op neer dat je een mapping maakt tussen identifiers en vertalingen. Of je dat nu met een XML bestand, een ini, een *dbm of relationele database opslaat, is natuurlijk niet echt van groot belang.

[Verwijderd]

Verwijderd schreef op 06 oktober 2004 @ 21:40:
Om eerlijk te zijn snap ik vrij weinig van de XML documentstructuur die Gordijnstok laat zien. Het lijkt mij niet zo erg handig. Ik zou zelf eerder kiezen voor een structuur als:

code:

<label id="file">Bestand</label>

Dat lijkt me beter te verwerken.

Maar het principe is natuurlijk redelijk eenvoudig. Het komt er in vrijwel elke situatie op neer dat je een mapping maakt tussen identifiers en vertalingen. Of je dat nu met een XML bestand, een ini, een *dbm of relationele database opslaat, is natuurlijk niet echt van groot belang.

Op een enkel systeem draaien momenteel pakweg 80 websites, en met in totaal zo'n 8000 sourcecode bestanden, is het voor mij belangrijk om een goede structuur aan te brengen die me niet in de weg gaat zitten. Ik kan met deze structuur modulair vertalingen aanbrengen, en een bestand ook opdelen in categorien. Het bestand wat je nu ziet is 3kb, maar er zitten ook bestanden bij met factor 100 aan vertalingen, vandaar die opdeling.

[ Voor 3% gewijzigd door Verwijderd op 06-10-2004 22:56 ]

[Verwijderd]

Suepahfly schreef op 06 oktober 2004 @ 21:31:
Ik moet zeggen dat ik de xml oplossing mooier vind.

En in mijn geval kan ik het server wide cachen vanwege de applicatie server die ik ervoor gebruik. Ik lees de bestanden eenmaal in, maak daarvan structures, en deze worden gedurende een periode in het geheugen van de server geplaatst:

application.culture."culture"."xmlbestandsnaam zonder extensie"."categorie"."label"

Dan krijg je dus application.culture.nl.sitemanagement.labels.file als referentie.

Waarom de categorien zou je zeggen, dit biedt de mogelijkheid voor bijv. dit

<labels>
<file>bestand</file>
</labels>

<tooltips>
<file>bestand</file>
</tooltips>

Dit versnelt ontwikkeling omdat je met algemene termen snel de referentie kunt maken. Ik zou sneller fouten maken als ik de tooltip bijv. file_tooltip had genoemd. Nu kan ik dus collecties relateren aan elkaar.

Tevens bied het mij de mogelijkheid om een bepaald niveau van die structure te overriden per klant. Kortom eerst de shared files inladen, dan bij de klant kijken of hij een eigen vertalingsbestand heeft, en die kan dan zo over de referentie heenschrijven.

[ Voor 25% gewijzigd door Verwijderd op 06-10-2004 23:05 ]

[maartenba]

Heb je dan ook een vereenvoudigde parser voor dit soort XML bestanden? Lijkt me niet dat hij nog attributen etc. moet gaan uitspitten?

[-FoX-]

De structuur van Gordijnstok is imho de best mogelijke aanpak die je kan gebruiken. Deze bronbestanden kunnen ook makkelijk vertaald worden door non-programmers.

Het principe van Gordijnstok is misschien ook wel afgeleidt van het i18n (Struts) principe. Daar zijn er ook resource bestanden voor iedere taal beschikbaar, waarnaar dus verwezen wordt mbv keys (die dan in de source gebruikt worden):
login.username=Username in het engelse resource bestand.
login.username=Gebruikersnaam in het nederlandse bestand.

Dus ik zou voor dit XML-principe gaan, aangezien dit de juiste structuur in je applicatie zal brengen!

[-FoX-]

maartenba schreef op 07 oktober 2004 @ 08:39:
Heb je dan ook een vereenvoudigde parser voor dit soort XML bestanden? Lijkt me niet dat hij nog attributen etc. moet gaan uitspitten?

Wat is er dan mis met de gewone PHP XML-parser? Die kan dit perfect aan hoor...

[chem]

-FoX- schreef op 07 oktober 2004 @ 08:42:

Dus ik zou voor dit XML-principe gaan, aangezien dit de juiste structuur in je applicatie zal brengen!

Beetje onzin natuurlijk, want andere vertaaltools bieden hetzelfde.

Enige voordelen van XML zijn ... nou, die weet ik eigenlijk niet.

Zoals Cheatah zegt - het maakt geen fuck uit waar je voor kiest. Migratisch naar een andere tool zijn vaak eenvoudig, en de keuze voor tool 1 of tool 2 zijn vaak situatie gebonden; zoals Gordijnstok aangeeft heeft cacheing voor hem de voorkeur. Bij mijn tool wordt de zut omgezet naar een binair geindexed bestand en zijn er emacs-modes om het te editten en is er standaard support.
Andere tools zullen weer andere mogelijkheden bieden.

-FoX- schreef op 07 oktober 2004 @ 08:43:
[...]

Wat is er dan mis met de gewone PHP XML-parser? Die kan dit perfect aan hoor...

Je bedoelt, behalve dat-ie stronttraag is en het parsen van 35kb aan XML bij elke pageview je server op z'n knieen legt?

[ Voor 17% gewijzigd door chem op 07-10-2004 10:26 ]

[Verwijderd]

maartenba schreef op 07 oktober 2004 @ 08:39:
Heb je dan ook een vereenvoudigde parser voor dit soort XML bestanden? Lijkt me niet dat hij nog attributen etc. moet gaan uitspitten?

Nee, ik gebruik de interne parser. In eerste instantie had ik voor het oudere platform wat nog geen ingebouwde XML parser had, een handmatige parser, maar momenteel gebruik ik gewoon de ingebouwde parser. In mijn geval is dat de Apache Crimson XML parser, dat is de standaard parser ingebouwd in Jrun. Voor een initiele cache ben ik pakweg 800ms in zijn totaliteit (alle talen, alle bestanden) kwijt, dat is zo gepiept zeg maar. Ik hoef ook geen enkele attributen in tags te lezen, puur parent > child relaties, lekker simpel houden

Ik kan ook zonder cache de xml serveren, maar dat koste me 35ms per request extra om de lookup in de bestanden etc. te doen, bovendien wil ik zoveel mogelijk disk access voorkomen, en zoveel mogelijk uit ram geheugen serveren. Voor een gemiddelde template incl. multilingual frontend, en vertalingen ben ik nu tussen de 10ms a 16ms kwijt, je blijft in mijn geval nog iets disk access houden ivm host files.

Zonder caching kon ik max. 20 request per seconde uitvoeren, met caching heb ik het kunnen pushen tot ong. 350 req/sec.

Ik heb dan ook de mogelijkheid tussen verschillende scopes in mijn applicaties. Per applicatie op de server kan ik een sessie management omgeving creeren met een eigen UUID. Ik kan gebruiken maken van server, application en session variables.

server: server wide toegankelijk voor alle applicaties ongeacht uuid
application: alleen toegankelijk voor de applicatie, maar voor alle client sessies binnen die applicatie
session: alleen toegankelijk voor de client sessie

Bij deze applicatie server is het nodig, dat je indien je sessie management wilt gebruiken, dit via code activeerd.

<cfapplication
name="mijn applicatie"
sessionmanagement="yes"
clientmanagement="no">

Client Management is een scope die variables serverside bijhoud, in naar keuze database, of zelfs windows registry voor standaard 3 maanden.

Ik cache dus de shared scope in de server, deze kopieer ik naar application, de klant specifieke zaken overschrijf ik dan over de application scope. Dus de server scope bevat voor mij de basis, en daarna overschrijf ik (overriding) de klant specifieke vertalingen over de application scope die gevuld was met een kopie van basis.

[ Voor 44% gewijzigd door Verwijderd op 07-10-2004 10:48 ]

[maartenba]

chem schreef op 07 oktober 2004 @ 10:25:
[...]
Je bedoelt, behalve dat-ie stronttraag is en het parsen van 35kb aan XML bij elke pageview je server op z'n knieen legt?

Zijn er andere, snellere parsers voor PHP of blijft het dit traag geval? Zou er, bij het zelf schrijven van een parser, snelheidswinst optreden?

[chem]

maartenba schreef op 07 oktober 2004 @ 19:24:
[...]

Zijn er andere, snellere parsers voor PHP of blijft het dit traag geval? Zou er, bij het zelf schrijven van een parser, snelheidswinst optreden?

Ik meen dat PHP5 aanzienlijk sneller is; maar mijn voorkeur zou het eenmalig parsen vv serializen de voorkeur hebben.
Sterker nog, ik zou het hele XML verhaal niet gebruiken aangezien Gordijnstok op dit moment geen extra attributen gebruikt dan echt een array geplot in XML.

[Verwijderd]

chem schreef op 07 oktober 2004 @ 22:06:
aangezien Gordijnstok op dit moment geen extra attributen gebruikt dan echt een array geplot in XML.

Yup Ik zou ook niet weten wat je met attributes zou moeten toevoegen aan een vertaling.

<oog green="groen" blue="blauw" red="red"></oog>

[Verwijderd]

Of je gebruikt een database die automatisch de gewenste taal voor je retourneerd op basis van de browser instellingen. (bv een rdf database die hier support voor heeft).

[Verwijderd]

Verwijderd schreef op 08 oktober 2004 @ 09:57:
Of je gebruikt een database die automatisch de gewenste taal voor je retourneerd op basis van de browser instellingen. (bv een rdf database die hier support voor heeft).

Maar dan ga je de content multilingual opslaan, en tevens op object niveau Dan zit je dus vast aan een vaste structuur.

[Verwijderd]

Verwijderd schreef op 08 oktober 2004 @ 11:07:
[...]


Maar dan ga je de content multilingual opslaan, en tevens op object niveau Dan zit je dus vast aan een vaste structuur.

tenzij je de navigatie ook op deze manier laat bepalen en voor een bepaalde taal wel of juist niet een pagina returned omdat deze niet in de database staat

[Verwijderd]

Verwijderd schreef op 08 oktober 2004 @ 11:31:
[...]


tenzij je de navigatie ook op deze manier laat bepalen en voor een bepaalde taal wel of juist niet een pagina returned omdat deze niet in de database staat

En hoe dacht je vervolgens in bijvoorbeeld een administratie interface, in een boomstructuur een actie als "vertaal naar" uit te voeren? Door je missende elementen maar dezelfde structuur zul je nooit meer je relaties kunnen leggen.

[Verwijderd]

Verwijderd schreef op 08 oktober 2004 @ 11:41:
[...]


En hoe dacht je vervolgens in bijvoorbeeld een administratie interface, in een boomstructuur een actie als "vertaal naar" uit te voeren? Door je missende elementen maar dezelfde structuur zul je nooit meer je relaties kunnen leggen.

Ik denk dat ik je niet helemaal volg. Als iets in 2 talen beschikbaar moet zijn dan maak je de pagina in de navigatie in twee talen beschikbaar zorg je voor twee talige content. Als je echter andere content plaatst dan zijn het ook niet dezelfde pagina's dus is een specifieke pagina maar in 1 taal aanwezig in de navigatie.