Wikiup Diskussion:Archiv/Umstellung auf Unicode/Archiv

aus Wikipedia, der freien Enzyklopädie

Diskussion über das Ob

also, ich fände eine Umstellung gut - sie wird eh kommen, warum also nicht jetzt? Und natürlich trifft es einige (mich auch, ich kann eines meiner älteren Stücke nicht mehr einsetzen, aber mit dem macht es eh keinen Spaß mehr im www zu surfen). Wenn die Wikipedia einen halben Tag (bz.w eine halbe Nacht) offline ist, sollte das zu verkraften sein - eine Hinweisseite, die solange alternativ erscheint, wäre allerdings sehr gut! -- Schusch 00:38, 22. Mär 2004 (CET)

  • Auch ich warte seit langem sehnsüchtig auf die Umstellung, damit endlich auch rumänische und polnische Artikelnamen möglich werden. Stern 00:43, 22. Mär 2004 (CET)
    • yep, me wartet auch schon lange auf problemlose tschechische artikelnamen. southpark 00:58, 22. Mär 2004 (CET)
      • ich sehe nur ein problem mit tschechische artikelnamen: sofern es keinen 'akzentfreien' redirect gibt, machen sie den 'Los'-Knopf ziemlich unbrauchbar, wenn man sich die akzente nicht perfekt genau merken kann. -- D 13:45, 26. Mär 2004 (CET)
        • Die Artikelnamen ohne Sonderzeichen, die einen Redirect enthalten, wird es natürlich acuh weiterhin immer geben. -- Hagbard 01:37, 5. Jun 2004 (CEST)

Eine Umstellung auf utf-8 kann ich auch nur mit Nachdruck unterstützen. Diese Zeichenkodierung stellt meiner Meinung nach insbesondere bei der Kodierung von Texten in überwiegend mitteleuropäischen Sprachen den besten Kompromiss aus Flexibilität, Zukunftssicherheit, Effiziens und Portierbarkeit/Kompatibilität dar.

P.S. Anmerkung zum geäußerten Kritikpunkt zur Auffindbarkeitn von Artikeln: Dass ein Gebrauch von Sonderzeichen in Artikelnamen die Artikelsuche erschwert hat eigentlich nichts mit der verwendeten Zeichenkodierung zu tun, denn dies ist ja auch bei ISO-8859-1 für viele Sonderzeichen schon möglich: durch automatischens URI-Encoding (wenn man mal von der Verwendung von Entitäten absieht). Dem Problem der Auffindbarkeit von Artikeln mit nicht-deutschnen Sonderzeichen (z.B. diakritischen Zeichen) im Titel wird ja auch jetzt schon durch Redirects mit deutschen Transkriptionen gelöst. --SteffenB 15:19, 26. Mär 2004 (CET)

  • ich frage mich, ob man dafür nicht einen automatismus schaffen könnte - google macht das mit seinem

'meinten sie...' gar nicht schlecht. -- D 19:33, 26. Mär 2004 (CET)

Browserfalle

Man könnte zusätzlich zu #1 auch auf jeder Bearbeiten-Seite ein "Falle" für Nicht-Unicode-fähige Browser einbauen. Das heißt, man setzt irgendwo ein verstecktes Feld, das einige spezielle Unicode-Zeichen enthält. Kommen diese nicht richtig an, wird der geänderte Text nicht angenommen und der User-Agent-String in der Datenbank vermerkt. -- 3247 00:56, 22. Mär 2004 (CET)

