Vertalingen: XML of DB ?

woensdag 4 juni 2008 01:30

Topicstarter

g4wx3 schreef op woensdag 04 juni 2008 @ 01:15:
DB

makkelijkste:
template in 3 talen (hardcoded)
oproepen doen naar de 3 tables met een prefix: FR_BLABLA, NL_BLABLA

Zou ik zo doen, mja, ik ben maar een amateur

Ik heb slechte ervaringen met XML, gebruik het nooit nimeer, enkel mischien nog JSON

Ehhhhhh ja, dat is helemaal een oplossing waar ik niet op zit te wachten eigenlijk. Ik wil dan evt. één template, en twee tabellen: language en translations. Anders moet ik bij veranderingen 3 tabellen en 3 templates aanpassen.

Acties:

woensdag 4 juni 2008 01:42

MATERIALISE!

Je vergeet eigenlijk de optie flat files.
Gewoon txt of .php-bestanden die één of meerdere php-arrays bevat.
$lang['index']['btnSubmit'] bijvoorbeeld. Je maakt dan per taal een bestand aan.
Zo werd het gedaan in (een oudje

) YaBB.SE (forum)

Als je dit echt alleen gebruikt voor dingen als buttons en statische tekstjes die niet veranderen is dit imho de manier die je moet gebruiken.
Een database is de tweede keus (maar aangezien je het niet veranderd en weinig teksten hebt eigenlijk alleen maar onzinnig).
Zodra je naar meer dan die 500 regels gaat zou ik wel alles in een database stoppen.
XML is hier niet het goede idee voor.
Granted, alles is gestructureerd, maar het is voor zoiets zo enorm bloated. XML is een middel, geen doel. XML is leuk om data te transferen tussen systemen (hard/soft), maar voor pure opslag vind ik het minder geschikt, al hangt het van de situatie af.

Pong is probably the best designed shooter in the world.
It's the only one that is made so that if you camp, you die.

Acties:

woensdag 4 juni 2008 01:47

Topicstarter

't Punt is dat ik gewoon leesbare tekst in de templates wil. De ontwerper gaat die templates maken, en vind het prettig als 'ie gewoon in een default taal (Engels of Nederlands in dit geval) wat tekst erin kan zetten, en dan kan ik in de database of whatever een vertaling plaatsen.

Die flatfile-optie ben ik zeker niet vergeten, maar dat vind ik gewoon niet praktisch.

Acties:

disjfa

be

mcdronkz schreef op woensdag 04 juni 2008 @ 01:42:
Die flatfile-optie ben ik zeker niet vergeten, maar dat vind ik gewoon niet praktisch.

Dus wat je eigenlijk wilt zeggen is dat je de conclusie al hebt gezien maar het niet zeker weet. Doe dan gewoon wat je zelf wilt en laat ons daar niet over beslissen

disjfa - disj·fa (meneer)
disjfa.nl

woensdag 4 juni 2008 01:53

Acties:

left part of the evil twins

g4wx3 schreef op woensdag 04 juni 2008 @ 01:15:
DB

makkelijkste:
template in 3 talen (hardcoded)

Uhm templates kun je in een systeem als Smarty ook laten precompilen met vertalingen. Hoef je niet 3 varianten te onderhouden en houd je je systeem generiek.

En goh, laat topicstarter nu net PHP gebruiken.

woensdag 4 juni 2008 01:55

Acties:

woensdag 4 juni 2008 02:00

Topicstarter

disjfa schreef op woensdag 04 juni 2008 @ 01:47:
[...]

Dus wat je eigenlijk wilt zeggen is dat je de conclusie al hebt gezien maar het niet zeker weet. Doe dan gewoon wat je zelf wilt en laat ons daar niet over beslissen

Nee, ik zoek argumenten om wel of geen database te gebruiken. Ik kan het niet compleet aan mezelf verantwoorden om één van beide opties te gebruiken.

Wat voor mij ook wel het overwegen waard is.. dalijk zit ik natuurlijk met een ontwerper/contentmanager die vertalingen enzo wil aanmaken/muteren. Nu is 't voor een databaseomgeving natuurlijk stukken makkelijker om een tooltje te schrijven waarin dat mogelijk is dan dat zoiets voor een XML bestand zou zijn. Bovendien ga je XML dan ook als een soort database gebruiken en dat lijkt me allerminst de bedoeling. 't Is in elk geval wel handig als een ontwerper niet in XML bestanden hoeft te gaan wroeten met eventueel alle gevolgen van dien.

[ Voor 38% gewijzigd door mcdronkz op 04-06-2008 02:01 ]

Acties:

Juup

