Sprachkonzept: Fremdsprache wo hinterlegen?

[Kalle_B]

Hallöle,

ich halte das hier nicht für Doppelposting, weil es jetzt nicht darum geht, woher und in welcher Reihenfolge die Spreche(n) kommt/kommen.

Sondern: Im Projekt remso.eu kommen n Sprachen auf mich zu, auch noch in verschiedenen Codierungen (kyrillisch, griechisch).

Mein System sieht vor, dass jedes Programm eine *.htm Datei mit der entsprechenden Sprache hat, also das Startprogramm p590.php hat irgendwann
p590_de.htm
p590_en.htm
p590_nl.htm
p590_sv.htm
...

Bei zwei Sprachen bisher war das toll. Da konnte man in der jeweiligen Sprache kleine Aufsätze schreiben (etwa Hinweise zum Ausfüllen eines Formulars). Bei 3, 4 oder mehr Sprachen ist das doch nicht so lustig, weil Änderungen dann entsprechend häufig nachzuziehen sind.

Ich könnte programmweise damit beginnen, Vokabeln oder Sätze aus der Datenbank zu holen. Ist schon vorgesehen, um etwa Select- Boxen und Beschreibung der Events mehrsprachig zu haben. Beim Hinzufügen einer Eventart kann ich natürlich nicht einige dutzend *.htm Dateien ändern. Sondern nur einmal die neue Art in allen Sprachen.

Wer setzt die Mehrsprachigkeit per "Wörterbuch" um? Und welche Probleme ergeben sich da?

Wie bekommt man dann z.B. die diverse Schreibweise des Datums in den Griff? Und Texte, die nur für ein einziges Programm gebraucht werden, müssen dann auch in der DB verwaltet werden?

Bin dankbar für Tipps und Anregungen.

Kalle

[hotti]

hi,

Wie bekommt man dann z.B. die diverse Schreibweise des Datums in den Griff? Und Texte, die nur für ein einziges Programm gebraucht werden, müssen dann auch in der DB verwaltet werden?

Hierzu würde ich mit Templates/Platzhaltern arbeiten. Je nach Sprachauswahl wird z.B. der Platzhalter ##DATUM## mit dem passend formatierten Datum befüllt.

Bin dankbar für Tipps und Anregungen.

Utf-8 ;-)

Horst Fuel

[hotti]

h2,

Bin dankbar für Tipps und Anregungen.

Mach Deine Projektverwaltung objektorientiert. HTmL-Seiten als Objekte mit Eigenschaften. Eine der Eigenschaften ist lang. Weitere Eigenschaften:
 css
 lastmod
 Author
 Title
 descr
...

Horst Spitzbart

[Beat]

Wie bekommt man dann z.B. die diverse Schreibweise des Datums in den Griff? Und Texte, die nur für ein einziges Programm gebraucht werden, müssen dann auch in der DB verwaltet werden?

Indem man den Unterschied zwischen Übersetzung und Internationalisierung erkennt.
Sowenig ich SFr nach Dollars übersetze, nur weil ein Gast die englische Sprache wählt, so wenig werde ich das Datumsformat ändern. ich werde allenfalls die Wochentags und Monatsnamen anpassen.

mfg Beat

[Kalle_B]

Sowenig ich SFr nach Dollars übersetze, nur weil ein Gast die englische Sprache wählt, so wenig werde ich das Datumsformat ändern. ich werde allenfalls die Wochentags und Monatsnamen anpassen.

Unglückliches Beispiel. Sprache ist nicht gleich Land. Hier wird immer wieder gemeckert, wenn man die Sprachauswahl per Landesflaggen anbietet - zu recht.

Und Sprache ist nicht gleich Währung. Wieso Dollar und nicht Pfund in der en Version?

Das Thema Währung spricht für meine Version. Auf einer deutschsprachigen Seite würde ich Preise in EUR und zusätlich in umgerechnete SFr darstellen, aber eher nicht in Dollar.

Auf einer en Seite könnte dann die Umrechnung in Pfund und Dollar erscheinen.

Ich denke jetzt an schlichten Text, etwa die Zimmerpreise eines Hotels. Falls die Preise aus der Datenbank kommen, muss dort natürlich die Währungseinheit hinterlegt sein.

Gruß, Kalle

[Beat]

Das Thema Währung spricht für meine Version. Auf einer deutschsprachigen Seite würde ich Preise in EUR und zusätlich in umgerechnete SFr darstellen, aber eher nicht in Dollar.
Auf einer en Seite könnte dann die Umrechnung in Pfund und Dollar erscheinen.

Wenn du ein landesspezifisches Publikum anvisieren willst, ergo dessen Währung und sonstigen Masse, verwende eine diesbezügliche TLD.

Ich denke jetzt an schlichten Text, etwa die Zimmerpreise eines Hotels. Falls die Preise aus der Datenbank kommen, muss dort natürlich die Währungseinheit hinterlegt sein.

Du willst Metainformation über ein Feld mit diesem speichern, und nicht in Honolulu.

translate('Kosten pro Übernachtung: ### pro Person', '###', $value);