Das Problem ist wohl angeblich auch, dass einige Browser Unicode zwar richtig lesen, aber nicht richtig schreiben können (weiß nichts genaueres darüber, ich glaube, Brion hat so etwas mal im Chat erwähnt). Absolut nötig wäre jedenfalls ein ausführlicher Test, für den wir z. B. einige Unicode-Zeichen auswählen (das ' scheint z. B. auf MacOS 9 / IE 5 Probleme zu machen) und diesen mit verschiedenen Browsern auf der französischen Spielwiese zu schreiben und zu lesen. Vorher sollten wir aber unbedingt bei den Unicode-Wikipedias nachfragen, in welcher Form sich die Probleme auftreten, etwa um die Zeichen auszuwählen. --Head 01:09, 22. Mär 2004 (CET)
Können wir nicht ein paar Seiten als Unicode- Spielweise einrichten? Und sei es, dass interessierte auf einem bereits umgestellten Wikipedia einen "Benutzer:Unicode" einrichten und unter "Benutzer:Unicode/Test1" (und so weiter) spaßeshalber ein paar Artikel schreiben und in einer Diskussion ihre Probleme beschreiben? Ansonsten denke ich, die Umstellung wird auf jeden Fall kommen, also solten wir auf der Hauptseite schon mal eine Ankündigung aufnehmen, ggf. mit Auflistung der Browser, die beizeiten Ersetzt werden sollten, um Wikipedia-Kompatibilität zu gewährleisten.-- RainerBi 07:34, 22. Mär 2004 (CET)
Als Spielwiese könnt ihr diese Unterseite meiner Benutzerseite auf fr: benutzen: fr:Utilisateur:Head/Unicode-Test --Head 16:11, 22. Mär 2004 (CET)
stellt mit mozilla 1.6 unter linux lauter hybsche zeichen dar - aber ob's auch die richtigen sind? -- D 23:40, 22. Mär 2004 (CET)
Ich habe Head schon gebeten, auf der Seite dazuzuschreiben, welche Zeichen man sehen soll. Wird er bestimmt bald machen. --DaB. 23:51, 22. Mär 2004 (CET)
sinnvoll wäre vielleicht auch, einfach mal eine seite zu editieren und wieder zu speichern - dann sieht man, ob der browser nur kaputte zeichen darstellt, oder auch kaputt speichert. -- D 00:24, 23. Mär 2004 (CET)
Ich finde Beta-Versionen müssen nicht unbedingt in die Tabelle aufgenommen werden. Was Mozilla 1.6 konnte wird Mozilla 1.7 ohne b vermutlich auch können. Das Problem mit der Lautschrift beim IE ([ʃɪˈkaːɡəʊ]) besteht auch beim Längezeichen (Hora̱̲z), wie man es aus diversen Lexika kennt. Wie kann man sicherstellen, dass nicht ein unbedarfter IE-Nutzer, dem Mark Anton sein Längezeichen klaut, weil er das für Kästchenmüll hält? Könnte man vielleicht für IE-Nutzer irgendwo einen kleinen Hinweis à la "Bitte nehmen Sie zur Kenntnis, dass nur das Einstellen einer Unicode-Schrift wie z.B. Arial Unicode MS oder Lucida Sans Unicode oder eines Browsers der Unicode besser unterstützt eine fehlerfreie Anzeige gewährleistet" anbringen; den User-Agent auswerten vielleicht, damit die Nutzer anderer Browser, die das auch so können, nicht genervt werden? --128.176.76.15 12:19, 23. Mär 2004 (CET)
Könnte man nicht den User-Agenten auswerten und dann nur für den IE eine eigene CSS-Datei erstellen, in der dann "Arial Unicode MS" und "Lucida Sans Unicode" festgelegt wird? --128.176.76.232 17:39, 23. Mär 2004 (CET)
oder einfach an den Anfang der Liste setzen (man kann bei CSS beliebig viele Schriften angeben, wovon die erste genutzt wird). Dann haben die anderen Browser halt diese Schrift auch - sollte keine Nachteile bringen, oder? TheK 20:24, 19. Mai 2004 (CEST)

Ich habe mal eine Vergleichsseite mit HTML-Entities erstellt, um beim Test die Probleme auszufiltern, die lediglich auf fehlende Fonts zurückzuführen sind. Der Test soll ja schließlich Aufschlüsse darüber geben, ob sich durch eine Umstellung auf UTF-8 etwas verschlechtern würde. --Head 16:19, 23. Mär 2004 (CET)

UTF-8, UTF-16 und UTF-32

Wenn ich das richtig verstanden habe, dann lassen sich mit UTF-16 und UTF-32 noch mehr Zeichen aus den wildesten Sprachen darstellen. (Richtig?) Warum stellen wir dann nicht gleich auf UTF-16 oder UTF-32 um? Gibt es da Browserprobleme? -- sk 09:39, 22. Mär 2004 (CET)

Nein, das ist nicht so. utf8, -16 und -32 sind verschiedene Kodierungen von Unicode. Sie stellen alle sämtliche Zeichen dar und sind austauschbar. Bei Buchstabenschriften ist die utf8-Kodierung kürzer, bei Bildschriften (CJK)) ist utf16 besser. utf32 ist immer am längsten, aber einfacher zu programmieren. Im Web wird nur utf8 verwendet. 195.93.72.17 10:50, 22. Mär 2004 (CET)
Besten Dank für die Aufklärung. Vielleicht kann ja mal ein Wissender die Artikel UTF-16 und UTF-32 anfangen! ;-) -- sk 11:14, 22. Mär 2004 (CET)
Wichtiger noch als die unterschiedliche Effizienz der unterschiedlichen UTF-Kodierungen ist deren unterschiedliche Kompatibilität (bzw. Protierbarkeit) mit (bzw. beim Übergang von) US-ASCII bzw. einer ISO-8859-Varianten:
  • Beim Übergang von den genannten 1-Byte-Kodierungen zu utf-8 bleiben alle Zeichne mit einer Ordnungszahl kleiner #127 unverändert, insbesondere also alle gewöhnlichen Buchstaben. Lediglich nicht-US-ASCII-Zeichen werden multibyte-kodiert. Deutscher Text, mit seinem hohen Anteil gewähnlicher Buchstaben, bleibt damit in utf-8-Kodierung auch auf einem System lesbar, das utf-8 nicht unterstützt („nur“ die Sonderzeichen erscheinen dann „verhunzt“)
  • Bei den beiden anderen UTF-Varianten werden alle Zeichen in mehreren Bytes kodiert. Ein System das diese Kodierung nicht unterstützt zeigt dann ausschließlich Müll an!
  • (Anmerkung: bitte nagelt mich jetzt nicht darauf fest, exakt ab welchen Zeichen bei utf-8 multibyte-kodiert wird. Auf jeden Fall jedoch oberhalb der gewöhnlichen Buchstaben, d.h. insbesondere deutsche Umlauten. werden 2-byte-kodiert.)--SteffenB 14:32, 24. Mär 2004 (CET)
