Weiterentwicklung i18n, l10n

[hrj]

Hallo timo und emergence,

Nach 3 Monaten bin zurück bei Contenido.
Diesmal möchte ich mit euch die Weiterentwicklung von i18n und l10n seriös besprechen.

Sorry für mein Deutsch, ist nicht meine Muttersprache.

Ich habe Contenido 4.5.0 alpha (CVS Version vom 16.04.2004) bei einem typischem slowakischem ISP erfolgreich installiert (d.h. safe_mode ist On und vielleicht noch weitere Beschränkungen sind eingeschaltet)

Frontend läuft problemlos zweisprachig SK / DE (iso-8859-2 / iso-8859-1).
Demo ist online
http://www.web-office.sk/contenido/cms/ ... ontent.php

Und jetzt meine Bemerkungen; Reihenfolge nach Priorität.
Ich versuche auch evtl. Lösungen vorschlagen.

1. no encoding set in backend
Dieses Thema wurde schon besprochen
http://www.contenido.de/forum/viewtopic.php?t=2583

Bild 1 - Editor bleibt in ISO-8859-1 - das ist der Fehler


Bild 2 - Man muss die Encoding manuel im Browser umschalten (central european ISO)


Bild 3 - Preview ist gut. Encoding wurde mit meta Tag definiert wie im Frontend.


Ich kann euch Login und Passwort ins mein Backend per PM schicken, damit ihr sieht dass dieses Problem Nummer 1 ist.

Lösung 1: jede html Template im Backend anpassen
Lösung 2: hack im class.template.php; vielleicht am Ende der Funktion generate().

2. Sprache mit encoding reicht nicht, man braucht Locale.
Locale für Formatieren von Datum, Zeit, Nummer und Währung.
(z.B. im Modul für eCommerce, oder Schnittstelle zu ERP, usw.)

Lösung: class.lang.php und DB Tabelle con_lang erweitern

3. Mehrsprachigkeit im Module
http://www.contenido.de/forum/viewtopic.php?t=2593

Timos Arbeit geht flott voran
I habe mir class.module.php angeschaut.
Kein Vorbehalt mehr.

4. Buttons im Backend
Freut mich sehr, dass anstatt "Speichern" kommt "Save".
Aber ich bin der Meinung, dass universelle Icons besser sind.

Wir (AP soft GmbH) interesieren uns um diese Erweiterungen und bieten euch aktive Mitarbeit (direkt Codierung im CVS, eine vollständige slowakische und tschechische Lokalisation, Testen, Support usw.)

MfG

Jozef Hribik

AP soft GmbH
http://www.apsoft.ch

[emergence]

Bild 3 - Preview ist gut. Encoding wurde mit meta Tag definiert wie im Frontend.

ad. 1 zur editor ansicht:
wenn ich das richtig im kopf habe befindet sich die metatag einbindung in der function conGenerateCode.
der teil der die metatags schlussendlich einbindet, sollte erstens als seperate funktion ausgegliedert werden...
und dann zweitens in der include_editcontent.php zusätzlich aufgerufen werden...
dann stimmt zumindestens mal das encoding beim editor und nicht nur in der vorschau.
ähm ich hab da ne frage dazu, wenn du auf Text HTML gehst (also in den SPAW) stimmt der zeichensatz dort ? wenn nicht müsste dort auch noch etwas gemacht werden...

2. Sprache mit encoding reicht nicht, man braucht Locale.
Locale für Formatieren von Datum, Zeit, Nummer und Währung.
Lösung: class.lang.php und DB Tabelle con_lang erweitern

ich bin mir jetzt nicht sicher aber kann dies über metatags oder ähnliches definiert werden ? wenn ja sollte dies bei der sprache des mandanten mit definierbar sein.

[hrj]

1. no encoding set in backend
Sorry aber es geht nicht nur um den Editor.
Kannst du dir vorstellen dass deine Installation komplett slowakisch wäre (GUI im backend, content und auch alle Attribute von Objekten)
Schau mal hier


2. Sprache mit encoding reicht nicht, man braucht Locale.

Ich möchte Locale im Contenido API haben. Nicht nur Texte sondern auch Locale sollte im Frontend automatisch mit changelang gewechselt werden (mit setlocale("sk_SK") ). z.B. Wenn ein Modul das Datum formatiert, soll es mittels strftime() machen. Ich muss wiederholen: Es geht nicht nur um Slowakei.
Ich brauche Locale auch für Schweiz. Schau dir http://www.php.net/manual/de/function.localeconv.php an und versuche mit setlocale(LC_ALL, "de_DE") und setlocale(LC_ALL, "de_CH") ein bisschen zu basteln. Siehst du schon den Unterschied ?

[emergence]

ähm das mit setlocale -> siehe
functions.i18n.php
function i18nInit an...
im backend müsste dies somit gemacht werden...
ich tippe darauf das im backend wirklich nur mehr der eintrag für den zeichensatz fehlt... und da bleib ich wieder bei class.template.php hängen..