ich kann meinem Languagepack zum übersetzenden Teil einen Platzhalter, seine Definition, und die einzufügende Variable mitgeben.
Dadurch erspare ich mir die Fragmentierung von zu übersetzenden Sätzen.

mfg Beat

[Gunnar Bittersmann]

@@Beat:

nuqneH

so wenig werde ich das Datumsformat ändern.

Das hieße für alle Sprachen das internationale Datumsformat zu verwenden: 2010-01-13.

ich werde allenfalls die Wochentags und Monatsnamen anpassen.

Selbst dabei wird das Datum unterschiedlich formatiert: 13. Januar 2010 (mit Punkt) vs. 13 January 2010 (ohne Punkt).

AFAIK gilt es bei den ersten beiden Monaten des Jahres zwischen de-DE und de-AT zu unterscheiden.

Qapla'

[Der Martin]

Hallo,

Selbst dabei wird das Datum unterschiedlich formatiert: 13. Januar 2010 (mit Punkt) vs. 13 January 2010 (ohne Punkt).

wohl eher: January 13, 2010 (ohne Punkt, mit Komma).

AFAIK gilt es bei den ersten beiden Monaten des Jahres zwischen de-DE und de-AT zu unterscheiden.

Beim zweiten auch? Das kenne ich noch nicht.

Ciao,
 Martin

[Patrick Andrieu]

Hallo Der!

wohl eher: January 13, 2010 (ohne Punkt, mit Komma).

Fast genauso das meine ich das heute.

Viele Grüße aus Frankfurt/Main,
Patrick (ja, ok, Eigenwerbung - Eigentor - zumal ich die Formate mehr oder weniger aus Date::Calc her habe) ;)

[Der Martin]

Hallo,

Hallo Der!

okay, gelegentlich passiert's doch noch. ;-)

wohl eher: January 13, 2010 (ohne Punkt, mit Komma).
Fast genauso das meine ich das heute.

Wednesday, January 13th 2010

Das "th", das die Tageszahl als Ordnungszahl kennzeichnet, wird sowohl im Schriftlichen als auch zunehmend in der Umgangssprache weggelassen. Das Weglassen des Kommas vor der Jahreszahl kommt mir aber eigenartig vor.

Ciao,
 Martin

[Patrick Andrieu]

Hallo Martin, ja Der!

Hallo Der!
okay, gelegentlich passiert's doch noch. ;-)

Ja, Du bereitest mir halt mehr Arbeit als all die anderen Einwortigen Usernamen ;)

Wednesday, January 13th 2010
Das "th", das die Tageszahl als Ordnungszahl kennzeichnet, wird sowohl im Schriftlichen als auch zunehmend in der Umgangssprache weggelassen. Das Weglassen des Kommas vor der Jahreszahl kommt mir aber eigenartig vor.

In der Methode  »date_to_text_en« (Ausgabe: Wed, 13 Jan 2010) ist das Orinalsuffix ja auch weg. Wie gesagt, ich habe mich an Date::Calc orientiert, und ich traue Steffen Beyer zu, dass er das »richtig« macht.

1&1 hat die Version 5.34 von Date::Calc, ich habe letztens mittels PPM (Perl Package Manager) auf die letzte Version upgedated, mir ist allerdings bei der Ausgabe nichts Neues aufgefallen: 1und1 hat noch Version 5.34.

|
Viele Grüße aus Frankfurt/Main,
Patrick

[alfie]

Hallo!

AFAIK gilt es bei den ersten beiden Monaten des Jahres zwischen de-DE und de-AT zu unterscheiden.

Beim zweiten auch? Das kenne ich noch nicht.

de-de (Januar), de-at (Jänner)
de-de (Februar), de-at (Feber) Wikipedia

Wobei Jänner in AT ausschließlich verwendet wird und Feber im Aussterben begriffen ist (manchmal noch auf Behörden-Formularen anzutreffen).

mfg Alfie

[Gunnar Bittersmann]

@@Kalle_B:

nuqneH

ich halte das hier nicht für Doppelposting

ACK.

auch noch in verschiedenen Codierungen (kyrillisch, griechisch).

Wenn du für verschiedene Schriften verschiedene Zeichencodierungen verwendest, machst du was falsch.

p590_de.htm
p590_en.htm
p590_nl.htm
p590_sv.htm

'.' anstatt '_' könnte Apache-Sprachvereinbarung vereinfachen.

Ich könnte programmweise damit beginnen, Vokabeln oder Sätze aus der Datenbank zu holen.

Datenbank muss hier nicht DBMS bedeuten. Ein Array in PHP täte es auch.

Wie bekommt man dann z.B. die diverse Schreibweise des Datums in den Griff?

Schwierig. Du müsstest dazu bspw. auch en-US und en-GB unterscheiden: 13/01/10 vs. 1/13/10. Für alle Sprachen bietet sich das internationale Datumsformat 2010-01-13 an.

Du könntest den Nutzer auch das ihm genehmen Datumsformat einstellen lassen (und in einem Cookie ablegen). Ebenso die bevorzuge Währung, falls du Euro in andere unrechnen willst (wozu es eines Webservices bedarf, der sie aktuellen Wechselkurse liefert).

Qapla'