Mehrere Sprachen

[Thomas]

Hallo,

meine kleine Webseite soll mehrsprachig werden. Bis jetzt habe ich für den Inhalt (Impressum, Über uns, Datenschutz, usw.) eine Tabelle mit folgenden Spalten:

1. id
2. titel
3. titel-url
4. inhalt
5. status

meine Idee war, einfach weitere Felder hinzuzufügen für die weiteren Sprachen also z.B.

1. en_titel
2. en_titel-url
3. en_inhalt
4. en_status

auf der anderen Seite bin ich so nicht wirklich flexible, sollten irgendwann weiter Sprachen hinzukommen. Wie geht ihr in so einem Fall vor?

[Gunnar Bittersmann]

@@Thomas

Wie geht ihr in so einem Fall vor?

Ich packe Inhalte von statischen Seiten nicht in eine Datenbank.

LLAP 🖖

[Thomas]

Hallo,

Ich packe Inhalte von statischen Seiten nicht in eine Datenbank.

hast du später also für z.B. 10 Sprachen, 10 verschieden HTML / PHP Dateien auf dem Server? Dazu sag ich nur "viel Spaß beim pflegen / layouten". Ich passe mein Design z.B. mehrmals im Jahr an (immer zu besonderen Tagen wie z.B. Muttertag, Vatertag, Ostern, Sommer, Herbst, Winter, Weihnachten, Fasching, usw.).

[Der Martin]

Hi,

Ich packe Inhalte von statischen Seiten nicht in eine Datenbank.

hast du später also für z.B. 10 Sprachen, 10 verschieden HTML / PHP Dateien auf dem Server?

bestimmt nicht.

Dazu sag ich nur "viel Spaß beim pflegen / layouten". Ich passe mein Design z.B. mehrmals im Jahr an (immer zu besonderen Tagen wie z.B. Muttertag, Vatertag, Ostern, Sommer, Herbst, Winter, Weihnachten, Fasching, usw.).

Ich selbst praktiziere eine Zwischenlösung: Ich habe ein großes Array mit Strings, das in einer Datei per include eingebunden wird - jeweils für die gewünschte Sprache. So kann ich die Texte bequem in einer Datei pro Sprache überblicken, während die gesamte HTML-Seitenstruktur sprachneutral in einer übergeordneten PHP-Datei steckt.
So kann ich Struktur, Design und layout jederzeit global für alle Sprachen ändern, und um eine neue Sprache hinzuzufügen, muss ich nur eine der include-Dateien kopieren und die Strings anpassen, d.h. übersetzen (lassen).

So long,
 Martin

[Linuchs]

... ein großes Array mit Strings, das in einer Datei per include eingebunden wird - jeweils für die gewünschte Sprache. So kann ich die Texte bequem in einer Datei pro Sprache überblicken, ...

Gilt die include-Datei einer Sprache für ein Projekt oder für eine Seite?

In beiden Fällen sehe ich den Nachteil x Sprach-Dateien zu pflegen, wenn Texte hinzukommen. Was spricht gegen eine einzige Datei, die pro Text-Schnippsel die Sprachkennung enthält?

So mache ich das z.B. mit Wochentagen:

  $wochentage = array (
   "cz"  =>  array("Neděle", "Pondělí", "Úterý", "Středa", "Čtvrtek", "Pátek", "Sobota" )
  ,"da"  =>  array("Søndag", "Mandag", "Tirsdag", "Onsdag", "Torsdag", "Fredag", "Lørdag" )
  ,"de"  =>  array("Sonntag", "Montag", "Dienstag", "Mittwoch", "Donnerstag", "Freitag", "Samstag" )
  ,"en"  =>  array("Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday", "Saturday" )
  ,"es"  =>  array("Domingo", "Lunes", "Martes",  "Miércoles", "Jueves", "Viernes", "Sábado" )
  ,"fr"  =>  array("Dimanche", "Lundi", "Mardi", "Mercredi", "Jeudi", "Vendredi", "Samedi" )
  ,"it"  =>  array("Domenica", "Lunedi", "Martedì", "Mercoledì", "Giovedi", "Venerdì", "Sabato" )
  ,"nds" =>  array("Sönndach", "Moandach", "Diengsdach", "Middewääk", "Dönnerdach", "Freedach", "Soaterdach" )
  ,"nl"  =>  array("Zondag", "Maandag", "Dinsdag", "Woensdag", "Donderdag", "Vrijdag", "Zaterdag" )
  ,"no"  =>  array("Søndag", "Mandag", "Torsdag", "Onsdag", "Torsdag", "Fredag", "Lørdag" )
  ,"pl"  =>  array("Niedziela", "Poniedzialek", "Wtorek", "Sroda", "Czwartek", "Piatek", "Sobota" )
  ,"ru"  =>  array("Воскресенье", "Понедельник", "Вторник", "Среда", "Четверг", "Пятница", "Суббота")
  );

Linuchs

[Gunnar Bittersmann]

@@Linuchs

  ,"pl"  =>  array("Niedziela", "Poniedzialek", "Wtorek", "Sroda", "Czwartek", "Piatek", "Sobota" )

Da kann ich gleich mal korrigieren:

  ,"pl"  =>  array("Niedziela", "Poniedziałek", "Wtorek", "Środa", "Czwartek", "Piątek", "Sobota" )

Warum schreibst du die Wochentage mit großem Anfangsbuchstaben?

LLAP 🖖

[Linuchs]

Hallo Gunnar,

Da kann ich gleich mal korrigieren:

  ,"pl"  =>  array("Niedziela", "Poniedziałek", "Wtorek", "Środa", "Czwartek", "Piątek", "Sobota" )

Danke dir. Stammte wohl noch aus der Zeit, als mein damaliger Windoof-Editor kein UTF-8 konnte. Kyrillisch ist erst später dazugekommen.

Warum schreibst du die Wochentage mit großem Anfangsbuchstaben?

Von den meisten Sprachen habe ich keine Ahnung und habe einfach die Regel der mir bekannten Sprachen auch aufs Polnische angewendet. Schreibt man die klein? Ist der Kalender falsch?

Linuchs

[Gunnar Bittersmann]

@@Linuchs

Warum schreibst du die Wochentage mit großem Anfangsbuchstaben?

Schreibt man die klein?

Ja. Am Satzanfang groß. Wenn einfach so alleinstehend, kann man sie vielleicht auch großschreiben.

LLAP 🖖

[Der Martin]

Hallo,

... ein großes Array mit Strings, das in einer Datei per include eingebunden wird - jeweils für die gewünschte Sprache. So kann ich die Texte bequem in einer Datei pro Sprache überblicken, ...

Gilt die include-Datei einer Sprache für ein Projekt oder für eine Seite?

je nachdem. Ich habe beide Ansätze schon verwendet.

In beiden Fällen sehe ich den Nachteil x Sprach-Dateien zu pflegen, wenn Texte hinzukommen.

Stimmt ...

Was spricht gegen eine einzige Datei, die pro Text-Schnippsel die Sprachkennung enthält?

Auch ein guter Ansatz. Irgendwann ist dann halt mal der Punkt erreicht, wo es langsam unübersichtlich wird.

So mache ich das z.B. mit Wochentagen:

Hm. Heißt der Dienstag und der Donnerstag im Norwegischen gleich? Oder ist das ein Fehler bei dir?

  ,"no"  =>  array("Søndag", "Mandag", "Torsdag", "Onsdag", "Torsdag", "Fredag", "Lørdag" )

