Benutzer Diskussion:Beatovich/Internationalisierung

Aus SELFHTML-Wiki
Wechseln zu: Navigation, Suche
Hinweis:
Eine Diskussionsseite dient dazu, Änderungen am Artikel zu besprechen. Allerdings werden diese Seiten in unserem Wiki erfahrungsgemäß nur von sehr wenigen Leuten besucht.
  • Deshalb sollten Diskussionen über den Artikel zum Thema „Internationalisierung“ besser im SELFHTML-Forum geführt werden.
  • Unter https://forum.selfhtml.org/self/new kannst du einen entsprechenden Beitrag erstellen.
  • Bitte hinterlasse einen entsprechenden Link auf dieser Diskussionsseite, wenn du einen Thread im Forum eröffnet hast.

Beachte den Unterschied zwischen Zeichensatz und Zeichenkodierung. „Ein Dokument darf nicht aus verschiedenen Zeichensätzen bestehen.“ Als Seitenersteller hat man keinen Einfluss auf den Zeichensatz, da ist generell Unicode festgelegt. Man kann lediglich eine Zeichenkodierung wählen. Mit anderen Worten: Jedes Dokument hat vollen Zugriff auf das gesamte Unicode-Spektrum. Und wenn Zeichen mit der gewählten Kodierung nicht darstellbar sind, kann man NCRs/Entitys verwenden. (Keine Frage, wenn man UTF-8 nehmen kann, sollte man das bevorzugt tun.)

hm ja, grober Lapsus. Natürlich lässt sich pro Dokument höchstens eine Kodierung übertragen/festlegen. --Beat 19:16, 26. Apr. 2010 (CEST)

„Bei Volltextsuche werden Stellen eventuell wegen der Maskierung nicht gefunden.“ Das halte ich für falsch, denn wenn ein Programm anhand des Quellcodes und nicht anhand des Nutztextes sucht, hat es ja schon mal mit den HTML-Tags und Script/Style-Inhalten eine Menge Probleme. Außerdem hätten sich in der Vergangenheit schon Massen beschwert, wenn sie Wörter mit &Uml;auten nicht hätten finden können. --dedlfix 18:45, 26. Apr. 2010 (CEST)

Naja, zum Beispiel in meinem CMS. Ich mache mir nicht die Mühe, In einem User-Text-Duplikat zu suchen. Statt dessen wende ich striptags an bevor ich im Text suche. Ich verzichte dabei auf die Rückkonvertierung von Html-Entities.
Aber es gibt sicher noch andere Gründe, warum von Entities im allgemeinen (aber nicht überall) abzuraten ist.--Beat 19:16, 26. Apr. 2010 (CEST)
Mit „deinem CMS“ hast du einen Spezialfall, der entsteht, wenn man das Problem nicht grundlegend löst. Warum dürfen Benutzer Entitys eingeben? Wie unterscheidest du, ob eine solche Entity-Zeichenfolge als Code oder Nutztext gemeint ist? Wie realisierst du, dass bei erlaubter Code-/Entity-Eingabe ein korrekt maskiertes Ergebnis entsteht? Wenn zum Beispiel   erlaubt ist, kann & nur falsch sein.
Fehlerhafte oder Programme mit nicht gelösten Problemen sollten jedenfalls nicht der Maßstab für die (Nicht-)Verwendung von bestimmten Dingen sein. --dedlfix 20:44, 26. Apr. 2010 (CEST)
Ich entscheide anhand des CMS-Datentyps. Dieser ist mit einigen klaren Ausnahmen HTML. Natürlich soll man keine kaputte Anwendung als Argument verwenden. Aber nimm ein System wie dieses WIKI, das in dieser Beziehung wirklich kaputt ist.
Wenn in einem CMS mehrere Autoren im Quelltext arbeiten, ist Konsistenz und Konsequenz von grosser Wichtigkeit. Gleichzeitig will man speditiv arbeiten. Von daher wäre hier UTF-8 und der weitgehende Verzicht auf HTML-Entities in meinen Augen ein besseres Beispiel, als jenes bezüglich der Suchfunktion.--Beat 21:16, 26. Apr. 2010 (CEST)

Übrigens, zum Thema Zeichenkodierung könntest du ja im Wesentlichen auf Zeichencodierung und Doku:Grundlagen/Praxisnah/Zeichenkodierung und geschriebene Sprache verweisen und nur noch herausstreichen, was speziell die i18n für Vorteile aus Unicode/UTF-8 ziehen kann. --dedlfix 22:46, 26. Apr. 2010 (CEST)

Genauer: Ich muss die Aspekte ansprechen, die Zeichenkodierung und Internationalisierung verbinden. Aber Links zu weiterführenden Artikeln werden gewiss gesetzt.
Es soll ein Grundlagenartikel werden, das heisst, Übersicht über das Thema liefern und nur vorausschauend ein paar konkrete Beispiele nennen.
Wir haben Technologiereferenzen. Im zweiten Teil der Grundlagen-Artikel haben wir auch eine Art Referenz, ähnlich der Cheat-sheats der Best-Practices.
--Beat 22:54, 26. Apr. 2010 (CEST)

