>
> 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/aspdecoffeehouse.asp