Eigenartige Notation übrigens, das Komma am Zeilenanfang.

So long,
 Martin

[j4nk3y]

Hey,

Hm. Heißt der Dienstag und der Donnerstag im Norwegischen gleich? Oder ist das ein Fehler bei dir?

  ,"no"  =>  array("Søndag", "Mandag", "Torsdag", "Onsdag", "Torsdag", "Fredag", "Lørdag" )

Im Schwedischen ist Dienstag : Tisdag, dürfte im Norwegischen nicht (viel) anders sein.

Gruß Jo

[Linuchs]

Hm. Heißt der Dienstag und der Donnerstag im Norwegischen gleich? Oder ist das ein Fehler bei dir?

Nee, der Dienstag heißt Tirsdag, habe ich korrigiert. Danke fürs Mitlesen.

Eigenartige Notation übrigens, das Komma am Zeilenanfang.

Immer wieder habe ich Fehler bei Aufzählungen (auch bei SQL-SELECT), weil es ein Komma weniger sein muss als Zahl der Argumente. Also ob Komma hinten oder vorne, vor dem ersten Argument darf keines stehen. Es prüft sich leichter, wenn die Kommata am Zeilenanfang untereinander stehen.

Linuchs

[Gwunderi]

,"it" => array("Domenica", "Lunedi", "Martedì", "Mercoledì", "Giovedi", "Venerdì", "Sabato" )

Bin ganz zufällig auf dieses Forum und diesen Beitrag gestossen, und da ich so gerne korrigiere:

Lunedì bis venerdì wird durchgehend mit einem ì am Ende geschrieben (nicht i).

Wünsche ein gutes Gelingen,

Gwunderi

[Linuchs]

,"it" => array("Domenica", "Lunedi", "Martedì", "Mercoledì", "Giovedi", "Venerdì", "Sabato" )

Lunedì bis venerdì wird durchgehend mit einem ì am Ende geschrieben (nicht i).

Danke auch dir fürs Mitlesen. Wenn ich "sonntag, montag, Dienstag, mittwoch, donnerstag, freitag, samstag" bei Google Translate ins Italienische übersetze, kommt "Domenica, Lunedi, Martedì, Mercoledì, Giovedi, Venerdì, Sabato"

Bedeutet der Akzent, dass die Silbe betont wird statt - wie im Spanischen - die vorletzte?

Linuchs

[Gunnar Bittersmann]

@@Thomas

Ich passe mein Design z.B. mehrmals im Jahr an

Warum sollte sich dabei das Markup ändern?

LLAP 🖖

[j4nk3y]

Morgen,

meine kleine Webseite soll mehrsprachig werden. Bis jetzt habe ich für den Inhalt (Impressum, Über uns, Datenschutz, usw.) eine Tabelle mit folgenden Spalten:

1. id
2. titel
3. titel-url
4. inhalt
5. status

meine Idee war, einfach weitere Felder hinzuzufügen für die weiteren Sprachen also z.B.

1. en_titel
2. en_titel-url
3. en_inhalt
4. en_status

auf der anderen Seite bin ich so nicht wirklich flexible, sollten irgendwann weiter Sprachen hinzukommen. Wie geht ihr in so einem Fall vor?

Ich würde den Text für jede Sprache in eine eigene Tabelle legen. Und dann für die jeweilige Sprache eine Abfrage an die dazugehörige Tabelle (z.b text_de oder text_eng mit einer text_id und text) richten und dann alles in ein Assoc packen und den Text über das Array, an der Stelle ausgeben wo du ihn haben möchtest.

Gruß Jo

[Der Martin]

Hallo,

meine kleine Webseite soll mehrsprachig werden. Bis jetzt habe ich für den Inhalt (Impressum, Über uns, Datenschutz, usw.) eine Tabelle mit folgenden Spalten:

1. id
2. titel
3. titel-url
4. inhalt
5. status

meine Idee war, einfach weitere Felder hinzuzufügen für die weiteren Sprachen also z.B.

1. en_titel
2. en_titel-url
3. en_inhalt
4. en_status

auf der anderen Seite bin ich so nicht wirklich flexible, sollten irgendwann weiter Sprachen hinzukommen. Wie geht ihr in so einem Fall vor?

Ich würde den Text für jede Sprache in eine eigene Tabelle legen.

das würde ich nicht tun. Dann hat man mehrere Tabellen mit derselben Struktur und von der Bedeutung her demselben Inhalt.
Stattdessen würde ich bei einer Tabelle bleiben und lediglich eine Spalte für die Sprache (de, en, fr, ru, ...) hinzufügen.

Allerdings gilt auch der Einwand von Gunnar. Inhalte für statische, unveränderliche Seiten in eine Datenbank? Ist irgendwie mit Elefanten auf Mücken geschossen ...

So long,
 Martin

[Tabellenkalk]

Hallo,

Ist irgendwie mit Elefanten auf Mücken geschossen ...

Aber wenn doch die Mücken aus Porzellan sind?...

Gruß
Kalk

[Der Martin]

Hi,

Ist irgendwie mit Elefanten auf Mücken geschossen ...

Aber wenn doch die Mücken aus Porzellan sind?...

dann müssen die Spatzen die Scherben zusammenkehren, wenn sie die Elefantenkanone abgefeuert haben.

Ciao,
 Martin

[j4nk3y]

Hallo,

Stattdessen würde ich bei einer Tabelle bleiben und lediglich eine Spalte für die Sprache (de, en, fr, ru, ...) hinzufügen.

Allerdings gilt auch der Einwand von Gunnar. Inhalte für statische, unveränderliche Seiten in eine Datenbank? Ist irgendwie mit Elefanten auf Mücken geschossen ...

Stimmt, das ist sogar noch besser. Naja aber so könnte man im nachhinein einfach eine weitere Sprache hinzufügen ohne alle Seiten kopieren und statisch den ganzen Text übersetzen zu müssen, oder nicht?

Gruß Jo

[Der Martin]

Hi,

Naja aber so könnte man im nachhinein einfach eine weitere Sprache hinzufügen ohne alle Seiten kopieren und statisch den ganzen Text übersetzen zu müssen, oder nicht?

kopieren und übersetzen musst du so oder so, egal ob die Inhalte in einer DB oder in einzelnen Quelldateien stehen.
Oder habe ich etwas falsch verstanden?

So long,
 Martin

[j4nk3y]

Hi,

Naja aber so könnte man im nachhinein einfach eine weitere Sprache hinzufügen ohne alle Seiten kopieren und statisch den ganzen Text übersetzen zu müssen, oder nicht?

kopieren und übersetzen musst du so oder so, egal ob die Inhalte in einer DB oder in einzelnen Quelldateien stehen.
Oder habe ich etwas falsch verstanden?

Naja wenn der gesamte Text in einer Datenbank steht, hat man eine Seite die mit beliebig vielen Sprachen ausgegeben wird. Je nachdem welche Sprache der User gerade angibt (Oder für den User in der Datenbank hinterlegt ist). Klar muss man den text übersetzen. Aber es bleibt nur eine Datei.php und nicht eine Datei-de.php und eine Datei_eng.php ...

Gruß Jo

[Der Martin]

Hallo,

kopieren und übersetzen musst du so oder so, egal ob die Inhalte in einer DB oder in einzelnen Quelldateien stehen.
Oder habe ich etwas falsch verstanden?

