projekt-sprachen - auswahl anstatt selbsteingabe, oder: lang-id inkl. festes internes sprach-kürzel ("DE",&qu |
Willkommen, Gast ( Anmelden | Registrierung ) [ Hilfe | Mitglieder | Suche ]
projekt-sprachen - auswahl anstatt selbsteingabe, oder: lang-id inkl. festes internes sprach-kürzel ("DE",&qu |
Mon. 10. July 2006, 10:13
Beitrag
#1
|
|
TRAIL AND ERROR SPECIALIST Gruppe: AdvancedMembers Beiträge: 1.708 Mitglied seit: 27.06.2006 Wohnort: Hansestadt Rostock, Deutschland Mitglieds-Nr.: 9 |
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 -------------------- cheers, Alex
|
|
|
Tue. 11. July 2006, 15:07
Beitrag
#2
|
|
Advanced Member Gruppe: Members Beiträge: 54 Mitglied seit: 26.06.2006 Wohnort: Karlsruhe Mitglieds-Nr.: 3 |
ZITAT 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. -------------------- Technikwürze - Design & Webstandards Podcast |
|
|
Tue. 11. July 2006, 15:19
Beitrag
#3
|
|
TRAIL AND ERROR SPECIALIST Gruppe: AdvancedMembers Beiträge: 1.708 Mitglied seit: 27.06.2006 Wohnort: Hansestadt Rostock, Deutschland Mitglieds-Nr.: 9 |
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. ... -------------------- cheers, Alex
|
|
|
Wed. 12. July 2006, 14:31
Beitrag
#4
|
|
Advanced Member Gruppe: Members Beiträge: 54 Mitglied seit: 26.06.2006 Wohnort: Karlsruhe Mitglieds-Nr.: 3 |
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 -------------------- Technikwürze - Design & Webstandards Podcast |
|
|
Wed. 12. July 2006, 20:52
Beitrag
#5
|
|
TRAIL AND ERROR SPECIALIST Gruppe: AdvancedMembers Beiträge: 1.708 Mitglied seit: 27.06.2006 Wohnort: Hansestadt Rostock, Deutschland Mitglieds-Nr.: 9 |
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 -------------------- cheers, Alex
|
|
|
Wed. 9. August 2006, 13:28
Beitrag
#6
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
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 |
|
|
Wed. 9. August 2006, 13:41
Beitrag
#7
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 853 Mitglied seit: 16.06.2006 Wohnort: Wien / Österreich Mitglieds-Nr.: 2 |
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. -------------------- SEFRENGO | a free choice ... again!
|
|
|
Wed. 9. August 2006, 13:50
Beitrag
#8
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
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 |
|
|
Wed. 9. August 2006, 14:00
Beitrag
#9
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 853 Mitglied seit: 16.06.2006 Wohnort: Wien / Österreich Mitglieds-Nr.: 2 |
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 ZITAT 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. -------------------- SEFRENGO | a free choice ... again!
|
|
|
Wed. 9. August 2006, 14:21
Beitrag
#10
|
|
Advanced Member Gruppe: AdvancedMembers Beiträge: 680 Mitglied seit: 09.08.2006 Wohnort: nähe Mainz Mitglieds-Nr.: 182 |
ZITAT 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 |
|
|
Vereinfachte Darstellung | Aktuelles Datum: 23.9.24 - 05:05 |