WoltLab Community Forum

hallo,

ich habe bereits einige akrobatioen angestellt, es ist mir aber nicht gelungen mein forum , das zur zeit mit der codierung iso-8859-2 läuft, einwandfrei zu importieren.
es wird zwar importiert ( ich kann ja nur iso-8859-1 oder utf-8 wählen) aber die diaktrischen zeichen werden nicht korrekt dargestellt.
was kann ich da bitte tun?

hallo,
ja, ich kann euch eine sicherung der db zur verfügung stellen (gehe davon aus, dass diese "vertraulich" behandelt wird)
dazu 2 fragen noch:
1. an wen soll ich diese schicken?
2. womit soll ich sie erstellen? mit dem forumswerkzeug oder mysqldumper?


@selftitled:
warum iso-8859-2 und nicht utf-8?
es ist fast 2 jahre her, wo ich das wbb2 übersetzt habe... ich erinnere mich dunkel, dass da mit utf-8 etwas nicht klappte und übrigens, das richtige anzeigen der verdammten zeichen in forummails hab ich bis heut nicht hinbekommen, ist aber jetzt nicht mehr wichtig...

prima,

die mail, mit den datenbanktabellen bb1_threads und bb1_posts ist bereits raus.
bin echt froh, dass ich da nicht allein dran "kauen" muss...

oha?

dann wundert es mich jetzt echt, dass alles bisher im wbb2 geklappt hat.
wie kann ich denn jetzt im nachhinein die kodierung ändern? oder würd es reichen, wenn ich beim import die kodierung des importierten forum als iso-8859-1 angebe? aber das würd wahrscheinlich nichts bringen.

hallo,

ich weiss jetzt nicht mehr weiter...
laut meines hosters, sollte ich die besagte db löschen und neu einspielen, dabei die kodierung wählen. nur... wenn ich (in phpmyadmin) latin2 wähle gibt es eine fehlermeldung


und so wird es mit " ( 1, 'witam' ) , ( 2, 'ten' )" bis zu 2800 worter fortgesetzt...drunter steht :
klick ich auf "anzeigen" kommt:
, gebe ich utf8 beim importieren an, imoprtiert er sie alle mit latin1.

ich habe im mysqldumper zeichenstaz und sortierung auf latin2 geändert allerdings nicht bei allen , bei wbb1_thread und post, es sind 74 tabellen , die zusätzlich noch in den fields den zeichensatz definiert haben. es hilft alles nichts.

das wird doch sicher irgenwie hinzubekommen sein.
jemand, der sich mit mysql richtig auskennt wird wohl wissen, was da angemeckert wird, ich blick da nicht mehr durch.

hallo,

der import hat nichts gebracht, ich habe auch die kodierung der einzelnen tabellen, zu fuß, geändert, das nuzt auch nichts, zumindest wirkt sich nicht auf das ausgeben der vorhandenen einträge in der DB

zusammen gefasst:
im original haben die tabellen, die kodierung und kollation auf "latin1_swedish_ci" stehen. die polnische zeichen werden im browser (im wbb2) korrekt angezeigt aber nur so lange der user die forums sprache auf polnisch eingestellt hat und nur solange in dem polnischen sprachpaket (kategorie-global), in der variable LANG-GLOBAL-ENCODING "iso-8859-2 " eingetragen ist.

ich bin schon auf die "glorreiche" idee gekommen in den inhalten die zeichen zu ersätzen, ging natürlich daneben, die geänderten dateien wurden nicht angenommen. wie viel zeit und aufwand darauf ging sag ich lieber nicht *selbstschuld*...

meine frage jetzt: gibt es einen sql befehl mit dem man zeichen in den tabelleninhalten ersetzen kann?

p.s.
das konvertieren mit iconv, das selftitled vorgeschlagen hat schaff ich wohl nicht allein...

Quoted from "selftitled"

machs mal ohne inhalt der bb1_wordlist. diese kannst du ja im acp eh wieder erstellen lassen.

hallo,

sagt mir bitte jemand wie ich die wordlist im acp wieder erstellen kann? und in welcher abhängigkeit von einander die tabellen: bb1_wordmatch und bb1_wordlist stehen?
aber bitte zum geniessen nicht in fach-chinesisch...

hallo,

ja, genau das, danke!

und mit der "anzeige aktualisieren" hast du mich auch zur lösung eines anderes problems gebracht , denn:
mein eigentliches problem ist ja die kodierung...
da die kodierung des wbb2 von der kodierung der *.lang datei abhängig ist, habe ich mir eine in utf-8 kodierte *.lang datei erstellt. nach umschalten der forumssprache auf polnisch utf, waren die inhalte der sprachdatei ( forumsfunktionen) alle korrekt dargestellt, die inhalte der threads und titel nicht, ein totaler salat...
dank mysqldumper und diesen artikel Die Umlautproblematik habe ich meine datenbank wieder "gerade gerückt" aber die inhalte des forums waren immer noch kauderwelsch...
erst nach aktualisieren der anzeige des forums... endlich... funktioniert es

die datenbank hat jetzt den zeichensatz auf utf, das forum funktioniert auch unter utf aber nach dem import ins wbb3 ist es wieder käse. und diesmal hab ich an der anzeige aktualisation gedacht...
ich weiss nicht was noch passieren muss...

ich habe so ziemlich alle, die in frage kämen ausprobiert...

jau es ist zum mäuse melken...
aber ich denke, dass es an irgendeinem kleinen "einstellungsdetail" liegt, ich hoffe es zumindest...

kann mir bitte jemand erklären in wie fern, beim import der foruminhalte von wbb2 zu wbb3, sich die einstellung der kodierung der datenquelle, auf das importierte im wbb3 auswirkt? (ich gebe zu, ich habe nicht viel ahnung, aber ich gebe noch lange nicht auf und werde weiter "forschen")

(ich habe sämtliche "konstelationen" erfolglos ausprobiert, dabei möchte ich auch wissen, wie sich der script beim import der daten verhält, wenn:
im template headinclude "charset={$lang->items['LANG_GLOBAL_ENCODING']}" steht und mehrere sprachpakete mit verschiedenen kodierungen vorhanden sind. am rande bemerkt, ich habe auch schon (vor dem import) das charset im besagtem template auf utf-8 und auch auf iso-8859-2 festgesetzt gehabt... die daten importiert, einmal das utf-8 kodierte sprachpaket als standard definiert, das andere mal iso-8859-2 [kreuz und quer] kann es sein, dass hier die verschiedenen sprachpakete stören? womit hat die datenquelle kodierung zu tun? geht es hier um die kodierung der datenbank? dann musste es doch funktionieren!)

wenn euch irgend etwas dazu einfällt, so schreibt bitte, es muss ja nicht direkt die lösung sein, aber so, wie selftitled mich (siehe oben) durch zufall zur lösung der utf-8 anzeige im wbb2 gebracht hat, möglicherweise kommt eine "erläuchtung" durch irgendein gedankenanstoß...

ich weiß, dieses thema nervt langsam, aber verflixt und zugenäht, ich will und muss es lösen...
mfg
lili

selftitled danke für deine antwort!

aber... ... ich habe es geschafft! ich habe diese verdammten zeichen jetzt sauber drin!
ich will mal nicht so... sein und erzähle wie. denn es war hier noch jemand, der genau das selbe prob hat :
in dem oben erwähntem artikel "Die Umlautproblematik " steht folgendes:

Quoted

Was mache ich jetzt, wenn ich über die Anzeige im MySQLDumper
feststelle, dass sich die Standardzeichensätze von altem und neuen Server
unterscheiden?
Einen entscheidenen Vorteil hast Du nun bereits: Du weißt,
welche Kodierung vom neuen MySQL-Server erwartet wird!
Also brauchst Du
letztlich nichts weiter zu tun, als ihm genau diese Kodierung zu liefern.

Dazu benötigst Du einen TextEditor, der in der Lage ist eine Text-Datei in
verschiedenen Formaten zu speichern (Achtung, aber ohne BOM - siehe oben!).

Mein Lieblingseditor zu diesem Zweck ist TextPad: http://www.textpad.com/download/index.html

das hat bei mir jetzt nicht direkt geholfen... aber... ich übersetze das email programm wikmail ins polnische und mir fiel wieder ein, dass ich anfangs ansi kodierte dateien schicken musste und damit es mit den zeichen klappte setzte ich damals extra ein polnisches system auf ( windows auf polnisch)
das tat ich jetzt auch, installierte den textpad (auch polnische version) öffnete meine DB - die vom wbb3 (beim öffnen aber den zeichensatz auf utf-8 gewählt-wichtig! - denn meine DB war inzwischen utf-8 kodiert...) gespeichert mit zeichensatz utf-8, gepackt und mit MSD (mysqldumper) wieder eingespielt. das war es...
welche rolle hier die sprache des systems spielt, kann ich nicht erklären, ich weiß es einfach nicht, ich stelle aber zum zweiten mal fest: damit kommt man weiter...

eine frage habe ich noch:
wird es ein polnisches sprachpaket nun geben?
wenn nicht, kann ich im rc7 anfangen zu übersetzen ohne , dass es in der final probleme geben könnte?