nachdem neue Daten eingegeben wurden, muss ein Dolmetscher sie wieder in alle Sprachen übersetzen.
Ok das mit dem join bei X feldern wird anstrengend seh ich ein 
.
Bleiben wir also bei Funktionen .
Ich hab noch bissel rumgespielt , villeicht hilft dir ja noch der syntax .
DELIMITER //
CREATE FUNCTION thedatenbank.translate(basisword varchar(255) , userid varchar(255)) RETURNS varchar(255)
READS SQL DATA
BEGIN
set @userlang = '';
SELECT lang into @userlang FROM auser WHERE name = userid;
set @fieldresult = '';
SELECT wort into @fieldresult FROM alllang WHERE idx = basisword and lang=@userlang ;
RETURN @fieldresult ;
END//
DELIMITER ;
Dann brauch man nur word und userid mitgeben . geht natürlich auch nur mit ‚en‘ oder ‚de‘
DELIMITER //
CREATE FUNCTION thedatenbank.translate(basisword varchar(255) , userlang varchar(255)) RETURNS varchar(255)
READS SQL DATA
BEGIN
set @fieldresult = '';
SELECT wort into @fieldresult FROM alllang WHERE idx = basisword and lang=userlang ;
RETURN @fieldresult ;
END//
DELIMITER ;
Auf jedenfall muss aber ein Index auf die alllang , dann gehts super fix.
ah ich vergessen :
Beispiel :
select translate(emotion,‚Thomas‘) , translate(status,‚Thomas‘) FROM fellings where status NOT LIKE „%dis%“
oder
select translate(emotion,‚de‘) , translate(status,‚de‘) FROM fellings where status NOT LIKE „%dis%“
bzw
set @lg = ‚de‘;
select translate(emotion,@lg) , translate(status,@lg) FROM fellings where status NOT LIKE „%dis%“
…
nur fals noch wer mit liesst …
ungetestet …
kann sein das du UTF-8 noch ergänzen musst bei der rückgabe etc.
steht aber im mysql online handbuch .
wäre dann
RETURNS varchar(255) CHARACTER SET utf8
Und jetzt kann ich Dir sagen was ich meinte.
Ich hole den Wert den ich als Filter habe einfach in den
VALUE Bereich und damit hab ich in der Abfrage die Einfacheit.
denn meine tabelle und die felder kenn ich das ist meine datenstruktur für X Languages ohne das ich was verändern muss , ich füg einfach nur neue zeilen hinzu. Wenn das viel wird (also der basis index auch in bibel stärke , ok dann müsste ich mir auch eine neue logik zusammenbasteln. Aber durch den index auf die tabelle wird das eigentlich schon wieder in überschaubare happen geteilt.
Aber da kann ich erst was zu sagen wenn ich das getestet hätte . -)
P.S. Deswegen auch meine Verwirrung warum soll der Suchwert mit in den Tabellen Namen oder Feldnamen . Damit setzt du eine Feste Struktur wo ich aber eine Dynamische brauch (festlegen des Fitlers(Sprache)) und da wo ich eine Feste brauch machst du es Dynmaisch (Festlegen der Tabelle oder Felder) .
Da transportiere ich den Dynamischen Filter (Sprache) dahin wo ich ihn gut Verarbeiten kann. Und am besten geht das als VALUE
Frag mich nicht wie ich das mache . Es gibt da bestimmt eine Normmalsierung für und die mach ich automatisch zum Anwendungsfall.
Und MySQL mit seinem geringen Funktionsumpfang tut das seinige dazu.
Brauch ich eine Gesammtübersicht dann Frimel ich mir ein View Zusammen Bestimmt kann man da als VALUE die Sprache auch gut durch ein loop schicken um so die tabelle zu füllen
Mal sehen . Sach mir auf jedenfall was du schliesendlich angewendet hast. Ein grund musst du mir nicht nennen , nur das Resultat
Thomas Punkt.
Hi Marvin,
Vielleicht
wäre ein Beispiel „in klein“ hilfreich.
Ein Beispiel in ‚sehr‘ klein:
Artikeltabelle:
Index, Artikelbezeichnung, Lagerortindex, Stückzahl, Einzelpreis
Lagerorttabelle:
Index, Lagerortbezeichnung, Kommentar
Ist das nicht normalisiert? Wie sonst würdest du die Tabellen aufbauen?
Die Bezeichnungen und der Kommentar sollen nun in x verschiedenen Sprachen vorliegen.
Gruß Fralang
Hi Thomas,
SELECT wort into @fieldresult FROM alllang WHERE idx =
basisword and lang=@userlang ;
Das Problem dabei ist leider: welchen Zeichensatz gebe ich der Column ‚wort‘? Eine Spalte kann immer nur einen Zeichensatz und einen Sortierzeichensatz (Collation) haben.
Wenn das nicht so wäre, dann wär’s leicht. Man bräuchte nur die sprachabhängigen Felder in eine eigene Tabelle mit Sätzen pro Sprache auslagern und über den Index des Hauptsatzes sie mit diesem verbinden.
Gruß Fralang
Mal sehen . Sach mir auf jedenfall was du schliesendlich
angewendet hast.
An die Realisierung geht’s erst im Dezember, aber ich denke, ich werde das einfachste System mit allen Sprachfeldern innerhalb der jeweiligen Tabellen anpeilen. Wie am 18.11. 21 Uhr gepostet.
Ein grund musst du mir nicht nennen , nur
das Resultat
Von der Laufzeit her sicherlich das mit Abstand am effizientesten. Weiters sehe ich außer der Lösung mit den vielen Joins keine Möglichkeit der Realisierbarkeit. Es geht gar nicht anders.
Ich melde mich dann mal mit einem klenen Erfahrungsbericht. Wer weiß, was alles noch Probleme machen wird.
Gruß Fralang
PS: es gäbe schon noch eine Möglichkeit das zu realisieren, nämlich die Übersetzungsarbeit auf die Frontend-Anwendung, auf den PC des Users, zu verlagern. Man liest die Tabelle mit Basiswort-Indizes und die gewünschte Sprachtabelle und löst das dann in welch immer Programmiersprache man verwendet. So machen das wahrscheinlich die meisten anderen für ähnliche Aufgabenstellungen.
Es ist aber alles andere als effizient. Für eine Tabelle mit 20.000 Zeilen und 10 sprachabhängigen Wörtern muss ich dann in einer Schleife über 200.000 Übersetzungen durchführen. Auf dem schwachen Anwender-PC. Der Server in SQL sollte das besser können.
Moin ,
Es ist aber alles andere als effizient. Für eine Tabelle mit
20.000 Zeilen und 10 sprachabhängigen Wörtern muss ich dann in
einer Schleife über 200.000 Übersetzungen durchführen. Auf dem
das ist falsch gedacht.
wenn ich z.b. php nehme brauch ich nur die basis als assoziatives array key nehmen. das geht eins zu eins schnell , da ist nix mit übersetzung suchen . wenn ich die jeweils sogar in 2 assoziative arrays schaufel kann ich geschickt hin und her translieren ohne zeitverlust. Ich übersetz ja nur das was ich ausgebe
Moin moin,
Das Problem dabei ist leider: welchen Zeichensatz gebe ich der
Column ‚wort‘? Eine Spalte kann immer nur einen Zeichensatz
und einen Sortierzeichensatz (Collation) haben.
Keine Ahnung ich nehme UTF-8 für alles und noch hat sich keiner auf der Welt beschwert. Und der rest bleibt bei mir immer latin .
Ich mach aber auch weniger in der Datenbank sondern eher mit der Programmiersprache weiter Verarbeitung.
Auf jeden fall viel Erfolg.
uebrugens ist es dem wert egal . utf-8 ist utf-8 codiert somit ist also der select into variable genau der 1:1 wert. erst die rückgabe würde bestimmen welche codierung das ist. Aber deswegen nehm ich überall UTF-8 für Multilanguage , klar ist es ein Problem wenn man das nicht kann . Wenn man aber strict mit UTF_8 arbeitet sollte da kein Problem auftreten.
Ich hoffe du findest eine gute Lösung.
Hallo FraLang,
Artikeltabelle:
Index, Artikelbezeichnung, Lagerortindex, Stückzahl,
Einzelpreis
Ist das nicht normalisiert?
Ist schon in Ordnung. Aber für deine Übersetzungen stelle ich mir eine Extra-Tabelle vor, mit dem Artikelindex als Fremdschlüssel, also etwa so:
CREATE TABLE Translationtab
(
Artikelindex: INT UNSIGNED NOT NULL,
lfd\_Nr: INT UNSIGNED NOT NULL,
Sprachcode: char(2),
Bezeichnung\_transl: char(200),
FOREIGN KEY (Artikelindex)
REFERENCES Artikeltabelle (index)
);
vielleicht noch einen Index:
CREATE UNIQUE INDEX Translation\_Key
ON Translationtab (Artikelindex, lfd\_Nr);
Aber genau genommen würde ich diese Übersetzerei nicht der Datenbank überlassen, sondern „auslagern“, weil der Kunde ja sowieso noch was „drumrum“ in seiner Sprache braucht, oder?
Das ist dann natürlich Betriebssystem-abhängig, für Linux wäre da gettext das Instrument der Wahl
http://de.wikipedia.org/wiki/GNU_gettext
In Microsoft-Umgebungen gibt es dazu z.B. die .resx bzw. .restext-Dateien
http://st-lange.net/post/Silverlight-Tipp-der-Woche-…
das Prinzip ist ähnlich wie bei gettext, aber viel mehr kann ich zu Windows nicht sagen.
Auf jeden Fall hat beides den Vorteil, daß die DB kleiner gehalten wird und dem Übersetzer kann eine verständliche, lesbare und editierbare Datei in die Handgegeben werden, ohne daß er sich irgendwie mit SQL auskennen oder rumärgern muß.
Viele Grüße
Marvin
Hallo Marvin,
danke für die Links, interessant zu wissen, wie der gettext das macht. Er benutzt eine große Portable Object Datei, in der alle zu übersetzenden Begriffe enthalten sind. Das ist für meine Anwendung aber zuviel des Guten. In meinen Tabellen sind vorwiegend technische Fachbegriffe einthalten, sie sollten nicht generell, sondern nur Feld für Feld übersetzt werden. Beispiel: ein Motor hat mehrere Zylinder. In der Mathematik? Die Pumpe des Kühlschranks wird auf spanisch als Motor bezeichnet. Ein allgemeines Wörterbuch passt hier nicht.
Das .resx für Microsoft geht ähnlich vor, kann aber nur mit utf-8 arbeiten. Das eben reicht nicht.
Wie du vorschlägst, eine Tabelle als Wörterbuch zu benutzen:
Bezeichnung_transl: char(200),
In einem Wörterbuch mit Sprachcodes hat man das Problem mit den Zeichensätzen. Bezeichnung_transl kann ja nur einen Zeichencode haben. Man kann die verschiedenen Sprachen nur in verschiedenen Spalten platzieren.
Das Auslagern der Uebersetzungsarbeit auf den Anwender-PC ist das, was ich vermeiden wollte. Der langsame, alte PC soll die Arbeit machen. Die Tabellen können ev. sehr groß werden. Schön, wenn der Server gleich die richtigen Texte liefern kann.
Gruß Fralang
Hi,
Ich übersetz ja nur das was
ich ausgebe
ja, wenn das möglich ist, ist es eine Lösung. Das Ereignis „Zeile anzeigen“ abfangen und dort die Uebersetzung machen. Ich verwende den Treeview von Microsoft Visual Basic, der kann das nicht. Man muss ihm alle Titel der Knoten vorgeben, wenn sie angezeigt werden, wird kein Ereignis mehr ausgelöst.
G.Fr.
Keine Ahnung ich nehme UTF-8 für alles und noch hat sich keiner auf der Welt beschwert
Hast du griechisch oder türkisch probiert? Hebräisch oder Japanisch?
Ich habe mich auch noch nicht so intesniv damit befasst. Aber MySQL bietet Unterstützung für 30 Zeichensätze und 70 Sortierfolgen. Warum? Man kann sie pro Column festlegen. Das muss zu irgendetwas gut sein.
G.Fr.
Hallo FraLang,
Er benutzt eine große Portable Object Datei, in der
alle zu übersetzenden Begriffe enthalten sind. Das ist für
meine Anwendung aber zuviel des Guten. In meinen Tabellen sind
vorwiegend technische Fachbegriffe einthalten, sie sollten
nicht generell, sondern nur Feld für Feld übersetzt werden.
Das hast Du aber falsch verstanden. Das ist keine generelle Datei (wie ein Wörterbuch), sondern die Datei wird von den Übersetzern selbst erstellt und nach Bedarf gefüllt…
Beispiel: ein Motor hat mehrere Zylinder. In der Mathematik?
… und insofern trägt der Übersetzer in die Datei eben nur das genaue spanische Wort für einen Motorenzylinder ein und nicht etwa den mathematischen Zylinder.
Die Pumpe des Kühlschranks wird auf spanisch als Motor
bezeichnet. Ein allgemeines Wörterbuch passt hier nicht.
Wie gesagt, die po-Datei ist kein vorgefertigtes allgemeines Wörterbuch, sondern wird vom Übersetzer hergestellt.
In einem Wörterbuch mit Sprachcodes hat man das Problem mit
den Zeichensätzen. Bezeichnung_transl kann ja nur einen
Zeichencode haben. Man kann die verschiedenen Sprachen nur in
verschiedenen Spalten platzieren.
Nein, das ist genau der Denkfehler. Du kannst ja ohne Probleme z.B. utf-32 benutzen. Da hast Du einen Zeichensatz, mit dem Du deinen Motorzylinder sogar in ägyptischen Hieroglyphen reinschreiben könntest…
Das Auslagern der Uebersetzungsarbeit auf den Anwender-PC ist
das, was ich vermeiden wollte. Der langsame, alte PC soll die
Arbeit machen. Die Tabellen können ev. sehr groß werden.
Schön, wenn der Server gleich die richtigen Texte liefern
kann.
Das macht er doch auch. MySQL, gettext (oder was immer Du nimmst), liegt ja auf dem Server. Ausgeliefert wird ja wohl nur eine HTML-Seite mit UTF-Zeichen. Die Größe der Tabellen ist ebenfalls für den Anwender uninteressant, weil es ja eh unergonomisch wäre, ihm eine Liste mit 10000 Zeilen anzubieten. Wenn die Treffermenge über, sagen wir mal, 500 ansteigt, sollte eine Blätterfunktion angeboten werden, die immer nur so maximal 100 Treffer anbietet.
Viele Grüße
Marvin
hi,
Ich übersetz ja nur das was
ich ausgebe
irgendwo habe ich das schon erwähnt, ich benutze unter anderem den TreeView von Visual Basic, hier muss ich die Titel aller Knoten bereits beim Aufbau des Trees kennen. Beim Scrollen im Tree werden keine Ereignisse mehr erzeugt.
Problem Sortierfolge
Hi Marvin,
Das ist keine generelle
Datei (wie ein Wörterbuch), sondern die Datei wird von den
Übersetzern selbst erstellt und nach Bedarf gefüllt…
Hab ich schon so verstanden, generell in dem Sinne dass ich sie dann für eine Tabelle oder Tabellen generell benutzte. Innerhalb einer Tabelle kann es zu Uneindeutigkeiten kommen. Ich würde vorziehen, je ein Wort pro Feld einer Zeile in jeder anderen Sprache zu haben. So etwa: myTab1_chinesisch enthält alle sprachabhängigen Felder auf chinesisch, gejoint über den Index des Hauptdatensatzes von myTab1.
Man kann die verschiedenen Sprachen nur in
verschiedenen Spalten platzieren.Nein, das ist genau der Denkfehler. Du kannst ja ohne Probleme
z.B. utf-32 benutzen. Da hast Du einen Zeichensatz, mit dem Du
deinen Motorzylinder sogar in ägyptischen Hieroglyphen
reinschreiben könntest…
Welche Sortierfolge ( Collation ) gibst du dann an? Werden dann alle Texte mit 4 Bytes dargestellt? Bläht das nicht die Datenbank um fast einen Faktor 4 auf?
Das wäre wirklich wichtig : Ich habe mich mit den verschiedenen Zeichensätzen noch nicht sehr intensiv befasst. Wozu werden 30 verschiedene Zeichensätze unterstützt? Wenn mit utf-32 alles erschlagen werden könnte?
Das Auslagern der Uebersetzungsarbeit auf den Anwender-PC ist
das, was ich vermeiden wollte. Der langsame, alte PC soll die
Arbeit machen. Die Tabellen können ev. sehr groß werden.
Schön, wenn der Server gleich die richtigen Texte liefern
kann.Das macht er doch auch. MySQL, gettext (oder was immer Du
nimmst), liegt ja auf dem Server. Ausgeliefert wird ja wohl
nur eine HTML-Seite mit UTF-Zeichen.
Das Konzept in diesem Projekt ist aber ein anderes. Es werden nur die Daten aus Views auf Tabellen vom Server zum Anwender-PC übertragen, dort werden die Formulare aufgebaut, Verarbeitungen, Eingaben, und satzweise Rückübertragungen zum Server durchgeführt. Velleicht hätte man das Konzept bereits anders gestalten sollen.
Gruß Fralang