Naja wenn der gesamte Text in einer Datenbank steht, hat man eine Seite die mit beliebig vielen Sprachen ausgegeben wird. Je nachdem welche Sprache der User gerade angibt (Oder für den User in der Datenbank hinterlegt ist). Klar muss man den text übersetzen. Aber es bleibt nur eine Datei.php und nicht eine Datei-de.php und eine Datei_eng.php ...

aha, also bist du derjenige, der etwas übersehen hat. ;-)

Der Ansatz von Thomas sieht doch vor, die Inhalte in eine DB zu packen - also hat seine PHP-Datei keine Textinhalte, die übersetzt werden müssten. Die stecken alle in der DB. Was ist also einfacher: Eine PHP- oder HTML-Datei kopieren und dann sequentiell durchgehen und alle Textstellen übersetzen, oder einen Datensatz in der DB kopieren und alle Felder übersetzen?

Letztendlich bleibt der Aufwand in etwa derselbe, aber ich editiere lieber Dateien im Editor als Felder der DB. Das ist aber Geschmackssache.

So long,
 Martin

[j4nk3y]

Hallo,

kopieren und übersetzen musst du so oder so, egal ob die Inhalte in einer DB oder in einzelnen Quelldateien stehen.
Oder habe ich etwas falsch verstanden?

Naja wenn der gesamte Text in einer Datenbank steht, hat man eine Seite die mit beliebig vielen Sprachen ausgegeben wird. Je nachdem welche Sprache der User gerade angibt (Oder für den User in der Datenbank hinterlegt ist). Klar muss man den text übersetzen. Aber es bleibt nur eine Datei.php und nicht eine Datei-de.php und eine Datei_eng.php ...

aha, also bist du derjenige, der etwas übersehen hat. ;-)

Der Ansatz von Thomas sieht doch vor, die Inhalte in eine DB zu packen - also hat seine PHP-Datei keine Textinhalte, die übersetzt werden müssten. Die stecken alle in der DB. Was ist also einfacher: Eine PHP- oder HTML-Datei kopieren und dann sequentiell durchgehen und alle Textstellen übersetzen, oder einen Datensatz in der DB kopieren und alle Felder übersetzen?

Letztendlich bleibt der Aufwand in etwa derselbe, aber ich editiere lieber Dateien im Editor als Felder der DB. Das ist aber Geschmackssache.

Da gebe ich dir vollkommen Recht, der Aufwand alles zu übersetzen bleibt der gleiche. Jedoch, wie schon erwähnt, das nachträgliche pflegen einer Seite im Gegensatz zu mehreren sollte doch geringer und weniger Fehler anfällig sein.

Gruß Jo

[Der Martin]

Hi,

Letztendlich bleibt der Aufwand in etwa derselbe, aber ich editiere lieber Dateien im Editor als Felder der DB. Das ist aber Geschmackssache.

Da gebe ich dir vollkommen Recht, der Aufwand alles zu übersetzen bleibt der gleiche. Jedoch, wie schon erwähnt, das nachträgliche pflegen einer Seite im Gegensatz zu mehreren sollte doch geringer und weniger Fehler anfällig sein.

kann es sein, dass du immer noch etwas anderes siehst als ich? So wie ich das Konzept von Thomas verstehe, hat er in seiner DB nur reinen Text, kein Markup (hoffe ich jedenfalls für ihn). Das nachträgliche Pflegen beschränkt sich also auf eine gemeinsame, sprachneutrale PHP-Datei.

Ciao,
 Martin

[j4nk3y]

Hi,

Letztendlich bleibt der Aufwand in etwa derselbe, aber ich editiere lieber Dateien im Editor als Felder der DB. Das ist aber Geschmackssache.

Da gebe ich dir vollkommen Recht, der Aufwand alles zu übersetzen bleibt der gleiche. Jedoch, wie schon erwähnt, das nachträgliche pflegen einer Seite im Gegensatz zu mehreren sollte doch geringer und weniger Fehler anfällig sein.

kann es sein, dass du immer noch etwas anderes siehst als ich? So wie ich das Konzept von Thomas verstehe, hat er in seiner DB nur reinen Text, kein Markup (hoffe ich jedenfalls für ihn). Das nachträgliche Pflegen beschränkt sich also auf eine gemeinsame, sprachneutrale PHP-Datei.

Nein genau davon rede ich auch. Genau wie du hier sagst:

Ich packe Inhalte von statischen Seiten nicht in eine Datenbank.

hast du später also für z.B. 10 Sprachen, 10 verschieden HTML / PHP Dateien auf dem Server?

bestimmt nicht.

Ich selbst praktiziere eine Zwischenlösung: Ich habe ein großes Array mit Strings, das in einer Datei per include eingebunden wird - jeweils für die gewünschte Sprache. So kann ich die Texte bequem in einer Datei pro Sprache überblicken, während die gesamte HTML-Seitenstruktur sprachneutral in einer übergeordneten PHP-Datei steckt.
So kann ich Struktur, Design und layout jederzeit global für alle Sprachen ändern, und um eine neue Sprache hinzuzufügen, muss ich nur eine der include-Dateien kopieren und die Strings anpassen, d.h. übersetzen (lassen).

Ob der Text jetzt in einer Tabelle in einer Db oder in einer Text Datei steht bleibt ja vom Prinzip das gleiche. Wobei die Text Datei leichter zu bearbeiten ist.

Gruß Jo

[Thomas]

Hallo,

kann es sein, dass du immer noch etwas anderes siehst als ich? So wie ich das Konzept von Thomas verstehe, hat er in seiner DB nur reinen Text, kein Markup (hoffe ich jedenfalls für ihn). Das nachträgliche Pflegen beschränkt sich also auf eine gemeinsame, sprachneutrale PHP-Datei.

nur reiner Text ist in der Datenbank :)

[Gunnar Bittersmann]

@@j4nk3y

Naja wenn der gesamte Text in einer Datenbank steht, hat man eine Seite die mit beliebig vielen Sprachen ausgegeben wird. Je nachdem welche Sprache der User gerade angibt (Oder für den User in der Datenbank hinterlegt ist). Klar muss man den text übersetzen. Aber es bleibt nur eine Datei.php und nicht eine Datei-de.php und eine Datei_eng.php ...

Dann muss man aber auch Sprachvereinbarung (language negotiation) mit PHP implementieren.

LLAP 🖖

[Thomas]

Hallo,

Stimmt, das ist sogar noch besser. Naja aber so könnte man im nachhinein einfach eine weitere Sprache hinzufügen ohne alle Seiten kopieren und statisch den ganzen Text übersetzen zu müssen, oder nicht?

finde ich nicht, wie bereits hier geschrieben. Einfacher ist, einfach eine bestehende HTML / PHP Datei zu kopieren, den Text zu tauschen und wieder hochzuladen. Wenn du allerdings mehrmals im Jahr das Design änderst sind mehrere Dateien eher nervend, da du nicht nur eine Ausgabedatei anpassen musst, deshalb liegt bei mir alles in der Datenbank.

[j4nk3y]

Hallo,

Stimmt, das ist sogar noch besser. Naja aber so könnte man im nachhinein einfach eine weitere Sprache hinzufügen ohne alle Seiten kopieren und statisch den ganzen Text übersetzen zu müssen, oder nicht?

