[ALG] Multilingual content beheren

[Verwijderd]

Ik zit een beetje met een design issue. Ik heb een bestaand CMS systeem. Nu wil ik dit systeem multilingual maken voor de te tonen content. De administratie interface is al multilingual.

Nu heb je naar mijn idee 2 manieren om dit te doen. Door de structuur van de website uit te breiden met bijv. 2 branches, taal 1, en taal 2. Nu moet je in je templates bepalen welke branch de root wordt van de taal van de website.

Dan heb je ook nog de mogelijkheid om op object niveau meerdere talen vast te leggen. Artikel a bestaat dan uit de childs, Nederlands en Engels bijv. Systemen als Smartsite doen dit met het commando "translation" maar de technische ondergrond daarvan weet ik niet, het kan best zijn dat er op de achtergrond toch branches worden aangemaakt.

Maar dan komt het, ga je ook de content library per taal bepalen, of wordt het een shared library, idem voor workflow, approval queue, files, accounts, etc.

Zijn er mensen die voor dezelfde probleemstelling hebben gestaan, en hebben jullie het aangepakt? Het gaat er ook om wat algemeen de gebruiker verwacht, verwacht die gescheiden stores voor de talen, of alleen die scheiding aan de frontend?

[drm]

Ik heb hier een tijdje geleden nog wat over gepost. Ik weet niet of je er wat aan hebt, maar ik quote mezelf maar even:

drm schreef op 09 juni 2004 @ 09:59:
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.


[...]
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]

drm schreef op 20 september 2004 @ 19:23:
Ik heb hier een tijdje geleden nog wat over gepost. Ik weet niet of je er wat aan hebt, maar ik quote mezelf maar even:

[...]

Ja die technische uitwerking had ik min of meer al klaar staan toen ik dacht, ho is even, maar dan moet ik ook zus en zo en die en dat en daar etc. de boel scheiden op taal.

Maar je hebt alleen wel dat je soms geen vertaling wilt hebben van een pagina, hoe maak je dan alsnog de structuur inzichtelijk, puur door een switch van taal zodat de treeview de juiste structuur gaat laden, .. zoja.. dan switched ook je content library naar de juiste taal? Of bestanden bijvoorbeeld, .. de ene keer wil je engelse pdf's tonen en de andere keer nederlandse pdf's.

En accounts? Ik heb departments, roles, policies en users, zijn die dan opeens ook per taal gedefinieerd.

[ Voor 41% gewijzigd door Verwijderd op 20-09-2004 19:31 ]

[Verwijderd]

je kan bv. voor elke tabel een language tabel opnemen.

code:

Category_ID: <PK>
Parent_ID: <FK>
Image

en dan een beschrijvende tabel:

code:

Category_ID: <PK>
Language_ID: <PK>
Name
Description

dit is de manier hoe ik het nu bijhoud, je kan dus voor al je tabellen zo'n extra tabel opnemen, en natuurlijk een tabel waarin Languages zitten zodat de user deze kan selecteren. Voor de rest gebruik ik resource files binnen .NET, maar voor database content gebruik ik bovenstaand. Ik weet niet wat PHP voor de rest bied kwa resources.

[drm]

Gordijnstok:
Maar je hebt alleen wel dat je soms geen vertaling wilt hebben van een pagina, hoe maak je dan alsnog de structuur inzichtelijk, puur door een switch van taal zodat de treeview de juiste structuur gaat laden, .. zoja.. dan switched ook je content library naar de juiste taal? Of bestanden bijvoorbeeld, .. de ene keer wil je engelse pdf's tonen en de andere keer nederlandse pdf's.

En accounts? Ik heb departments, roles, policies en users, zijn die dan opeens ook per taal gedefinieerd.

Is je vraag nu of zo'n structuur je dat verplicht, of juist wat voor keuzes je daarin moet maken?

[Verwijderd]

