projekt-sprachen - auswahl anstatt selbsteingabe, oder: lang-id inkl. festes internes sprach-kürzel ("DE",&qu Einstellungen

[amk]

ich weiss nicht ob's noch so ist ... jedenfalls bei der 1.2 bestand ja das problem, dass beim löschen einer sprache die entsprechenden sprach-id's nicht zurückgesetzt werden.

anfänglich
deutsch lang=1, english lang=2
ergab nach dem löschen und neuanlegen von english dann
deutsch lang=1, english lang=3

dies kann dann zu einem problem werden, wenn man seine module o.ä. mit einer entsprechenden ursprünglichen sprach-id-definitionen versehen hat.

ferner ist es zur multilingualen plugin/modulprogrammierung sehr schlecht, dass module nicht "wissen", mit welcher sprache sie gerade laufen, da jeder user unterschiedliche bezeichnungen für die einzelnen projekt-sprachen definieren können.

vielleicht wäre es daher überlegenswert, projekt-sprachen intern (neben der lang-id) auch mittels festen string-kürzeln ("DE" "EN" "FR") zu führen und die selbsteingabe der projektsprache gegen eine auswahlbox mit allen sprachen (wie bei "automatischen Standardsprache (Browserabhängig)") auszutauschen.

somit würde besagte auswahlbox bei "automatischen Standardsprache (Browserabhängig)" auch entfallen können und gegen eine simple checkbox (auto standardsprache ja/nein) ausgetauscht werden o.ä.

der sinn einer freien eingabe des sprachnamens bei den projekten ist mir ziemlich schleierhaft ...

Der Beitrag wurde von amk bearbeitet: Mon. 10. July 2006, 10:17

[Daniel]

der sinn einer freien eingabe des sprachnamens bei den projekten ist mir ziemlich schleierhaft ...

Also ich sehe da schon einen Sinn. Man kann ja auch durchaus mehrere Sprachen haben, die alle unter "Deutsch" fallen. Z.B. kann man seine Seite in "leichtes deutsch" (-> accessibility) übersetzen oder in Schwäbisch, Schweizerisch, ...

Aber der Sprache einen two-letter-code zu spendieren (oder noch besser die erweiterten, die mit einem Unterstrich abgetrennt noch eine Subsprache definieren - z.B. DE_de oder EN_us) finde ich eine gute Idee.

[amk]

Also ich sehe da schon einen Sinn. Man kann ja auch durchaus mehrere Sprachen haben, die alle unter "Deutsch" fallen. Z.B. kann man seine Seite in "leichtes deutsch" (-> accessibility) übersetzen oder in Schwäbisch, Schweizerisch, ...

Aber der Sprache einen two-letter-code zu spendieren (oder noch besser die erweiterten, die mit einem Unterstrich abgetrennt noch eine Subsprache definieren - z.B. DE_de oder EN_us) finde ich eine gute Idee.

alles kein problem ... deshalb gibt es ja dann DE_de und DE_ch usw. ...

[Daniel]

alles kein problem ... deshalb gibt es ja dann DE_de und DE_ch usw. ...

die Definition von diesem Format spricht von Sprache, Terretorium, Codierung (was bei uns ja immer UTF-8 wäre) und einem Modifier. Damit kann man denke ich alle Sprachen eindeutig kennzeichnen.

de_DE -> Deutsch für Deutschland
de_CH -> Deutsch für die Schweiz
de_DE@easy -> Leichtes Deutsch für Deutschland
de_DE@swabian -> Schwäbisch

Aber:
Eine Auswahlbox mit allen Sprachen, wie du sie in deinem ersten Post vorgeschlagen hast, wird es wohl nicht geben können. Zum einen wäre die Liste doch etwas sehr groß und mit frei definierten Modifier wie "easy" etc. ja gar nicht möglich.
Auch würde ich die Bennenung der Sprache immer dem Administrator überlassen - ob er das in Englisch in der Muttersprache in einem Dialekt oder sonstwie bennenen möchte, weiß ja kein Mensch

[amk]

ich denke es gilt hier die wahrscheinlichkeit abzuwägen - nicht mit eventualitäten zu spekulieren.

DE_de
DE_ch
DE_li
usw.

ist imo ausreichend. dialekt ist keine eigenständige sprache und gilt gesprochen und nicht geschrieben. falls websites irgendwann mal anfangen zu reden - sieht das natürlich ggf. anders aus - auch schwaben lernen in der schule hochdeutsch. wenn ich mich da irre - sorry ... also ich halte es für so unwahrscheinlich das es eine seite in schwäbischem deutsch und in hochdeutsch gibt / geben muss ... habe ich jedenfalls noch nie (seit 1997) im internet entdeckt soetwas.

es gab auf dem amiga mal ein programm das war in bayrischem deutsch und in hochdeutsch (schmarrn = fehler usw. *g*) - das war aber lediglich zum fun!

aber es gibt natürlich auch untergeangene sprachen wie z.b. plattdeutsch, die kein dialekt darstellen. wenn aber jemand so eine seite macht, dann macht er sie nur in dieser sprache aufgrund der zielgruppe, würde ich sagen.

es geht mir nur darum anstelle von zahlen (ID's) eben auch einen NICHT frei definierbaren sprachstring intern zur verfügung zu haben ... und ich finde es überflüssig immer die sprache einzutippen.

eine auswahlbox muss imo her ... meinetwegen noch ein zusätzliches eingabefeld für einen modifier und gut is!

Der Beitrag wurde von amk bearbeitet: Wed. 12. July 2006, 21:03

[MaZderMind]

Ich muss amk zustimmen, ich denke dass es schon wichtig ist die Sprachen in den Modulen erkennen zu können. Die Sprach-ID könnte dann im übrigen auch komplett wegfallen..., also dass die Links dann mit &lang=DE bzw. &lang=DE_de erstellt werden.

Gruß, Peter

[alexander]

der benutzer kann ja genau diesen iso 3166 code jetzt pro sprache vergeben. der steht auch bei jeder sprache in der cms_lang im feld iso_3166_code.

falls kein code definiert ist, weil er in den spracheinstellungen nicht vorgegeben muss man im modul halt eine standardsprache wählen bzw. diese auswahl konfigurierbar machen.

[MaZderMind]

Das Problem ist doch z.B. ein Gästebuch-Modul, bei dem die Texte wie "Eintrag Hinzufügen" etc. automatisch an die Sprache angepasst werden sollen. Wie soll das denn von statten gehen? Kann auch sein dass ich das Problem missverstehe ^^

Gruß, Peter

[alexander]

Ich muss amk zustimmen, ich denke dass es schon wichtig ist die Sprachen in den Modulen erkennen zu können.

genau diese info wird pro sprache jetzt gespeichert, wenn der benutzer diese in den spracheinstellungen hinterlegt. wie du darauf dann mit deinem modul reagierst ist dann deine sache

Das Problem ist doch z.B. ein Gästebuch-Modul, bei dem die Texte wie "Eintrag Hinzufügen" etc. automatisch an die Sprache angepasst werden sollen.

genau dass kannst du ja mit dem iso code bewerkstelligen (z.B. eigens Langfile laden, spracharrays anpassen etc).

Er wird aber auch wenn die beta2 mit dem neuen design fertig ist ein plugin geben, dass es erlaubt sprachabhängig platzhaltervariablen im frontend-output durch definierte inhalte zu ersetzten. damit kann fast jedes modul lokalisiert werden, ohne es umschreiben zu müssen. das spart auch etliche templates.

[MaZderMind]

genau diese info wird pro sprache jetzt gespeichert

Ohh sorry ich hatte nicht mitbekommen dass qwas zum Dedi-Verhalten geändert wurde.. Sorry ^^

Gruß, Peter