Ich habe bei einem 4 Sprachigem Projekt Variate d verwendet. Vor allem
deshalb, weil der Kunde die Texte auch Online pflegen wollte. Es l�uft in
einer annembahren Geschwindigkeit. Von daher kann ich es durchaus empfehlem.


Andreas Roth
--------------------------------------
[EMAIL PROTECTED]           *jetzt mit Chat*
http://www.EuphoriasChild.DarkTech.org
-------------------------------------- 

> -----Urspr�ngliche Nachricht-----
> Von: Claudius Ceteras [mailto:[EMAIL PROTECTED]]
> Gesendet: Mittwoch, 19. Dezember 2001 22:20
> An: AspGerman Kaffeehaus
> Betreff: [aspdecoffeehouse] RE: Vorschlag zu language-file
> 
> 
> 
> > 
> > Hallo,
> > 
> > Prinzipiell....
> > Eine Intranet - Oberfl�che soll mehrsprachig sein
> > (Buttons, Erkl�rungstexte, �berschriften,...jedes kleine fitzel...)
> > 
> > M�gl. a)
> > F�r jedes Fitzel eine eigene Variable schreiben, das File includesn
> und an
> > den entsprechenden stellen ausgeben.
> 
> Schlechte Idee.
> Nicht dynamisch inkludierbar... z.B. wenn ein Surfer eine 
> andere Sprache
> m�chte als die anderen...
> 
> > 
> > M�gl. b)
> > Das ganze clientseitig in ein Javascript packen und wenn der Text
> nicht
> > deutsch ist die Stellen (z.B. mit ID gekennzeichnet) mit der sprache
> > �berschreiben
> 
> Schlechte Idee. (aber innovativ ;-))
> Lokalisierung sollte serverseitig implementiert werden, da nur dort
> unproblematisch z.B. auch Datumsformate etc. lokalisierbar sind...
> 
> > 
> > M�gl. c)
> > stylesheet definieren...Behaviours und im behaviour die Sprachen
> > definieren
> > (Find ich nicht sehr performant die behaviours ... um nicht zu sagen
> > beschi*** langsam)
> genau! Ansonsten siehe Kommentar zu M�gl. b
> 
> > 
> > M�gl. d.)
> > DB-Tabelle und jedesmal ein rs �ffnen
> > 
> > M�gl. e.)
> > Die Sprachen in z.B. ein XMl-File reinschreiben ... in der 
> global.asa
> und
> > dann an den Stellen die Nodes auslesen
> > 
> > 
> > Andere Vorschl�ge? Tips?
> > 
> 
> Ich w�rde eine Mischung aus d und e vorschlagen...
> Eine DB als Persistenz-Medium, wegen des leichten Handlings und ein
> FreeThreadedDOMDocument in einer Application-Variable als schneller
> Cache
> 
> Noch besser als ein FreeThreadedDOMDocument w�re ein freethreaded
> Dictionary-Objekt, allerdings sollte man dann unbedingt das Verhalten
> mit vielen Daten testen, man kann nie wissen, ob der 
> Programmierer nicht
> irgendwo einen Bock geschossen hat, der sich erst bei gr�sseren
> Datenmengen sich...
> 
> Als DB-Schema w�rde ich sowas vorschlagen:
> 
> Sprachen:
> LCID int PK
> Short varchar
> Name varchar
> Icon varchar
> 
> Beispiel-Eintr�ge:
> 1031, "de", "deutsch", "de.gif"
> 1033, "en", "english", "en.gif"
> -------------
> Texte:
> ID int PK
> LCID int PK
> Text varchar
> 
> Beispiel-Eintr�ge:
> 1, 1031, "Apfel"
> 1, 1033, "Apple"
> 2, 1031, "Auto"
> 2, 1033, "Car"
> 
> Zum Caching ist folgendes zu sagen:
> 
> Wenn man ein Dictionary benutzt ist der Zugriff durch Hashing schnell
> genug auch bei gr�sseren Datenmengen...
> Mann k�nnte "[LCID][ID]" als Schl�ssel ins Dictionary nehmen, 
> also z.B.
> "10332" f�r "Car"
> 
> Wenn man ein XMLDOM benutzt darf man die Eintr�ge nicht flach 
> abbilden,
> den das w�rde beim Zugriff dann linear durchsucht und sehr langsam
> werden...
> 
> Am einfachsten bildet man nach dem 10er-System ab(optimaler w�re wohl
> 4er bis 6er, aber der zus�tzliche Umwandlungsaufwand lohnt 
> nicht), d.h.
> dass der deutsche text mit der id 1234 im XML-Baum unter
> /de/A1/A2/A3/A4/@text ablegt, also etwa so
> 
> <root>
>  <de>
>   <A1>
>    <A2>
>     <A3>
>      <A4 text="Hallo %1%, willkommen im XYZ Intranet">
>       ....
>       ....
>      </A4>
>     </A3>
>    </A2>
>   </A1>
>  </de>
> </root>
> 
> die Nummern als Tag-Namen zu nehmen ist �brigens schneller als ein
> Konstrukt mit Attributen(<A3> statt <A n="3"> o.�.)
> 
> Dann muss man sich noch �berlegen, ob man den Cache vom Anfang an voll
> f�llt, oder auf Anfrage...
> Bei einem normalen Intranet, bei dem nur die Oberfl�che 
> �bersetzt wird,
> kann man ruhig im Application_onstart die gesamte Texte-Tabelle ins
> XMLDOM spiegeln
> 
> Was man auf jeden Fall vorsehen sollte sind Variablen im Text, so wie
> oben angedeutet....
> 
> Die LCID w�rde ich f�r ein intranet in einer session-variable 
> speichern,
> so dass man nur z.B. locText(123) schreiben muss bzw. wenn man auch
> variablen zul�sst und nur eine funktion haben m�chte, dann
> locText(123,Null) oder locText(145,Array(name, alter)), wobei 
> das Array
> die Variablen enth�lt, mit dennen %1%, %2% usw. Ersetzt werden....
> 
> So... das soll erstmal reichen....
> 
> Claudius
> 
> 
> | [aspdecoffeehouse] als [EMAIL PROTECTED] subscribed
> | http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv
> | Sie k�nnen sich unter folgender URL an- und abmelden:
> | 
> http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffee
house.asp

| [aspdecoffeehouse] als [email protected] subscribed
| http://www.aspgerman.com/archiv/aspdecoffeehouse/ = Listenarchiv
| Sie k�nnen sich unter folgender URL an- und abmelden:
| http://www.aspgerman.com/aspgerman/listen/anmelden/aspdecoffeehouse.asp

Antwort per Email an