finde ich nicht, wie bereits hier geschrieben. Einfacher ist, einfach eine bestehende HTML / PHP Datei zu kopieren, den Text zu tauschen und wieder hochzuladen. Wenn du allerdings mehrmals im Jahr das Design änderst sind mehrere Dateien eher nervend, da du nicht nur eine Ausgabedatei anpassen musst, deshalb liegt bei mir alles in der Datenbank.

Hä? also willst du jetzt deine Php Dateien kopieren und jede übersetzen oder dir den Text aus einer Tabelle ziehen?

Gruß Jo

[Thomas]

Hallo,

Hä? also willst du jetzt deine Php Dateien kopieren und jede übersetzen oder dir den Text aus einer Tabelle ziehen?

natürlich möchte ich nicht meine PHP Dateien kopieren, wie gesagt dieses ist viel zu umständlich wenn ich mehrmals im Jahr mein Design ändere. Es soll alles aus einer Datenbank kommen.

[j4nk3y]

Hallo,

Hä? also willst du jetzt deine Php Dateien kopieren und jede übersetzen oder dir den Text aus einer Tabelle ziehen?

natürlich möchte ich nicht meine PHP Dateien kopieren, wie gesagt dieses ist viel zu umständlich wenn ich mehrmals im Jahr mein Design ändere. Es soll alles aus einer Datenbank kommen.

Ja, so hatte ich es verstanden.

Stimmt, das ist sogar noch besser. Naja aber so könnte man im nachhinein einfach eine weitere Sprache hinzufügen ohne alle Seiten kopieren und statisch den ganzen Text übersetzen zu müssen, oder nicht?

Das bezog sich auf Martins Kommentar den ganzen text in eine Tabelle einzufügen mit einer Spalte für eine Sprache. So vermeidet man mehrere Tabellen.

Gruß Jo

[Thomas]

Hallo,

das würde ich nicht tun. Dann hat man mehrere Tabellen mit derselben Struktur und von der Bedeutung her demselben Inhalt.
Stattdessen würde ich bei einer Tabelle bleiben und lediglich eine Spalte für die Sprache (de, en, fr, ru, ...) hinzufügen.

also würdest du die Tabelle so aufbauen?

1. id
2. land
3. titel
4. titel-url
5. inhalt
6. status

in die spalte land kommt dann z.B. de-De oder en-En

[j4nk3y]

Hallo,

das würde ich nicht tun. Dann hat man mehrere Tabellen mit derselben Struktur und von der Bedeutung her demselben Inhalt.
Stattdessen würde ich bei einer Tabelle bleiben und lediglich eine Spalte für die Sprache (de, en, fr, ru, ...) hinzufügen.

also würdest du die Tabelle so aufbauen?

1. id
2. land
3. titel
4. titel-url
5. inhalt
6. status

in die spalte land kommt dann z.B. de-De oder en-En

Ja und in die Felder titel, titel url... kommt dann einfach nurnoch die text_id. Dann holst du nurnoch den Text in der sprache mit der text_id aus der DB.

aus der Tabelle:

Text_id text_de text_eng . . . So jedenfalls setze ich das um.

Gruß Jo

[Der Martin]

Hi,

das würde ich nicht tun. Dann hat man mehrere Tabellen mit derselben Struktur und von der Bedeutung her demselben Inhalt.
Stattdessen würde ich bei einer Tabelle bleiben und lediglich eine Spalte für die Sprache (de, en, fr, ru, ...) hinzufügen.

also würdest du die Tabelle so aufbauen?

1. id
2. land
3. titel
4. titel-url
5. inhalt
6. status

so ungefähr. Ich würde die zusätzliche Spalte aber nicht "land" nennen, sondern "sprache" oder "language". Sprachen sind selten eindeutig einem Land zuzuordnen - Paradebeispiele sind Schweiz und Belgien, wo mehrere Sprachen in einem Land gesprochen werden, oder umgekehrt Deutsch und Englisch als Sprachen, die in mehreren Ländern gesprochen werden.

in die spalte land kommt dann z.B. de-De oder en-En

Nein. Willst du so spezifisch sein, ausdrücklich österreichisches von deutschem "Deutsch" zu unterscheiden, oder amerikanisches von britischem Englisch? Glaube ich nicht. Es bleibt also wahrscheinlich beim unspezifischen Sprachcode "de" oder "en".

Übrigens: Der Ländercode wird in Großbuchstaben notiert, und en-EN gibt es nicht. Dafür aber beispielsweise en-GB oder en-US.

So long,
 Martin

[Gunnar Bittersmann]

@@Der Martin

Ich würde die zusätzliche Spalte aber nicht "land" nennen, sondern "sprache" oder "language".

Unbedingt. Oder "lang". Vielleicht war es ja nur ein Tippfehler. ;-)

Sprachen sind selten eindeutig einem Land zuzuordnen - Paradebeispiele sind Schweiz und Belgien, wo mehrere Sprachen in einem Land gesprochen werden

Wie auch in Deutschland.

Übrigens: Der Ländercode wird in Großbuchstaben notiert

Das ist eher eine Konvention denn ein Muss. Anwendungen sollten Sprach-und Länderkürzel case-insensitive verarbeiten.

LLAP 🖖

[Der Martin]

Mahlzeit,

Sprachen sind selten eindeutig einem Land zuzuordnen - Paradebeispiele sind Schweiz und Belgien, wo mehrere Sprachen in einem Land gesprochen werden

Wie auch in Deutschland.

mehrere Sprachen in Deutschland? Meinst du de facto von Minderheiten? Das ist sicher auch ein Punkt, den man beachten möchte, aber der Gedanke war mir jetzt nicht präsent. Ich dachte erstmal nur an die offiziellen Amtssprachen, und das sind in der Schweiz AFAIK Deutsch, Französisch, Italienisch und Rätoromanisch, in Belgien Französisch, Niederländisch und Deutsch, und in Deutschland nur Deutsch.

Übrigens: Der Ländercode wird in Großbuchstaben notiert

Das ist eher eine Konvention denn ein Muss. Anwendungen sollten Sprach-und Länderkürzel case-insensitive verarbeiten.

Ah. Ich dachte, das sei ein Muss, um gleichlautende Sprach- und Ländercodes zu unterscheiden, wie etwa Sprache de und Land DE.

So long,
 Martin

[Linuchs]

Moin,

mehrere Sprachen in Deutschland? Meinst du de facto von Minderheiten?

Mir war im Sinn, dass "sorbisch" neben "deutsch" Amtssprache sei. Bei der Recherche habe ich gefunden, dass "niederdeutsch" (nds) strittig auch eine deutsche Sprache sei. Zur Frage des Niederdeutschen:

Der Bundesgerichtshof (BGH) stellt in einer Entscheidung zu Gebrauchsmustereinreichung beim Deutschen Patent- und Markenamt (DPMA) in plattdeutscher Sprache das Niederdeutsche einer Fremdsprache gleich und erklärte: „Niederdeutsche (plattdeutsche) Anmeldeunterlagen sind im Sinn des § 4a Abs. 1 Satz 1 GebrMG nicht in deutscher Sprache abgefasst“.[13] Dagegen ist nach dem Kommentar von Foerster/Friedersen/Rohde zu § 82 a des Landesverwaltungsgesetzes Schleswig-Holstein unter Deutsch sowohl Hochdeutsch als auch Niederdeutsch zu verstehen. Die Schleswig-Holsteinische Landesregierung teilt diese Rechtsauffassung.[14] Dabei wird auch auf Entscheidungen höherer Gerichte zu § 184 GVG seit 1927[15] verwiesen, nach denen auch das Plattdeutsche als deutsche Sprache zu definieren ist.