Ja en nee, .. ik heb een centrale bibliotheek waar de artikelen worden beheerd onderverdeeld in categorien per domein. Tevens worden hier de versies getoond en de status van elke versie, zodra je op een artikel instantie klikt.

De artikelen worden aan de linkerkant in een treeview getoond incl. de categorien. Zodra je op een artikel klikt opent in de rechterkant een lijst met de versie van het artikel. Echter.. moet ik hier ook een oplossing voor verzinnen aangezien ik meerdere talen van een artikel kan hebben. Oftewel, ik toon in de treeview links meerdere artikelen alleen in de verschillende talen, of ik maak een algehele switch van de content library naar de specifieke taal toe.

Het is ook echt een design issue qua user interface, icm wat zou in de praktijk het handigst werken voor een gebruiker. Zou het in de praktijk verstandig zijn om accounts bijvoorbeeld aan een taal te koppelen in plaats van aan een domein.

Ik heb technisch geen enkel obstakel aangezien het systeem redelijk flexibel is, maar het is wel belangrijk om vanaf het begin de goede keuze te maken aangezien het van invloed is op de algehele werking van de administratie interface.

Tevens als je gaat kijken naar de frontend kun je jezelf een aantal vragen stellen, hoe ga ik tussen talen switchen? Als ik een link in google heb, en ik klik als franzoos op die link dan wil ik wel dat de id in de url niet vastzit aan een taal. Dan ben je bij wijze al weer verkeerd bezig met meerdere branches, en moet je op object niveau definieren.

Idem als je gaat switchen tussen een taal terwijl je al op een bepaalde pagina bent aanbeland, dan wil je niet naar de homepage worden terugverwezen in de gewenste taal, maar diezelfde pagina met hetzelfde id laden in een andere taal.

[ Voor 39% gewijzigd door Verwijderd op 20-09-2004 19:57 ]

[drm]

Gordijnstok:
Tevens als je gaat kijken naar de frontend kun je jezelf een aantal vragen stellen, hoe ga ik tussen talen switchen? Als ik een link in google heb, en ik klik als franzoos op die link dan wil ik wel dat de id in de url niet vastzit aan een taal. Dan ben je bij wijze al weer verkeerd bezig met meerdere branches, en moet je op object niveau definieren.

Idem als je gaat switchen tussen een taal terwijl je al op een bepaalde pagina bent aanbeland, dan wil je niet naar de homepage worden terugverwezen in de gewenste taal, maar diezelfde pagina met hetzelfde id laden in een andere taal.

Dat is inderdaad bij websites het grote voordeel van een n:m relatie tussen "whatever_entity" en de verschillende talen. Nadelen zitten er niet zo heel sterk aan, als je je bedenkt dat het opbouwen van een tree enkel een extra join in de queries oplevert. Als je in de join (of in de where clause) de taal opgeeft, kun je daarin precies zo'n boom opbouwen als je zou hebben wanneer je maar 1 taal hebt. (backend). Verder kun je, wanneer een switch van taal optreedt op de website van te voren al checken welke talen er beschikbaar zijn van die pagina en daar adequaat op reageren. (frontend)

Gezien de relatieve eenvoud van het querien van zo'n database is het (vanuit usability oogpunt) in de backend misschien wel verstandig om de keuze uit verschillende manieren van de data presenteren aan de gebruiker zelf over te laten?

[Gomez12]

Maar hoe wil je dan met objecten omgaan die niet bestaan. Een artikel bestaat wel in het engels, maar niet in het nederlands??? Krijg ik dan mijn site in het nederlands en alleen de content in het engels? Hoe weet ik dan waar ik zit, want van de hele navigatie klopt dan niks meer ( tenminste ik kan niks bedenken voor iets als relevante artikelen etc. ).

En als ik de hele site in het engels krijg, dan krijg ik dus een situatie dat ik afhankelijk van de vertaling op http://troep/id=50 een engelse site krijg en op http://troep/id=51 een nederlandse. lekker onduidelijk.