Er is nog een mooie optie: een XML database (zoals eXist)
Daar praat je met XQuery tegenaan (of met Java) en het cobineert de snelheid van een database met de handigheid van xml.

Een wappie is iemand die gevallen is voor de (jarenlange) Russische desinformatiecampagnes.
Wantrouwen en confirmation bias doen de rest.

woensdag 4 juni 2008 02:07

Acties:

woensdag 4 juni 2008 02:15

MATERIALISE!

Database
Tegen (vanuit jouw zichtspunt):
- NET zo onoverzichtelijk voor de designer als textfiles (namelijk: het staat alsnog niet in de templates)
- Extra belasting voor je DB (en dus minder goed schaalbaar)
- Voor "elke" vertaling moet je een query doen, anders werk je ALSNOG met arrays (zie flat files

)
- Ongestructureerd (jij wil alle talen immers in 1 tabel)

Voor:
- "Makkelijker" voor jou.
- Minder moeite een extra vertaling toe te voegen

XML
Tegen:
- Bloated
- Even leesbaar voor de designer als flat files
- Onoverzichtelijk met veel vertalingen in 1 bestand
- Per taal een xml-file nodig (anders wordt ie te groot)

Voor:
- Makkelijk vertalingen "ergens anders" ook te gebruiken
- Gestructureerd

Flat Files
Tegen:
- Even onleesbaar als een database of xml-files voor de designer
- Per taal een file nodig (evenals bij xml)

Middel:
- Redelijk gestructureerd te houden, maar niet vanuit dat oogpunt opgezet

Voor:
- Sneller dan andere opties (al kan xml dichtbij zitten)
- Makkelijk met programmeren

Gettext e.a.
Tegen:
- Je moet hem "builden"
- Minder goed leesbaar voor je designer

Voor:
- Even snel als / sneller dan flat files
- "Native" php-functie

Dus als je geen flat files of gettext wil gebruiken, om wat voor reden dan ook, dan moet je inderdaad maar even naar de oplossing van curry684 kijken.
Als je dat ook niet wil dan staan hierboven dus mijn redenen per oplossing waarom wel/niet.

Als opmerking nog:
- Templates / flat files / xml-bestanden zijn per webserver te cachen. De database niet.
Een webserver is veelal goedkoper dan een zwaardere kickass DB-server.

[ Voor 5% gewijzigd door krvabo op 04-06-2008 02:08 ]

Pong is probably the best designed shooter in the world.
It's the only one that is made so that if you camp, you die.

Acties:

woensdag 4 juni 2008 02:28

Topicstarter

krvabo schreef op woensdag 04 juni 2008 @ 02:07:
[..]

Mooi overzicht, kan me er grotendeels in vinden, thanks !

Ik zie alleen even niet waarom een database ongestructureerd zou zijn. Als ik een fatsoenlijk genormaliseerd database-ontwerp maak is het prima mogelijk om de vertalingen vrij gestructureerd op te kunnen slaan. Het los ophalen van elke vertaling met daarbij de nodige queries is natuurlijk niet zo tof, kan ik me goed in vinden. Maar als ik alles ophaal (wat natuurlijk niet immens veel is, voor DB-begrippen) zit ik welliswaar met arrays (of objecten) te werken, maar 't is niet echt een eerlijk vergelijk met flatfiles aangezien het op een totaal andere manier opgeslagen wordt. Ik ga liever vertalingen in een DB muteren dan dat ik dat in een flatfile met een array moet gaan doen. 't Is niet zo'n issue ofzo, maar gemak dient de mens.

Wat XML betreft ben ik het met al je punten wel eens.