[Quelle](https://de.wikipedia.org/wiki/Amtssprache_in_Deutschland#Zur_Frage_des_Niederdeutschen)

Linuchs

[Tabellenkalk]

Hallo,

Mir war im Sinn, dass "sorbisch" neben "deutsch" Amtssprache sei. Bei der Recherche habe ich gefunden, dass "niederdeutsch" (nds) strittig auch eine deutsche Sprache sei.

Wer sorbisch und niederdeutsch aufzählt, darf frasch, öömrang und sicher einige weitere nicht vergessen!

Gruß
Kalk

[Gunnar Bittersmann]

@@Der Martin

mehrere Sprachen in Deutschland? Meinst du de facto von Minderheiten?

Die Sprachen der in Deutschland lebenden Menschen: Deutsch, Türkisch, Polnisch, Russisch, Arabisch, Englisch, … auch Ober- und Niedersorbisch (aber vermutlich gibt es keinen Sorben mehr, der nicht deutsch spricht).

Ich dachte erstmal nur an die offiziellen Amtssprachen

Ob eine oder mehrere Sprachen offiziell zu Amtssprachen erklärt wurden, ist im Webumfeld irrelevant. (In den USA bspw. gibt es keine.)

Relevant ist: welche Sprachen werden in der jeweiligen Zielgruppe gesprochen?

LLAP 🖖

[Linuchs]

Moin,

Übrigens: Der Ländercode wird in Großbuchstaben notiert

Das ist eher eine Konvention denn ein Muss. Anwendungen sollten Sprach-und Länderkürzel case-insensitive verarbeiten.

Sehe ich anders, ist in der Norm ISO 3166-1 (Länderkürzel) geregelt:

Länder werden dabei durch Großbuchstaben gekennzeichnet.

Linuchs

[MudGuard]

Hi,

Allerdings gilt auch der Einwand von Gunnar. Inhalte für statische, unveränderliche Seiten in eine Datenbank? Ist irgendwie mit Elefanten auf Mücken geschossen ...

Das heißt doch: "mit Spatzen auf Kanonen scheißen".

cu,
Andreas a/k/a MudGuard

[Linuchs]

Hallo,

auf der anderen Seite bin ich so nicht wirklich flexible, sollten irgendwann weiter Sprachen hinzukommen. Wie geht ihr in so einem Fall vor?

Was spricht dagegen, neue Felder für neue Sprachen zu ergänzen?

Ich habe mich vor Jahren entschieden und das nie bereut, die Sprachen bei den HTML-Tags (wie etwa include) in der HTML-Datei zu notieren. Das sieht für ein Formular etwa so aus:

<tr>
  <td>###Titel###Title###Title###</td>
  <td>*</td>
  <td>F</td>
  <td>
<input
required
type      = "text"
name      = "titel"
maxlength = "50"
VALUE     = "[titel]"

>

Es sind Templates, die sowieso zeilenweise mit PHP durchlaufen werden. Ich schreibe sie als "Array" innerhalb einer Zeile in dieser Form: ###deutsch###english###Nederlands###

$lg_ndx = 1; // 1=de, 2=en, 3=nl, ...
...
if ( strpos( 'x'.$zeile, '###' )) {
  $arr_lg = explode( '###', $zeile );
  $zeile  = $arr_lg[0].$arr_lg[$lg_ndx].$arr_lg[count($arr_lg)-1];
...

Ohne Templates get es auch mit der kleinen Funktion zeig_lg( $zeile ):

<p><b><? zeig_lg( "###Neu am 10.02.2016###New on 2016-02-10###Nieuw op 10/02/2016###" ) ?>:</b><br>
<? zeig_lg( "###Auf einigen Listen und auf der Detailansicht von Veranstaltungen siehst du ein Notiz-Symbol neben dem Titel###On some lists and on detail-view of events there is a notice-symbol next to the title###Op sommige lijsten en detail-view van de gebeurtenissen is er een aankondiging-symbool naast de titel###" ) ?>:</p>

.. und dann gibt es ja noch sprachenabhängige Schreibweisen, die du mit festen Tabellen nicht in den Griff bekommst, etwa das Datum. Für mich kein Problem:

###07.05.2016###2016-05-07###07/05/2016###

Linuchs

[Linuchs]

Ergänzung:

Ein Teil der Übersetzungen habe ich in include-Dateien. Dazu gehören die Namen der Wochentage, Monate und Feiertage der Kalender-Einträge. Je nach Land kann ein Datum Feiertag sein oder nicht. Oder in derselben Sprache verschieden heissen (Stefanitag (A) = 2. Weihnachtstag (de)). Das Land kenne ich, weil eine Veranstaltung zu einem Ort gehört:

// ===============================================================
   function welcherFeiertag ( $jjjj_mm_tt, $land_kz, $region_kz )
// ===============================================================
{
  $fixe = array (
   array( '01-01', '',   '', 'Neujahr' )
  ,array( '01-06', 'D',  '', 'Hl. drei Könige' )
  ,array( '04-30', 'NL', '', 'Koninginnedag' )
  ,array( '05-01', 'A',  '', 'Staatsfeiertag (A)' )
  ,array( '05-01', '',   '', 'Maifeiertag' )
  ,array( '05-05', 'NL', '', 'Befrijdingsdag' )
...
  ,array( '12-26', 'A',  '', 'Stefanitag (A)' )
  ,array( '12-26', 'NL', '', '2. Kerstdaag' )
  ,array( '12-26', '',   '', '2. Weihnachtstag' )
  );

  $variable = array (
...
  ,array( '2016-03-25', '',  '', 'Karfreitag' )
  ,array( '2016-03-27', 'NL','', 'Eerste Paasdag' )
  ,array( '2016-03-27', '',  '', 'Ostersonntag' )
  ,array( '2016-03-28', 'NL','', 'Tweede Paasdag' )
  ,array( '2016-03-28', '',  '', 'Ostermontag' )
...
  );
...

Aber das ist für die Frage zu "meine kleine Webseite" wohl übertrieben.

Linuchs

[pl]

Moin,

auf der anderen Seite bin ich so nicht wirklich flexible, sollten irgendwann weiter Sprachen hinzukommen. Wie geht ihr in so einem Fall vor?

Also wenns nur ums Speichern der Inhalte geht: Ich benutze das Muster Entity, Attribute, Value. Und das lässt sich auf genau 3 Spalten abbilden, d.h., egal welche und wieviele Attribute (title, descr, class, css, js, language....) eine Seite hat, es sind immer 3 Spalten. Und es ist auch egal, ob dieser abstrakte Datentyp in MySQL gespeichert wird oder in einer Datei.

Für bestimmte Attribute stellt die Konfiguration einen Default bereit. Also, wenn für die auszuliefernde Seite css= oder js= nicht angegeben ist, greifen die Defaults und für die Sprache ist lang=de der Default.

.pl

[pl]

Na, das -- kam aber spät heute. Egal, meine Wette habe ich gewonnen ;)

[Tabellenkalk]

Hallo,

Na, das -- kam aber spät heute. Egal, meine Wette habe ich gewonnen ;)

wettest du gegen dich selbst?

Gruß
Kalk

[pl]

Hallo,

Na, das -- kam aber spät heute. Egal, meine Wette habe ich gewonnen ;)