UTF-8 hat eine dynamische Zeichenlänge von 8 bis 32 Bit. Vorteil für Zeichensätze, die zumindest zum Großteil auf ASCII aufbauen sind, dass man den Text auch ohne Unicode-fähigen Browser noch deuten kann und dass der Kram in der Datenbank viel kleiner wird, als wenn immer mindestens 16Bit benutzt werden. Bei meinem Absatz hier sind zwischen ASCII/ISO-8859-15 und UTF-8 7Byte Unterschied (in der Länge), bei UTF-16 wäre er doppelt so lang. TheK 19:24, 19. Mai 2004 (CEST)
Also UTF-7 wäre natürlich auch eine Möglichkeit. UTF-7 nützt nur 7bit pro byte. Wenn UTF-7 code als ASCII oder ISO-8859-. interpretiert wird, schaut es garnicht so schlecht aus. Beispiel: »Kübel«, in UTF-8, das als ISO-8859-1 interpretiert wird: Kübel, in UTF-7, das als ISO-8859-1 interpretiert wird: K+APw-bel. (Bei längeren Wörtern sieht UTF-7 besser aus: 日本語 wird zu 日本語 mit UTF-8 und zu +ZeVnLIqe- mit UTF-7. Das ist also sogar editierbar.) Allerdings befürchte ich, dass uns das bei den meinsten Browserproblemen nicht hilft, weil die Browser ohnehin die Kodierung erkennen, dann aber blödsinn machen. Auf der anderen Seite kann man bei UTF-8 wahrscheinlich alle Filter für Wikisyntax unverändert beibehalten, während man bei UTF-7 bei + und - aufpassen müsste. – Hokanomono|Diskussion 08:37, 20. Mai 2004 (CEST)
Eh, vergiss utf-7. Das ist nur sinnvoll, wenn der Zeichensalat 7bit-clean übertragen werden muss. Die Browser verstehen es nicht und es ist am Ende größer als utf-8. TheK 18:49, 2. Jun 2004 (CEST)

Noch was Anderes:
Ich werde gleich mal den utf-8-Test durchführen. Kann danach mal jemand mit installiertem arabischen und chinesischem Zeichensatz überprüfen, ob diese beiden multibyte-Zeichen noch korrekt angezeigt werden? Danke! :-) --SteffenB 14:32, 24. Mär 2004 (CET)


Vorschlag für Seitendarstellung nach Umstellung

  • Anzeige einer Seite:
Server wertet Browser-Request nach Accepted-Encoding aus und schickt die Seite entweder als UTF8 oder als 7bitASCII bei Umwandlung aller Codepoints > 126 in &#-Schreibweise.
das Problem existiert nicht. Außer iCab (kommt in freier Wildbahn nicht vor) und einigen älteren Netscape 4.0 (der eh schon an der Stanrtseite scheitert), kann jeder Browser UTF-8 spätestens nach einer Umstellung (lynx) anzeigen. TheK 22:43, 19. Mai 2004 (CEST)
  • Bearbeiten einer Seite:
    • Browser steht auf Positiv-Liste für UTF8: alles wie gehabt.
    • Browser steht auf Negativ-Liste für UTF8: Umwandlung aller Codepoints > 126 in &#-Schreibweise, Benutzereingaben werden als ISO8859-1 interpretiert, &#-Eingaben in UTF8 gewandelt
    • Browser-Verhalten unbekannt:
      • Benutzer ist IP-Nummer: Benutzer wird auf einer Hinweisseite über die Problematik informiert und gebeten, sich entweder anzumelden oder einen anderen Browser zu verwenden.
      • Angemeldeter Nutzer:
        • Bearbeiten eines Abschnitts, der nur Codepoints < 256 enthält: Umwandlung in ISO8859-1, Benutzereingaben werden als ISO8859-1 interpretiert, &#-Eingaben in UTF8 gewandelt
        • Andernfalls: Umleitung auf eine Test-Seite, wo der Nutzer Testeingaben machen kann. Das Ergebnis wird an die Devoloper geleitet, nach Eintragung des Browser in Pos- oder Neg-Liste wird der Nutzer informiert

Die Umwandlung ist unproblematisch, da HTML-Tags und Wiki-Tags immer aus ASCII-Zeichen < 127 bestehen.

° 15:22, 28. Mär 2004 (CEST)

Nun es kommt vor, dass Browser sich für andere Browser ausgeben weil deren Benutzer einige saublöd geschriebene Webseiten von Experten die keine Ahnung haben und keine Ahnung haben dass es noch andere Browser gibt besser lesen können wenn sie den Referer zu IE ändern. Ich würde also mit einer Liste vorsichtig sein. -- Schnargel 14:38, 7. Apr 2004 (CEST)

Hehe, hast recht, vielleicht geben sich ein paar IE als Galeon aus. ;-)
Bei "Browser-Verhalten unbekannt/Benutzer ist IP-Nummer" besser nicht empfehlen, einen anderen Browser zu verwenden, sondern ASCII mit &# verwenden. (oder Test-Seite) Hokanomono 10:35, 13. Apr 2004 (CEST)
stimmt. Man kann auch Pech haben und was nagelneues erwischen und dann ist der Spruch schlichtweg bescheuert. Ich würde aber den Standard für unbekannte Browser nach einer gewissen Zeit (2 Monate?) auf UTF-8 drehen - es werden kaum neue schlechte Browser hinzukommen. ;) TheK 22:43, 19. Mai 2004 (CEST)

Illegale Sonderzeichen (nicht-iso-8859-1)

Als nächstes müssen sämtliche Fehler in Artikeln gefunden und korrigiert werden, die von Windows verursacht wurden. Dabei dürfe es sich vor allem um deutsche Anführungszeichen, Eurozeichen und die OE-Ligatur Œ handeln.

(ach was, die lassen sich auch automatisch nach UTF-8 konvertieren) — Timwi 05:12, 22. Mär 2004 (CET)
bloß, dass diese nicht in Latin-1 existieren? Man müsste also wissen, dass da stattdessen "rohes" Windows-1252 verwendet wird. (So etwas führte z.B. auch zu Problem in Liste tschechischer Bezeichnungen von Orten im deutschen Sprachraum, wo s/S und z/Z mit Hacek im Original verwendet wurden und bei Änderungen gelegentlich durch Fragezeichen ersetzt wurden, weil das Zeichen nicht in Latin-1 vorkommt.) -- pne 16:43, 13. Apr 2004 (CEST)
Die Zeichen existieren aber in Unicode. Das Problem ist nicht, dass die Zeichen nicht in Latin-1 vorkommen, sondern, dass sie kein sinnvoller ISO-8859-1 Kode sind. Deshalb muß vor der ISO-8859-1-zu-UTF-8-Umstellung ein Skript die Controlcodes 0x80–0x9F heraussuchen. Die meisten davon werden als CP1252 gedacht sein, es kann aber auch CP850 sein. – Hokanomono|Diskussion 19:52, 13. Apr 2004 (CEST)
Mal abgesehen von den unsauber kodierten Sonderzeichen, die in iso-8859-1 garnicht kodiert werden können, und die trotz media-type-Parameter charset=iso-8859-1 (sowohl im http entity header als auch im meta tag) ANSI-kodiert (oder schlimmer noch: Windows-CP-1252-kodiert) übertragen werden, was passiert eigentlich mit den sauber in Entitäten ausgedrückten Sonderzeichen...
  • werden Entitäten vor der Umstellung aus dem Quelltext gefischt, um sie dann in lesbarerem utf-8 zu kodieren, oder
  • bleiben die Entitäten bei der Umstellung prinzipiell unangetastet? --SteffenB 21:07, 13. Apr 2004 (CEST)
(P.S.. sollten wir die ganze Diskussion ab (ach was... nicht besser auf die Diskussionsseite verschieben?)
Die HTML-Entitäten werden von Meds Software automatisch nach UTF-8 konvertiert. Man kann allerdings einzelne Entitäten von der Ersetzung ausschließen: sinnvoll wäre etwa evtl., nbsp, ndash, amp oder gt als Entitäten stehen zu lassen. Übrigens ist es auch nach der Umstellung weiterhin möglich, Entitäten zu verwenden, so dass man &alpha; schreiben kann, wenn man das α nicht aus der Zeichentabelle fischen will. --Head 21:14, 13. Apr 2004 (CEST)
Dazu Nachfrage und Anregungen:
  1. Alle CP-1252-Sonderzeichen, die nicht iso-8859-1 konform sind (in der verlinkten Tabelle die Zeichen zwischen x0F und xA0), und über die wir in der Wikipedia zufällig stoßen sollten ja schonmal aus dem Text gefischt und korrigiert werden. Unter Korrektur verstehe ich dann richtig die Umwandlung in Entitäten, oder? Zum Aufspüren der illegalen Zeichen könnte ja, wie oben schon geschrieben, ein Bot behilflich sein.
  2. Es gibt Seiten, die nicht-iso-8859-1-Sonderzeichen enthalten (derzeit als Entitäten) und nur von einem kleinen Personenkreis editiert werden, die mit der schlechteren Quelltextlesbarkeit zurechtkommen, und die zugleich von einem sehr heterogenen Personenkreis mit entsprechend heterogenen Systemvoraussetzungen besucht werden. Gibt es für solche Seiten eine Möglichkeit Entitäten so einzufügen, dass sie nicht in utf-8 konvertiert werden, d.h. als geschützte Entitäten oder durch ausnahme solcher Seiten von der Entitäten-Konvertierung? Beispiel: Wenn ein Besucher der Seite Wikipedia:Botschaft diese mit einem Browser ohne utf-8-Unterstützung editiert besteht die Gefahr, dass die Sonderzeichen zerschossen werden, bei Entitäten besteht diese Gefahr nicht. (Mit diesem Vorschlag meine den Schutz beliebige Entitäten in bestimmten Fällen zu schützen, im Unterschied (und in Ergänzung) zum Schutz bestimmter Entitäten (vor allem whitespace) bei jeder Verwendung, um den es nachfolgend geht) --SteffenB 10:09, 23. Apr 2004 (CEST)
für das Zerschießen sollte/muss es eine globale Regel geben. Die Idee wäre, bei gängigen Browsern (vulgo: MSIE 5 auf MacOS) das ganze per Script auf Entities umzubauen. Für Browser, die eh nahezu tot sind (Netscape 4, iCab), wird das Ändern global gesperrt - damit schafft man sich das Problem auf die Dauer ganz aus dem Weg.
iCab wird ständig weiterentwickelt, aber man kann ja nicht alles wissen. -- Schnargel 21:10, 21. Mai 2004 (CEST)
Solange der Browser nur durch technische Unzulänglichkeit auffällt, wird sich aber an seinem 0,00x% Marktanteil nichts ändern und er insofern weiterhin "egal" sein. TheK 21:17, 21. Mai 2004 (CEST)

Entities die nicht konvertiert werden sollten

Ich denke "unsichtbare" Entities außer SPACE sollten HTML-Entities bleiben und nicht vollautomatisch zu UTF-8 gemacht werden. Hier mal eine Liste

Unsichtbare Zeichen
UCS-2 Dezimal-Entity HTML-4-Entity Name
0x00a0 &#160; &nbsp; NO-BREAK SPACE
0x00ad &#173; &shy; SOFT HYPHEN
0x115f &#4447; HANGUL CHOSEONG FILLER
0x1160 &#4448; HANGUL JUNGSEONG FILLER
0x1680 &#5760; OGHAM SPACE MARK
0x2000 &#8192; EN QUAD
0x2001 &#8193; EM QUAD
0x2002 &#8194; &ensp; EN SPACE
0x2003 &#8195; &emsp; EM SPACE
0x2004 &#8196; THREE-PER-EM SPACE
0x2005 &#8197; FOUR-PER-EM SPACE
0x2006 &#8198; SIX-PER-EM SPACE
0x2007 &#8199; FIGURE SPACE
0x2008 &#8200; PUNCTUATION SPACE
0x2009 &#8201; &thinsp; THIN SPACE
0x200a &#8202; HAIR SPACE
0x200b &#8203; ZERO WIDTH SPACE
0x200c &#8204; &zwnj; ZERO WIDTH NON-JOINER
0x200d &#8205; &zwj; ZERO WIDTH JOINER
0x200e &#8206; &lrm; LEFT-TO-RIGHT MARK
0x200f &#8207; &rlm; RIGHT-TO-LEFT MARK
0x2028 &#8232; LINE SEPARATOR
0x2029 &#8233; PARAGRAPH SEPARATOR
0x202a &#8234; LEFT-TO-RIGHT EMBEDDING
0x202b &#8235; RIGHT-TO-LEFT EMBEDDING
0x202c &#8236; POP DIRECTIONAL FORMATTING
0x202d &#8237; LEFT-TO-RIGHT OVERRIDE
0x202e &#8238; RIGHT-TO-LEFT OVERRIDE
0x202f &#8239; NARROW NO-BREAK SPACE
0x205f &#8287; MEDIUM MATHEMATICAL SPACE
0x2060 &#8288; WORD JOINER
0x2061 &#8289; FUNCTION APPLICATION
0x2062 &#8290; INVISIBLE TIMES
0x2063 &#8291; INVISIBLE SEPARATOR
0x206A &#8298; INHIBIT SYMMETRIC SWAPPING
0x206B &#8299; ACTIVATE SYMMETRIC SWAPPING
0x206C &#8300; INHIBIT ARABIC FORM SHAPING
0x206D &#8301; ACTIVATE ARABIC FORM SHAPING
0x206E &#8302; NATIONAL DIGIT SHAPES
0x206F &#8303; NOMINAL DIGIT SHAPES
0x3000 &#12288; IDEOGRAPHIC SPACE
0x3164 &#12644; HANGUL FILLER
0xfeff &#65279; ZERO WIDTH NO-BREAK SPACE
0xffa0 &#65440; HALFWIDTH HANGUL FILLER
0xfff9 &#65529; INTERLINEAR ANNOTATION ANCHOR
0xfffa &#65530; INTERLINEAR ANNOTATION SEPARATOR
0xfffb &#65531; INTERLINEAR ANNOTATION TERMINATOR
Außerdem &amp;, &lt;, &gt etc. also alle HTML-Sonderzeichen. Hokanomono|Diskussion 00:45, 27. Apr 2004 (CEST)
Also am besten auch alle Entitäten für Unicode-Werte kleiner als U+00A0 intakt lassen, damit es zu keinem Konflikt mit der Wikitext-Syntax kommt. (Zum Beispiel könnte ein &#124; in einer Tabelle unangenehme Auswirkungen haben, wenn es zu | wird.) – Hokanomono|Diskussion 11:27, 11. Mai 2004 (CEST)

Versionsgeschichte

Um DaB.s Punkt aufzugreifen: was passiert bei der Umstellung mit der Versionsgeschichte? Ist die Umstellung ein Eintrag in der Geschichte oder wird die Geschichte mitkonvertiert? – Hokanomono|Diskussion 10:14, 20. Mai 2004 (CEST)

Auch die alten Versionen müssen natürlich konvertiert werden; ansonsten wären sie später voller ungültiger Codes und somit unbrauchbar. Es wird somit hinterher so aussehen, als wäre die Wikipedia schon immer UTF-8-kodiert gewesen. -- Sloyment 02:28, 21. Mai 2004 (CEST)

Es wird die gesamte Datenbank konvertiert, einschließlich aller Versionen. Einen Eintrag in die History gibt es nicht. -- Schnargel 21:14, 21. Mai 2004 (CEST)

Warum tun wir's nicht einfach?

Was hält uns davon ab, auf UTF-8 umzustellen? Über die Sinnhaftigkeit dieser Umstellung wird es ja wohl keine Diskussion geben. Oder wollen wir noch drei Wochen warten, damit wir dan 80.000 Artikel umstellen müssen? Zwei Monate, für 100.000? Dadurch wird die Umstellung sicher nicht einfacher. --denny vrandečić | talk 00:02, 28. Mär 2004 (CET)

Hallo,
ich glaube das Übersteigt das Prinzip: "Sei mutig" doch etwas. Wir müssen uns schon einig sein, ob wir das wollen. Laut Tabelle gibt es bis jetzt 6 Browser/Betriebssystemkombinationen, die definitiev nicht gehen und einige mit Einschränkungen. Außerdem scheint auch in der franzö. Wikipedia nicht alles glatt gelaufen zu sein. Die Umstellung eilt auch nicht, ob das Programm 70.000 oder 100.000 Artikel bearbeitet ist wurscht. --DaB. 00:12, 28. Mär 2004 (CET)
"6 Kombinationen, die nicht gehen" : lynx und iCab sind nicht sehr weit verbreitet. Wer einen Text-Browser will, kann ebensogut w3m oder [e]links verwenden. Mozilla 1.2.1 ist auch schon ziemlich alt, was spricht dagegen, auf 1.5 oder 1.6 upzudaten? Bleibt also nur der IE5.5 unter MacOS als "echtes" Problem -- Stw 01:14, 28. Mär 2004 (CET)
Das lynx nicht geht ist IMHO ein großer Nachteil, weil ich mal gehört habe das viele Blinde ihn für die Braile-Zeile benutzen. Und solche Menschen wolllen wir doch nicht ausschliessen????? Außerdem sind diese 6 Kombinationnen, diejenigen die bestimmt nicht gehen. Alles was in der Tabelle Gelb ist, macht irgenwie Probleme und die meisten Felder sind gelb. Also, wie ich oben schon sagte, nichts überstürzen, wir haben Zeit. --DaB. 01:36, 28. Mär 2004 (CET)
Wie willst du denn chinesische, arabische oder griechische Zeichen auf einer Braillezeile darstellen? Da nützt es nicht, wenn der Browser eine Million verschiedene Zeichen versteht, mit Braille kannst du nur 64 darstellen -- Stw 17:11, 28. Mär 2004 (CEST)
Natürlich kann auch chinesisch in Braille dargestellt werden: Chinesisches Braille-Alphabet. Ich nehme mal an, dass ein chinesischer Web-Browser für Blinde UTF8 automatisch in Braille wandelt. Aber auch deutsche Blinde benötigen Umlaute. ° 11:56, 29. Mär 2004 (CEST)

Und was müssen wir tun, damit das Gelb verschwindet?

Das Lynx von Blinden benutzt wird, halte ich für ein Gerücht. Blinde benutzen soweit ich weiß Spezialbrowser, die wir ohnehin nicht testen. Da würde es mich sehr interessieren, ob wir tatsächlich blinde Leser und Schreiber haben - könnte man da einen Aufruf auf der Titelseite machen, um das herauszufinden?

Schließlich: wenn wir den Wechsel gemacht haben, können wir die paar Fehler auch noch ausgleichen. Nahezu alle Wikipedias sind umgestellt, und all die Benutzer scheinen keine Probleme dort zu haben mit UTF-8 - warum also sollten es die deutschen Benutzer haben?--denny vrandečić | talk 14:04, 28. Mär 2004 (CEST)

Viele der gelben Einträge sind wahrscheinlich lediglich auf nicht installierte Schriftarten zurückzuführen, so dass auf den Testsystemen auch die Zeichen der Latin-1-Variante nicht richtig angezeigt würden. Leider habe ich die Latin-1-Variante erst zu spät eingestellt. Wir müssten also bei den gelben Einträgen nochmal nachhaken, ob sich 1. durch eine Umstellung auf UTF-8 tatsächlich etwas verschlechtern würde; denn wenn es so oder so nicht funktioniert, spricht auch nichts gegen eine Umstellung, und ob sich 2. durch Nachinstallation von Schriftarten etc. das Problem lösen lässt (wäre gut zu wissen, um nachher Benutzer beraten zu können, die sich wundern, warum Zeichen nicht angezeigt werden). --Head 15:44, 28. Mär 2004 (CEST)
IE, Mozilla (inkl. Firefox), Konqueror beherrschen Unicode in den neueren Versionen vollständig. IE und Konqueror müssen für Lautschrift o.Ä. auf einen Schriftart eingestellt werden, die die Zeichen enthält, Mozilla macht das von selbst. Da das sowohl bei Latin-1 mit Entities (also bisher) als auch bei UTF-8 gilt, sehe ich darin keinen Hinderungsgrund. Gäbe man die Schriftart wikimäßig vor (was sicher den Puristen nicht gefallen mag), bräuchten IE-Nutzer u.Ä. möglicherweise gar nichts umstellen. Vornehmen könnte man diese Einstellung doch sicher in der zentralen CSS-Datei (und ebenso schnell wieder löschen, wenn man das nicht mehr will). --128.176.21.157 11:19, 31. Mär 2004 (CEST)

Das spricht alles für eine schnelle Umstellung. Insbesondere das Speicherplatz-Argument auf der Seite von Head: Für die französische Wikipedia (knapp halb so groß wie die deutsche) wurden temporär 2 GB benötigt; zur Zeit sind nur knapp 3 GB frei. Angenommen der benötigte Speicherplatz ist linear zur Artikelzahl - was nicht gegeben sein muss - bedeutet jeder Monat, den wir warten, etwa ein halber Gigabyte mehr. Zudem wächst die Wikipedia schneller als das Mooresche Gesetz es für den Wachstum der technischen Eckdaten vorhersagt, sprich: wir können nicht einfach abwarten, bis die Technik groß genug ist, weil wir schneller wachsen als die Technik (zumindest zur Zeit).

Also, schnell umsteigen. Danach wird es Probleme geben, aber das wird es auch, wenn wir später umsteigen. Die starke Community kann das aber ausgleichen. --denny vrandečić | talk 16:28, 28. Mär 2004 (CEST)

Theoretisch hast du recht, aber du übersiehst zwei Dinge:
  1. Es passt einfach nicht. Wenn wir jetzt 5 GB brauchen und 3 GB haben, sind wir nicht besser dran, als würden wir später 6 GB brauchen und 2 GB haben.
  2. In dem Moment, wo der Server Geoffrin wieder installiert wird bzw. Suda eine größere Festplatte bekommt, wächst die Kapazität verdammt schnell, da kommt auch kein Artikelschreiber mit ;)
5 GB sind ja nicht die Welt, daran wird es nicht langfristig scheitern. Mit Moore hat das ganze nicht viel zu tun. Allerdings hast du insofern schon recht, als dass die Konvertierung (= Downtime) länger wird, je länger wir warten. --Head 16:35, 28. Mär 2004 (CEST)

Nein, nein, ich gebe Dir natürlich vollkommen Recht! Die Argumente oben waren auch tatsächlich provokativ gemeint - mir ist bewusst, dass der Wachstum der Wikipedia nicht langfristig exponentiell sein kann, und deswegen das Argument nicht zieht, aber es klang gerade so schön. Und natürlich ist mangelnde technische Machbarkeit ein verdammt guter Grund gegen eine sofortige Umstellung. Die eiegtnliche Frage ist aber: ist es der einzige? Sprich, sobald die neue Platte da ist, sobald der neue Server läuft, und bewiesen hat, dass er stabil ist - können wir los? --denny vrandečić | talk 18:34, 28. Mär 2004 (CEST)

Ich habe jetzt extra Mozilla von 1.2.1 auf 1.6 aktualisiert und es funkioniert immer noch nicht. Wenn ich schon zu blöd bin, mit diesem ganzen Codierungs- und Font-Müll zurechtzukommen, dann dürfte das für einige andere auch zutreffen. Ich meine, wir sollten noch ein paar Jahre mit der Umstellung warten. Jedenfalls werde ich mich nicht davon abhalten lassen, Seiten zu bearbeiten, auf denen es irgendwelche Sonderzeichen gibt. Links von der deutschen zur französischen Wikipedia mit Sonderzeichen wie z.B. fr:Wikipédia:À propos funkionieren bei mir ebenfalls trotz Upgrade nicht. Fehlermeldung ist weiterhin "Mauvais titre". Innerhalb der französischen Wikipedia gibt es kein Problem.--El 14:28, 3. Apr 2004 (CEST)

Ich hab den Farbsalat mal etwas entschärft. Jetzt gibt es statt 3 5 Farbcodes. Nur bei rot und orange kann etwas kaputtgehen. Bei Orange muss an den Einstellungen gedreht werden, danach ist's ok. Lynx kann nach dieser Umstellung exakt soviel anzeigen, wie mit ISO+Entities (das gilt auch für das Editor-Fenster), hier ist also kein echtes Problem. (nur bescheidene Voreinstellungen). Bleiben Netscape 4 (der scheitert eh an allem möglichen, inklusive Startseite), der 0,0x%-Exot iCab und MSIE5 unter MacOS. Letzterer ist das echte Problem, nutzt den doch mindestens jeder dritte Mac-User...

Was ist da noch mit Mozilla 1.2 kaputt? TheK 00:02, 20. Mai 2004 (CEST)

Ergebnisse

Könnt Ihr Euren Umstellungsprozess dokumentieren, die Probleme bei der Umstellung und die Lösungen beschreiben und die Ergebnisse hier reinstellen? [Maxi]

Abgerufen von „https://de.wikiup.org/index.php?title=Wikiup_Diskussion:Archiv/Umstellung_auf_Unicode/Archiv&oldid=210792400“