En ik ga er gemakshalve ook even vanuit dat niet elk bericht ( = meerderheid van de berichten ) in elke taal aanwezig is. Heel weinig sites / intranetten die ik ken hebben echt alles compleet 2-talig. Puur doordat dat te veel werk zou zijn en er te veel dingen regionaal zijn.

[drm]

Gomez12:
Maar hoe wil je dan met objecten omgaan die niet bestaan. Een artikel bestaat wel in het engels, maar niet in het nederlands??? Krijg ik dan mijn site in het nederlands en alleen de content in het engels?

Dat probleem speelt pas echt als men van taal gaat switchen. In de andere gevallen is het een kwestie van altijd een INNER JOIN doen op de juiste taal; zodoende krijg je nooit gegevens te zien die niet in de juiste taal beschikbaar zijn.

Hoe weet ik dan waar ik zit, want van de hele navigatie klopt dan niks meer ( tenminste ik kan niks bedenken voor iets als relevante artikelen etc. ).

idem.

En als ik de hele site in het engels krijg, dan krijg ik dus een situatie dat ik afhankelijk van de vertaling op http://troep/id=50 een engelse site krijg en op http://troep/id=51 een nederlandse. lekker onduidelijk.

Juist niet. De combinatie van taal en id levert een juist artikel in de juiste taal op. Als dat artikel niet bestaat in de juiste taal, kom je er ook niet terecht, simpelweg omdat je de navigatie er naartoe niet geboden hebt. (Nogmaals met als uitzondering het switchen van taal, maar daarbij vind ik het niet onbegrijpelijk dat je de gebruiker op de hoogte stelt van het feit dat de opgevraagde vertaling niet beschikbaar is, met de nodige excuses e.d. )

edit:
Overigens kan ik me zo voorstellen dat het switchen naar een andere taal ook wel de minst gebruikte manier is om op een bepaalde pagina terecht te komen, maar dit heb ik niet onderzocht ofzo.

[ Voor 8% gewijzigd door drm op 20-09-2004 20:19 ]

[Verwijderd]

Gomez12 schreef op 20 september 2004 @ 20:11:
Maar hoe wil je dan met objecten omgaan die niet bestaan. Een artikel bestaat wel in het engels, maar niet in het nederlands??? Krijg ik dan mijn site in het nederlands en alleen de content in het engels? Hoe weet ik dan waar ik zit, want van de hele navigatie klopt dan niks meer ( tenminste ik kan niks bedenken voor iets als relevante artikelen etc. ).

En als ik de hele site in het engels krijg, dan krijg ik dus een situatie dat ik afhankelijk van de vertaling op http://troep/id=50 een engelse site krijg en op http://troep/id=51 een nederlandse. lekker onduidelijk.

En ik ga er gemakshalve ook even vanuit dat niet elk bericht ( = meerderheid van de berichten ) in elke taal aanwezig is. Heel weinig sites / intranetten die ik ken hebben echt alles compleet 2-talig. Puur doordat dat te veel werk zou zijn en er te veel dingen regionaal zijn.

En in zo'n geval heb je inderdaad weer baat bij meerdere branches. Dat maakt het weer lastig om de content library te filteren.

Momenteel is de structuur:

PHP:

domein
   - pagina
   - artikelen
   - accounts

Ik denk dan dat een structuur zoals volgende beter zou zijn

PHP:

domein
   - taal
       - pagina
       - artikelen
   - accounts

Zo bepaal je per domein de content, maar zijn de accounts bepaald voor het domein ipv per taal.

[ Voor 22% gewijzigd door Verwijderd op 20-09-2004 20:33 ]

[alienfruit]

Zelf maak ik gebruik van overerf het principe, waarbij ik een bepaalde prioriteit toe ken aan een publication constrain vervolgens kun je meerdere constraints aan elkaar koppelen. De master constrain bevat dan het "statische" asset, en de kinderen bijv. voor een bepaalde taal. Je kan vervolgens bij een publication constraint een bepaalde locale id opgeven (i.e. UK, NL of zoiets) vervolgens als je een item wilt vertalen kun je dus kiezen voor welk taal het is d.m.v. van he topgeven van een van child publication constraints. Maar goed dat werkt nu de admin nog... treeviews zijn irritant

code:

publication constraint  (branding assets)
        |
      /   \
    NL   EN

NL child PC => 200
EN  child PC -> 200
Branding Assets PC => [magic number] 1105198201923

Op het moment dat er geen vertaling is voor een engelse asset, wordt er niet gebruik gemaakt van de asset. Maar wordt er automatische workflow aangeslingerd zodat iedereen die normaal die dingen vrtaal een mailtje krijgen zodat ze weer wat te doen hebben. Maar goed, het is voorlopig toch niet af. Vandaag maar even het beheergedeelte maken, hopelijk met een mooie treeview (Zucht )

[ Voor 38% gewijzigd door alienfruit op 21-09-2004 13:47 ]

[Verwijderd]

De treeview is niet het probleem, wel wat je wel en niet laat zien op welk moment.

[Verwijderd]

alienfruit schreef op 21 september 2004 @ 13:41:

code:

publication constraint  (branding assets)
        |
      /   \
    NL   EN

NL child PC => 200
EN  child PC -> 200
Branding Assets PC => [magic number] 1105198201923

Zo'n principe heb ik dus inderdaad ook geimplementeerd. Alleen iets anders,

code:

instance     label                 culture       subinstance
           1     my content       1                1
           1     mijn content     2                2

Ik heb me alleen een beetje in de nesten gewerkt want ik bezit momenteel al erg veel functionaliteit die nu afhankelijk word van vertaling. Rechten op een instance, worden nu verplaatst naar een subinstance, versies van een instance worden nu verplaatst naar een subinstance, many to many relatie tabellen idem naar subinstance. Waar je normaliter op het laagste niveau nog is een table erbij kan plaatsen moet ik nu op het allerhoogste niveau een table ertussen plaatsen, met als gevolg dat alle, maar dan ook alle relaties verlegd worden.

Voor mij is multilingual content echt een enorm karwei.

[alienfruit]

Aah, moet eerlijk toegeven dat het nog niet echt werkt hoor Work in progress. Maar zou ik jou misschien eens mogen mailen over het treeview gebeuren? Ik krijg dat echt niet voor elkaar

[Verwijderd]

Wat niet? Het maken ervan?

[ Voor 50% gewijzigd door Verwijderd op 21-09-2004 22:57 ]

[alienfruit]

Nou hij laadde eerst mijn plaatjes niet, maar dat kwam om er gewerkte met hard-coded waardes in de andere js-scripts dus die moest ik veranderen. Enige probleem wat ik nu heb is dat ik niks kan doen als er op een bepaald item wordt geklikt, het zou leuk zijn als ik dan een pagina kan openen in een bepaald frame. Ik zag dat je wel een TARGET en HREF property uit de XML file haalt, maar je doet er vervolgens niks mee? (toch?)

[Anders]

Verwijderd schreef op 20 september 2004 @ 19:20:
Zijn er mensen die voor dezelfde probleemstelling hebben gestaan, en hebben jullie het aangepakt? Het gaat er ook om wat algemeen de gebruiker verwacht, verwacht die gescheiden stores voor de talen, of alleen die scheiding aan de frontend?

Ik zie iedereen meteen in de database-structuur duiken, terwijl dit essentiële gedeelte wordt overgeslagen. Eerst dienen de functionele requirements en randvoorwaarden vastgesteld te worden, anders valt er geen zinnig woord over te zeggen.