wettest du gegen dich selbst?

Nächste Wette: Wetten dass man aus JEDEM Problem (egal wer jetzt mit wem eins hat) ein Geschäft machen kann!?

[Tabellenkalk]

Hallo,

Nächste Wette: Wetten dass man aus JEDEM Problem (egal wer jetzt mit wem eins hat) ein Geschäft machen kann!?

Gegenwette: Wetten, dass du meine nächste Frage auch nicht beantwortest!?

Gruß
Kalk

[pl]

Hallo,

Nächste Wette: Wetten dass man aus JEDEM Problem (egal wer jetzt mit wem eins hat) ein Geschäft machen kann!?

Gegenwette: Wetten, dass du meine nächste Frage auch nicht beantwortest!?

Also gut, ich hatte heut morgen gewettet, dass mein Lösungsvorschlag spätestens bis Mittag negativ bewertet wird. D.h., um Deine Frage zu beantworten: Die Wette hatte mit mir gar nichts zu tun.

[dedlfix]

Tach!

Also gut, ich hatte heut morgen gewettet, dass mein Lösungsvorschlag spätestens bis Mittag negativ bewertet wird.

Hast du das eben Lösungsvorschlag genannt? Ich sah da nur einen Begriffsnennung und konnte dem nicht entnehmen, wie du dir damit die Lösung vorstellst.

dedlfix.

[pl]

Tach!

Also gut, ich hatte heut morgen gewettet, dass mein Lösungsvorschlag spätestens bis Mittag negativ bewertet wird.

Hast du das eben Lösungsvorschlag genannt? Ich sah da nur einen Begriffsnennung und konnte dem nicht entnehmen, wie du dir damit die Lösung vorstellst.

Du kannst das einfach nicht lassen meine Beiträge schlecht zu reden. Hat das schonmal jemand mit Dir gemacht? Das ist einfach nur hinterfotzig und das hab ich Dir wiederholt zu verstehen gegeben! Und ja, ich als Praktiker weiß genau, wie meine Lösung aussieht, denn ich praktiziere die ja.

[Christian Kruse]

Hallo pl,

Du kannst das einfach nicht lassen meine Beiträge schlecht zu reden. Hat das schonmal jemand mit Dir gemacht? Das ist einfach nur hinterfotzig und das hab ich Dir wiederholt zu verstehen gegeben!

Kritikfähigkeit stünde dir gut zu Gesicht. Denke doch mal darüber nach, was Dedlfix und andere dir immer wieder versuchen zu sagen.

Und ja, ich als Praktiker weiß genau, wie meine Lösung aussieht, denn ich praktiziere die ja.

ABER ES HILFT KEINEM WENN NUR DU DAS WEIßT! Das hier ist ein Forum zur Vermittlung von Wissen, keine Masturbationsvorlage.

LG,
CK

[pl]

Hallo pl,

Du kannst das einfach nicht lassen meine Beiträge schlecht zu reden. Hat das schonmal jemand mit Dir gemacht? Das ist einfach nur hinterfotzig und das hab ich Dir wiederholt zu verstehen gegeben!

Kritikfähigkeit stünde dir gut zu Gesicht. Denke doch mal darüber nach, was Dedlfix und andere dir immer wieder versuchen zu sagen.

CK, Du bist auch einer von denen, der genau wie dedlfix meine Beiträge schlecht redet, ich hab ein gutes Gedächtnis und gewisse Empfindlichkeiten für sowas Widerliches.

Hat das schonmal jemand mit Euch gemacht? Wohl kaum, denn sonst würdet ihr hier nicht so auftreten. Ihr solltet mal darüber nachdenken, es ist euer Forum.

Und ja, es ist nicht das Erstemal, dass ich versuche, euch das zu erklären. Also bitte, versucht euch mal vorzustellen wie ihr reagieren würdet. Wenn z.B. jemand schreiben würde "... was der CK schreibt, wir alle wissen doch, dass das Unfug ist..."

Ja, und dann stell Dir mal vor, wie das auf jemanden wirkt, der zum Erstenmal hier ist. Wenn ich derjenige wäre, ich würde nie wieder kommen.

Also, Thomas, falls Du meine Lösung nicht verstehen solltest, frag einfach. Es ist ne Lösung, die hat sich seit Jahren bewährt.

[Christian Kruse]

Lieber Rolf Rost, Hotti, pl,

wir kennen uns wirklich lange. Sicherlich schon 10 Jahre oder mehr. Ich weiß, dass Kritikfähigkeit nicht so dein Ding ist. Trotzdem versuche ich dir noch einmal begreiflich zu machen, dass es sich hier nicht um eine Schmähung dreht, sondern um konkrete und fallbezogene Kritik. Keiner will dich prinzipiell niedermachen, wenn du eine gute Antwort gibst bewerte ich sie durchaus auch positiv (in dem aktuellen Thread-Index gibt es da ein paar Beispiele zu).

Nicht stehen lassen kann man aber deine Ausrutscher Richtung schlechte Antworten. Denn entweder wird dort fachlich falsches Verbreitet, oder du verfällst in ein Bullshit-Bingo (so wie hier) aus dem kein Anfänger etwas herauslesen kann oder du machst nur nebulöse Anmerkungen.

Es geht also einfach nicht um einen persönlichen Angriff alla „der Hotti schreibt nur Unsinn.“ Bitte versuche doch, das zu verstehen. Danke.

LG,
CK

[Der Martin]

Lieber Rolf Rost, Hotti, pl,

Nicht stehen lassen kann man aber deine Ausrutscher Richtung schlechte Antworten. Denn entweder wird dort fachlich falsches Verbreitet, oder du verfällst in ein Bullshit-Bingo (so wie hier) aus dem kein Anfänger etwas herauslesen kann oder du machst nur nebulöse Anmerkungen.

... oder du gibst eine Antwort oder einen Lösungsvorschlag für eine ganz andere Frage, um die es im Moment gar nicht geht.

So long,
 Martin

[dedlfix]

Tach!

auf der anderen Seite bin ich so nicht wirklich flexible, sollten irgendwann weiter Sprachen hinzukommen. Wie geht ihr in so einem Fall vor?

Also wenns nur ums Speichern der Inhalte geht: Ich benutze das Muster Entity, Attribute, Value. Und das lässt sich auf genau 3 Spalten abbilden, d.h., egal welche und wieviele Attribute (title, descr, class, css, js, language....) eine Seite hat, es sind immer 3 Spalten.

Deinem Beitrag fehlt es wie so oft an Verständlichkeit. Warum du das EAV-Muster einsetzt und welchen Vorteil das gegenüber anderen Verfahren bringt, lässt du offen. "Nur drei Spalten" ist kein ausreichend erklärendes Argument. Wie also würdest du konkret auf den Fall des Fragenden die Daten ablegen wollen? Was kommt in welche Spalte? Ich bitte um ein Beispiel.

Und es ist auch egal, ob dieser abstrakte Datentyp in MySQL gespeichert wird oder in einer Datei.

Was genau ist der Hintergrund für diese Aussage? Lassen sich konkrete Datentypen etwa nicht sowohl in MySQL als auch in anderen Dateien speichern?

Für bestimmte Attribute stellt die Konfiguration einen Default bereit. Also, wenn für die auszuliefernde Seite css= oder js= nicht angegeben ist, greifen die Defaults und für die Sprache ist lang=de der Default.

Das hat jetzt konkret auf das Problem der Mehrsprachigkeit des Fragenden was zu bedeuten?

dedlfix.

[pl]

Das hat jetzt konkret auf das Problem der Mehrsprachigkeit des Fragenden was zu bedeuten?

Den seine Frage bezog sich auf die Art und Weise der Daten-Speicherung. Und mal ehrlich, eine Anwwendung dermaßen vom DB-Design abhängig zu machen, das ist doch ein Gemurkse ohne Ende. Eine Änderung der Feldnamen würde einem Neubau der Anwendung gleichkommen. Wobei es in Fakt genügen würde, eine Spalte LANG hinzuzufügen womit ein jeder Record eindeutig einer bestimmten Sprache zugeordnet werden kann.

Aber meine Lösung geht ja in Richtung objektorientierte Datenhaltung, d.h., nur die Anwendung bestimmt wie der Abstrakte Datentyp aussieht und ab da ist es der Anwendung egal ob der von CD, Diskette, Dongel, Oracle, MySQL oder sonstwoher kommt.

Das Nächste wäre dann die Sprachauswahl an sich und dafür gibt es die Content-Negotiation. Insofern wird, wenn unter einunddemselben URL Inhalte verschiedener Sprachen ausgehandelt werden, eben nicht der URL sondern ein internes Attribut dafür zuständig sein, was auch wieder eher für eine objektorientierte Datenhaltung spricht.

[dedlfix]

Tach!

Das hat jetzt konkret auf das Problem der Mehrsprachigkeit des Fragenden was zu bedeuten?

Meine Frage bezog sich auf den von mir davor zitierten Kontext. Du beantwortest sie nicht diesbezüglich, sondern sprichst von etwas anderem. Auch die anderen konkreten Fragen lässt du unbeantwortet. Und da wunderst du dich, dass deine am Thema vorbeigehenden und nichts konkret beantwortenden Beiträge negativ bewertet werden?

Den seine Frage bezog sich auf die Art und Weise der Daten-Speicherung. Und mal ehrlich, eine Anwwendung dermaßen vom DB-Design abhängig zu machen, das ist doch ein Gemurkse ohne Ende.

Das mag bei großen Projekte der Fall sein, bei kleinen geht es eher in Richtung unnötige Verkomplizierung. Man braucht einen ausgewachsenen ORM nicht zwingend in jedem Projekt. Seine Flexibilität ist zwar nett, aber seine Komplexität auch nicht zu verachten.

Eine Änderung der Feldnamen würde einem Neubau der Anwendung gleichkommen.

Ach, wirklich? Mein Editor kann Suchen und Ersetzen.

Wobei es in Fakt genügen würde, eine Spalte LANG hinzuzufügen womit ein jeder Record eindeutig einer bestimmten Sprache zugeordnet werden kann.

Das ist mal wenigstens ein Punkt, der in Richtung einer möglichen Lösung geht. Der Nachteil daran ist, dass man für die Verwaltung der Texte eine Oberfläche benötigt, die die zusammengehörigen Übersetzungen gleichzeitig darstellen kann, wenn man sie direkt vergleichen können möchte. Pro Sprache eine Spalte hingegen ist zwar nicht wirklich flexibel, aber man hätte dann mit dem vermutlich vorhandenen phpMyAdmin oder ähnlichen datensatzorientierten Werkzeugen bereits eine Oberfläche, die gleichzeitiges Darstellen und Bearbeiten eines Textes in allen Sprachen ohne weiteres Zutun bietet, nebst der einfachen Übersicht, in welcher Sprache welche Texte fehlen. Spalte leer - Text fehlt. Mach das mal mit der anderen Methode, da braucht es ein etwas komplexeres SQL-Statement, um diese Information zu gewinnen.

Ob der Vorteil, ohne die Datenbankstruktur anzupassen und gegebenenfalls noch das Programm drumherum erweitern zu müssen, eine neue Sprache hinzufügen zu können, den restlichen Aufwand wert ist, vermag ich aus "meine kleine Webseite" nicht direkt zu entnehmen. Das kann ja auch tiefgestapelt sein. Insofern wäre meine Antwort so ausgefallen, dass sie die beiden Möglichkeiten und deren Eigenschaften aufzeigt, so dass der Fragende möglichst selbst zu entscheiden in der Lage ist, was für sein Projekt angemessen ist.

Aber meine Lösung geht ja in Richtung objektorientierte Datenhaltung,

Und das muss ein offensichtlich noch nicht so weit fortgeschrittener Programmierer aus dem was du nicht gesagt hast herausnehmen?

d.h., nur die Anwendung bestimmt wie der Abstrakte Datentyp aussieht und ab da ist es der Anwendung egal ob der von CD, Diskette, Dongel, Oracle, MySQL oder sonstwoher kommt.

Schön, aber wozu braucht er denn für "meine kleine Webseite" eine Entkopplung zwischen dem Model in der Datenablage und dem Modell in der Anwendung? Was ist das echte und nicht nur hypothetische Problem, was damit gelöst werden soll?

Das Nächste wäre dann die Sprachauswahl an sich und dafür gibt es die Content-Negotiation. Insofern wird, wenn unter einunddemselben URL Inhalte verschiedener Sprachen ausgehandelt werden, eben nicht der URL sondern ein internes Attribut dafür zuständig sein, was auch wieder eher für eine objektorientierte Datenhaltung spricht.

Erkläre bitte, welche konkreten Vorteile die Objektorientiertheit für "meine kleine Webseite" bietet, die mit herkömmlichen Datenstrukturen nicht zu erreichen sind.

dedlfix.

[pl]

Erkläre bitte, welche konkreten Vorteile die Objektorientiertheit für "meine kleine Webseite" bietet, die mit herkömmlichen Datenstrukturen nicht zu erreichen sind.

Herkömmliche Datenstrukturen kannst Du immer auch objektorientiert betrachten. Du kommst nicht von Perl, daher noch einmal die Herangehensweise:

Betrachte ein Objekt als eine Ansammlung von Daten, wie die innere Struktur aussieht sei dahingestellt. Das Objekt kann in dem Augenblick als Instanz einer Klasse betrachtet werden, wenn es weiß, zu welcher Klasse es gehört.

So hätten wir auch bei kleinen Webprojekten für eine Einzelseite einen eindeutigen URL. Den bezeichnen wir als Entity. Dieser URL soll Inhalte ausliefern, das sind dann die Attribute wie title, descr, body usw. Zur internen Unterscheidung kommt ein Attribut hinzu: lang=de, lang=en usw. Diese 3 Dinge, Entity, Attribute, Value ergeben genau 3 Spalten: ent/att/val

Also egal, welche Größe das Projekt umfasst, ein Kleines könnte größer werden... das DB-Design ist immer dasselbe, auch wenn weitere Attribute hinzukommen, sind das immer 3 Felder. Request /index.html holt für diesen Entity alle Attribute aus der Tabelle und wie die Attribute heißen, bestimmt nicht das DB-Design sondern die Anwendung.

In Perl ist dieser Abstrakte Datentype ein Hash of Hashes. Für einen bestimmten Entity bilden Attribute/Value einen Hash. In PHP als assoziative Arrays auch bekannt, praktisch dasselbe wie in Perl.

EAV ist praktisch ein Sammlung von Datenobjekten. Denen auch mit einem class= beigebracht werden kann, zu welcher Klasse die gehören.

Am Ende machts die Sache nicht komplizierter sondern einfacher. Oft ist jedoch gerade das Einfache das was schwer zu verstehen ist.

[Thomas]

Hallo,

danke für die Antworten, leider artet die Diskussion so aus, dass sie zum Teil schon gar nichts mehr mit meiner Frage zu tun hat. Deshalb hat sich das Thema erstmal für mich erledigt, ich habe a) nicht die Zeit alle Beiträge durchzulesen ob da noch etwas sinnvolles für mich drin steht und b) finde ich es schade dass ein Beitrag zum Teil als Spam missbraucht wird. Ich bin dieses aus anderen Foren nicht gewöhnt, ist mir aber egal, da es ja nicht mein Forum ist.

[Matthias Apsel]

Hallo Thomas,

b) finde ich es schade dass ein Beitrag zum Teil als Spam missbraucht wird.

Wo hast du denn Spam gefunden?

Bis demnächst
Matthias

[Thomas]

Hallo Matthias,

Wo hast du denn Spam gefunden?

Spam in "" z.B. Beiträge wo es um irgendwelche Wetten geht oder wer welchen Beitrag schlecht redet / schreibt verstehe ich als Spam da diese nicht mit dem eigentlichen Thema zu tun hat und es ist sehr mühsam durch alle Beiträge zu schauen was interessant für einen ist und was einfach nur nebensächlich diskutiert wird.

[Der Martin]

Hallo,

Wo hast du denn Spam gefunden?

Spam in "" z.B. Beiträge wo es um irgendwelche Wetten geht oder wer welchen Beitrag schlecht redet / schreibt verstehe ich als Spam da diese nicht mit dem eigentlichen Thema zu tun hat und es ist sehr mühsam durch alle Beiträge zu schauen was interessant für einen ist und was einfach nur nebensächlich diskutiert wird.

ach so meinst du das. Ja, okay ... teilweise sind ja auch solche Abschweifungen noch nützlich, aber wenn's natürlich nur noch um persönliche Befindlichkeiten geht ...

Ein Indiz, an dem du solche Äste oft (nicht immer) erkennen kannst, ist ein geänderter Thread-Titel oder das Tag menschelei, das plötzlich auftaucht.

So long,
 Martin

[Julius]

Hallo Martin,

Ein Indiz, an dem du solche Äste oft (nicht immer) erkennen kannst, ist ein geänderter Thread-Titel oder das Tag menschelei, das plötzlich auftaucht.

... oder wenn wenn Beiträge negativ bewertet wurden – oder wenn pl etwas schreibt...

Gruß
Julius

[Matthias Apsel]

Hallo Julius,

... oder wenn wenn Beiträge negativ bewertet wurden – oder wenn pl etwas schreibt...

Das möchte ich nicht unkommentiert stehen lassen. PLs Beiträge sind nicht per se schlecht oder falsch. Und es gehört sich auch nicht, über jemanden so zu urteilen.

Bis demnächst
Matthias

[Christian Kruse]

Hallo Matthias,

... oder wenn wenn Beiträge negativ bewertet wurden – oder wenn pl etwas schreibt...

Das möchte ich nicht unkommentiert stehen lassen. PLs Beiträge sind nicht per se schlecht oder falsch. Und es gehört sich auch nicht, über jemanden so zu urteilen.

Zumal wir genau das das gerade erst hatten.

LG,
CK

[Julius]

Hallo Matthias,

... oder wenn wenn Beiträge negativ bewertet wurden – oder wenn pl etwas schreibt...

Das möchte ich nicht unkommentiert stehen lassen. PLs Beiträge sind nicht per se schlecht oder falsch.

Das habe ich so auch nicht geschrieben:
Martin schrieb „Ein Indiz, an dem du solche Äste oft (nicht immer) erkennen kannst[…]“ und an diesen Satz habe ich durch ein Zitat „angebaut“.

Gruß
Julius

[Matthias Apsel]

Hallo Julius,

... oder wenn wenn Beiträge negativ bewertet wurden – oder wenn pl etwas schreibt...

Das möchte ich nicht unkommentiert stehen lassen. PLs Beiträge sind nicht per se schlecht oder falsch.

Das habe ich so auch nicht geschrieben:
Martin schrieb „Ein Indiz, an dem du solche Äste oft (nicht immer) erkennen kannst[…]“ und an diesen Satz habe ich durch ein Zitat „angebaut“.

Ja.
Liest sich: „Ein Indiz, an dem du ‚Spam‘^[1] (denn darum ging es in der Fragestellung) erkennen kannst, ist, wenn pl etwas schreibt“.

Bis demnächst
Matthias

---

1. Hier als nicht zum Thema gehörend definiert. ↩︎

[Matthias Apsel]

Hallo Thomas,

Spam in "" z.B. Beiträge wo es um irgendwelche Wetten geht oder wer welchen Beitrag schlecht redet / schreibt verstehe ich als Spam da diese nicht mit dem eigentlichen Thema zu tun hat und es ist sehr mühsam durch alle Beiträge zu schauen was interessant für einen ist und was einfach nur nebensächlich diskutiert wird.

Aha. Verstehe.

Das ist hier ganz oft so, vor allem, wenn es unterschiedliche Lösungswege oder Herangehensweisen gibt. Ich persönlich mag dies sehr, da es bei mir sehr oft zu wirklichen Erkenntnissen führt. Das Geben der richtigen Lösung (oft gibt es die Lösung ohnehin nicht) ist nicht das, was SELFHTML ausmacht. Ziel der Energie des Verstehens ist, dich zu einer Lösung zu führen, nicht, dir eine vor die Füße zu werfen. Gerade bei einer nicht mal so nebenbei zu beantwortenden Frage solltest du die Diskussionen verfolgen und für dich selbst Lösungsansätze mitnehmen. Leider gibt es da kein ja/nein, schwarz/weiß.

Bis demnächst
Matthias

[Tabellenkalk]

Hallo,

Leider gibt es da kein ja/nein, schwarz/weiß.

sondern nur Jein und Schweiß...

Gruß
Kalk

[Julius]

Hallo Thomas,

danke für die Antworten, leider artet die Diskussion so aus, dass sie zum Teil schon gar nichts mehr mit meiner Frage zu tun hat.

Threaddrift ist nicht per se etwas Schlechtes, oft ergeben sich daraus interessante neue Aspekte.

Außerdem können die Autoren ja oft nur mutmaßen, ob ihr Beitrag für dich interessant sein könnte oder eben nicht – gerade bei so einer allgemein gestellten Frage wie der deinen sind viele verschiedene Ansätze möglich.

b) finde ich es schade dass ein Beitrag zum Teil als Spam missbraucht wird. Ich bin dieses aus anderen Foren nicht gewöhnt, ist mir aber egal, da es ja nicht mein Forum ist.

In anderen Foren wirft dir jemand ein paar Brocken Code hin und das war es. Hier ist man der Ansicht, dir zu helfen, dein Problem selbst zu lösen – und du fragtest nun mal nach Anregungen, die du auch bekommen hast.

Gruß
Julius

Edit: Es ist zweckmäßig, die anderen Beiträge im entsprechenden Baum zu lesen, bevor man etwas schreibt. ;-)