offene Fragen

Silbentrennung.

  • Silbentrennung ist in HTML nur händisch zu erreichen, entweder über ­ oder über das Unicode-Zeichen für den bedingten Bindestrich. Wegen der Problematik von unsichtbaren Zeichen in Formularen ist hier ­ wohl angesagt.
  • Bei automatisierten Tools:
    • Javascript: Silbentrennung ist ein Sprachfeature und damit abhängig von einem lang-Attribut bzw dem aktuellen Status der Sprache, wie sie im nächst höheren Parent-Element definiert wurde. Solche Tools sollte Silbentrennung nur in Rücksicht der Sprache ausführen. Hierbei ist wohl die Silbentrennung über die Unicode-Angabe angesagt.


http://www.w3.org/International/articles/idn-and-iri/ Various document formats and specifications already support IRIs. Examples include HTML 4.0, Das ist Neuland für mich. Meines Wissens muss ich in HTML immer noch URIs definieren. Ich habe keine Gewähr, dass Browser die IRI->URI Konversion übernehmen, bevor sie eine Ressource navigieren. Hier würde ich wirklich gern mehr über die verbreitete Praxis, nicht die Theorie, erfahren.--Beat 21:41, 26. Apr. 2010 (CEST)

HTML/ XHTML

Bei den HTML-Schnippseln im Artikel wäre ein Hinweis auf das xml:lang-Attribut denke ich mal nicht verkehrt, gerade Anfänger, die direkt mit XHTML anfangen, werden dass nicht wissen.

Welchen Hinweis soll ich anbringen? XHTML als HTML -> lang Attribut, XHTML als XML -> xml:lang Attribut? Im Zwei-fels-fall beides?--Beat 16:36, 21. Mai 2010 (CEST)
Idealerweise wohl Beides, 
<span xml:lang="de" lang="de">wai</span>
Ich meine der Gunnar hatte mich mal darauf hingewiesen, dass das folgende Schema Dokumentweit durchgezogen werden sollte
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="de" lang="de">

PHP: Ermitteln der Sprache des Browsers

Und als ergänzung für Weiterführende Links wäre noch folgender Artikel Empfehlenswert: http://aktuell.de.selfhtml.org/artikel/php/httpsprache/

Ich habe den Artikel bereits referenziert. kann ihn aber unter weiterführendes ein zweites Mal aufführen.--Beat 16:32, 21. Mai 2010 (CEST)
Hatte ich nicht gesehen; aber, wo wir schon bei diesem Artikel sind, wann landet der Artikel hier im Wiki, gibt es einen Plan, wie ihr hier vorgeht? Ich konnte aus Zeitlichen gründen die Diskussionen bzgl. des Wikis nicht verfolgen.
Wenn Ich neue Seiten erstelle, für die es in Selfhtml 8.12 noch keine Vorlage gibt, oder wenn ich Seiten aus 8.12 anders Strukturiere (Beispiel hypertext) dann erstelle ich den Artikel in meinem Namensraum. Für das Einstellen in die Doku:Grundlagen gibt es derzeit noch ein paar offene Fragen. Ziemlich viele Seiten müssen dort noch verschoben werden, um schöne Level zu erhalten.--Beat 01:04, 22. Mai 2010 (CEST)
Da ist jedenfalls eine potentielle Fehlerquelle in Zeile 6; ich habe es bei mir mit folgender ergänzung gelöst
/* 
  HTTP_ACCEPT_LANGUAGE kann Leer sein (bspw. der W3C-Validator), daher muss es auf vorhanden sein geprüft werden 

  06  $lang_variable = $_SERVER['HTTP_ACCEPT_LANGUAGE']; 
*/
$lang_variable = (isset($_SERVER['HTTP_ACCEPT_LANGUAGE']))
               ? $_SERVER['HTTP_ACCEPT_LANGUAGE'] 
               : null ;
Apache Content-Negotiation
ich frage mich, welche Rolle CN in Apache spielt, da der Nutzen ja nur, gring ist, so man bedenkt, dass eine einmalige aktive Sprachwahl des Users zu bevorzugen ist.
Mögliche Anwendung: Sprachunspezifische index.html
Für die automatische Sprachwahl auf der Startseite (generische URL) verwende ich idR. typemaps, die Adressen selbst sind dann aber idR. sprechend, somit hat auf den Unterseiten eine generische Version ohne Sprache wenig Sinn. --Suit 11:02, 20. Mai 2010 (CEST)
Ich habe http://httpd.apache.org/docs/2.0/content-negotiation.html vor Augen.
Welches ist der sinnvollste Weg unter Annahme, dass Content-Negotiation nur betrieben werden sollen auf http://example.org/someressource nicht aber auf http://example.org/de/someressource ?
Wird hier die typemap in httproot abgelegt? Sind Unterordner ebenfalls betroffen?
Beat 18:27, 9. Jan. 2011 (CET)