[ Voor 46% gewijzigd door mcdronkz op 04-06-2008 02:30 . Reden: 't is al laat. ]

Acties:

left part of the evil twins

krvabo schreef op woensdag 04 juni 2008 @ 02:07:
Als opmerking nog:
- Templates / flat files / xml-bestanden zijn per webserver te cachen. De database niet.
Een webserver is veelal goedkoper dan een zwaardere kickass DB-server.

Ahum, precompiled templates, database queries en retrieved dictionaries zijn perfect op je webserver te cachen. Daarmee kun je eenvoudig je best case DB-load reduceren tot 1 of 2 queries per page.

- Voor "elke" vertaling moet je een query doen, anders werk je ALSNOG met arrays (zie flat files )

Kan iemand me uitleggen waarom arrays ev0l zouden zijn in deze construct?

Tip: PHP slaat associative arrays op als b-trees.

[ Voor 20% gewijzigd door curry684 op 04-06-2008 02:30 ]

woensdag 4 juni 2008 02:31

Acties:

woensdag 4 juni 2008 02:34

Topicstarter

curry684 schreef op woensdag 04 juni 2008 @ 02:28:
[...]

Kan iemand me uitleggen waarom arrays ev0l zouden zijn in deze construct?

Tip: PHP slaat associative arrays op als b-trees.

Dat zijn ze niet, maar het opslaan van taalbestanden in flatfiles met arrays erin lijkt me niet zo'n relaxed plan.

Acties:

left part of the evil twins

mcdronkz schreef op woensdag 04 juni 2008 @ 02:31:
[...]

Dat zijn ze niet, maar het opslaan van taalbestanden in flatfiles met arrays erin lijkt me niet zo'n relaxed plan.

Dat is een tweede, maar waarom zou je niet eenmalig alle vertalingen uit je DB trekken en als associative array opbouwen en deze vervolgens serialized in je disk cache dumpen?

edit:
oh wacht dat zei je zelf ook al... dan is de vraag voor krvabo

[ Voor 9% gewijzigd door curry684 op 04-06-2008 02:36 ]

woensdag 4 juni 2008 02:37

Acties:

woensdag 4 juni 2008 02:44

Topicstarter

curry684 schreef op woensdag 04 juni 2008 @ 02:34:
[...]

Dat is een tweede, maar waarom zou je niet eenmalig alle vertalingen uit je DB trekken en als associative array opbouwen en deze vervolgens serialized in je disk cache dumpen?

Dat is voor mij geen enkel probleem.

edit:
Ok, ik wou al zeggen

[ Voor 5% gewijzigd door mcdronkz op 04-06-2008 02:38 ]

Acties:

Verwijderd

http://framework.zend.com...zend.translate.using.html

woensdag 4 juni 2008 08:55

Acties:

Niemand_Anders

Dat was ik niet..

Bij een meertalige website komt meer kijken dan alleen vertalingen. Het gaat ook op presentatie van getallen (1,000.00 vs 1.000,00) en uiteraard datums. Al nagedacht hoe je voorkomt dat een Nederlands artikel in de engelse layout wordt getoond? Je zult dus ook per taal (culture) een navigatie boom nodig hebben.

Wij werken veel met xml/xsl en ik gebruik een xsl template per culture. Wij hebben dus bestanden als layout.nl-nl.xsl, layout.nl-be.xsl, layout.en-us.xsl, etc. In ons geval is het dus niet nodig om de vertalingen in een apart bestand of database bij te houden. Onze GetXslStylesheet functie kijkt eerst of {name}.{language.dialect}.xsl bestand, dan {name}.{language}.xsl en vervolgens {name}.xsl.

If it isn't broken, fix it until it is..

woensdag 4 juni 2008 09:29

Acties:

woensdag 4 juni 2008 10:02

MATERIALISE!

curry684 schreef op woensdag 04 juni 2008 @ 02:28:
[...]

Ahum, precompiled templates, database queries en retrieved dictionaries zijn perfect op je webserver te cachen. Daarmee kun je eenvoudig je best case DB-load reduceren tot 1 of 2 queries per page.

Ik moet toegeven dat ik zeker geen database-expert ben (ik wist ook niet van het bestaan van retrieved dictionaries

), maar ik zei ook al dat de templates te cachen zijn op de webserver. Wat bedoel je met de queries cachen? Puur de tekst, of al het resultaat plaatsen in (bijvoorbeeld) memcache?
Tja uiteraard kun je de resultaten wel cachen, maar die zijn ook maar beperkte tijd goed. Het blijft uiteraard een work-around voor het probleem dat je bottleneck gewoon de database is.
Deze vertalingen zijn uiteraard "oneindig" te cachen in memcache, maar dan neem je ook weer ruimte in die misschien beter ergens anders voor gebruikt kan worden.
Het is een afweging of je dit wil.

[...]

Kan iemand me uitleggen waarom arrays ev0l zouden zijn in deze construct?

Tip: PHP slaat associative arrays op als b-trees.

Ik zei ook niet dat arrays evil zouden zijn?
Ik had het eerder over het zelf uitschrijven van de arrays in een flat file. Ik vind dat zelf een prima oplossing voor dit probleem, de TS gaf echter aan dat hij dit niet ziet zitten. Ik dacht dat een van zijn problemen misschien was dat hij geen arrays hiervoor wilde gebruiken..
Wat je gaat doen als je alles ophaalt vanuit de DB, namelijk alles in een array zetten, kan je dus ook al "vooraf". Het voordeel met het halen uit de database is uiteraard wel dat je maar van 1 pagina de gegevens hebt. Met die flat files heb je alle pagina's in je array.
Het uiteindelijke 'mechanisme' om alles op 1 pagina te krijgen is bij flat files met arrays hetzelfde als het halen uit de database. Je print bij beiden de output vanuit de array op de knop of pagina.

Bij flat files kun je die language-arrays gewoon importeren en kun je ze meteen vanuit php aanroepen, bij de database moet je een query uitvoeren en de resultset vervolgens in een array plaatsen voordat je het kunt gebruiken.
Als de TS ruimte heeft op zijn server om deze gegevens te cachen m.b.v. bijvoorbeeld memcache dan is dat ook een valide keuze.
Ik weet echter niet wat dan nog sneller is, het omzetten van de (kleinere) resultset naar een array en outputten, of het importen van een (grotere) array en die outputten.
Als de TS hangt op snelheid is dat misschien iets wat hij kan testen?

Pong is probably the best designed shooter in the world.
It's the only one that is made so that if you camp, you die.

Acties:

unclero

MB EQA ftw \o/

* unclero heeft vaker met dit bijltje gehakt

Ik zou eerst kijken hoeveel tekst je nodig hebt. Als je alleen maar string resources moet hebben voor je webapplicatie.. Dan zou ik platte tekstfiles gebruiken.

code:

webroot
 |
 +- /res
       |
       +- 1033.txt
       +- 1036.txt
       +- 1043.txt

enz.

Als je complete paginas multi-language wil hebben zou ik in je CMS met vlaggetjes in je content tables gaan werken.

Quelle chimère est-ce donc que l'homme? Quelle nouveauté, quel monstre, quel chaos, quel sujet de contradiction, quel prodige!

woensdag 4 juni 2008 10:11

Acties:

Haan

dotnetter

Microsoft doet het (in ieder geval in Dynamics producten) met XML

Bijvoorbeeld

XML:

<root>
    <Buttons>
        <Button icon="icon.gif">
            <Titles>
                <Title lcid="1033" text="English" />
                <Title lcid="1043" text="Nederlands" />
            </Titles>
            <ToolTips>
                <ToolTip lcid="1033" text="English" />
                <ToolTip lcid="1043" text="Nederlands" />
             </ToolTips>
         </Button>
    </Buttons>   
</root>

Kater? Eerst water, de rest komt later

woensdag 4 juni 2008 10:13

Acties:

left part of the evil twins

krvabo schreef op woensdag 04 juni 2008 @ 09:29:
[...]

Ik moet toegeven dat ik zeker geen database-expert ben (ik wist ook niet van het bestaan van retrieved dictionaries )

Mwah de term is dan wat onduidelijk

Ik bedoel gewoon een gerichte query op wat je uit de DB nodig hebt en deze met beperkte TTL in mem of op disk cachen.

Wat bedoel je met de queries cachen? Puur de tekst, of al het resultaat plaatsen in (bijvoorbeeld) memcache?

Care, doe iets?

Tja uiteraard kun je de resultaten wel cachen, maar die zijn ook maar beperkte tijd goed. Het blijft uiteraard een work-around voor het probleem dat je bottleneck gewoon de database is.

Dat is iedere vorm van caching, en daardoor juist zo krachtig.

Deze vertalingen zijn uiteraard "oneindig" te cachen in memcache, maar dan neem je ook weer ruimte in die misschien beter ergens anders voor gebruikt kan worden.
Het is een afweging of je dit wil.

Geloof me, je kunt een local disk cache met duizenden vertalingen gewoon op disk storen en per pageview unserializen, en dan nog op complexe pagina's die nog 10+ andere queries doen minder dan 0.5 seconde kwijt zijn per pagina. Easy.

De grootste fout die mensen maken met cachen is dat ze de performance van hun database overschatten en die van hun disk onderschatten. Een filetje van een paar k serializen/unserializen kost zo enorm geen kruim in vergelijking met je DB in gaan... van die 0.0005 seconde heeft niemand last, en je maakt je site er ZO veel sneller mee.

Wat je gaat doen als je alles ophaalt vanuit de DB, namelijk alles in een array zetten, kan je dus ook al "vooraf". Het voordeel met het halen uit de database is uiteraard wel dat je maar van 1 pagina de gegevens hebt. Met die flat files heb je alle pagina's in je array.

Waarom zou je het maar voor 1 pagina halen? Hoppa, if Nederlands, then retrieve all Nederlandse vertalingen, en serializen naar dutch-dictionary.dat. Braaf filemtime checken voor stale cache zodat je iedere paar minuten een nieuwe trekt en het performt als een gek.

woensdag 4 juni 2008 11:08

Acties: