Ich suche nach einer _einfachen_ Möglichkeit, Mehraprachigkeit zu
realisieren.

Momentan mache ich das so, dass ich bei umfangreicheren Texten einfach
verschiedene Dateien vorhalte, z.B.

index.de
index.fi

usw.

Bei einzelnen Wörtern habe ichd as so gelöst, dass ich if-Kaskaden habe,
in denen verschiedene Wörter zugewiesen werden, z.B.

if (lang=="fi") {
$montag = "Maanantai";
} else {
[...]
} else $montag = "Montag";

Aber das ist alles sehr uneinheitlich

Möglich wäre natürlich eine ascii-Datei in diesem Stil

montag|de|Montag|fi|Maanantai|nl|Maandag|x|Montag

wobei "x" eben der not found-Fall ist.


Aber es ist ja auch nicht sinnvoll, bei jedem Zugriff auf die Datei
zuzugreifen

$montag = getword ($lang, "montag");

Oder geht der Zugriff so schnell, dass es unerheblich ist?

Eine Möglichkeit wäre natürlich, die ganze Datei in eine globale Tabelle
einzulesen und auf die dann zuzugreifen.

Gibt's noch andere Möglichkeiten, die einfach und leicht beherrschbar sind.

SQLite wäre wohl noch eine Möglichkeit, aber da ist wohl die Pflege per
Frontend nicht so dolle. Und MySQL möchte ich definiti dafür nciht nehmen.

Bis jetzt läuft's eigentlich ganz gut bei mir, aber ich möchte den
Sprachzugriff vereinfachen und vereinheitlichen

Vielen Dank

Werner




--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de

"Werner Partner" <kairos [at] sonoptikon.de> schrieb im Newsbeitrag
news:f826q9$8fl$1 [at] online.de...

Hallo Werner,

> Ich suche nach einer _einfachen_ Möglichkeit, Mehraprachigkeit zu
> realisieren.

Tipp: Nimm Smarty, gestalte Deine Seiten als Templates, registriere eine
Session-Variable für die Sprache und nutze die Konfigurationsdateien von
Smarty für die Ablage der Textbausteine. Das ist aber nur dann sinnig, wenn
sich die Texte nicht sehr oft ändern bzw. nicht per Web-Interface editiert
werden soll (ginge mit RegExp aber zur Not auch).

Noch ein Tipp: Benutze bei statischen Werten wie Wochentagen, Monatsnamen
usw. lieber Konstanten bei der Definition, die Werte bleiben ja in der Regel
gleich. Auch die könntest Du - unabhängig von Smarty - in eigene Dateien wie
german.lang.php und suomi.lang.php ablegen, wenn Du Dich nicht in Smarty
einarbeiten willst:

#german.lang.php:
define('MONDAY','Montag');

#suomi.lang.php:
define('MONDAY',Maanantai|);

Auch hier eine Session-Variable für die Sprache und die jeweilige Datei mit
den Konstanten per require / include einbinden - fertig.

Das läßt sich auch noch weiter spinnen mit einem Ordner je Sprache, wo z.B.
auch grafische Headlines und Buttons der jeweligen Sprache liegen (img dann
natürlich ohne Angabe von Abmessungen einbinden).

Viel Spass beim Tüfteln! ;)

Gruß

Klaus

Moin,

Werner Partner wrote:
> Ich suche nach einer _einfachen_ Möglichkeit, Mehraprachigkeit zu
> realisieren.

Den Hinweis mit Templates wurde ja schon gegeben, damit erschlägt man
in der Regel auch schon 90% aller Mehrsprachigkeitsprobleme.

Nutze zunächst einheitliche Codes für die Sprachbezeichnung, wie z.B.=

die ISO Codes (de_DE für Deutsch, en_GB für Englisch, usw.) Somit kan=
n
dann alles, was mehrsprachig ausgelegt sein soll, einfach die Endung
des Sprachcode erhalten:

z.B. template_de_DE.tpl für Deutsch, entsprechend template_en_GB.tpl
für die englische Fassung.

Auch im Datenbank-Design kann das Einzug halten
=2E..
description_de_DE varchar(100) ...
description_en_GB varchar(100) ...
description_... varchar(100)

Würde man nun ein Objekt (also ein Klasse) darauf zugreifen lassen,
würde die Klasse prinzipiell so aussehen können:

class myObject{
var $language=3D"de_DE";
var $objectID=3D0
var $objectdata=3Darray();

...

function getdescription(){
return $this->objectdata["description_".$this->language];
}
}

Setzt natürlich erstmal voraus, dass das initialisierte Objekt in einem=

assoziativem Array sitzt.(objectdata)

Die Verwendung von Konstanten für alles weitere, wie z.B. Wochentage,
Monate, Währungen oder ähnliches scheitert zumeist an der fehlenden
Möglichkeit, diese Werte zu indizieren, sprich Arrays zu bilden.
Variablen sind da wieder vorteilhafter, sind nur leider nicht global
gültig, solange man sie nicht diebezüglich geklariert (wovon ich imme=
r,
immer, immer abrate). Das indizieren hat zudem den Vorteil, dass man
Zahlen statt Strings für die Kennzeichnungen verwendet, was kürzer un=
d
schneller ist, gerade wenn eine Datenbank im Spiel ist.

$currency["de_DE"][0]=3D"Deutsche Mark";
$currency["en_GB"][0]=3D"Deutsch Mark";

$language["de_DE"][0]=3D"Deutsch";
$language["en_GB"][0]=3D"German";
$language["de_DE"][1]=3D"Englisch";
$language["en_GB"][1]=3D"English";
$language["de_DE"][2]=3D"Französisch";
$language["en_GB"][2]=3D"French";

Ein Satz wie:
"Ihre gewählte Sprache ist Deutsch."

wäre demnach wie folgt zu programmieren:
echo "Ihre Sprache ist ".$language[$LANGUAGE][0];

In einer anderen Sprache wäre fast alles gleich:
echo "Your language is ".$language[$LANGUAGE][0];

Nun bedarf es eigentlich nur ein Template mit dem Satz und der
Platzhalter wird mit $language[$LANGUAGE][0] beschrieben.

Das $LANGUAGE natürlich den ISO-Sprachcode beinhaltet, versteht sich
fast von selbst.

Von einer Verwendung mit einer Datenbank rate ich immer ab, weil das
nachher zu aufwendig wird. Ausnahme ist natürlich das Objekt, welches
in der Datenbank mehrsprachig gepflegt wird.

Gruß
Anne

Werner Partner schrieb:
> Ich suche nach einer _einfachen_ Möglichkeit, Mehraprachigkeit zu
> realisieren.

gettext: http://de2.php.net/manual/de/ref.gettext.php

Gruß, Markus

Werner Partner schrieb:

> Bei einzelnen Wörtern habe ichd as so gelöst, dass ich if-Kaskaden habe,
> in denen verschiedene Wörter zugewiesen werden, z.B.
>
> if (lang=="fi") {
> $montag = "Maanantai";
> } else {
> [...]
> } else $montag = "Montag";

Gib jedem Textteil einen eindeutigen Key. Erzeuge ein Array, dass zu
jeder Kombination aus Key und Sprache die entsprechende Übersetzung
sowie evtl. einen Default (falls Sprache ungültig oder nicht vorhanden)
enthält, etwa so:

$texte = array('Montag' => array('fi' => 'Maanantai',
'en' => 'Monday',
'fr' => 'Lundi',
0 => 'Montag'),
'Dienstag' => array(...),
...);

Dann kannst Du Dein obiges Beispiel ersetzen durch:

$montag = isset($texte[$key][$lang]) ? $texte[$key][$lang]
: $texte[$key][0];

Oder etwas kürzer, aber nicht unbedingt übersichtlicher:

$montag = $texte[$key][isset($texte[$key][$lang]) ? $lang : 0];

Gruß. Claus

Claus Reibenstein schrieb:
> Oder etwas kürzer, aber nicht unbedingt übersichtlicher:
>
> $montag = $texte[$key][isset($texte[$key][$lang]) ? $lang : 0];

Oder wir bauen ne Funktion drum, dann wirds richtig übersichtlich:

function t($key)
{
global $texte;
return isset($texte[$key][$lang]) ? $texte[$key][$lang]
: $texte[$key][0];
}

$montag = t("Monday");

Gruß
Pta

Klaus Holsten schrieb:
> "Werner Partner" <kairos [at] sonoptikon.de> schrieb im Newsbeitrag
> news:f826q9$8fl$1 [at] online.de...
>
> Hallo Werner,
>
>> Ich suche nach einer _einfachen_ Möglichkeit, Mehraprachigkeit zu
>> realisieren.
>
> Tipp: Nimm Smarty, gestalte Deine Seiten als Templates, registriere eine
> Session-Variable für die Sprache und nutze die Konfigurationsdateien von
> Smarty für die Ablage der Textbausteine. Das ist aber nur dann sinnig, wenn
> sich die Texte nicht sehr oft ändern bzw. nicht per Web-Interface editiert
> werden soll (ginge mit RegExp aber zur Not auch).
>
> Noch ein Tipp: Benutze bei statischen Werten wie Wochentagen, Monatsnamen
> usw. lieber Konstanten bei der Definition, die Werte bleiben ja in der Regel
> gleich. Auch die könntest Du - unabhängig von Smarty - in eigene Dateien wie
> german.lang.php und suomi.lang.php ablegen, wenn Du Dich nicht in Smarty
> einarbeiten willst:
>
> #german.lang.php:
> define('MONDAY','Montag');
>
> #suomi.lang.php:
> define('MONDAY',Maanantai|);
>
> Auch hier eine Session-Variable für die Sprache und die jeweilige Datei mit
> den Konstanten per require / include einbinden - fertig.
>
> Das läßt sich auch noch weiter spinnen mit einem Ordner je Sprache, wo z.B.
> auch grafische Headlines und Buttons der jeweligen Sprache liegen (img dann
> natürlich ohne Angabe von Abmessungen einbinden).
>
> Viel Spass beim Tüfteln! ;)
>

Ja, danke
Von Smarty habe ich schon mal gehört ...

Mal schaun

Werner

--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de

Peter Schmidt schrieb:
> Claus Reibenstein schrieb:
>> Oder etwas kürzer, aber nicht unbedingt übersichtlicher:
>>
>> $montag = $texte[$key][isset($texte[$key][$lang]) ? $lang : 0];
>
> Oder wir bauen ne Funktion drum, dann wirds richtig übersichtlich:
>
> function t($key)
> {
> global $texte;
> return isset($texte[$key][$lang]) ? $texte[$key][$lang]
> : $texte[$key][0];
> }
>
> $montag = t("Monday");

Uff!
Aber ich habe auch heute mittag noch an eine Funktion gedacht - oder an
ein Array - oder beides. Alles andere ist ganz schön anspruchsvoll. Aber
es macht ja auch mal Sinn, an einem verhältnismäßig dicken Brett zu bohren.

Grüße

Werner

--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de

Werner Partner wrote:
>
> Uff!
> Aber ich habe auch heute mittag noch an eine Funktion gedacht - oder an=

> ein Array - oder beides. Alles andere ist ganz schön anspruchsvoll. A=
ber
> es macht ja auch mal Sinn, an einem verhältnismäßig dicken Brett =
zu bohren.

Wenn man wirklich Arbeit haben will, fängt man an, seine Anwendungen zu=

internationalisieren. Dabei fällt die =DCbersetzung schonmal gar nicht =
so
sehr ins Gewicht.

Alleine schon unterschiedliche Formulareingaben hinsichtlich der
Internationalisierung des Datums korrekt zu interpretieren, ist lustig.

Viel Spaß

Anne

> Bis jetzt läuft's eigentlich ganz gut bei mir, aber ich möchte den
> Sprachzugriff vereinfachen und vereinheitlichen

Ich habe mir gerade eine kleine Klasse zu dem Thema geschrieben...
Die Sprachdateien lege ich in einem Ordner wie folgt ab:
de/datei.txt
en/datei.txt
.....
Instantiiert wird die Klasse mit Verweis auf den Sprachenfolder,
Sprachdatei, Hauptsprache und übersetzte Sprache. Er versucht dann,
sowohl die Hauptsprachdatei als auch die Übersetzung zu laden; wenn in
der Übersetzung etwas fehlt, greift er auf die Hauptsprache zurück.

Dort, wo ein mehrsprachiger Wert gebraucht wird, lade ich dann den
entsprechenden Wert aus der Klasse.

Weil ich faul bin, gibt es noch einen Destruktor. Der schreibt eine
Übersetzung neu mit den bereits vorhandenen Werten und fügt leere
Schlüssel hinzu, wenn es in der Hauptsprachdatei neue Schlüssel gibt.

Ich denke, dass das Ding performancemässig überschaubar bleiben sollte,
weil ich im Zweifel die Inhalte unterteilen kann. Von Vorteil ist, dass
die Spracheinstellung recht zentral bei der Instantiierung der Klasse
bestimmt ist. Da ich aber ein einfaches Schema schlüssel:wert verwende,
wird es natürlich schwierig mit Umbrüchen. Eine Erweiterung, die statt
auf Dateien auf eine Datenbank zurückgreift, wäre denkbar.

Sowas hatte ich auch schon, das hat die Pflege erleichtert. An dem
Projekt waren Partner aus aller Herren Länder beteiligt, die dann
Meldungen wie z. B. "Ihre Mail wurde gesendet" in ihre jeweilige Sprache
übersetzt haben. Datentabellen habe ich dann aufgeteilt in
sprachunabhängige (Name, Vorname) und sprachspezifische Teile
(Beschreibung).



--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

> Auch im Datenbank-Design kann das Einzug halten
> ...
> description_de_DE varchar(100) ...
> description_en_GB varchar(100) ...
> description_... varchar(100)

hngggnggng....skaliert sicher wunderschön, wenn Du dann mehrere tausend
Spalten in einer Tabelle hast...

Sowas ist prädestiniert für 1:n.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

Anne Kaeppes schrieb:
> Werner Partner wrote:
>>
>> Uff!
>> Aber ich habe auch heute mittag noch an eine Funktion gedacht - oder
>> an ein Array - oder beides. Alles andere ist ganz schön anspruchsvoll.
>> Aber es macht ja auch mal Sinn, an einem verhältnismäßig dicken Brett
>> zu bohren.
>
> Wenn man wirklich Arbeit haben will, fängt man an, seine Anwendungen zu
> internationalisieren. Dabei fällt die Übersetzung schonmal gar nicht so
> sehr ins Gewicht.
>
> Alleine schon unterschiedliche Formulareingaben hinsichtlich der
> Internationalisierung des Datums korrekt zu interpretieren, ist lustig.

Wie wahr!
Ich habe es relativ einfach angefangen und möchte es auch einfach
lassen, aber ein bisschen eimnheitlicher und eleganter möchte ich es
schon haben.

Grüße

Werner

--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de

Anne Kaeppes schrieb:

> Auch im Datenbank-Design kann das Einzug halten
> ...
> description_de_DE varchar(100) ...
> description_en_GB varchar(100) ...
> description_... varchar(100)

Das DB-Design ist kaputt.

mnemo varchar(255) -- Zugriffskürzel
lang char(5) -- Sprachkürzel
translation varchar(255) -- =DCbersetzung

ist schon allein deshalb besser, weil die Tabellenstruktur für
zusätzliche Sprachen nicht geändert werden muss.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Hi!

Also ich löse das immer so: Ich packe alle Strings in eine Datenbank und
speicher bei jedem String auf welcher Seite dieser angezeigt wird. Dann
speicher ich zu dem String noch Bezeichner der auf der jeweiligen Seite
eindeutig sein muss. Wenn jetzt eine Seite aufgerufen wird hole ich alle zu
dieser seite gehörenden Strings in der gerade gewählten Sprache aus der
Datenbank und weise den Stringwert einer Smartyvariablen zu die den Namen
des gespeicherten Bezeichners trägt, also etwa so:

while( $row = mysql_fetch_assoc($select_result) )
{
$smarty->assign( $row['identifier'] , $row['text'] );
}

Das template sieht dann einfach so aus:

<html>
<body>
....
{$bezeichner1}
....
{$bezeichner2}
....
{$bezeichner3}
....
</body>
</html>

Dann trägt smarty für mich den Wert in das Template ein. Ob du jetzt die
Daten mit MySQL speicherst, SQLlite, XML oder ASCII-Dateien ist dabei
eigentlich egal. Dann wird nur das holen der Datensätze etwas aufwendiger.

mfg Xion

Hadanite Marasek wrote:
>>Auch im Datenbank-Design kann das Einzug halten
>>...
>> description_de_DE varchar(100) ...
>> description_en_GB varchar(100) ...
>> description_... varchar(100)
>
>
> hngggnggng....skaliert sicher wunderschön, wenn Du dann mehrere tause=
nd
> Spalten in einer Tabelle hast...

Wo sollte das Problem deiner Meinung nach sein? Ich sehe ehrlich gesagt
keins.

Zugegeben, tausend Spalten in einer Tabelle habe ich noch nicht geschafft=
=2E

> Sowas ist prädestiniert für 1:n.

Kann man auch machen, jedoch sehe ich obiges Problem nicht.

Niels Braczek wrote:
> Anne Kaeppes schrieb:
>
>
>>Auch im Datenbank-Design kann das Einzug halten
>>...
>> description_de_DE varchar(100) ...
>> description_en_GB varchar(100) ...
>> description_... varchar(100)
>
>
> Das DB-Design ist kaputt.

Das Design ist an sich völlig in Ordnung. Gegen welche Datenbank-Design=

Regel sollte sowas verstoßen?

> mnemo varchar(255) -- Zugriffskürzel
> lang char(5) -- Sprachkürzel
> translation varchar(255) -- =DCbersetzung
>
> ist schon allein deshalb besser, weil die Tabellenstruktur für
> zusätzliche Sprachen nicht geändert werden muss.

Ich ändere meine Tabellenstrukturen in der Regel sehr häufig.
Eigentlich ist alles darum herum so programmiert, dass die =C4nderung in =

der Tabellenstruktur keinerlei weitere Massnahmen erforderlich macht.

Vielleicht würde ich bei 100 verschiedenen Sprachen, das ganze Design
anders gestalten, jedoch habe ich noch keine Anwendung erstellt, die
mehr als 4 Sprachen hatte.

Davon einmal ab, ist obiges Design eigentlich nur dazu da, um
Benutzereingaben wie z.B. Artikelbeschreibungen, Titel usw.
mehrsprachig aufzufassen. Das schränkt schon zumeist die Anzahl der
Sprachen ein, denn wer möchte denn seine Artikelbezeichnungen usw. in
mehreren Sprachen eingeben oder vorhalten?

Anne Kaeppes schrieb:

> Hadanite Marasek wrote:
>
>>> Auch im Datenbank-Design kann das Einzug halten
>>> ...
>>> description_de_DE varchar(100) ...
>>> description_en_GB varchar(100) ...
>>> description_... varchar(100)
>>
>> hngggnggng....skaliert sicher wunderschön, wenn Du dann mehrere tausend
>> Spalten in einer Tabelle hast...
>
> Wo sollte das Problem deiner Meinung nach sein? Ich sehe ehrlich gesagt
> keins.

Es ergibt grundsätzlich keinen Sinn, mehrere Tabellen mit identischem
Aufbau zu benutzen. So etwas zeugt von kaputtem Datenbankdesign.

Gruß. Claus

Claus Reibenstein wrote:

>>Wo sollte das Problem deiner Meinung nach sein? Ich sehe ehrlich gesagt=

>>keins.
>
>
> Es ergibt grundsätzlich keinen Sinn, mehrere Tabellen mit identischem=

> Aufbau zu benutzen. So etwas zeugt von kaputtem Datenbankdesign.

Was heißt identischer Aufbau? Wenn ich die Beschreibung eines z.B.
Artikels habe, kommen, sofern mehrsprachig mehrere Spalten nach
folgendem Aufbau hinein:

description_de_DE
description_en_GB usw.

Warum sollte ich das nun in eine andere Tabelle mit 1:n auslagern?

Das ist weder kaputt noch gegen irgendwelche Normalformen.

Anne Kaeppes schrieb:

> Claus Reibenstein wrote:
>
>> Es ergibt grundsätzlich keinen Sinn, mehrere Tabellen mit identischem
>> Aufbau zu benutzen. So etwas zeugt von kaputtem Datenbankdesign.
>
> Was heißt identischer Aufbau? Wenn ich die Beschreibung eines z.B.
> Artikels habe, kommen, sofern mehrsprachig mehrere Spalten nach
> folgendem Aufbau hinein:
>
> description_de_DE
> description_en_GB usw.

Ja, ok, ich habe falsch gelesen. Ich dachte, das wären einzelne Tabellen.

Aber auch einzelne Spalten - pro Sprache eine - ergibt irgendwie keinen
Sinn. Besser wäre hier _eine_ einzige sprachunabhängige Spalte für
_alle_ Texte und eine zweite Spalte für den Sprachcode.

> Warum sollte ich das nun in eine andere Tabelle mit 1:n auslagern?

Weil es besser ist.

Wie sieht z.B. ein SQL-Statement aus, das zu einem Artikel alle
Beschreibungen in allen Sprachen auswirft? Wie willst Du feststellen, in
welchen Sprachen passende Beschreibungen vorhanden sind? Wie willst Du
feststellen, welche Sprachen überhaupt vorhanden sind? Bei Deinem Aufbau
werden schon diese einfachen Abfragen unnötig kompliziert.

> Das ist weder kaputt noch gegen irgendwelche Normalformen.

Doch, es ist kaputt. Du schleppst bei Deinem Design zu jedem Artikel
immer alle Sprachfelder mit, auch wenn nur wenige Sprachen (im
Extremfall sogar nur eine einzige) besetzt sind. Das heißt, Du hast
unnötig viele Leerfelder.

..oO(Claus Reibenstein)

>Es ergibt grundsätzlich keinen Sinn, mehrere Tabellen mit identischem
>Aufbau zu benutzen. So etwas zeugt von kaputtem Datenbankdesign.

Kommt drauf an.

Ich habe bei mir durchaus Tabellen, welche mehrsprachige Informationen
enthalten, auf jeweils zwei Tabellen aufgeteilt. Tabelle 'Foo' enthält
dabei sämtliche sprachunabhängigen Informationen, ggf. Referenzen auf
Datensätze anderer Tabellen etc. Dazu kommt eine zweite Tabelle
'FooI18n' mit den sprachabhängigen Werten (dabei pro Sprache jeweils ein
Datensatz). Das Löschen eines Datensatzes aus 'Foo' löscht dabei auch
gleich die zugehörigen Werte aus 'FooI18n'.

Nun kommt eine zweite Tabelle 'Bar' für eine völlig andere Aufgabe
daher, aber ebenfalls mehrsprachig. Es kann dann durchaus vorkommen, daß
'FooI18n' und 'BarI18n' einen praktisch identischen Aufbau haben (abge-
sehen von den Fremdschlüsseln). Trotzdem ist diese Trennung notwendig.

Micha

..oO(Claus Reibenstein)

>Weil es besser ist.
>
>Wie sieht z.B. ein SQL-Statement aus, das zu einem Artikel alle
>Beschreibungen in allen Sprachen auswirft? Wie willst Du feststellen, in
>welchen Sprachen passende Beschreibungen vorhanden sind? Wie willst Du
>feststellen, welche Sprachen überhaupt vorhanden sind? Bei Deinem Aufbau
>werden schon diese einfachen Abfragen unnötig kompliziert.

ACK

Dazu käme, daß beim Hinzufügen einer Sprache die Tabellenstruktur selbst
geändert werden müßte, anstatt einfach nur die neuen Daten einzutragen.

Micha

Anne Kaeppes wrote:
> Niels Braczek wrote:
>> Das DB-Design ist kaputt.
>
> Das Design ist an sich völlig in Ordnung. Gegen welche Datenbank-Design
> Regel sollte sowas verstoßen?

U.a. gegen eine Grundlegende. Nennt sich Normalisierung:
http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)

MfG, Ulf

Hier noch ein Vorschlag:



$lang = array(
de => array(
monday=> "Montag",
),
en => array(
monday=> "monday",
),
);



$tr = $lang['de'];

echo "Heute ist: " . $tr['monday'];



Werner Partner schrieb:
> Ich suche nach einer _einfachen_ Möglichkeit, Mehraprachigkeit zu
> realisieren.
>
> Momentan mache ich das so, dass ich bei umfangreicheren Texten einfach
> verschiedene Dateien vorhalte, z.B.
>
> index.de
> index.fi
>
> usw.
>
> Bei einzelnen Wörtern habe ichd as so gelöst, dass ich if-Kaskaden habe,
> in denen verschiedene Wörter zugewiesen werden, z.B.
>
> if (lang=="fi") {
> $montag = "Maanantai";
> } else {
> [...]
> } else $montag = "Montag";
>
> Aber das ist alles sehr uneinheitlich
>
> Möglich wäre natürlich eine ascii-Datei in diesem Stil
>
> montag|de|Montag|fi|Maanantai|nl|Maandag|x|Montag
>
> wobei "x" eben der not found-Fall ist.
>
>
> Aber es ist ja auch nicht sinnvoll, bei jedem Zugriff auf die Datei
> zuzugreifen
>
> $montag = getword ($lang, "montag");
>
> Oder geht der Zugriff so schnell, dass es unerheblich ist?
>
> Eine Möglichkeit wäre natürlich, die ganze Datei in eine globale Tabelle
> einzulesen und auf die dann zuzugreifen.
>
> Gibt's noch andere Möglichkeiten, die einfach und leicht beherrschbar sind.
>
> SQLite wäre wohl noch eine Möglichkeit, aber da ist wohl die Pflege per
> Frontend nicht so dolle. Und MySQL möchte ich definiti dafür nciht nehmen.
>
> Bis jetzt läuft's eigentlich ganz gut bei mir, aber ich möchte den
> Sprachzugriff vereinfachen und vereinheitlichen
>
> Vielen Dank
>
> Werner
>
>
>
>

> U.a. gegen eine Grundlegende. Nennt sich Normalisierung:
> http://de.wikipedia.org/wiki/Normalisierung_(Datenbank)
>
> MfG, Ulf

Hmm, mal angenommen, sie füllt stets alle Felder aus, dann doch nicht
mehr? Dann sind drei Sprachspalten halt drei Attribute eines
Datensatzes. Ich werde es vermutlich bei einer Liste von Kategorien so
machen, dass es eine deutsche und eine englische Spalte gibt, weil die
immer 1:1 übersetzt werden.

Skaliert halt schlecht.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

Claus Reibenstein wrote:

> Ja, ok, ich habe falsch gelesen. Ich dachte, das wären einzelne Tabel=
len.
>
> Aber auch einzelne Spalten - pro Sprache eine - ergibt irgendwie keinen=

> Sinn. Besser wäre hier _eine_ einzige sprachunabhängige Spalte fü=
r
> _alle_ Texte und eine zweite Spalte für den Sprachcode.

Ja, diese Idee ist doch auch in Ordnung. Ich hätte nur das Problem mit =

den zwei Tabellen, die ich dann dafür benötige und pflegen müsste.

Bei sehr vielen Sprachenversionen könnte der Vorteil in "kleine"
Datensätze der Haupttabelle liegen. Das ist eine Ermessensfrage je nach=

Anforderung.

>>Warum sollte ich das nun in eine andere Tabelle mit 1:n auslagern?
>
> Weil es besser ist.

Bezweifel ich ob es besser ist. S.o.

> Wie sieht z.B. ein SQL-Statement aus, das zu einem Artikel alle
> Beschreibungen in allen Sprachen auswirft?

Na gott lob laufe ich nicht mit einzelnen SQL-Statements durch die
Gegend sondern kapsel nochmal alles in einer Klasse darüber.

Die Beschreibungen werden einfach durch ein ->getdescription()
ausgelesen. Ein ->setlanguage({Sprachcode}) wählt die Sprache.

Ein AUswerfen alle Beschreibungen in allen Sprachen habe ich noch nie
benötigt. Wofür sollte das auch gut sein?

> Wie willst Du feststellen, in
> welchen Sprachen passende Beschreibungen vorhanden sind?

Obiges ->getdescription() liefert einen leeren Text. Aber auch eine
Abfrage, die ich noch nie brauchte. Wäre dem so, wird einmal eine Query=

gebastelt.

> Wie willst Du
> feststellen, welche Sprachen überhaupt vorhanden sind?

->getlanguages() führt eine Auflistung aller Sprachen. Die Sprachen
werden als Default-Werte aus der Datenbank beim Initialisieren des
Objekts gelesen.

> Bei Deinem Aufbau
> werden schon diese einfachen Abfragen unnötig kompliziert.

Das glaube ich kaum, es sei denn, du läufst nur mit nackten Queries
durch die Gegend und denkst nicht an Datenkapselung.

>>Das ist weder kaputt noch gegen irgendwelche Normalformen.
>
>
> Doch, es ist kaputt. Du schleppst bei Deinem Design zu jedem Artikel
> immer alle Sprachfelder mit, auch wenn nur wenige Sprachen (im
> Extremfall sogar nur eine einzige) besetzt sind. Das heißt, Du hast
> unnötig viele Leerfelder.

Nein, dann deklariere ich nur eine Sprache in der Datenbank und die
Sache ist erledigt und habe dann überhaupt keine Leerfelder. Platz fü=
r
20 Sprachen zu deklarieren um dann nur eine zu benutzen macht auch
keinen Sinn.

..oO(Anne Kaeppes)

>Ein AUswerfen alle Beschreibungen in allen Sprachen habe ich noch nie
>benötigt. Wofür sollte das auch gut sein?

Bei Beschreibungen vielleicht eher weniger, aber bei anderen Dingen wie
z.B. dem Titel eines Dokuments kann es durchaus mal erforderlich sein,
alle Sprachversionen abzufragen. Zum Beispiel wenn man auf einer Seite
Links zu allen anderen verfügbaren Sprachversionen anbieten will.

Micha

..oO(Stefan Braumeister)

>Hier noch ein Vorschlag:
>
>$lang = array(
> de => array(
> monday=> "Montag",
> ),
> en => array(
> monday=> "monday",
> ),
>);

Solche Dinge lassen sich auch prima automatisiert ausgeben, vernünftige
locale-Unterstützung vorausgesetzt.

Micha

Anne Kaeppes schrieb:
> Niels Braczek wrote:
>> Anne Kaeppes schrieb:
>>
>>>Auch im Datenbank-Design kann das Einzug halten
>>>...
>>> description_de_DE varchar(100) ...
>>> description_en_GB varchar(100) ...
>>> description_... varchar(100)
>>
>> Das DB-Design ist kaputt.
>
> Das Design ist an sich völlig in Ordnung. Gegen welche Datenbank-Desi=
gn
> Regel sollte sowas verstoßen?

Der Fehler ist so grob, dass dieser Fall von den Normalformen, wie sie
bei Wikipedia aufgeführt sind, nicht erfasst wird. Da er aber
grundlegender ist als ein Verstoß gegen die 1. Normalform, müsste das=

also ein Verstoß gegen die 0. Normalform sein. Wenn mehrere Spalten
logisch gleiche Information (description) enthalten und der Spaltenname
für den Zugriff dynamisch hergeleitet werden muss, ist das DB-Design
definitiv kaputt.
Dein Ansatz ist praktisch gleichwertig mit (um bei dem CD-Beispiel der
Wikipedia-Seite zu bleiben)
CD_ID Albumtitel Interpret Track1 Track2 Track3
4811 Not That Kind Anastacia Not That Kind I'm Outta Love ...

Spätestens hier solltest du das selbst erkennen können.

> Ich ändere meine Tabellenstrukturen in der Regel sehr häufig.

Dann machst du in der Regel etwas falsch.

> Eigentlich ist alles darum herum so programmiert, dass die =C4nderung i=
n
> der Tabellenstruktur keinerlei weitere Massnahmen erforderlich macht.

Das ist in diesem Falle unerheblich. Damit hast du eine Lösung gefunden=
,
deinen Fehler zu kompensieren.

> Vielleicht würde ich bei 100 verschiedenen Sprachen, das ganze Design=

> anders gestalten, jedoch habe ich noch keine Anwendung erstellt, die
> mehr als 4 Sprachen hatte.

Ich schon. Einschließlich Arabisch und Urdu. Außerdem haben meine
Anwendungen dank eines orderntlichen Designs keine Einschränkung in
Hinblick auf die Anzahl der Sprachen.

MfG
Niels

--
| http://www.kolleg.de =B7 Das Portal der Kollegs in Deutschland |
| http://www.bsds.de =B7 BSDS Braczek Software- und DatenSysteme |
| Webdesign =B7 Webhosting =B7 e-Commerce =B7 Joomla! Content Management =
|
------------------------------------------------------------ ------

Anne Kaeppes schrieb:
> Claus Reibenstein wrote:
>
>>> Wo sollte das Problem deiner Meinung nach sein? Ich sehe ehrlich gesa=
gt
>>> keins.
>>
>> Es ergibt grundsätzlich keinen Sinn, mehrere Tabellen mit identische=
m
>> Aufbau zu benutzen. So etwas zeugt von kaputtem Datenbankdesign.
>
> Was heißt identischer Aufbau? Wenn ich die Beschreibung eines z.B.
> Artikels habe, kommen, sofern mehrsprachig mehrere Spalten nach
> folgendem Aufbau hinein:
>
> description_de_DE
> description_en_GB usw.
>
> Warum sollte ich das nun in eine andere Tabelle mit 1:n auslagern?
>
> Das ist weder kaputt noch gegen irgendwelche Normalformen.

Na ja, je nachdem wie man das Schema interpretiert, verletzt das sogar
ALLE Normalformen (nur die nullte nicht), und zwar weil die 1. NF sehr
lax oder sehr strikt ausgelegt werden kann. Verstößt die Tabelle gege=
n
die 1.NF, so verstößt sie auch gegen alle höheren Normalformen.

Die 1. NF sieht vor, dass alle Attribute atomar sein müssen. Bei der
Auflösung von nicht atomaren Attributen entstehende Wiederholgsgruppen
müssen in andere Relationen ausgelagert werden.

Bei laxer Auslegung der 1.NF darf man sogar eine Spalte "uebersetzungen"
haben und dort Einträge wie "de:Flughafen,en:airport" reinschreiben. De=
r
Datenbereich der Spalte ist dann halt "textuelle Liste von
=DCbersetzungen". Sowas wird dennoch immer wieder mal verwendet und das
kann sogar sinnvoll sein, nämlich wenn man eben diese Daten niemals
anders als zusammen braucht.

Hierzu ein Beispiel: Speichert man $_SESSION Arrays in einer Datenbank,
so ist es selten sinnvoll, das Array in seine Keys und Values
aufzuspalten und diese fein säuberlich in die Datenbank einzutragen.
Stattdessen schmeißt man einfach serialize($_SESSION) in eine Spalte un=
d
fertig.

Bei strikter Auslegung aber handelt es sich bei den zahlreichen
=DCbersetzungen um die oben genannten Wiederholungsgruppen mit
gleichartigen Informationen. Somit müssen sie in eine weitere Relation
ausgelagert werden.

Letztendlich geht es darum, von welchem Typ der Wertebereich der Spalten
mit den Namen "description_xx_YY" ist. Ist er bei allen "=DCbersetzung de=
s
Schlüssels in eine andere Sprache", so wird die 1. NF verletzt. Ist er
aber jeweils "=DCbersetzung des Schlüssels in die Sprache xx_YY", so is=
t
die Tabelle in 1. NF. Nach kurzem Nachdenken kommt man dazu, dass der
Typ wohl "=DCbersetzung" ist, denn auf der PHP-Seite behandelt man die
Rückgaben schließlich alle identisch.

Bei der Normalisierung würde ich persönlich immer im Zweifel gegen de=
n
Angeklagten entscheiden: Kann man etwas logisch bei gleicher Funktion
weiter zerlegen, so sollte man es tun. Findet man das Ergebnis im
Einzelfall unpraktisch, kann man immer noch einen View erstellen. Aber
ich zweifle stark an, dass das passieren wird...

OLLi

--
My hands - they can touch anything but themselves -- No, wait!
[Futurama]

Hallo, Oliver,

Du (oliver.graetz) meintest am 24.07.07:

> Bei laxer Auslegung der 1.NF darf man sogar eine Spalte
> "uebersetzungen" haben und dort Einträge wie
> "de:Flughafen,en:airport" reinschreiben. Der Datenbereich der Spalte
> ist dann halt "textuelle Liste von Übersetzungen". Sowas wird dennoch
> immer wieder mal verwendet und das kann sogar sinnvoll sein, nämlich
> wenn man eben diese Daten niemals anders als zusammen braucht.

Und irgendwann landet man bei "gettext" - eine pure Wortliste ist rasch
am Ende der Möglichkeiten.
Bei "gettext" wird jeweils der gesamte Text (also beispielsweise ein
Satz oder gar Absatz) übersetzt; da ist zwar viel Redundanz drin, aber
die Übersetzung kann erheblich verständlicher sein.

Viele Gruesse!
Helmut

On 24 Jul 2007 07:57:00 +0200 Helmut Hullen wrote:
> Und irgendwann landet man bei "gettext"

Spaetestens dann, wenn man sich mit Pluralbildung beschaeftigt :)

Servus,
Stefan

--
http://kontaktinser.at/ - die kostenlose Kontaktboerse fuer Oesterreich

Zäh und doch pfiffig?! Stefan - bevor du zum Chef mußt.
(Sloganizer)

Stefan Braumeister schrieb:
> Hier noch ein Vorschlag:
>
>
>
> $lang = array(
> de => array(
> monday=> "Montag",
> ),
> en => array(
> monday=> "monday",
> ),
> );
>
>
>
> $tr = $lang['de'];
>
> echo "Heute ist: " . $tr['monday'];
>

ich glaube, das ist für meine Zwecke di einfachste und eleganteste
Möglichkeit, dabei würde ich eine externe Wortliste anlegen.

Dann gibt es eine Klasse, z.B. c_getlang ($texte, $lang)

Dann gibt es eine Funktion getlang ($wort);

Der Klasse wird dann $texte mitgeteilt, und so ist das für kleine
Anwendungen universell.

Die oben beschriebene Arrayform (mit den Pfeilen) habe ich nie wirklich
verstanden (ich komme von C, und da ist das alles einfacher und
strenger), aber durch Abschreiben und Nachlesen werde ich wohl dahinter
kommen.

Grüße

Werner

--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de

Oliver Grätz wrote:

> Na ja, je nachdem wie man das Schema interpretiert, verletzt das sogar
> ALLE Normalformen (nur die nullte nicht), und zwar weil die 1. NF sehr
> lax oder sehr strikt ausgelegt werden kann. Verstößt die Tabelle ge=
gen
> die 1.NF, so verstößt sie auch gegen alle höheren Normalformen.
>
> Die 1. NF sieht vor, dass alle Attribute atomar sein müssen. Bei der
> Auflösung von nicht atomaren Attributen entstehende Wiederholgsgruppe=
n
> müssen in andere Relationen ausgelagert werden.

Wenn ich einen Artikel habe, der sowohl eine deutsche als auch eine
englische Beschreibung hat, frage ich mich jetzt im Ernst, wie Atomarer
eine Beschreibung denn noch sein muss. Es geht dabei ja nicht um
einzelne Vokabeln wie das angeführte Beispiel: de:Flughafen,en:airport =

sondern um ganze Beschreibungsblöcke, entweder als varchar(255) oder
gar Text.

Die Inhalte sind von Artikel zu Artikel eben nicht gleich, es handelt
sich bei diesem Design nicht um eine =DCbersetzungstabelle, sondern um
unterschiedliche Attribute zu einem Datensatz, eben die Beschreibung,
der Titel in unterschiedlichen Sprachen. Beschreibungen sind in der
Regel auch mehr als aus einem Satz bestehend.

> Dein Ansatz ist praktisch gleichwertig mit (um bei dem CD-Beispiel der
> Wikipedia-Seite zu bleiben)
> CD_ID Albumtitel Interpret Track1 Track2 Track3
> 4811 Not That Kind Anastacia Not That Kind I'm Outta Love ...
>
> Spätestens hier solltest du das selbst erkennen können.

Das ist jetzt doch etwas zu streng. Die Normalisierungsregeln sollten in
einem Kontext betrachtet werden. Dein Beispiel mit den Tracks ist
broken, weil das 1:n ist; eine CD kann unvorhersehbar viele Tracks haben.
Wenn hingegen die Anzahl der Tracks stets gleich wäre, wäre es nur ein
unnötiger Aufwand ohne Nutzen, da eine 1:n-Beziehung draus zu machen.

Die Sprachen sind ein Grenzfall. Ich habe auf meiner privaten Webseite
nur Deutsch & Englisch, weil meine Fremdsprachenkenntnisse danach rapide
abfallen. Also kann ich da durchaus dort, wo ich 1:1 übersetze, ein
derartiges Konstrukt nehmen. An anderen Stellen - z. b. bei Texten, bei
denen es rein englische, rein deutsche und beides gibt - nicht.

Auf einer anderen Webseite mit 6 Sprachen, deren Anzahl sich ändern
könnte, ebenfalls nicht.

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

> Die Inhalte sind von Artikel zu Artikel eben nicht gleich, es handelt
> sich bei diesem Design nicht um eine Übersetzungstabelle, sondern um
> unterschiedliche Attribute zu einem Datensatz, eben die Beschreibung,
> der Titel in unterschiedlichen Sprachen. Beschreibungen sind in der
> Regel auch mehr als aus einem Satz bestehend.

Liegt eigentlich jeder Artikel dann in allen Sprachen vor?

--
Mein Zeugs:
http://www.hadanite-marasek.de/classes.php
http://www.objektivsuche.de/

Niels Braczek wrote:

> Der Fehler ist so grob, dass dieser Fall von den Normalformen, wie sie
> bei Wikipedia aufgeführt sind, nicht erfasst wird. Da er aber
> grundlegender ist als ein Verstoß gegen die 1. Normalform, müsste d=
as
> also ein Verstoß gegen die 0. Normalform sein. Wenn mehrere Spalten
> logisch gleiche Information (description) enthalten und der Spaltenname=

> für den Zugriff dynamisch hergeleitet werden muss, ist das DB-Design
> definitiv kaputt.

Nun, das dynamische herleiten sehe ich nicht kritisch, denn irgendwo
muss die Sprachinformation herkommen, die ich aus der Datenbank holen
möchte.

> Dein Ansatz ist praktisch gleichwertig mit (um bei dem CD-Beispiel der
> Wikipedia-Seite zu bleiben)
> CD_ID Albumtitel Interpret Track1 Track2 Track3
> 4811 Not That Kind Anastacia Not That Kind I'm Outta Love ...

Nein, eben das nicht.

> Spätestens hier solltest du das selbst erkennen können.

Ich verwalte keine CDs, sondern unterschiedliche
Beschreibungen/Sprachvarianten für unterschiedliche Items. Die Inhalte =

sind zwar logisch ähnlich, aber inhaltlich völlig unterschiedlich. Da=
s
Problem würde da anfangen, wenn jemand nur "ein einziges mal" 20
Sprachen haben möchte und den Rest sich mit einer begnügt. Dann, aber=

nur dann würde ich den Bereich Sprache auskoppeln.

>>Ich ändere meine Tabellenstrukturen in der Regel sehr häufig.
>
>
> Dann machst du in der Regel etwas falsch.
>

Nein, ich entwickel fortlaufend, da passiert das hin und wieder. Zudem
habe ich riesige Datenbanken hier laufen. Da bleiben =C4nderungen nicht a=
us.

>>Eigentlich ist alles darum herum so programmiert, dass die =C4nderung i=
n
>>der Tabellenstruktur keinerlei weitere Massnahmen erforderlich macht.
>
> Das ist in diesem Falle unerheblich. Damit hast du eine Lösung gefund=
en,
> deinen Fehler zu kompensieren.

Wenn es denn ein Fehler ist. Das sehe ich nicht so. Aber du hast recht,
ein Grenzfall ist es schon. Das Prinzip hapert wirklich dann, wenn
obiges eintritt mit den 20 Sprachen eintritt.

>>Vielleicht würde ich bei 100 verschiedenen Sprachen, das ganze Design=

>>anders gestalten, jedoch habe ich noch keine Anwendung erstellt, die
>>mehr als 4 Sprachen hatte.
>
>
> Ich schon. Einschließlich Arabisch und Urdu. Außerdem haben meine
> Anwendungen dank eines orderntlichen Designs keine Einschränkung in
> Hinblick auf die Anzahl der Sprachen.

Einschränkungen hatte ich bisher auch noch nicht. ABer letztendlich
wären nur zwei =C4nderungen an den entsprechenden Klassen notwendig, ei=
n
Datentransport zwischen einer zu einer anderen Tabelle und schon hätte =

ich das Design angepasst.

Da ich jedoch nur diese Anzahl der Sprachen installiere, die der Kunde
nutzt, sehe ich zwar die gleichen Bedenken wie du, jedoch interpretiere
ich jede Sprachversion als Attribut und damit einzigartig und habe ein
in sich vernünftiges Design.

Hadanite Marasek wrote:
>>Die Inhalte sind von Artikel zu Artikel eben nicht gleich, es handelt
>>sich bei diesem Design nicht um eine =DCbersetzungstabelle, sondern um
>>unterschiedliche Attribute zu einem Datensatz, eben die Beschreibung,
>>der Titel in unterschiedlichen Sprachen. Beschreibungen sind in der
>>Regel auch mehr als aus einem Satz bestehend.
>
>
> Liegt eigentlich jeder Artikel dann in allen Sprachen vor?

Wenn Kunde sagt, er möchte die Artikel in Deutsch, Englisch, Franzöis=
ch
eingepflegt haben, dann ja. Nur Deutsch, dann nur Deutsch etc.

Mein Designfehler fängt dann an, wenn Kunde X sagt, er möchte von nur=

einen Bruchteil seiner Artikel in mehreren verschiedenen Sprachen
einpflegen, den Rest in nur einer. Dann wäre in jedem Fall 1:n besser, =

alleine nur wegen dem Oberhead in der Datenbank.

Aber diese Kunden hatte ich noch nicht, habe sogar erst einen Kunden,
der konsequent alle seine Artikel in 4 Sprachen einpflegt. Der Rest
begnügt sich mit deutsch und englisch.

Werner Partner schrieb:
> Ich suche nach einer _einfachen_ Möglichkeit, Mehraprachigkeit zu
> realisieren.
>

Vielen Dank für die vielen Vorschläge und Diskussionen

Ich hab's so gelöst:

/* -------------------------------------------------------

Klasse c_getlang

Versorgt unterschiedliche Sprachvarinaten

Parameter:
$lang: Sprache
$texte: Sprachdatei
------------------------------------------------------- */



class c_getlang {
var $lang;
var $texte;

function c_getlang ($lang, $texte) {
$this->lang = $lang;
$this->texte = $texte;
}

function getlang ($key) {
$text = isset($this->texte[$key][$this->lang]) ?
$this->texte[$key][$this->lang]
: $this->texte[$key][0];

return ($text);
}

--------------------------------------------------

Bei der Instanttierung werden Sprache und Sprachvariable mitgeteilt, die
Sprachvariable sieht so aus:

$texte = array ('kairos' => array ( 0 => 'Der richtige Zeitpunkt',
'fi' => 'oikea ajankohta',
'en' => 'the right moment',
'nl' => 'het juiste tijdstip',
'pl' => 'własciwy moment'),
'lchange' => array( 0 => 'Letzte Änderung',
'fi' => 'Viimeinen muutos',
'en' => 'Last change',
'nl' => 'Laatste verandering',
'pl' => 'ostatnie zmianay'));

Ich habe das Null-Element nach oben gechrieben, so dass neben dem Key
sofort der deutsche Begriff auftaucht. In einer englischen Umgebung wäre
das dann natürlich der englische Begriff usw.

Es ging recht schnell und muss jetzt nur auf breiter Ebene implementiert
werden.

Herzliche Grüße an alle Helfer
(evtl. gibt es ja noch was, was ich übersehen habe)

Werner



--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de

Werner Partner schrieb:
> Stefan Braumeister schrieb:
>> Hier noch ein Vorschlag:
>>
>>
>>
>> $lang = array(
>> de => array(
>> monday=> "Montag",
>> ),
>> en => array(
>> monday=> "monday",
>> ),
>> );
>>
>>
>>
>> $tr = $lang['de'];
>>
>> echo "Heute ist: " . $tr['monday'];
>>
>
> ich glaube, das ist für meine Zwecke di einfachste und eleganteste
> Möglichkeit, dabei würde ich eine externe Wortliste anlegen.
>
> Dann gibt es eine Klasse, z.B. c_getlang ($texte, $lang)
>
> Dann gibt es eine Funktion getlang ($wort);
>
> Der Klasse wird dann $texte mitgeteilt, und so ist das für kleine
> Anwendungen universell.
>
> Die oben beschriebene Arrayform (mit den Pfeilen) habe ich nie wirklich
> verstanden (ich komme von C, und da ist das alles einfacher und
> strenger), aber durch Abschreiben und Nachlesen werde ich wohl dahinter
> kommen.

Die Schreibweise benötigst du ja auch nicht unbedingt, wenn du so einen
"Hash" aufbauen willst. Denn du kannst das Array ja mittles array[key]=
value aufbauen oder array_push etc. verwenden. Meiner Meinung nach ist
sie aber leicht zu lesen:-)

Ich hab damals für jede Sprachvariante aus einer db die PHP Arrays
erzeugt, z.B. de_tranlation.php usw. die dann von PHP inkludiert wurden
im apc_cache landeten und danach nur noch aus dem Cache gelesen wurden,
was so ziemlich die Performanteste Variante sein dürfte.

Aber wie man sieht hat hier jeder seine eigenen Präferenzen und auch
andere Requirements.

>
> Grüße
>
> Werner
>

Stefan Braumeister schrieb:
> Werner Partner schrieb:
>> Stefan Braumeister schrieb:
>>> Hier noch ein Vorschlag:
>>>
>>>
>>>
>>> $lang = array(
>>> de => array(
>>> monday=> "Montag",
>>> ),
>>> en => array(
>>> monday=> "monday",
>>> ),
>>> );
>>>
>>>
>>>
>>> $tr = $lang['de'];
>>>
>>> echo "Heute ist: " . $tr['monday'];
>>>
>> ich glaube, das ist für meine Zwecke di einfachste und eleganteste
>> Möglichkeit, dabei würde ich eine externe Wortliste anlegen.
>>
>> Dann gibt es eine Klasse, z.B. c_getlang ($texte, $lang)
>>
>> Dann gibt es eine Funktion getlang ($wort);
>>
>> Der Klasse wird dann $texte mitgeteilt, und so ist das für kleine
>> Anwendungen universell.
>>
>> Die oben beschriebene Arrayform (mit den Pfeilen) habe ich nie wirklich
>> verstanden (ich komme von C, und da ist das alles einfacher und
>> strenger), aber durch Abschreiben und Nachlesen werde ich wohl dahinter
>> kommen.
>
> Die Schreibweise benötigst du ja auch nicht unbedingt, wenn du so einen
> "Hash" aufbauen willst. Denn du kannst das Array ja mittles array[key]=
> value aufbauen oder array_push etc. verwenden. Meiner Meinung nach ist
> sie aber leicht zu lesen:-)
>
> Ich hab damals für jede Sprachvariante aus einer db die PHP Arrays
> erzeugt, z.B. de_tranlation.php usw. die dann von PHP inkludiert wurden
> im apc_cache landeten und danach nur noch aus dem Cache gelesen wurden,
> was so ziemlich die Performanteste Variante sein dürfte.

Davon gehe ich aus!
Aber bei einer so kleine Datenbasis wie ich sie habe. dürfte das keine
Rolle spielen.

Mal kurz ne Frage, wenn ich z.B. einen sprachabhängigen Header erzeuge,
etwa in dieser Form

include ("gen_header.php")
gen_header ($lang);
include ("dic_" . $lang);

Dann müsste ja zuerst die Funktion gen_header() ablaufen, danach müsste
bei include ("dic_" . $lang) z.B. das dic_de bereits vorhanden sein.

Ist das so?

Grüße

Werner


--
--------------------------------------------------
Dorothee & Werner Partner, 45699 Herten
http://www.sonoptikon.de