[XML] meertaligheid

[Genoil]

Ben bezig met het ontwerpen van een XML structuur voor een meertalige CD-ROM. De (textuele) content wordt aangeleverd als (gegenereerde) XML. Ik mag zelf bepalen hoe de structuur van de XML is, de aanleveraar van de content past de output van z'n CMS hierop aan. Wat is nu de gemakkelijkste manier om meertaligheid te ondersteunen? Ik onderscheid de volgende alternatieven:

1. meerdere files
2. meerdere elementen voor elke vertaling
3. verwijzingen naar taal-elementen in 1 of meer XML files

1. gewoon kopieen van de gehele XML file, maar dan steeds ingevuld met een andere taal. simpel, maar nadeel is dat niet-taalafhankelijke informatie x maal verdubbeld op de CD staat, en dat een niet volledig ingevulde vertaling minder eenvoudig terug zou kunnen vallen op een default taal.

2. op deze manier:

code:

<person>
    <name xml:lang="nl">piet</name>
    <name xml:lang="en">pete</name>    
    <name xml:lang="fr">pierre</name>
</person>

nadeel is dat er veel overbodige informatie in wordt geladen die niet van toepassing is, maar dat boeit voor een CD-ROM ook weer niet echt. echt overzichtelijk wordt de XML file er ook niet van, maar dat is ook niet zo heel erg..

3. zo:

code:

<person>
    <name id="123"/>
</person>

..

En dit in of dezelfde file of in aparte language xml files:

<language xml:lang="nl">
     <content id="123">piet</content>
</language>

<language xml:lang="en">
     <content id="123">pete</content>
</language>

Of zijn er nog andere handige foefjes/standaarden?

[Verwijderd]

Manier 2 lijkt mij de mooiste oplossing. Deze is erg gestructureerd.

[Genoil]

mja 3 is wat aan de complexe kant he..

[Soultaker]

Ik zie absoluut het nut van optie 3 niet. Wat dacht je daarmee te bereiken?

Wat mij betreft is de keuze dus tussen optie 1 en 2. Conceptueel is formaat 2 natuurlijk het mooiste. Verder lijkt de inhoud van formaat 1 me uit die van formaat 2 te genereren, door per bestand alle niet-relevante tags (op basis van hun taal) uit te filteren.

Formaat 2 lijkt me dus ideaal vanuit gegevensoogpunt: alles zit er precies éénmaal in. Als je echter aparte CD-ROM's voor aparte talen gaat genereren, kun je gewoon gebruik maken van formaat 1, aangezien het nogal vervelend is om informatie te hebben die je nooit kunt/wilt gebruiken.

[Genoil]

ja optie is idd een beetje bull . maar bij het maken van keuzen is het altijd mooi om 3 alternatieven aan te bieden. uit onzerzoek is dan ook nog eens gebleken dat mannen meestal de middelste optie kiezen...en kijk aan het werkt

[Verwijderd]

Hehehe, geinig,... die onderzoekjes

Maarre, ik denk dat het afhangt van je precieze doelstellingen. In .Net kan je bijvoorbeeld standaard resouce-files (.resx) gebruiken. Hiermee zou je voor elke taal een file aan kunnen maken. Hebben we hier al eens eerder gedaan en is goed te doen.

Alleen heb ik zelf nogal eens te maken gehad met kl#$%^@te vertalingen waarbij je variabelen moest combineren.
Voorbeeld: "We nodigen Typhon uit om te reageren" wordt:
NL: Var1="We nodigen ", Var2=" uit om te reageren."
EN: Var1="We invite ", Var2=" to give his reaction."
En dan Var1 en Var2 aan elkaaar plakken natuurlijk. Maar dan krijgen je variabelen hele vreemde namen die ook niet echt meer voor hergebruik geschikt zijn.

C# kan daar beter mee overweg:
string.Format("We nodigen {1} uit om te reageren.", Typhon)

Just a thought from experience...

[hobbit_be]

persoonlijk zou ik gaan voor optie 1 (word het meeste gedaan). mischien niet zo mooi als 2. maar wel non-redundant. het geven v/e 'id' aan die tags is ook helemaal niet zo slecht, maar als het net dezelfde xml moeten zijn is je 'absolute path' genoeg. Tis een beetje het probleem dat xml niet zo fantastisch is voor 'Grid' Data.

[Verwijderd]

Tis een beetje het probleem dat xml niet zo fantastisch is voor 'Grid' Data.

Hier ben ik het niet helemaal mee eens. Qua opslag in XML kan dit namelijk heel goed. Alleen is de xml met het blote oog dan misschien wat lastig te lezen en is de opslag misschien wat redundant. Feit blijft wel dat alle data heel eenvoudig in een array of dataset in te lezen is. En daarmee kan het eenvoudig in een applicatie toegepast worden.

hoe dan ook, de 'echte' datagrid moet je natuurlijk gewoon in een database dumpen, maar XML is een mooie techniek.

[drm]

Mijn voorkeur gaat uit naar optie 2.

nadeel is dat er veel overbodige informatie in wordt geladen die niet van toepassing is, maar dat boeit voor een CD-ROM ook weer niet echt. echt overzichtelijk wordt de XML file er ook niet van, maar dat is ook niet zo heel erg..

Dat is volgens mij ook geen nadeel, want daar heb je xslt voor En anders is het een kwestie van een SAX-achtige parser te gebruiken die enkel de elementen inlaadt die ook worden geselecteerd.

[RobIII]

Verwijderd schreef op 22 April 2003 @ 17:19:
...Alleen heb ik zelf nogal eens te maken gehad met kl#$%^@te vertalingen waarbij je variabelen moest combineren.
...
C# kan daar beter mee overweg:
string.Format("We nodigen {1} uit om te reageren.", Typhon)

Just a thought from experience...

Je kunt in praktisch iedere taal gewoon een replace uitvoeren.In VB(6) doe ik het altijd zo:

code:

myStr = "We nodigen %1 uit om te reageren op %2"

msgbox replace(replace(myStr,"%1",CustName),"%2",DealerName)

Of iets in die richting...

[Genoil]

Verwijderd schreef op 22 april 2003 @ 17:44:
[...]

hoe dan ook, de 'echte' datagrid moet je natuurlijk gewoon in een database dumpen, maar XML is een mooie techniek.

Ik ga er ook vanuit dat de maker van het CMS dat ook doet. De CD-ROM wordt steeds opnieuw gebrand/geperst met ververste data uit het CMS. XML wordt daarom alleen gebruikt als transportlaag tussen het CMs en de (Director) applicatie op CD-ROM.

[Bigs]

Sjah 2 is wel de mooiste manier.. en aangezien de XML toch gegenereerd en ook weer door een programma ingelezen wordt zou ik het gewoon zo doen.

[Genoil]

drm schreef op 22 april 2003 @ 17:56:
Mijn voorkeur gaat uit naar optie 2.


[...]
Dat is volgens mij ook geen nadeel, want daar heb je xslt voor En anders is het een kwestie van een SAX-achtige parser te gebruiken die enkel de elementen inlaadt die ook worden geselecteerd.

Jammer dat Director niet beschikt over een echt degelijke XML parser laat staan XSLT. Het enige wat je hebt is een DOM achtig ding en een ding wat van je XML een "property-list" maakt (da's een soort meerdimensionale array met associative indices)...