im frontend hast du recht, da wird nirgendwo setlocale angewendet...
dort müsste dies bei edit site mitkonfigurierbar sein....

mal sehen was timo dazu meint...

[hrj]

mein Resümee

1. no encoding set in backend (Thema i18n)
die Regel im Backend: Encoding muss immer mittels meta tag gesetzt werden und muss der Definition der aktuellen ausgewählten "Site" entsprechen. Egal ob GUI im Backend deutsch, englisch oder chinesisch ist, encoding des Content hat grossere Priorität.

Mein Wünsch wäre: make Contenido compatible with all 8bit encodings used around Europe.

Bemerkung: ohne Unicode wird PHP nie ideal. Man kann momentan Unicode vergessen. Auch im PHP5 kommt keine Verbesserung. Ich kenne keinen ISP der standardmässig die mbstring Extension einschaltet.

2. Sprache mit encoding reicht nicht, man braucht Locale (Thema l10n)
seriöse Lösungen brauchen Locale !!!

[timo]

ganz so einfach ist das aber nicht: Man müßte bei einigen Seiten 2 Encodings angeben - einmal das Encoding für die aktuelle Sprache der Benutzerführung und ein Encoding für die Werte, die eingetragen werden...

Bisher gibt's da aber keine Lösung dafür...

[hrj]

Timo du hast Recht. Ich bin mir dieser Situation von Anfang bewusst.
Das macht Probleme auch in meinem Fall. Wenn mein Backend in SK ist ich editiere DE Content ich schalte im Browser die Encoding nach iso-8859-1 und meine SK "Sprache der Benutzerführung" ist zerstört. Aber "die Werte, die eingetragen werden" stimmen. Das ist das wichtigste.

Zweitens, ich kann immer die englische GUI nehmen. Ich vermute dass alle englische ASCII Zeichen bei allen 8bit ISO encodings auf gleicher Position sind. Mindestens im iso-8859-2 habe ich keine Probleme mit englischen Texte. Oder bin ich im Irrtum?

[hrj]

Also wenn Contenido bei ISO-8859-xy Familie bleibt, sollten alle EU Sprachen unterstützt werden und niemand sollte Probleme mit einem englischem Backend haben.

http://en.wikipedia.org/wiki/ISO_8859

Und drittens wollte ich sagen, dass vorgeschlagene Erweiterungen keine Auswirkung auf bestehende Contenido Websiten haben.
Ich glaube 99.9% von Websiten powered by Contenido sind west EU Länder.

Als Konsequenz dieser Feststellung kommt eine Frage. Warum habt ihr im Dropdown mit encodigs auch utf-8 oder euc-jp? (config.misc.php)

[hrj]

Hurra, Timo ist nicht taub

Du hast schon in CVS mit class Template und include.str_overview.php gebastelt. setEncoding() funktioniert super. Jetzt muss man alle Templates behandeln.

Eine dirty Idee: Template->generate() konnte selbst die $lang Variable aus $sess holen. Ich weiss, dass es gegen Architekturprinzipen geht aber man muss nicht alle Templates behandeln.

Noch immer keine Interesse an Mitarbeit?

[timo]

doch, aber im Moment bin ich nicht in der Firma. Ich melde mich die nächsten Tage!

[emergence]

ähm hab mir gerade den header angesehen der mit der ergänzung der zeile

Code: Alles auswählen

header("Content-Type: text/html; charset={$encoding[$lang]}");

in der front_content.php erzeugt wird.
der sieht bei mir so aus

Code: Alles auswählen

HTTP/1.1 200 OK
Date: Tue, 18 May 2004 08:50:05 GMT
Server: OpenSA/1.0.4 / Apache/1.3.27 (Win32) PHP/4.2.2 DAV/1.0.3
X-Powered-By: PHP/4.2.2
Expires: Tue, 18 May 2004 09:50:06 GMT
Last-Modified: Tue, 18 May 2004 08:50:06 GMT
Cache-Control: private, no-cache
Pragma: no-cache
ETag: 3a6018531231a6ecf745081a9797573f
Connection: close
Content-Type: text/html; charset=iso-8859-1

sollte das mit dem encoding nicht in die session.inc hineinwandern ?

[timo]

Ja, der Content-Type schaut doch okay aus?

Das in die Session reinzubasteln kannst du gerne machen, aber ich hab keine Ahnung, ob das funktioniert, da ich immer noch nicht ganz durchblicke, wie diese ganzen phpLib-Sachen genau funktionieren (sind einige sehr grobe Unschönheiten drin).

[emergence]

ja, Content-Type schaut richtig aus.
das einzige was ich nicht weiss ist ob der content-type vor dem Connection: close stehen soll. ne syntax definition wie http header auszusehen haben find ich leider nicht...

[timo]

Eigentlich nicht, denn das connection: close sagt, was nach dem Dokument passieren soll (persistent oder close, und bezieht sich nicht auf den Header). Von daher ist das schon ok so

[emergence]

okay dann stimmts eh...