Sprachen & Flaggen

Den Abschnitt "Warum Sprachen nichts mit Länderflaggen zu tun haben" finde ich in dieser Form etwas einseitig. Ich finde es okay, auf die Probleme hinzuweisen, so wie du es tust, aber man sollte nicht suggerieren, dass die Verwendung von Flaggen für Sprachen ein "Irrtum", also grundsätzlich immer falsch sei.

"Die Schweiz hat 4, Südafrika hat 11, Indien gar 23 Amtssprachen." - Und? Deswegen nimmt man diese Flaggen normalerweise ja auch nicht, um Sprachen auf Webseiten zu kennzeichnen!

"Englisch ist die de-facto Amtssprache im Vereinigten Königreich und den USA, jedoch in beiden Staaten keine offiziell festgelegte Amtssprache." - Ja, aber die Anwender haben sich inzwischen an diese Verwendung der Flaggen gewöhnt.

"Flaggen werden zuweilen obsolet und abgelöst durch andere Flaggen." - Und? Kommt zum einen selten vor, und ist auch nur relevant, wenn das die Sprachen betrifft, die auf meiner Site vorkommen.

"In welchem Land wird Latein oder Esperanto gesprochen?" - Was kümmert's mich, wenn ich meine Site auf Deutsch und Englisch anbiete? Übrigens: Esperanto hat eine eigene Flagge. Aber das nur nebenbei.

Und überhaupt: Was schlägst du als Alternative zu den Flaggen vor? Ein Menü mit "Deutsch", "English", "Espanol" usw.? Okay, aber ganz ehrlich: Da finde ich die Flaggen hübscher, seien sie auch noch so inkonsistent!

Wie gesagt, deine Einwände finde ich völlig in Ordnung. Ich finde nur, man sollte die Grundaussage etwas entschärfen. --MathiasB 11:32, 13. Mai 2010 (CEST)

Schneidet es dich, dann ist es OK! Du kannst ja zu deiner Entscheidung stehen, aber die Tatsache bleibt, dass du damit eher deine Gäste irreführst.
BTW. Ich habe auch eine Site, in der ich Flaggen verwende. ich werde das aber irgendwann ändern.
BTW2. Ich arbeite derzeit am CMS an der Internationalisierung. Im Hinblick auf eine Software, die man an andere aushändigt, darf man solche Irrtümer nicht begehen.--Beat 11:48, 13. Mai 2010 (CEST)
Auch ich verwende of (ergänzend) Flaggen, aber nicht weil ich das gut finde, sondern weil es die Kunden so wollen. Nur eine Flagge allein bedeutet garnichts, wieviele US-Amerikaner kennen wohl die Flagge des vereinigten Königreichs? Wenn man davon ausgeht, dass 20 % der US-Amerikaner ihr eigenes Land auf einer politischen Karte finden können, gehe ich davon aus, dass es wenige sind. Also warum potentielle Kunden/Gäste ausschließen?
Ich empfehle meinen Kunden _immer_ die Sprache ausgeschrieben zu verwenden und wenn es unbedingt sein muss, dann eine Flagge dazu - aber niemals ausschließlich die Flagge zu verwenden. Es gibt nur sehr wenige Kunden die nur die Flagge haben wollen, die meisten sehen ein, dass es sinnvoll ist, den Sprachnamen auszuschreiben, wollen aber auf die "hübsche" Flagge nicht verzichten.
"Weil es hübsch ist", ist aber dennoch keine fundierte Argumentation für deine (technische) Dokumentation. Flaggen sich schlichtweg Unsinn, darum steht das auch so im Artikel. Wenn es jemand anders machen möchte, kann er das aber - es verbietet ja niemand. Genausowenig ist man nach lesen einer selfhtml-Dokmentationsseite gezwungen, immer validen Code zu schreiben es nicht zu tun meistens unsinnig ist ;) --Suit 11:09, 20. Mai 2010 (CEST)

Referenzen

Testseite (meiner Ansicht nach aber mit falschen/ungültigen Tests)

right-to-left Schriften (arabisch, persisch)

Es fehlt noch die Behandlung des Themas von rtl-Schriftsystemen.

  • Muss ich das Design spiegeln?
  • Schwierigkeiten selbst bei copy&paste von rtl-Glyphen in einen ltr-Quelltext

--Suit 17:57, 8. Jun. 2010 (CEST)

Abgerufen von „http://wiki.selfhtml.org/index.php?title=Benutzer_Diskussion:Beatovich/Internationalisierung&oldid=61880“