Wordt alle content 1 op 1 vertaald, kan de content vrijelijk verschillen tussen taalversies of zit het er een beetje tussenin? Dient content per taal gepubliceerd te worden, of generiek over het gehele systeem? Zijn er embargo's? Zijn die taal-afhankelijk?
Wie voert de content in? Is dat 1 meertalige redactie op een hoofdkantoor, of zijn het tig mensen verspreid over tig landen? Wie controleert de content?

Nog leuker wordt het als je behalve met meertaligheid, ook met landenindelingen te maken krijgt. België is tweetalig, Zwitserland viertalig. Is daar de meertalige content (wel) 1 op 1 gekoppeld?

Naast de content-kwestie, weet ik uit ervaring dat het eerder regel dan uitzondering is dat er per taal, per land of per combinatie van beide, verschillen in functionaliteit vereist worden. Wat weet je hierover van tevoren? Iedereen die een beetje programmeert, weet hoe lastig, irritant of onmogelijk het kan zijn om flexibiliteit in een generiek systeem te knutselen wanneer dat niet van tevoren, maar op het laatste moment duidelijk wordt. Kun je nagaan hoe zeer dat van toepassing zal zijn als je te maken hebt met meerdere talen, meerdere landen en een combinatie van die twee. Ik heb meerdere malen hele mooie (CM) systemen zien afglijden van een subliem fundament bij de start, naar een houtje-touwtje-bouwval bij oplevering omdat in een veel te laat stadium werd nagedacht over wat de eindgebruiker er nou eigen mee wil en moet kunnen doen.

Er zijn zoveel, zoveel vragen waar je antwoord op moet hebben voordat je ook maar kunt denken aan de ontwikkeling van een datamodel. Wanneer ik zie dat hier direct al allerlei technische voorstellen over tafel gaan, dan past daar wat mij betreft maar 1 reactie bij (excusez le smiley): Dat is niet om beledigend over te komen, maar omdat er essentiële stappen worden overgeslagen.

[Verwijderd]

Huh? ..

"Maar dan komt het, ga je ook de content library per taal bepalen, of wordt het een shared library, idem voor workflow, approval queue, files, accounts, etc."

Dat lijkt me toch redelijk uit de buurt van een technische aanpak liggen Maar ik ben er al uit, het systeem krijgt een master table met daarin referenties naar de instanties van elke cultuur. Dit houdt in dat elke cultuur zijn eigen content store krijgt, maar wel gedeelde accounts.

Dit houdt uiteindelijk in, dat:

De structuur niet synchroon hoeft te zijn
De structuur synchroon kan zijn
De content per taal per domein wordt bijgehouden
Elke instantie van een taal zijn eigen versiebeheer heeft
Elk domein zijn eigen workflow heeft

Al met al ligt er nu een transparante flexibele laag over het systeem die niet anders doet dat de publiekelijke referentie vertalen naar een systeem referentie.

[drm]

alienfruit:
Nou hij laadde eerst mijn plaatjes niet, maar dat kwam om er gewerkte met hard-coded waardes in de andere js-scripts dus die moest ik veranderen. Enige probleem wat ik nu heb is dat ik niks kan doen als er op een bepaald item wordt geklikt, het zou leuk zijn als ik dan een pagina kan openen in een bepaald frame. Ik zag dat je wel een TARGET en HREF property uit de XML file haalt, maar je doet er vervolgens niks mee? (toch?)

Modbreak:

Doe maar even niet topic kapen, alsjeblieft dankjewel

offtopic:
en bah, wat is die modbreak-tag verschillelijk lelijk

[alienfruit]

Sorry.

[Verwijderd]

alienfruit schreef op 22 september 2004 @ 11:55:
Sorry.

Mail maar, handelen we het daar even af. Het is super simpel namelijk. Alleen is er nog geen documentatie dus wordt het voor de onwetende nogal lastig.

[ Voor 27% gewijzigd door Verwijderd op 22-09-2004 12:04 ]