Diskussion:Unicode/Archiv

Diese Seite ist ein Archiv abgeschlossener Diskussionen. Ihr Inhalt sollte daher nicht mehr verändert werden. Benutze bitte die aktuelle Diskussionsseite, auch um eine archivierte Diskussion weiterzuführen.

Um einen Abschnitt dieser Seite zu verlinken, klicke im Inhaltsverzeichnis auf den Abschnitt und kopiere dann Seitenname und Abschnittsüberschrift aus der Adresszeile deines Browsers, beispielsweise

[[Diskussion:Unicode/Archiv#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

https://de.wikipedia.org/wiki/Diskussion:Unicode/Archiv#Thema_1

Symbole, diakritische Zeichen,Sonderzeichen, fremde Zeichen

090: Z 091: [ 092: \ 093: ] 094: ^ 095: _ 096: ` 097: a 098: b 099: c

100: d 101: e 102: f 103: g 104: h 105: i 106: j 107: k 108: l 109: m

110: n 111: o 112: p 113: q 114: r 115: s 116: t 117: u 118: v 119: w

120: x 121: y 122: z 123: { 124: | 125: } 126: ~ 127: ? 128: € 129: 

130: ‚ 131: ƒ 132: „ 133: … 134: † 135: ‡ 136: ˆ 137: ‰ 138: Š 139: ‹

140: Œ 141:  142: Ž 143:  144:  145: ‘ 146: ’ 147: “ 148: ” 149: •

150: – 151: — 152: ˜ 153: ™ 154: š 155: › 156: œ 157:  158: ž 159: Ÿ

160: 161: ¡ 162: ¢ 163: £ 164: ¤ 165: ¥ 166: ¦ 167: § 168: ¨ 169: ©

170: ª 171: « 172: ¬ 173: ­ 174: ® 175: ¯ 176: ° 177: ± 178: ² 179: ³

180: ´ 181: µ 182: ¶ 183: · 184: ¸ 185: ¹ 186: º 187: » 188: ¼ 189: ½

190: ¾ 191: ¿ 192: À 193: Á 194: Â 195: Ã 196: Ä 197: Å 198: Æ 199: Ç

200: È 201: É 202: Ê 203: Ë 204: Ì 205: Í 206: Î 207: Ï 208: Ð 209: Ñ

210: Ò 211: Ó 212: Ô 213: Õ 214: Ö 215: × 216: Ø 217: Ù 218: Ú 219: Û

220: Ü 221: Ý 222: Þ 223: ß 224: à 225: á 226: â 227: ã 228: ä 229: å

230: æ 231: ç 232: è 233: é 234: ê 235: ë 236: ì 237: í 238: î 239: ï

240: ð 241: ñ 242: ò 243: ó 244: ô 245: õ 246: ö 247: ÷ 248: ø 249: ù

250: ú 251: û 252: ü 253: ý 254: þ 255: ÿ 256: Ā 257: ā 258: Ă 259: ă

260: Ą ą Ć ć Ĉ ĉ Ċ ċ Č č

270: Ď ď Đ đ Ē ē Ĕ ĕ Ė ė

280: Ę ę Ě ě Ĝ ĝ Ğ ğ Ġ ġ

290: Ģ ģ Ĥ ĥ Ħ ħ Ĩ ĩ Ī ī

300: Ĭ ĭ Į į İ ı IJ ij Ĵ ĵ

310: Ķ ķ ĸ Ĺ ĺ Ļ ļ Ľ ľ Ŀ

320: ŀ Ł ł Ń ń Ņ Ņ Ň ň ʼn

330: Ŋ ŋ Ō ō Ŏ ŏ Ő ő Œ œ

340: Ŕ ŕ Ŗ ŗ Ř ř Ś ś Ŝ ŝ

350: Ş ş Š š Ţ ţ Ť ť Ŧ ŧ

360: Ũ ũ Ū ū Ŭ ŭ Ů ů Ű ű

370: Ų ų Ŵ ŵ Ŷ ŷ Ÿ Ź ź Ż

380: ż Ž ž ſ ƀ Ɓ Ƃ ƃ Ƅ ƅ

390: Ɔ Ƈ ƈ Ɖ Ɗ Ƌ ƌ ƍ Ǝ Ə

und ff ;-) Ilja

---

Die ersten 128 Zeichen entsprechen dem ASCII-Zeichensatz.

Trifft das auch auf UTF-16 zu? AFAIK nicht. --Head 12:17, 15. Okt 2003 (CEST)

Das hat nichts damit zu tun, welches Transformation Format man benützt. Unicode ordnet bestimmten Nummern Glyphen zu. U0001 bis U0079 entsprechen den ASCII Zeichen. Die Darstellung in einem Transformation-Format sieht i.A. anders aus. --Hokanomono 15:36, 23. Okt 2003 (CEST)

Eingabemethoden

Wozu die Anleitung für "VI Improved"? Das ist was für die Doku des Programmes, wegen mir auch was für den "VI Improved" Wiki Eintrag, hat aber doch auf der Unicode-Seite nichts verloren! Wo kommen wir hin, wenn jeder beschreibt, wie man in diesem oder jenem Programm/Betriebssystem Unicode-Zeichen eingeben kann! Dors 14:02, 19. Mai 2004 (CEST)

Ich habe einen Artikel zu Codepoint verfasst. Ich hoffe ergefällt euch. --Lemmi04 12:29, 6. Dez 2004 (CET)

Hoffentlich gefällt Dir meine erweiterte einzeilige Fassung. - J

Ich wäre dafür, die Eingabemethoden (vim und andere) in Kurzform drinzulassen. Emacs habe ich eben mal berichtigt (es heißt M-x, nicht M-c, das ALT statt META habe ich aus populistischen Gründen stehenlassen, und der Befehl heißt ucs-insert und will hex). Eventuell ging es auch schon in 21.3, was ich übersprang, aber egal ist - 21.4 ist seit Februar draußen. Die Überschrift (Eingabemethoden) habe ich hier in die Diskussion gepackt. --Ralf Muschall 21:40, 28. Jul 2005 (CEST)

Nachtrag: In OOO fehlt bisher die Möglichkeit, Unicode einfach einzugeben (Alt festhalten und Nummer eingeben funktioniert nicht, Nummer (hex) eingeben und Alt-x auch nicht (abgesehen davon ist Alt-x bereits durch den Menüpunkt "Extras" belegt). Folgendes Macro geht, würde aber den Artikel nun wirklich überlasten:

sub ucsinsert
dim cursor as Object
dim tc as Object
dim s as string
cursor=ThisComponent.getCurrentController.viewcursor
tc=ThisComponent.Text.createtextcursor()
tc.gotoRange(cursor,False)
tc.goLeft(4,True)
s=tc.getString
tc.setstring(chr(clng("&H"+s)))
end sub

Das Macro nimmt die letzten genau 4 Zeichen, interpretiert sie als Hexzahl und ersetzt sie durch das Zeichen mit dem entsprechenden Codepoint.

Ich denke, es ist Zeit für einen ausgelagerten Artikel Unicode-Eingabemethoden, der das alles sammelt.

Bei Vim habe ich gleich noch digraph erwähnt. --Ralf Muschall 17:12:17, 29. Jul 2005 (CEST)

Review: Unicode, 13. Dezember

Von Benutzer:Lemmi04 auf der Hauptseite eingetragen. --slg 20:28, 13. Dez 2004 (CET)

Ein Thema das mir am Herzen liegt, das aber notorisch schwierig zu behandeln ist. Der Artikel weist leider boch zahlreiche Ungenauigkeiten und Schwachstellen auf, ich hoffe einige davon beseitigen zu können.

• Geschichte kommt zweimal vor, in der Einleitung ein wenig Geschichte von Unicode, weiter unten Geschichte von Zeichenkodierungen allgemein.
• Das Verhältnis von ISO und Unicode scheint mir nicht ganz richtig dargestellt zu sein.
• Die Liste der Schriften ist sehr unvollständig, und sollte vielleicht augelagert werden.
• Wenn man sich die Listen, Weblinks und den HowTo-Abschnitt "Anwendung der Tabellen" wegdenkt, bleibt wenig Substanz, insbesondere werden eigentlich alle komplizierten Fragen ausgelassen.

Pjacobi 21:21, 13. Dez 2004 (CET)

Ich gebe mir ebenfalls Mühe, den Artikel nach und nach zu verbessern. Leider habe ich nicht die Muße, mich mal einen ganzen Tag dranzusetzen. Das Thema ist recht komplex, und eine Reduzierung auf einen angemessenen Umfang ist ein recht schwieriges Unterfangen, zumindest, wenn das Thema allgemeinverständlich abgehandelt werden soll. Hieran hapert es in weiten Teilen ganz besonders.

Essenziell wäre vornehmlich noch die Erklärung des Unterschieds Character - Glyph und der verschiedenen Kodierungen, UTF8, -16 und-32. Beim gegenwärtigen Aufbau des Artikels wüßte ich nicht, wohin damit. Die Rudi Mentäre (Otto Graf Vieh an die neudeutsche Reformschreibweise angelehnt) Auflistung von Codebereichen halte ich für verzichtbar.

Jirret

Ich stimme meinem Vorredner zu, die Kodierungsarten sollten erklärt werden. Gibt es keine Literatur zum Thema? Amazon meint, dass es da durchaus etwas gibt. Vielleicht kennt jemand einige davon und kann eins empfehlen. -- Dishayloo [ +] 20:03, 21. Jan 2005 (CET)

Guter Hinweis! Ich füge gleich einen Link zum offiziellen Unicode-Buch ein. --Jirret 16:15, 27. Jan 2005 (CET)

Eigene Seite Codeblöcke

Ich bin dabei, eine eigene Seite mit sämtlichen Codeblöcken zu basteln. In diese werden auch Links zu den Charts integriert. Codeblöcke, die zwar definiert sind, bei denen aber die Normierung noch aussteht, werden mit eingebaut und, sofern schon Kodierungsvorschläge auf der ISO-WG 2-Webseite verfügbar sind, siehe Balinesische Schrift, werden die auch verlinkt. Das dürften gut 160 Zeilen werden, die den Hauptartikel meines Erachtens ziemlich verunstalten würden.
--Jirret 04:02, 5. Feb 2005 (CET)

Liste der Unicode Codeblöcke --Pjacobi 13:47, 5. Feb 2005 (CET)

Quadrate

Trotz Decodiercode UTF-8 (MSIE 6.0) erscheinen manche Zeichen als Quadrate - Was tun? Danke! --Matt1971 23:17, 7. Feb 2005 (CET)

Mehr Fonts installieren.

Wenn das noch nicht hilft, Firefox installieren.

Pjacobi 23:29, 7. Feb 2005 (CET)

Fraktur-Zwangsligaturen

Warum sind die Fraktur-Zwangsligaturen ch, ck und tz nicht im Unicode kodiert? --84.61.58.172 12:14, 18. Feb 2006 (CET)

Warum sollten sie?

Frag das die Leute vom Unicode-Konsortium. Ich nehme an, weil man nicht sämtliche Ligaturen mit aufnehmen wollte, die in irgendwelchen Schriften existieren. --RokerHRO 08:49, 31. Mai 2006 (CEST)

Digraphen

Warum bekam der Digraph ch keinen eigenen Platz im Unicode? --84.61.9.7 10:44, 19. Feb 2006 (CET)

Frag das die Leute vom Unicode-Konsortium. Ich nehme an, weil man nicht sämtliche Ligaturen mit aufnehmen wollte, die in irgendwelchen Schriften existieren. --RokerHRO 08:49, 31. Mai 2006 (CEST)

Griechisch und Kyrillisch

Warum bekamen die griechische Schrift und die kyrillische Schrift getrennte Plätze im Unicode? --84.61.30.195 09:29, 9. Mär 2006 (CET)

Weil es verschiedene Alphabete sind. :-) --RokerHRO 08:49, 31. Mai 2006 (CEST)

Noncharacters

Was ist mit den Kodepunkten U+FDD0-U+FDEF? --84.61.3.13 12:27, 23. Mai 2006 (CEST)

Sie wurden - wie viele andere Codepunkte auch - noch nicht "belegt". Man hat sich also bewusst Raum für spätere Erweiterungen offen gelassen, damit neue Zeichen, oder Zeichen, die man bisher "vergessen" hatte, leicht hinzufügen kann. --RokerHRO 08:49, 31. Mai 2006 (CEST)

Programmierung

Für den Programmierer hat der UTF-8 gegenüber UTF-16 den Vorteil, daß er mit den klassischen mit einem 0 Byte abgeschlossenen Zeichenketten, wie sie in ANSI C verwendet werden, kompatibel ist. Auch braucht man bei der Speicherung in Dateien oder der Kommunikation über Netzwerke keine besonderen Vorkehrungen treffen, da es sich bei UTF-8 lediglich um eine Octet Folge handelt.

Dies kann mit Escape Sequenzen verglichen werden, wie sie schon lange bei Terminals oder Druckern Verwendung finden.

Diesen Absatz würde ich in der nächsten Zeit in den Artikel einfügen, falls niemand Einspruch erhebt.

Lehrig 09:33, 27. Mai 2006 (CEST)

Inwiefern das ein Vorteil gegenüber UTF-16 sein soll, kann ich noch nicht ganz erkennen. Bei UTF-8 sind die einzelnen Zeichen nicht mehr über "zeichenkette[i]" adressierbar, was automatisch auch alle str***-Funktionen nicht anwendbar werden lässt. Kompatibilität zu C-Strings ist also nicht gegeben. Gut, UTF-16 hat denselben Nachteil (Multi-Byte-Encoding). Von der Programmierung her am ehesten an C-Strings wäre noch UTF-32 mit seiner konstanten Zeichenlänge. --Christoph 11:19, 27. Mai 2006 (CEST)

Eben nicht. UTF-32 und UTF-16 heißt schon mal erst mal, daß man char durch entsprechende 32-Bit bzw. 16-Bit Typen ersetzen muß. Aber nicht an den Stellen, wo char im Sinne von "Byte" verwendet wird. Und man muß auf einmal streng zwischen der Länge (in Zeichen) und Größe (in Bytes) unterscheiden. Es ist also mit Neucompilieren nicht getan, man muß den Code komplett durchgehen und oft erheblich überarbeiten.

Bei utf-8 hingegen funktioniert praktisch alles "fast wie gewohnt", auch die str-Funktionen. Sicher, strlen z.B. liefert die Länge in Bytes, nicht in Zeichen, aber das macht in den allermeisten Fällen nichts, ist sogar oft das was man braucht. Nur code, der Zeichen einzeln manipuliert und eine 1:1-Beziehung zwischen Bytes und Zeichen/Glyphen annimmt, muß überarbeitet werden. Der ist aber eher selten. Oefe 14:11, 27. Mai 2006 (CEST)

Stimmt, so gesehen hast du Recht. Vielleicht wäre es dann noch sinnvoll, deinen Satz über die str-Funktionen einzubauen, damit nicht gleich der nächste drüber stolpert. --Christoph 16:14, 27. Mai 2006 (CEST)

Ihr habe Recht. str* Funktionen sind weiterverwendbar. Es brauchte eigentlich nur eine zusätzliche str Funktion "int strglyphlen(const char *string);". Alte Programme wie z.B. "cat" sind weiterverwendbar, nur der Termialemulator muss die UTF-8 Escape Sequenzen verarbeiten können. Beziehungsweise die Widget Funktionen. Und bei der socket Kommunikation braucht man nichts zu ändern. Keine "byte order" oder so. Alles portabel. Also lediglich eine Octet Folge. Lehrig 11:00, 28. Mai 2006 (CEST)

Vorschlag:

Für den Programmierer hat der UTF-8 gegenüber UTF-16 und UTF-32 den Vorteil,
daß er mit den klassischen mit einem 0 Byte abgeschlossenen Zeichenketten,
wie sie in ANSI C verwendet werden, kompatibel ist.
Auch braucht man bei der Speicherung in Dateien oder der Kommunikation über Netzwerke 
keine besonderen  Vorkehrungen treffen,
da es sich bei UTF-8 lediglich um eine Octet Folge handelt.

Dies kann mit Escape Sequenzen verglichen werden,
wie sie schon lange bei Terminals oder Druckern Verwendung finden.

Die Funktion "int strlen(const char *str);" liefert allerding die benötigten Bytes zurück und 
nicht die Anzahl der Glyphen. 
Eine entsprechende Funktion müsste in die string Funktionen aufgenommen werden.
Ansonsten brauchen alte Programme nicht von char auf int16 bzw. int32 umgestellt zu werden.

Nur die Terminalemulatoren bzw. die Widget Methoden müssen UTF-8 unterstützen.

Lehrig 11:16, 28. Mai 2006 (CEST)

Ich würde knapper formulieren: UTF-8 teilt Vor- und Nachteile herkömmlicher Multibyte Character Sets. --Pjacobi 12:16, 28. Mai 2006 (CEST)

Diese Formulierung ist insofern irreführend, da utf-8 gegenüber herkömmlichen Multibyte Character Sets zahlreiche Vorteile hat (s. [utf-8]-Artikel). Oefe 15:37, 28. Mai 2006 (CEST)

Den Vergleich mit Escape-Sequenzen finde ich nicht besonders glücklich, denn Escape-Sequenzen sind nicht so standardisiert und umständlicher in der Handhabung, da sie i.R. normale (druckbare und nicht druckbare) ASCII-Zeichen mit einer anderen Bedeutung belegen, z.B. würde in einer Sequenz ESC-M (hex 1B 4D) das "M" eben nicht als Buchstabe "M" ausgegeben werden. In utf-8 dagegen bedeutet ein Byte "4D" immer den Buchstaben M.

Auch den Absatz:

Eine entsprechende Funktion müsste in die string Funktionen aufgenommen werden.
Ansonsten brauchen alte Programme nicht von char auf int16 bzw. int32 umgestellt zu werden.

würde ich eher weglassen. Mit einer Funktion ist es sicher nicht getan. Wenn man wirklich Zeichen- oder gar Glyphenweise (was nicht dasselbe ist) arbeiten, oder z.B. Zeichen transformieren will (toupper), kommt man um die Verwendung der Unicode-Tabellen (entweder direkt oder über entsprechende Funktionen) nicht herum. Und in diesem Fall ist man wohl oft mit UTF-16 oder -32 besser bedient.

Der Punkt ist nur, dass viele Programme das entweder gar nicht machen, oder dazu entsprechende System-Funktionen bzw. GUI-Widgets benutzen, die als Schnittstelle durchaus utf-8 verwenden können. Oefe 15:37, 28. Mai 2006 (CEST)

Den Vergleich mit Escape-Sequenzen habe ich absichtlich gebracht. Denn es geht doch darum, dass der Leser das Prinzip versteht. Darüber hinaus werden Escape-Sequenzen durchaus zur Ausgabe von sonst nicht darstellbaren Zeichen verwendet. UTF-8 hat doch wahrscheinlich auch noch ein Hintertürchen offen gelassen, um es über die bisher maximal definierten 4 Byte hinaus zu erweitern. Lehrig 18:15, 28. Mai 2006 (CEST)

Ein Beispiel für ein Widget Set, das Unicode unterstützt ist Qt. Es verwendet durchgängig die QString Klasse, die Unicode verwendet [1]. Character sequenzen lassen sich in QString konvertieren: "QString fromUtf8 ( const char * str, int size = -1 )".

Zitat:

Conversions between 8-bit strings and Unicode strings
QString provides the following four functions that return a const char * version 
of the string as QByteArray: toAscii(), toLatin1(), toUtf8(), and toLocal8Bit().
 toAscii() returns an ASCII encoded 8-bit string.
 toLatin1() returns a Latin-1 (ISO 8859-1) encoded 8-bit string.
 toUtf8() returns a UTF-8 encoded 8-bit string. UTF-8 is a superset of 
 ASCII that supports the entire Unicode character set through multibyte sequences.
 toLocal8Bit() returns an 8-bit string using the system's local encoding.
To convert from one of these encodings, QString provides fromAscii(), fromLatin1(),
fromUtf8(), and fromLocal8Bit(). Other encodings are supported through QTextCodec.

Qt lässt sich nicht nur zur Programmierung von GUI's einsetzen, sondern auch zur Programmierung z.B. von Serversoftware ohne eigene Benutzeroberfläche.

Vielleicht sollte man sich an der Qt Dokumentation orientieren PS:Ich bin Benutzer Lehrig, hatte vergessen mich einzuloggen. 80.131.222.13 17:51, 28. Mai 2006 (CEST)

Ich bin gegen ein ausführliches "für Programmierer" Kapitel. Welche Unicode-Kodierung am einfachsten zu benutzen ist, entscheidet der Language Designer, welche im Projekt tatsächlich benutzt wird, der Software Architect. Am ehesten noch eine kurze Tabelle welche Unicode-Kodierung welchem nativem Datentyp in welcher Programmiersprache entspricht. --Pjacobi 17:58, 28. Mai 2006 (CEST)

Mit Verlaub, das halte ich für falsch. Erstens spielt es keine Rolle, wer in einer Firma XY die Entscheidung trifft. Wahrscheinlich ökonomische Erwägungen. Darüber hinaus ist ein Absatz für Programmierer gerade wichtig, weil viele Programmierer sich noch nicht mit der Kodierung und Verarbeitung nichtlateinischer Schriften auskennen. Das wird allerdings immer wichtiger. Lehrig 18:21, 28. Mai 2006 (CEST)

Eine Enzyklopädie ist kein Tutorial. Ausserdem gibt es bereits gute Tutorials. --Pjacobi 09:31, 29. Mai 2006 (CEST)

Ein kurzer Absatz über die Probleme, die Unicode ggü 1-Byte-Zeichensätzen macht und wie man sie lösen kann, ist sicher nicht verkehrt. Dieser sollte aber möglichst programmiersprachenunabhängig sein und muss nicht zu sehr in die Tiefe gehen. Verweise auf Artikel, die das Thema genauer behandeln können, halte ich da eher für angebracht. --RokerHRO 08:49, 31. Mai 2006 (CEST)

Ich halte garnichts von solchen Programmier-Tipps. Ich als Programmierer habe mich direkt auf der offiziellen Unicode-Homepage informiert, wo ich alle Informationen gefunden habe, die ich brauche (Es gibt sogar ausfuerliche Informationen darueber, wann man am besten welche Kodierung benutzten sollte). Die Wikipedia ist meiner Meinung nach definitiv KEIN Ort, wo man solches Spezialwissen verbreiten sollte, erst recht nicht, wenn schon eine sehr umfangreiche und gute Homepage existiert (die offizielle). RedNifre 17:28, 23. Aug 2006 (CEST)

Verständlichkeit des Artikels

Nichts für ungut, aber nach zweimaligem Lesen des Artikels war mir hinterher immer noch nicht klar, was Unicode sein soll, bzw. hatte nur eine difuse Vorstellung davon, wie es funktioniert. Beispiel für eine verständliche Beschreibung: http://unicode.e-workers.de/. Bei diesem Artikel war mir nach ein mal querlesen klar, worum es bei Unicode geht und wie es aufgebaut ist.

Ich finde den von Dir angegebenen Artikel recht gelungen. Unglücklicherweise bin ich kein besonders guter Schreiber und es sollte ein anderer mal einen Absatz formulieren. Darin sollte auch dieses Zitat vorkommen.

Neben UTF-16 und UTF-32 ist auch das "USC Transformation Format 8 Bit" (UTF-8) gebräuchlich.  
UTF-8 kann jedes Unicode-Zeichen als Abfolge von Datenwörtern von je 8 Bit Länge ausdrücken. 
UTF-8 ermöglicht also die Umwandlung von 16 Bit- in 8 Bit-codierte Schriftzeichen. UTF-8 stimmt 
in den ersten 128 Zeichen mit dem "American Standard Code for Information Interchange" (ASCII)   
überein.

Vorschlag:

Unicode kommt in den Formen UTF-8, UTF-16 und UTF-32 vor. Bei UTF-8 kann jedes Unicode-Zeichen als Sequenz von 8 Bit Zeichen mit einem möglichen 0 Byte am Ende dargestellt werden. Dabei werden die ersten 128 Zeichen nach dem ASCII-Code dargestellt. Weitere Zeichen belegen 2 bzw. 4 Byte in Reihenfolge. Man kann mit dem UTF-8 Code bis zu 2^32 Zeichen darstellen. Bei UTF-16 bzw. UTF-32 werden int16 bzw. int32 Datentypen verwendet. Daher können 2^16 bzw. 2^32 Zeichen dargestellt werden. In der Code-Tabelle finden nach dem amerikanischen Zeichensatz die lateinischen Sprachen, griechische , kyrillische, hebräische, arabische, indische und andere Zeichensätze Platz. Es folgen die ostasiatischen Zeichensätze sowie Platz für tote Sprachen.

Die genaue Codierung ist für den Programmierer unerheblich, da es Bibliotheken gibt, mit denen die Unicode-Zeichen als Strings verarbeitet werden können. Beispielsweise erlaubt die QString Klasse der Qt Bibliothek die Verarbeitung von UTF-16-Zeichen und damit die Unterstützung aller lebenden Sprachen. In diesen Bibliotheken existieren Konvertierungsroutinen, mit denen UTF-8 codierte Zeichen in UTF-16 bzw. UTF-32 umgewandelt werden können und umgekehrt.

UTF-8 hat gewisse Vorteile gegenüber UTF-16 bzw. UTF-32. Zum Einen ist es aufwärtskompatibel zu der klassischen Textdarstellung in Programmiersprachen, weswegen die Unicode-Unterstützung ohne allzu großen Aufwand auch auf alte Programme angewendet werden kann. Zum Anderen handelt es sich bei UTF-8 um eine einfache Octet-Reihenfolge und man kann diese Octet-Reihenfolge über ein Netzwerk übertragen, ohne sich um die möglicherweise unterschiedliche Darstellung der Integer Datentypen auf den beteiligten Rechnersystemen kümmern zu müssen.

Falls dieser Vorschlag nicht euere Zustimmung finden sollte, bitte ich um einen Gegenvorschlag. Wie gesagt, ich bin nicht der beste Schreiber. Aber beim Programmieren lasse ich mir von keinem was vormachen :-) Lehrig 09:26, 29. Mai 2006 (CEST)

Absatz 1: Hä? Unicode hat immer einen potentiellen Zeichenvorrat von 17*2^16 - ein paar zerquetschte. Das ist unabhängig von der Verwendung von UTF-*, somit können alle UTF-* (sowie CESU-8 und GB18030) für alle Unicodebereiche benutzt werden. Das 0-Byte am Ende hat nichts mit Unicode zu tun.

Absatz 2: Wiederum der Fehler mit dem Zeichenvorrat

Absatz 3: Zu C-spezifisch, trifft z.B. nicht auf Java zu

Pjacobi 09:39, 29. Mai 2006 (CEST)

Gegenvorschlag ??? 2^16 bzw. 2^32 ist natürlich nur eine Phantasiegrösse, in der Realität muss natürlich noch was abgezogen werden. 0 Byte am Ende ist bei UTF-8 erlaubt und wichtig, für alte Programme !!! PS:Wir sollten hier auch keine endlose Grundsatzdiskussion führen. Was ist denn falsch an der obigen Darstellung ? Kann keine Widersprüche erkennen. Und C/C++ ist nun mal wichtig, evtl. wichtiger als Java oder andere Sprachen. 80.131.255.37 13:10, 29. Mai 2006 (CEST) ... Hach wieder das Login vergessen Lehrig 13:12, 29. Mai 2006 (CEST)

Der Unicode-Codepoint-Bereich ist mit U+000 bis U+10FFFF festgelegt. Alle UTFs können den gesamten Bereich abdecken. Alle Bytesequenzen die at face value zu einem Codepoint >0x10FFF führen sind illegal. Das 0-Byte am Ende ist eine C-Konvention und hat nichts mit UTF-8 zu tun. (U+0041, U+0000, U+0042, U+0000, U+0043) ist eine perfekt legale Folge von Unicodezeichen, die sich auch mit UTF-8 nicht C-String darstellen lässt. Ich schlage vor, wenn überhaupt, schreibst Du etwas in den Artikel C (Programmiersprache), da gibt es nämlich noch gar kein Kapitel zu Zeichensätzen und Unicode. --Pjacobi 13:20, 29. Mai 2006 (CEST)

Deine Ausführungen betreffen Details, die keinen Programmierer interessieren müssen. Ausserdem wird Unicode ständig erweitert und wird auch unter Garantie in Zukunft noch Erweiterungen (vielleicht sogar über UTF-32 hinaus) erfahren. In der C (Programmiersprache) werde ich (nach deinem Vorschlag) einen Link setzen. Lehrig 15:05, 29. Mai 2006 (CEST)

Zu der Zahl der Codepoint s.u. Wenn Du nichts von Unicode verstehst, solltest Du vielleicht nicht versuchen, einen Artikel darüber zu schreiben. Es geht nicht um Details, sondern um richtig oder falsch. --Pjacobi 16:34, 29. Mai 2006 (CEST)

Als Programmierer sollte man sich schon mit den Details befassen. In Java sollte man daran denken, dass Codepoint 0 speziell kodiert wird (kein sauberes Unicode, aber nicht wirklich schaedlich), damit ein C-Programm nicht denkt, der String wuerde enden. Und in C muss man sich selbst darum kuemmern, dass evtl. im String vorhandene 0-Codepoints irgendwie (zum Beispiel durch eine Escape-Sequenz) behandelt werden, damit C damit klarkommt. Und dass Unicode noch extrem veraendert wird ist m.M.n. auch sehr unwahrscheinlich, da mann dann UTF-16 vergessen koennte. RedNifre 17:44, 23. Aug 2006 (CEST)

Den folgenden Beitrag werde ich in den Artikel über Unicode einfügen, wenn kein weiterer Benutzer Einwände geltend macht.

Implementierung

Unicode kommt in den Formen UTF8, UTF-16 und UTF-32 vor. Bei UTF-8 kann jedes Unicode-Zeichen als Sequenz von 8 Bit Zeichen mit einem möglichen 0 Byte am Ende dargestellt werden. Dabei werden die ersten 128 Zeichen nach dem ASCII-Code dargestellt. Weitere Zeichen belegen zur Zeit 2 bzw. 4 Byte in Reihenfolge.

Man kann mit dem UTF-8 Code bis zu 2^32 Zeichen Brutto darstellen. Bei UTF-16 bzw. UTF-32 werden int16 bzw. int32 Datentypen verwendet. Daher können 2^16 bzw. 2^32 Zeichen Brutto dargestellt werden.

In der Code-Tabelle finden nach dem amerikanischen Zeichensatz die lateinischen Sprachen, griechische , kyrillische, hebräische, arabische, indische und andere Zeichensätze Platz. Es folgen die ostasiatischen Zeichensätze sowie Platz für tote Sprachen. Durch die Unterstützung der toten Sprachen musste UTF-16(ISO/IEC 10646) auf UTF-32 erweitert werden.

Die genaue Codierung ist für den Programmierer unerheblich, da es Bibliotheken gibt, mit denen die Unicode-Zeichen als Strings verarbeitet werden können. Beispielsweise erlaubt die QString Klasse der Qt Bibliothek die Verarbeitung von UTF-16-Zeichen und damit die Unterstützung aller lebenden Sprachen.

In diesen Bibliotheken existieren Konvertierungsroutinen, mit denen UTF-8 codierte Zeichen in UTF-16 bzw. UTF-32 umgewandelt werden können und umgekehrt.

UTF-8 hat gewisse Vorteile gegenüber UTF-16 bzw. UTF-32. Zum Einen ist es aufwärtskompatibel zu der klassischen Textdarstellung in Programmiersprachen, weswegen die Unicode-Unterstützung ohne allzu großen Aufwand auch auf alte Programme angewendet werden kann. Zum Anderen handelt es sich bei UTF-8 um eine einfache Octet-Reihenfolge und man kann diese Octet-Reihenfolge über ein Netzwerk übertragen, ohne sich um die möglicherweise unterschiedliche Darstellung der Integer Datentypen auf den beteiligten Rechnersystemen kümmern zu müssen.

Sinngemäss kann UTF-8 also als eine Art Escape Sequenz betrachtet werden, wie man Sie auch bei Terminalemulatoren oder Druckern antreffen kann. UTF-8 kann theoretisch auch auf mehr als 4 Zeichen erweitert werden.

Lehrig 15:05, 29. Mai 2006 (CEST)

Lese Dir bitte RFC 3629 durch. Dort wurde gegenüber RFC 2279 explizit der Raum der gültigen Codes für UTF-8 auf U+0000 bis U+10FFFF für alle Zeiten beschränkt. RFCs werden nicht mehr geändert.

UTF-8 könnte übrigens nicht nur 2³² sondern über 2³⁶ unterschiedliche Codes darstellen. Auch UTF-16 kann nicht nur 2¹⁶ Codes, sondern alle Codes von U+0000 bis U+10FFFF darstellen. --Fomafix 16:25, 29. Mai 2006 (CEST)

"für alle Zeiten beschränkt" Entschuldigung, aber nach meinen vernachlässigbaren Erfahrungen ist das totaler Blödsinn. JEDE Codierung muss PRINZIPIELL erweiterbar sein. Auch wenn das unter Umständen auch NIE erforderlich wird. PS: 640kB sollten für jeden Computer ausreichend sein :-) Lehrig 17:32, 29. Mai 2006 (CEST)

Wende Dich mit Deinem Anliegen an die Unicode-Mailingliste. Die Experten dort werden diesen Hinweisen ergriffen lauschen. Wir dokumntieren nur den vorliegenden Standard. --Pjacobi 18:00, 29. Mai 2006 (CEST)

Wir beide haben unsere gegenseitigen Auffassungen schon ausreichend diskutiert. Du hast auch keinen Gegenvorschlag gebracht. PS: Die heutigen Hüter des Unicode braucht man garnicht zu fragen. Fragen solltest Du die Generationen nach uns, die sich mit unserer Unicode Implementierung herumschlagen müssen. Trotzdem ist Unicode eine tolle Sache, weil es endlich gelungen ist, einen Konsens über die Codierung der Sprachen auf unserer Mutter Erde zu schaffen. Endlich ein Standard !!! Aber spätestens, wenn wir klingonisch und alle anderen Sprachen des Universums berücksichtigen müssen, wird Unicode erweitert werden müssen oder sogar obsolet werden. ... Aber langsam wird's philosophisch :-) Lehrig 18:24, 29. Mai 2006 (CEST)

Vielleicht auch einfach hier mit Lesen anfangen. --Pjacobi 16:40, 29. Mai 2006 (CEST)

Ich versuch's noch einmal, diesmal etwas produktiver:

• Wir haben einzelne Artikel zu UTF-8, UTF-16, UTF-32. Diese können gegebenenfalls einen Abschnitt "UTF-X in der Softwareentwicklung" vertragen. Wir haben auch einen Artikel Unicode Transformation Format der sich für den Überblick eignen würde, welche Sprachen, Bibliotheken und Betriebssysteme welches UTF unterstützen/vorziehen. Sehr vorsichtig (d.h. unter Beachtung von en:WP:NOR) könnten da Vor- und Nachteile dargestellt werden.
• Aber hier, in Unicode, sollte ein hypothetischer Abschnitt Softwareentwicklung sich um die Aspekte kümmern, die unabhängig von der Wahl des UTFs sind, da gibt es ja genug zu beachten: Rückwärts- und Vorwärtskompatibilität, Kompatibilitäts- und kanonische Äquivalent und Normalisierung, Bidi, Graphem- und Wortgrenzenerkennung, UCA, ...

Pjacobi 19:18, 29. Mai 2006 (CEST)

Das hört sich doch schon ganz anders an. Ich werde meine Zeilen an der entsprechenden Stelle eintragen und hier nur kleine Ergänzungen und Verlinkungen eintragen. Warum haben wir eigentlich so lange aneinander vorbei geredet ? Benutzer:Lehrig ist mal wieder nicht eingeloggt. 80.131.255.37 20:00, 29. Mai 2006 (CEST)

Die Diskussion wird in Unicode_Transformation_Format#Implementierung weitergeführt. Mit dem Auffassung von Pjacobi bin ich nicht einverstanden. Erst sollten sich noch andere Benutzer zu Wort melden, sonst kommen wir auf keinen grünen Zweig. Lehrig 08:12, 31. Mai 2006 (CEST)

Also in einem Artikel über Unicode sollte auf die verschiedenen "Unicode Transfer Formate" nur verwiesen werden, schließlich sind diese nur mögliche Kodierungen, um Sequenzen von Unicode-Zeichen zu speichern oder zu übertragen, mehr nicht.

Daher würde ich generell zwischen dem "Unicode" und seinen verschiedenen "Transfer-Formaten/-Kodierungen" unterscheiden. Unicode ist schlicht eine Codetabelle von Zahl zu Glyph und seinen Eigenschaften usw. Die Transferformate UTF-8, UTF-16 und UTF-32 beschreiben lediglich, wie man eine solche Zahl (aus de mdefinierten Wertebereich 0...10FFFF) übertragen kann. Diese Formate wurden zwar speziell für die Übertragung von (Sequenzen von) Unicode-Codepositionen (als Synonym für ein Zeichen) erdacht, aber prinzipiell ist denen die Bedeutung der Zahlen, die sie kodieren, egal. --RokerHRO 08:56, 31. Mai 2006 (CEST)

Kann mir jemand kurz und klar erklären...

…was ich tun muss, damit ein Zeichen dessen „Unicode“ ich kenne, in einem Browser auch erscheint? -- Peter Steinberg 00:44, 14. Sep 2006 (CEST)

Wenn du etwa das Unicode-Zeichen U+20AC eingeben willst, schreibst du einfach €. Und es erscheint dann: ein €. Wie gewünscht. Du kannst natürlich auch mit nem Taschenrechner den hexadezimalen Codewert in eine Dezimalzahl umwandeln und dann € schreiben, da ältere Browser mit den Hexadezimal-Sequenzen u.U. nicht klarkommen. Das ergibt dann ebenfalls ein: € :-) --RokerHRO 10:21, 14. Sep 2006 (CEST)

Zeichensatz/Zeichenkodierung

Ist Unicode selber nicht ein Zeichensatz? Es legt die Zeichen fest und deren Codepoints, aber in diesem Artikel wird auch noch von UTF-X und den ISO-8859-X geredet.

Sind denn UTF-X und ISO-8859-X nicht Zeichenkodierungen, die die Codepoints aus dem Unicode-Zeichensatz auf Bytes abbilden?

IMHO wird in diesem Artikel nicht so sehr zwischen Zeichensatz und -kodierung unterschieden.

Alle Zeichenkodierungen sogar ASCII können doch Unicode, ASCII z. B. aber nur 128 Unicode-Codepoints, darstellen.

Vielleicht habe ich auch nur was falsch verstanden. Gruß --L'ottimo 20:09, 9. Apr. 2007 (CEST)

Das sollte eigentlich bei uns schon alles erklärt sein:

Zeichensatz, Zeichenkodierung. Hmm, nicht so prickelnd.

Liest Du Englisch? Dann hier: en:Character_encoding#Modern_encoding_model.

Mit anderen Worten, der UNICODE Standard definiert character repertoire, coded character set, character encoding form und character encoding scheme.

Pjacobi 20:19, 9. Apr. 2007 (CEST)

Danke, ich glaub ich hab's verstanden --L'ottimo 20:39, 9. Apr. 2007 (CEST)

Deutsche Bezeichnungen für Unicode-Symbole

... und zwar ausschliesslich mit lateinischen Buchstaben geschrieben, soweit möglich. --Reiner Stoppok 01:24, 6. Jun. 2007 (CEST)

Siehe auch: Traduction française officielle de l’ISO/CEI 10646 et Unicode

Ich möchte vorschlagen, für alle Unicode-Symbole systematisch deutsche Begriffe zu prägen, die dann hier auch verwendet werden dürfen. Ich hatte gerade Schwierigkeiten bei "Seagull below" aus dem IPA, was ich hemdsärmelig mit "Möwe unten" übersetzt habe, mir aber ein Redirect von "Möwe unten" bzw. "Möwe unten (IPA)" gelöscht wurde mit dem üblichen Hinweis auf die Trefferzahl bei Google. --Reiner Stoppok 17:48, 3. Jun. 2007 (CEST) PS: Dazu habe ich in der neusten amerikanischen Literatur einfach nichts gefunden ... :)

Das wäre Theoriefindung, die nach den Grundsätzen der Wikipedia nicht zulässig ist. --Thogo (Disk.) -- Sorgen? 19:23, 3. Jun. 2007 (CEST)

Ich meinte sowas hier: Liste von Unicode Zeichen, was bei en.wikipedia durchaus erlaubt ist. --Reiner Stoppok 20:28, 3. Jun. 2007 (CEST)

Ich schliess mich Thogo an, siehe auch Diskussion IPA--Patrick 20:30, 3. Jun. 2007 (CEST).

Ich möchte nur erreichen, dass man auch deutsche Bezeichnungen einführen darf. Wie würdest Du ein Lemma mit dem Unicode-Zeichen "Möwe unten" (IPA 407) hier bei de.wikipedia betiteln? --Reiner Stoppok 20:41, 3. Jun. 2007 (CEST) PS: Weiss jemand zufällig, wie ich rein technisch die "Möwe unten" (bei Seagull below) so in einen Schaukasten rechts hinbekomme, wie bei Halblangzeichen?

Neue und bisher unübliche Begriffe einzuführen ist in der Wikipedia aber ausdrücklich unerwünscht. Die englischen Bezeichnungen sind die einzigen vom Unicode-Konsortium vergebenen Namen und die deutschen Übersetzungen sind bei den meisten exotischen Zeichen auch in der jeweiligen Fachsprache nicht üblich. --RokerHRO 22:25, 3. Jun. 2007 (CEST)

Ich plädiere dafür, wortwörtliche Übersetzungen zuzulassen. Wenn man das Wort Begriff so definiert wie hier, dann kann man es bei großzügiger Auslegung durchaus mit Wikipedia:Theoriefindung in Übereinstimmung bringen. "Seagull below" und "Möwe unten" wären dann zwar nicht dasselbe Wort, wohl aber derselbe Begriff. Demnach war es auch gar nicht nötig, dass das Unicode-Konsortium die Bezeichnungen der einzelnen Zeichen für andere Sprachen als das Englische festgelegt hat. Sie haben nur die Begriffe geprägt und dafür die englische Sprache benutzt. Die Zuordnung dieser englischen Bezeichnungen zu entsprechenden deutschen war nicht mehr Aufgabe des Konsortiums. Das heißt aber meiner Meinung nach nicht, dass wir das nicht tun sollten. Im Gegenteil, ich finde, wir sollten nicht an den englischen Bezeichnungen kleben bleiben. Gismatis 05:33, 4. Jun. 2007 (CEST)

Du hast mich verstanden, lieber Gismatis: "Wir sollten nicht an den englischen Bezeichnungen [des Unicode-Konsortiums] kleben bleiben". --Reiner Stoppok 17:03, 4. Jun. 2007 (CEST)

  ̼ 

 ̼

@Reiner: Man kann ja die Übersetzung des englischen Fachbegriffs in den jeweiligen Artikel mit dazufügen (wie das bei allen fremdsprachlichen Lemmata üblich ist), aber als Lemma selbst sind sie nicht geeignet, weil sie weder in der Wissenschaft anerkannt sind noch im allgemeinen Sprachgebrauch verwendet werden. Im übrigen sollten die Artikel auch etwas mehr Information enthalten als die IPA-Nummer und die Aussprache (ich meine, einen Mehrwert zur Liste der IPA-Symbole). (Seagull below ist ein Beispiel, wie solche Artikel nicht aussehen sollten, aber dort passt wenigstens das Lemma.) Bspw. wie es zu gerade diesem Zeichen kam, wäre mal ganz interessant (natürlich nur, wenn es dafür Quellen gibt). Eigentlich muss es für IPA-Zeichen gar keinen eigenen Artikel geben, es reicht, wenn bspw. Seagull below in Linguolabialer Laut erwähnt wird. Möglicherweise kann es eine Weiterleitung von "Seagull below" darauf geben, das wäre sogar sinnvoll, (nicht aber eine Weiterleitung vom Zeichen selbst oder gar von der deutschen Übersetzung des Zeichennamens).

Das Problem ist doch auch, dass viele Zeichen sich graphisch fast überhaupt nicht unterscheiden. Solche Klärungen graphischer Unterschiede (die natürlch Zeichen mit verschiedenen Unicode-Nummern sind) können nicht alle bei IPA oder sonstwo stattfinden. Auch nicht die Klärungen der Tatsache, mit welchen Zeichen ein Zeichen x oft verwechselt wird usw. Für das Zeichen "Seagull below" muss es möglich sein, unabhängig von den Prägungen des Unicode-Konsortiums dafür auch deutsche Begriffe einzuführen. --Reiner Stoppok 17:03, 4. Jun. 2007 (CEST) PS: Es sollten aber zumindest Redirects von deutschen Übersetzungen erlaubt werden. "Möwe unten, eine Übersetzung die Sinn macht, wurde mir zum Beispiel unter dem Hintern wegglöscht." Von mir aus mit dem Hinweis/einer Kategorie: es gibt noch keinen deutschen Fachbegriff dafür. --Reiner Stoppok 17:24, 4. Jun. 2007 (CEST)

Das technische sollte kein Problem sein. Wenn du einen kleinen <div> erzeugst, und die Schriftgröße entsprechend hochsetzt, kann das durchaus sehr hübsch aussehen, siehe das grüne Kästchen rechts oben. Du kannst natürlich auch die Vorlage {{Zeichen|...}} verwenden, musst dann halt nur &nbsp;̼ in die Variable eintragen (das blaue Kästchen). --Thogo (Disk.) -- Sorgen? 00:48, 4. Jun. 2007 (CEST)

Danke, Thogo, ich bin Techniktrottel, werde mir aber Deine Adresse für Fachfragen "notieren". Ich wollte auch nochmal sagen, dass es nicht darum geht, grundsätzlich englischen Fachbegriffen auszuweichen, aber es muss hier auch zulässig sein, Neuprägungen zu schaffen. Auch wenn die nirgendwo zitiert werden. (Siehe auch Löschdiskussion Halblangzeichen oder die Bemerkungen zu "Möwe unten"). Und wenn man keine eigenen Artikel für solche Zeichen hat, dann erfährt man auch nicht, dass z.B. die beiden oben dargestellten Zeichen verschiedene Unicode-Nummern haben:

ǀ

|

Auch die drei hier unten dargestellten Zeichen haben verschiedene Unicode-Nummern:

ǀǀ

||

ǁ

Die Zeichen "ǀ" und "[[|]]" konnte sogar ein technisch vorgeschulter Herr neulich nicht unterscheiden (sie lassen sich auch "auf den ersten Blick" optisch nicht auseinanderhalten), und das erste nach seiner Auskunft nicht auf seinem Computer eintippen. Um so was geht es hier. Und diese damit verbundenen Problematiken lassen sich sich durch zusätzliche griffige deutsche Benennungen sowie durch erlaubte Einzelartikel zu den Zeichen umgehen oder zumindest beleuchten. --Reiner Stoppok 17:18, 4. Jun. 2007 (CEST)

Auf jeden Fall sollten in der entstehenden Liste_von_Unicode-Zeichen zumindest die deutsche Übersetzung dastehen. Welches die beste Übersetzung ist, könnten wir auf der dortigen Diskussionseite diskutieren. Was gerade das Beispiel Seagull below betrifft, so finde ich, dass entweder "Möwe darunter" oder "Möwe unterhalb" korrekter wäre, als "Möwe unten", da das Zeichen sich unter einem anderen Zeichen und sich damit darunter/unterhalb dieses Zeichens und nicht "unten" befindet.

Diese wörtlichen Übersetzungen können meiner Meinung nach auch als Lemma benutzt werden. Da allerdings der Widerstand dagegen offenbar sehr groß ist, könnte ich mir auch vorstellen, das Zeichen direkt als Lemma zu nehmen. Das wäre zwar bei den meisten Zeichen nicht sonderlich benutzerfreundlich. Man stelle sich zum Beispiel vor, es gäbe keinen Namen für das Ausrufezeichen. Das Lemma müsste "!" lauten. Außerdem können solche Artikel nicht vorgelesen werden. Aber es wäre meiner Meinung durchaus akzeptabel. Ich glaube sogar, dass es nicht mal zwingend notwendig ist, Weiterleitungen, sei es vom englischen Namen oder der deutschen Übersetzung anzulegen. Die meisten würden den Artikel sowieso von der Liste aus anwählen oder würden das Zeichen ins Suchfeld kopieren. Gismatis 01:23, 7. Jun. 2007 (CEST)

Meinst Du ǃ (bitte anklicken) oder ! (bitte anklicken)? ... :) ... --Reiner Stoppok 23:44, 7. Jun. 2007 (CEST)

Ich bin auch strikt gegen die Neubildung von Begriffen in WP, wenn diese "Artikel" überhaupt nötig sein sollten, dann bitte unter ihrem geläufigen englischen Namen. Und bitte keine Redirects von den Pseudo-Deutschen Namen auf die englischen Namen! (Du hast schon wieder damit angefangen...). Danke --Achim Jäger 22:47, 5. Jun. 2007 (CEST)

"Pseudo-Deutsche Namen" habe ich heute nicht verwendet. Da müsstest Du schon konkreter werden. Ich verstehe also: Du lehnst generell die Verwendung der deutschen Sprache für die Unicode-Zeichen bei de.wikipedia ab. Und Dich interessiert auch nicht die Möglichkeit, sich von den damit verbundenen Fesseln hier zu befreien. --Reiner Stoppok 23:58, 5. Jun. 2007 (CEST)

Was ist denn mit "Ziffer Null" (ist schon schnellgelöscht worden...)? WP ist absolut nicht der richtige Ort um sich von "Fesseln zu befreien". WP ist eine Enzyklopädie, da kann man nicht einfach Lemmata mal eben so frei neu erfinden, nur weil einem das gefällt. --Achim Jäger 00:12, 6. Jun. 2007 (CEST)

Du nennst die deutsche Bezeichung "Ziffer Null" für das Symbol "0" also einen "pseudo-deutschen Namen", wenn ich Dich recht verstehe, und lehnst deshalb ein Redirect von "Ziffer Null" auf die englischsprachige Unicode-Bezeichnung "Digit zero" bei de.wikipedia ab. --Reiner Stoppok 00:35, 6. Jun. 2007 (CEST) PS: Und für Zeichen wie ǁ würdest Du die gross geschriebene englische Bezeichnung Unicode Character 'LATIN LETTER LATERAL CLICK' o.ä. bevorzugen, in dem Fall, in dem Du gezwungen wärest, eine Klarstellung zu einem solchen Zeichen vorzunehmen?!

Und wenn Du Dir mal die verschiedenen Unicode-Versionen anguckst, dann gibt es auch keine "geläufigen englischen Namen", sondern immer nur der letzte ist der richtige. --Reiner Stoppok 01:14, 6. Jun. 2007 (CEST)

So sehr ich mich immer freue, wenn sich ein Journalist mal die Mühe macht (meist begegnet es mir im erweiterten journalistischen Bereich), einen englischen Begriff mal vernünftig ins Deutsche zu übertragen ("Atomwaffensperrvertrag"), statt das Original ("non proliferation treaty") oder "gerne" eine Nichtübersetzung ("Nichtproliferationsvertrag") zu verwenden, so wenig ist Wikipedia der Ort dafür, irgendwelche Begrifflichkeiten einzuführen, ob es nun darum geht, deutsche Übertragungen anzubieten, oder gänzlich neue Begriffe zu entwickeln. Nun sollen bestimmte Unicodesymbole offensichtlich benannt werden dürfen, ohne sie selber zu verwenden, was eh nur für den WP-internen Gebrauch sinnvoll sein kann (von extern wird ja niemand das Lemma finden). Zugegeben ein Problem, für das mir auch keine direkte Lösung einfällt, aber ich würde derartiges komplett aus dem Artikelraum raushalten wollen, dort gehören eben keine "Einführungen von Begriffen" hin. Es ist eine verdienstvolle Aufgabe, aber nicht die der WP, so etwas einzuführen. Bestenfalls in einem anderen Namensraum zum "internen Arbeiten" (dann auch gerne "untere Möwe", was in meinen Segelohren besser klingt als "Möwe unten"), wobei mir der passende nicht einfallen will. Aber es wäre, und bliebe, flapsiger Randgruppenjargon und damit nicht WP-relevant. -- Ulkomaalainen 09:19, 6. Jun. 2007 (CEST)

Lieber Ulkomaalainen! Mir fällt dazu ein, dass man mal die Bezeichnungen für die verschiedenen Symbole der verschiedenen Unicode-Versionen auf die ständige Verbesserung der englischen Begriffe hin durchchecken sollte. Daran kann man nämlich erkennen, mit welch rasantem Tempo diese Bezeichnungen ständig verbessert wurden. Und solch ein griffiges Arbeitsbesteck soll man sich auf deutsch nicht schaffen können? --Reiner Stoppok 17:49, 6. Jun. 2007 (CEST) PS: Um Weihnachten wurde ich mal gefragt, ob ich das Lied " Silent night" kennen würde ... Gute Nacht, kann ich da nur sagen!

Meine Meinung dazu: Eine Übersetzung eines fremdsprachlichen Begriffs nimmt derjenige vor, der den Begriff als Erster im Deutschen verwendet. Wenn eine Sache also bisher nur von fremdsprachlicher Fachliteratur abgehandelt worden ist und der erste Ort, an dem der Sachverhalt auf Deutsch dargestellt werden soll, zufälligerweise die Wikipedia ist, dann kommt halt der Wikipedia auch die Aufgabe zu, den fremdsprachlichen Begriff zu übersetzen. Und ich finde eine bloße Übersetzung eines fremdsprachlichen Begriffs ist wirklich anders zu bewerten, als die Einführung eines völlig neuen Begriffs oder Wortes. Gismatis 01:23, 7. Jun. 2007 (CEST)

das ganze ist ja richtig erschreckend, ich versteh ja die beweggründe, aber vor lauter panik, keine deutschen namen zu kennen, auf solche schnappsideen zu kommen, aber sowas von daneben.. sorry, wenn ich mich da so echauffier, es gibt schon lange einen - wenn auch nicht offiziellen, aber defacto - standard der deutschen namen, und das ist die internationalisierung, die Microsoft verwendet: das kleine tool Zeichentabelle bietet für jedes (ja! jedes) zeichen der font Arial Unicode MS in jeder sprachvariante, die die firma auf den markt gebracht hat, eine übersetzung.. "möve unten", so ein kindischer quatsch (Sellin auf Rügen hat Möve oben), der deutsche name von U+033C lautet Verbindungszeichen Doppelbogen unten - mit der bitte, sich mal die seite Wikipedia:Recherche sorgfältig durchzulesen, und den artikel Seagull below hab ich verschoben -- W!B: 08:09, 7. Jun. 2007 (CEST)
und, wer flegelt, soll auch was gutes tun: @Reiner Stoppok, fall Du nicht auf Windows arbeitest, ich steh Dir jederzeit zur verfügung, die namen rauszusuchen, schreib mir einfach.. gruß und btte nichts für ungut

 ̼

Lieber W!B! Das Zeichen "Seagull below" (siehe Abb. rechts), was ich hemdsärmelig mit "Möwe unten" übersetzt habe, ist aber überhaupt kein Doppelbogen, denn bei einem Bogen reichen beide Ende bis ganz nach unten, was hier aber nicht der Fall ist. Solange Du das nicht beachtest, fürchte ich, ist Deine Weiterleitung von Seagull below nur verwirrend, ja falsch. Aus diesem Grund habe ich Deine m.E. falsche Microsoft-Benennung von "Seagull below" auf die Seite der Qualitätssicherung gesetzt. --Reiner Stoppok 13:31, 7. Jun. 2007 (CEST)

Nix gegen Microsoft, aber ich wüsste zu gerne, wo MS den deutschen Namen für das Zeichen herhat. Mich allein auf MS als Quelle zu verlassen, erzeugt in mir ein wenig Unbehagen. Schließlich sind MS schon des öfteren auch Übersetzungsfehler passiert (Das ist keine Kritik an MS, das kann jedem passieren. Unangenehm sind solche Pannen trotzdem.) Daher hätte ich gerne mehrere voneinander unabhängige Quellen für die Zeichennamen. --RokerHRO 08:56, 7. Jun. 2007 (CEST)

schon was gegen die, genau das ist ihr schmä, sie tuns einfach, setzten mit marktdominanz einen standard - und verdienen auch noch geld damit: bei 85% marktanteil ist MS die quelle -- W!B: 09:26, 7. Jun. 2007 (CEST)

Die zitierte Microsoft-Benennung "Verbindungszeichen Doppelbogen unten " für das Zeichen ist doch falsch: Bei einem Bogen gehen beide Enden bis ganz nach unten, entsprechend bei einem Doppelbogen. Und genau das müssen wir hier umgehen, unterwandern oder noch besser: bessermachen. --Reiner Stoppok 13:38, 7. Jun. 2007 (CEST) PS: Liebe Leute in Heiligendamm, sagt doch mal dem W!B, was eine Möwe ist, und wie die im Flug aussieht.

Eure Diskussion ist ja zur Zeit die lustigste auf WP (gaehn)... Nebenbei: Kreisbogen und Bogen (Architektur)#Segmentbogen. --Wrongfilter ... 21:07, 7. Jun. 2007 (CEST)

Du hier drüber! Das bei Microsoft heisst aber nicht Doppel"kreisbogen". --Reiner Stoppok 21:55, 7. Jun. 2007 (CEST) PS: Und was ist mit " ̯" (<= bitte vergrössern!) (U+032F, IPA 432)? Das ist ein Bogen! --Reiner Stoppok 21:55, 7. Jun. 2007 (CEST)

Du findest "Möve unten" also kindisch? Aber genau das bedeutet "Seagull below". Danke aber für den Hinweis mit Arial Unicode MS. Allerdings handelt es sich da offenbar um eigenständige Bezeichnungen, die sich nicht an die Unicode-Namen hält. Wir dürfen auf keinen Fall verschiedene Bezeichnungen durcheinanderbringen und immer genau unterscheiden zwischen einer Übersetzung und einer Bezeichnung anderer Herkunft. Gismatis 01:47, 8. Jun. 2007 (CEST)

Deutsche Übersetzung oder eigener deutscher Name?

Ein nicht zu unterschätzendes Problem ist, dass es für viele Unicode-Zeichen keine etablierten deutschen Namen gibt. Die englischen sind zwar in der englischen Bevölkerung oftmals ebensowenig bekannt wie die Zeichen selbst, aber immerhin sind die englischen Bezeichnungen normiert und somit eindeutig. Um das Beispiel SEAGULL BELOW zu nehmen: Wer diesen "Fachbegriff" benuzt, kann sich sicher sein, dass man das zugehörige Unicodezeichen eindeutig findet. Soll dieser nun mit "MÖWE UNTEN" oder "MÖWE DARUNTER" oder "MÖWE UNTENDRUNTER" übersetzt werden?
Ein anderes Beispiel sind die Anführungszeichen, deren genormte englische Namen sich an der Verwendung in der englischen Sprache orientieren. So ist LEFT DOUBLE QUOTATION MARK zwar im Englischen das linke (öffnende) Anführungszeichen, im Deutschen aber das schließende. Soll man dieses Zeichen nun mit "Linkes doppeltes Anführungszichen" übersetzen oder mit "Rechtes doppeltes Anführungszeichen" oder "öffnendes.." oder "schließendes.."? Es würde nur noch mehr Verwirrung stiften.
Wie würde man DASH übersetzen? mit "Strich"? Das könnte dann auch ein Schrägstrich sein, oder ein senkrechter Strich, welche im Englischen eigene Bezeichnungen haben: SLASH (STROKE) und BAR. Und jeden Zeichennamen mit DASH dieses Wort durch "waagerechter Strich" zu übersetzen wird arg lang und auch unübersichtlich.
Das Problem ist also deutlich komplexer und ich frage mich, ob wir uns das wirklich antun sollen. Bei Zeichen, die im Deutschen üblich sind und für die es eine gängige und eindeutige deutsche Bezeichnung gibt, stellt sich die Frage nicht. Aber selbst beim ¿ kann man sich streiten, ob man es als "umgedrehtes Fragezeichen" oder "umgekehrtes Fragezeichen", "kopfstehendes Fragezeichen" oder "spanisches öffnendes Fragezeichen" bezeichnen soll. Andere Zeichen, wie etwa das ª sind im Deutschen schon so unbekannt, dass überhaupt keine gängige deutsche Bezeichnung existiert, schlicht weil dieses Zeichen im Deutschen eben nicht benutzt wird und somit quasi unbekannt ist. Ein eingedeutschter Name für das Zeichen würde daran nichts ändern. --RokerHRO 08:50, 7. Jun. 2007 (CEST)

nochmal.. wird dürfen nicht übersetzen, sondern müssen recherchieren - muss ich Dir die namen auch noch raussuchen, um klarzustellen, das es die namen schon lange (und etabliert) gibt, und zwar seit etwa 1990? aber, wir könnten noch schauen, ob die ISO 10646 damals oder inzwischen eine deutschspachige regelung getroffen hat, die wäre dann natürlich sowieso verbindlich.. -- W!B: 09:26, 7. Jun. 2007 (CEST)

Das Zeichen ¿ hat bei en.wikipedia den Artikel Inverted question mark and exclamation point in Spanish, wunderbar, und alle können damit arbeiten und brauchen nicht weiter zu diskutieren. Hier aber muss alles lang und breit ausdiskutiert werden, wogegen ich nichts habe. Wogegen ich mich wehre, ist, die Flut von Löschanträgen, die gegen solche Leute anrollt, wenn man Artikel wie "umgedrehtes Fragezeichen" oder "umgekehrtes Fragezeichen", "kopfstehendes Fragezeichen" oder "spanisches öffnendes Fragezeichen" anlegt, oder von solchen Bezeichnungen ein Redirect zum "wikipedia-offiziellen" Stichwort macht. --Reiner Stoppok 13:46, 7. Jun. 2007 (CEST)

Der von dir angegebene engl. Wikipedia-Artikel behandelt aber schon ein bisschen mehr. Er erzählt die komplette Geschichte der beiden spanischen Zeichen ¡ und ¿ und das hat IMHO durchaus einen eigenen Artikel verdient. Wohingegen es Blödsinn wäre, die (gemeinsame) Geschichte usw. für diese beiden Zeichen sowoh bei ! als auch bei ? zu erzählen. Ich bin ja geneigt, ihn ins Deutsche zu übersetzen, aber ... wie sollte der Artikel dann heißen? Oder kann man das hier mit unterbringen? Ich glaube, letzteres würde genügen, dann entfällt auch die Suche nach einem geeigneten Lemmanamen. :-) --RokerHRO 10:58, 8. Jun. 2007 (CEST)

aber natürlich, mir wärs lieber, wir würden eine open-source quelle nutzen, aber ich glaub, Bitstream Cyberbit ist nicht internationalisiert, bin aber nicht sicher.. -- W!B: 09:44, 7. Jun. 2007 (CEST)

Das wird in der deutschen WP ganz einfach mit einem Satz im Artikel Fragezeichen erklärt. Und das redirect ¿ dahin haben wir auch. Das ist meiner Meinung nach völlig ausreichend.--Achim Jäger 14:33, 7. Jun. 2007 (CEST)

Wir müssen das Symbolbewusstsein hier mal gründlich erweitern. Ich zum Beispiel bin immer für eine strikte Trennung zwischen Symbol und Bedeutung. Und ʔ, ʡ, ʕ ʢ willst Du auch alle unter die Fragezeichen, lieber Achim Jäger? Das wird zu voll da, fürchte ich. Du machst damit sinnvoll angelegte Sammelartikel zur Müllkippe von Zeichenfetischisten. --Reiner Stoppok 19:56, 7. Jun. 2007 (CEST)

Deine Argumente überzeugen mich nicht. Zu der potenziellen Verwirrung: Deine Befürchtung, ein Zeichen könne nicht mehr gefunden werden, ohne die englische Bezeichnung, bezieht sich wohl eher auf das Gespräch unter Fachleuten, und um die mach ich mir ehrlich gesagt keine Sorgen. Es steht jedem frei, die englische Originalbezeichnung zu benutzen, wenn er fürchtet, anders könne es zu Missverständnissen kommen. Was dein Beispiel mit dem LEFT DOUBLE QUOTATION MARK betrifft, so würde es tatsächlich noch mehr Verwirrung stiften, wenn als Übersetzung "Rechtes doppeltes Anführungszeichen" angegeben würde, was zudem schlicht falsch übersetzt wäre. Die Übersetzung müsste natürlich "Linkes doppeltes Anführungszeichen" lauten. Über die unterschiedliche Verwendung in den verschiedenen Sprachen gibt der Artikel Anführungszeichen Auskunft. Und Dash heißt schlicht und einfach Gedankenstrich. Deine Sorge, die Übersetzung könnte zu lang und unübersichtlich (?) werden, scheint mir sehr gesucht.

Aber du hast natürlich recht, dass die Übersetzungsarbeit keine allzu leichte Angelegenheit ist. Aber diese Arbeit musst du dir ja auch nicht antun. Das erledigen Leute wie Reiner und ich. Natürlich gibt es oft mehrere Möglichkeiten, ein englisches Wort zu übersetzen. Aber dafür gibt es ja eine Diskussionsseite, wo die treffendste Übersetzung besprochen werden kann. Und vieles wiederholt sich auch: "above", "below", "inverted", "modifier letter" etc. Diese Begriffe müssen nur einmal übersetzt werden und können dann durchgängig verwendet werden. Das Ziel ist Einheitlichkeit. Gismatis 01:47, 8. Jun. 2007 (CEST) Und bitte Leute, setzt Leerzeilen zwischen eure Disskussionsbeiträge. Das verringert die Unübersichtlichkeit im Bearbeitungsfeld wenigstens ein bisschen. Und die korrekte Anzahl Doppelpunkte wären auch nicht schlecht!

Naja, wenn "Dash" stets "Gedankenstrich" bedeutet, dann ist die Übersetzung bei Minus nicht richtig.

Was die Anführungszeichen betrifft: Wenn du die Zeichennamen nicht wörtlich übersetzt, sondern die Anordnungen "links" und "rechts" an die Zielsprache anpassen willst, was machst du dann mit Zeichen, die in der Zielsprache gar nicht verwendet werden? Außerdem: wenn du “ (LEFT DOUBLE QUOTATION MARK) mit "Rechtes doppeltes Anführungszeichen" und ” (RIGHT DOUBLE QUOTATION MARK) mit "linkes doppeltes Anführungszeichen" übersetzt, finde ich das schon ziemlich verwirrend. Falsch ist es zudem auch noch, denn im Deutschen werden im Allgemeinen „ (DOUBLE LOW-9 QUOTATION MARK) als öffnendes und “ (LEFT DOUBLE QUOTATION MARK) als schließendes Anführungszeichen verwendet. --RokerHRO 11:11, 8. Jun. 2007 (CEST)

Nochmal, ich fordere ja genau die wörtliche Übersetzung. Hast du meinen Beitrag überhaupt richtig durchgelesen oder nur überflogen? Was den Artikel Minus betrifft: Dort werden die englischen Bezeichnungen nicht übersetzt sondern es werden andere deutsche Namen angegeben. Das ist ein fundamentaler Unterschied. Gismatis 12:14, 8. Jun. 2007 (CEST)

na dann noch einer, der zuerst mal WP:TF und WP:BLG lesen sollte (und zuviel textauszeichnung fett verwendet).. -- W!B: 07:00, 8. Jun. 2007 (CEST)

Seit wann verbieten WP:TF und WP:BLG Übersetzungen? Als Quelle können wir sogar Langenscheidts Taschenwörterbuch Englisch – Deutsch angeben. Und was sollte die Bemerkung mit der Textauszeichnung? Das ist lächerlich! Außerdem ist das ein sehr schlechter Stil von dir, mich nicht mal direkt anzusprechen. Gismatis 12:14, 8. Jun. 2007 (CEST)

stimmt, das war unschön, tut mir leid -- W!B: 13:55, 8. Jun. 2007 (CEST)

"stimmt, das war unschön, tut mir leid" (Benutzer:W!B:) --Reiner Stoppok 15:29, 8. Jun. 2007 (CEST)

Mich stört zwar ebenfalls dieses Festklammern an der englischen Bezeichnung, vor allem wenn mal wieder jemand meint, sie müsste unbedingt in Majusklen erfolgen, aber eine Übersetzung ist nicht unproblematisch. So wurde für viele Schriften der Name aus der englischen Transkription gebildet, die sich häufig von der deutschen Umschrift oder der sprachunabhängigen Transliteration unterscheidet, wenn es sowas jeweils überhaupt gibt. Außerdem ist teilweise eine wörtliche Übersetzung nicht sinnvoll, da die englische Bezeichnung einfach schlecht ist, z.B. weil sie aus älteren. evtl. lokalen Standards übernommen worden ist oder auch durch mangelnde Sachkenntnis. (Bei so einem komplexen Thema irren auch Experten ab und zu.) Ein gutes Beispiel dafür sind die bereits erwähnten Anführungszeichen, bei denen man sich besser durchgehend an die 6-9-Symbolik gehalten hätte.

Die nächste Frage, die die meisten hier zu verneinen scheinen, ist natürlich, ob Wikipedia der richtige Ort für solch eine Übersetzung ist, vielleicht sollte das eher auf Decode Unicode geschehen. Eine deutsche Ausgabe der betreffenden ISO-Norm bzw. eine DIN-Adaption wäre natürlich toll, wird es aber bis auf weiteres nicht geben, da niemand sich den riesigen Aufwand für den geringen Nutzen antut (d.h. bezahlt).

Microsofts Übersetzungen sind teilweise deutlich ad hoc und unprofessionell, aber man kann durchaus für ihre Aufnahme argumentieren, da Benutzer auf sie stoßen werden und danach suchen könnten – als Lemma taugen sie allerdings höchstens nach eingehender Prüfung. Christoph Päper 11:53, 8. Jun. 2007 (CEST)

@Gismatis: WP:TF und WP:BLG verbieten Übersetzungen: nach den Urheberrechtsgesetzen der EU ist eine übersetzung eine eigenleistung mit nötiger schaffenshöhe und daher geschützt: also ist jede übersetzung ein "erschaffen einer Primärquelle" - und genau das verbieten diese beiden richtlinien. bei texten ist jede übersetzung eine interpretation, und kann mit nötiger sorgfalt und angabe des originaltextes kontrolliert werden. wenn es sich aber um einen einzelnen begriff handelt, ist es echte begriffsfindung, weil der begriff damit erstmalig in die deutsche sprache eigeführt wird. das dürfen wir nicht: eine enzyklopädie beschreibt die welt, aber gestaltet sie nicht (immer nur auf "Primärquelle" einzelner themen bezogen, das die WP als ganzes die welt mitgestaltet, ist sowieso was anderes, darin verzetteln wir uns lieber garnicht, und das das ein heres ziel ist, gegen das überall verstossen wird, brauchen wir hier auch nicht erörten)

in dem fall ist es klar: es gibt seit 15 jahren die deutschen worte. deren qualität zu beurteilen, ist nicht aufgabe der WP - wie andernorts gesagt, wenn wir noch andere brauchbare quellen für übersetzungen ins deutsche haben, verschiedene übersetzungen gegeneinander abzuwägen, das passt dann schon, das ist Wikipedia:Recherche - nochmal (ich weiß, es ist hart, besonders in dem fall): jede schlechte information von ausserhalb der WP ist besser als eine, die die WP erfindet. also: fleissig suchen, es wär doch gelacht, wenn die MS-übersetzer die einzigen sind, die das je gemacht haben. wo sind unsere linuxer, wo die open-sourcler, und wo die sprachwissenschaftler, die auf der uni gelernt haben, wie jedes einzelne teil in fachkreisen heisst? ich trag noch immer auf die ISO 10646 an, die muss es doch deutsch geben - und wenn nicht, der tipp mit decodeunicode.org ist super: dort begriffe etablieren ginge schon, dann schreiben wir hier drüber, ohne uns unseren mühsam aufgebauten ruf zu zerstören ;) -- W!B: 13:55, 8. Jun. 2007 (CEST)

jetzt ist mir eingefallen, wie ich das kurz sagen kann: wenn der artikel Möve unten heisst, machen wir uns lächerlich, wenn er Verbindungszeichen Doppelbogen unten heisst, macht sich die Firma Microsoft lächerlich, und wir berichten nur darüber - das ist der unterschied -- W!B: 14:28, 8. Jun. 2007 (CEST)

W!B, ich bin baff! Wie du über den Umweg der Urheberrechtsgesetze der EU und deren Definition von Übersetzungen als Primärquelle zum Schluss kommst, dass WP:TF und WP:BLG Übersetzungen verbieten, das ist schon erstaunlich! Dieser Kunstgriff ändert aber nichts. Dass das Urheberrechtsgesetz der EU Übersetzungen als Primärquelle definiert (was ich dir einfach mal glaube) ist nämlich völlig irrelevant. Das ist eine rein juristische Definition und für die enzyklopädische Arbeit hier nicht von Bedeutung. Auch bei der Übersetzung eines ganzen Textes müssen mitunter einzelne Begriffe übersetzt werden, die es in dieser Verwendung im Deutschen bisher nicht gab. Und selbst wenn man einen Begriff in der Originalsprache belässt, die Angabe einer Übersetzung erhöht die Benutzerfreundlichkeit, vor allem wenn es sich um einen Begriff aus einer anderen Sprache als englisch handelt. Hier ist ein Beispiel, und deren gibt es in der Wikipedia viele. Es bleibt dabei, WP:TF und WP:BLG verbieten Übersetzungen nicht. Gismatis 04:02, 9. Jun. 2007 (CEST)

汉语拼音文字? Im Lexikon steht phonetisches Alphabet der chinesischen Sprache, ich persönlich finds wörtlich etwas holprig, aber zeichenweise übersetzung hat auch ihre vorteile.. wenn Du was anderes meinst, was? -- W!B: 10:32, 9. Jun. 2007 (CEST)

Lieber W!B:! Ich bitte Dich um stärkere Konzentration. Bitte hübsch beim Thema bleiben. Du wirst bestimmt ein Dutzend sinnvoller Übersetzungen von dem zitierten "汉语拼音文字" zusammenbekommen, wenn Du nur anfängst, einmal richtig darüber nachzudenken. --Reiner Stoppok 14:42, 9. Jun. 2007 (CEST) PS: Welches Lexikon meintest Du hier?

Entdeckt: Der Artikel Breve (Unterzeichen) enthält folgenden Abschnitt:

Der Zeichensatz Unicode enthält die folgenden Zeichen mit Breve darunter:

• Großbuchstabe H mit Breve darunter (Ḫ) U+1E2A
• Kleinbuchstabe H mit Breve darunter (ḫ) U+1E2B
• Kombinierende Breve darunter (kann mit jedem Buchstaben kombiniert werden) U+ 032E

Da wurde also bereits völlig abseits dieser Diskussion munter übersetzt! Gismatis 04:36, 11. Jun. 2007 (CEST)

Bist Du da etwa überrascht? Da gibt es noch viel mehr von. --Reiner Stoppok 18:27, 11. Jun. 2007 (CEST) PS: Hier hat das Problem auch schon mal "jemand" im großen Stil gelöst: Traduction française officielle de l’ISO/CEI 10646 et Unicode.

Es gibt also die folgenden Möglichkeiten für die Benennung des rechts abgebildeten Unicode-Symbols falls man darüber einen Artikel schreiben möchte (Fallbeispiel: U+033C):

 ̼

(Diesen Wahlzettel bitte ergänzen und verbessern.):

1. "Verbindungszeichen Doppelbogen unten" (so bei Microsoft, siehe z.B. unten: Zeichentabelle "Arial Unicode MS")

**Die Qualität dieser Bezeichnung ist in diesem Falle fragwürdig, da es sich hier nicht um Bögen handelt. (Siehe auch Löschdiskussion 7.6.2007 )

2. "COMBINING SEAGULL BELOW" oder "Combining seagull below" (nach Unicode)

**Dazu die Fragen: Wie soll mit verschiedenen Bezeichnungen einzelner Symbole/Zeichen in den verschiedenen Unicode-Versionen umgegangen werden? Soll die GROSSSCHREIBUNG streng beibehalten werden? Die offizielle französische Übersetzung lautet 033C DIACRITIQUE MOUETTE SOUSCRITE

3. "Verbindungszeichen Möwe unten" (wörtliche Übersetzung der Unicode-Bezeichnung)

**Frage: Darf man mit solchen Neubenennungen Lemma anlegen, soll man Redirects von ihnen aus auf die "offiziellen" englischen Unicode-Bezeichnungen oder auf die deutschen "halboffiziellen" (und manchmal unpräzisen) Microsoft-Bezeichnungen machen? (Siehe auch: Verbindungszeichen).

4. Verwendung von Kurzwörtern im Text, hier z.B. das ebenfalls oft verwendete "Seagull below" (wobei die dt. wörtlich übersetzten Kurzbezeichnungen, wie beispielsweise "Möwe unten" oder auch "Möve unten", bei manchen auf Ablehnung stossen), aber nicht als Lemma.

Frage: Hiess das nicht mal "Seagull below" in einer alten Unicode-Version? Wie soll man mit den verschiedenen Benennungen einzelner Zeichen in den verschiedenen Unicode-Versionen umgehen? --Reiner Stoppok 21:11, 8. Jun. 2007 (CEST) PS: Hier eine Möwe unten, allerdings nicht im Flug abgebildet

5. Das Zeichen direkt als Lemma nehmen

Nachteil: Eingabeprobleme. Deutsche Namensgebung wird evtl. nicht ausreichend geklärt.

6. U+033C (die Unicode-Kodierung) als Lemma nehmen

Nachteil: Die Bezeichnung kann sich niemand merken. Deutsche Namensgebung wird evtl. nicht ausreichend geklärt.

7. Das Zeichen soll kein eigenes Lemma erhalten, sondern redirected werden nach Internationales Phonetisches Alphabet und dort eingebaut werden.

Eine derzeit häufig in den Löschdiskussionen vertretene Position. Das Problem ist, dass sich viele Unicode-Zeichen nicht eindeutig bestimmten Sachgruppen zuordnen lassen, wie es in diesem Falle die Lautzeichen des IPA wären. Viele Unicode-Sybole und -Zeichen haben mehrere Bedeutungen und gehören zu mehreren Sachgruppen.

8. Das Zeichen soll kein eigenes Lemma erhalten, sondern redirected werden zu einem Lemma über einen Unicode-Block und dort behandelt werden

9. Möwe (diakritisches Zeichen)

Siehe mein Beitrag am Ende des Abschnitts Weiteres zu Artikelnamen. Gismatis 04:14, 11. Jun. 2007 (CEST)

10. Keine sinnlosen Lemmata, keine sinnlosen Weiterleitungen. Ein eigenes Lemma nur fuer Zeichen mit "Alleinstellungsmerkmal", d.h. genuegend interessante Informationen existieren. Ansonsten nur Behandlung in Listen. Relevanzkriterien ausarbeiten und Aufnahme in WP:RK beantragen

11. Möwe unten (diakritisches Zeichen)

In Anlehnung an die offizielle französische Übersetzung DIACRITIQUE MOUETTE SOUSCRITE. So wird auch die Position genauer anzugeben.

(bitte diesen Wahlzettel ergänzen und verbessern, auch optisch)

Weblinks

• Unicode Character 'COMBINING SEAGULL BELOW' (U+033C)

• [2]

Datei:Verbindungszeichen Doppelbogen unten.jpg

Screenshot Zeichentabelle

____________________

Weiteres zu Artikelnamen

 ;) gut gekontert.. ich wär ja noch immer dafür, einen sammelartikel für den ganzen Block 0300–036F Combining Diacritical Marks unter Kombinierende diakritische Zeichen zu erstellen, damit drücken wir uns elegant vor dem namensproblem, bis die wogen sich geglättet haben, später teilen können wir immer noch, wenn der artikel dann die 150kB-Marke sprengt.. dann wissen wir vielleicht auch, in welcher sprache die zeichen überhaupt vorkommen, und was für einen sinn sie haben: Bußmann, Hadumod: Lexikon der Sprachwissenschaft. Stuttgart 2002 steht in Diakritische Zeichen, vielleicht hat der was - es wird wahrscheinlich heutzutage schon schwer, auch nur redirs der form U+036F anzulegen, und noch genug zeichen mit konfliktpotential (ich hätte ja noch immer ∮ redir Kurvenintegral gern, aber derzeit trau ich mich nicht, also bitte jetzt nicht anlegen).. -- W!B: 10:08, 9. Jun. 2007 (CEST)

Lieber Benutzer:W!B:! Bei dieser Diskussion hier geht es a) nicht speziell um Zeichen aus bestimmten Sprachen oder Schriften, b) nicht speziell um die Gruppe der diakritischen Zeichen aus Unicode, c) nicht darum, Grüppchen zu einzelnen Unicode-Blöcken zu bilden (obwohl diese Idee natürlich Sinn macht). Es geht einzig und allein darum, für diejenigen "Wikipedianer" Möglichkeiten auszudiskutieren, die für ein beliebiges Unicode-Zeichen Artikel schreiben möchten. --Reiner Stoppok 14:32, 9. Jun. 2007 (CEST) PS: "Der" von Dir zitierte Hadumod Bußmann ist übrigens eine Frau und hat im Lexikon der Sprachwissenschaft ganz andere Sorgen. Ich würde das Wort "Verbindungszeichen" (statt:Kombinierende) immer bevorzugen. Dazu habe ich auch ein Lemma angelegt.

oh, peinlich, ich bitte sie hiermit um verzeihung, ich bin da nicht heikel - was ich damit gemeint hab, ist, dass artikel zu gewissen unicodezeichen wohl sinnvoll sind, aber nicht prinzipiell. Du hast mit ! eh ein gutes beispiel gegeben (LA-seite): in dem fall hielte ich es sinnvoll, denn der sachverhalt „Rufzeichen“ ist nicht ident mit dem sachverhalt „!“ - Rufzeichen ist auch "¡", und "!" ist auch Fakultät, Klicklaut, … „Satzzeichen“ ist es dann keines - tatsächlich widerspricht der artikel jetzt den grundsatz ein artikel = ein sachverhalt (und in dem artikel fehlt die unicode nummer überhaupt) - ich denke dass es wichtiger wäre, sich auf den sachverhalt „Schriftzeichen“, statt auf „Unicodezeichen“ zu konzentrieren: unicode gibt ja nur einen standard vor - wie würde dann der artikel zum schriftzeichen «!» selbst heissen? ich denke, dass wär ein gutes beispiel, eine "Namenskonvention" für schriftzeichen-artikel zu entwickeln, die dann auf alle unicode-artikel funktionieren würde -- W!B: 05:15, 10. Jun. 2007 (CEST)

Eine Namenskonvention für Schriftzeichen ist nötig. Diese Diskussion hier sprengt den Rahmen dieser Diskussionsseite. Wie aus meinem Beitrag weiter unten klar wird, stimme ich dir zu, beim Anlegen von Artikeln von Schriftzeichen auszugehen und nicht so sehr von einzelnen Unicode-Zeichen. Gismatis 04:28, 11. Jun. 2007 (CEST)

PS ich hab eine überschrift eingefügt, und ausgerückt

.. und Verbindungszeichen find ich gut - sollen wir den wir die windows-übersetzung als redir ansetzen, oder mal aussen vorlassen? wenn die LA-disk den windows-namen bei U+036F akzeptiert, und auch, dass es einen artikel zu genau dem einen zeichen gibt, wäre er dann in dem fall auch relevant - akzeptiert sie in nicht, dann sollte er wohl auch rot bleiben? -- W!B: 05:19, 10. Jun. 2007 (CEST)

noch ein nachtrag, grad gefunden..: U+01C3 „Lateinischer Buchstabe retroflexiver Click“ (wie üblich, MS Zeichentabelle) ! steht nicht für den Klicklaut, sondern ! - er wird ersetzt durch dieselbe font, darum ist er nicht rot: das hiesse, formal gesehen ist das ein {badname}-problem, und müsst über eine BKL ! steht für.. gelöst sein, da aber das Rufzeichen weitaus primär ist, im artikel Ausrufezeichen ein {Dieser Artikel|beschreibt das Unicodezeichen U+0021; zu U+01C3 siehe Postalveolarer Klick.} stehen.. - und U+01C3 dorthin redirecten -- W!B: 05:47, 10. Jun. 2007 (CEST)

Wunderbar, was Du alles entdeckst. Aber mit der Verfeinerung der Wahlliste für einen demokratischen Abstimmungsprozess sind wir damit um keinen Millimeter weitergekommen. --Reiner Stoppok 15:02, 10. Jun. 2007 (CEST)

"Kombinierende Zeichen" heißen die Dinger in der Zeichenpalette von Apple. Aber auch "Verbindungszeichen" ist gut. Wichtig ist vor allem eins: Diese Zeichen gehen eine nicht mehr trennbare Verbindung mit dem Trägerzeichen ein. Anders formuliert: Sie wirken kombinierend. Das scheint mir das Hauptmerkmahl dieser Zeichen zu sein. Alle anderen modifizierenden Zeichen, die das nicht tun, heißen bei Unicode "Modifier letters". Gismatis 04:19, 11. Jun. 2007 (CEST)

Ich bin mir jetzt sicher, dass die Übernahme der Unicodebezeichnungen als Lemma, sei es in der Form des englischen Originals oder der deutschen Übersetzung der falsche Weg ist und nicht zu einer Einheitlichkeit führen kann. Was wir brauchen ist ein Schema, das sich auf alle diakritischen Zeichen (und nur um die geht es mir jetzt im Moment) anwenden lässt. Dazu Folgendes: Im Artikel Diakritisches Zeichen findet sich eine Auflistung diverser diakritischer Zeichen. Da steht dann z. B. „Komma, untergesetztes“, „Unterstrich“ und „Punkt darunter“ (da war jemand bereits sehr kreativ, von Einheitlichkeit keine Spur). Die haben alle eigene Artikel. Wenn man den Links folgt, kommt man zu den Artikeln Komma (Unterzeichen), Makron (Unterzeichen) und Punkt (Unterzeichen). Mit Hilfe des Begriffs „Unterzeichen“ wurde hier Einheitlichkeit erzielt. Inspiriert durch diese Einheitlichkeit schlage ich also vor, das Lemma zu einem Artikel über diakritische Zeichen nach einem der folgenden Schemas zu wählen:

• Name des diakritischen Zeichens z. B. Makron

Diese Möglichkeit eignet sich nur, wenn der Zeichenname bereits eindeutig ist. Deshalb sollte eher diese Möglichkeit zur Anwendung kommen:

• Name des diakritischen Zeichens (diakritisches Zeichen)

Für  ̼ also Möwe (diakritisches Zeichen). Ja, richtig! Möwe als Name des diakritischen Zeichens, genauso wie Breve, Akut usw. Man könnte auch die Bezeichnung „Unterzeichen“ aufgreifen:

• Möwe (Unterzeichen)

Daran finde ich problematisch, dass die Unterscheidung eines diakritischen Zeichens nach der Setzung über oder unter einem Buchstaben oft nicht relevant genug ist. Auch frage ich mich, woher die Bezeichnung „Unterzeichen“ stammt, und ich vermisse den Begriff „Überzeichen“ als Äquivalent zum „Unterzeichen“ für übergesetzte Diakritika. Mein Favorit wäre die zweite Möglichkeit, und die trage ich deshalb auch oben ein. Ich weiß, das führt jetzt einen neuen Ansatz ein. Aber deutlich wird der Vorteil dieser Methode, wenn es zu einem abstrakt betrachtet einzigen Zeichen mehrere Unicode-Zeichen gibt. Ein Beispiel ist das Zeichen Ring, zu dem es sogar einen Artikel gibt, wenn auch unter der auch nicht gerade deutschen Bezeichnung Kroužek. Auch behandelt der Artikel nur einen Teilaspekt dieses Zeichens. Der englische Artikel zeigt eher, was ich meine. In Unicode gibt es vier Ring-Zeichen: Allein stehend je oben und unten sowie kombinierend je oben und unten. Also: Vier Zeichen in Unicode = ein Zeichen abstrakt betrachtet = ein Artikel = ein Lemma. Es ist offensichtlich, dass hier die Unicode-Benennungen kein geeignetes Lemma bieten. Gismatis 04:05, 11. Jun. 2007 (CEST)

 Pro das erscheint mir ein ausgezeichneter ansatz - und das möchte ich auch sagen, mit dieser methode seh ich auch nicht mehr ein problem mit WP:TF, weil es sich (wie bei dem :en beispiel) eindeutig um einen "artikeltitel" handelt, der sofort klarstellt, dass "ring" deskriptiv als "ringförmig" gemeint ist und das zeichen fachlich jeweils spezifische namen hat - eben Kroužek, keinen in Å (und dort auch klargestellt) oder r̥ , und auch "ring below" ist dort nur überschrift - das würde ich ;) dann auch für Möwe (diakritisches Zeichen) gelten lassen, wenn er ausdrücklich klarstellt, dass das eine beschreibung im sinne des fachlich korrekten (weil gernormten) SEAGULL ist, und nicht der fachausdrück - so ists keine begriffsetablierung, weil dann niemand sagen kann: "in der WP steht Möwe, also heisst es so.." oder ein sprachwissenschaftler in zehn jahren in einer arbeit feststellt, dass der name am 11.06.2007 das erste mal im deutschen belegbar ist, und zwar in der WP.. -- W!B: 06:52, 11. Jun. 2007 (CEST)

Das freut mich sehr, dass ich es geschafft habe, einen Vorschlag zu bringen, dem du zustimmen kannst! Übrigens, wird das Zeichen eigentlich wirklich "Seagull" genannt, oder ist das nicht auch einfach eine beschreibende Erfindung des Unicode-Konsortiums? Ansonsten würden wir nämlich wieder Begriffsetablierung betreiben, wenn wir einfach schrieben, das Zeichen werde im Englischen "Seagull" genannt. Gismatis 03:15, 13. Jun. 2007 (CEST)

Unterzeichen klingt nach einer sehr holprigen Übersetzung, so als ob es zu gewissen Zeichen noch eine "Unterkategorie", nämlich "Unterzeichen" geben würde oder sowas, was natürlich Blödsinn ist.

Außerdem: Wie nennt man dann die Diakritika, die über oder neben dem Buchstaben stehen? Was wird z. B. aus COMBINING RING ABOVE? Ein Kombinationszeichen Ring drüber? Oder Kombinierender Ring drüber oder Ring (Überzeichen)? Ich finde "(Diakritisches Zeichen)" als Lemmazusatz vollkommen ausreichend, dort können dann die Varianten mit ABOVE und BELOW gemeinsam behandelt werden. Oder? --RokerHRO 11:09, 11. Jun. 2007 (CEST)

Richtig. In den allermeisten Fällen wird eine Aufteilung von Artikeln nach Plazierung des Zeichens nicht sinnvoll sein. Wenn es aber doch vorkommt, wie schon beim Makron (Unterzeichen), muss man das irgendwie im Lemma unterbringen. Die Bezeichnung "Unterzeichen" sollte nochmal überprüft werden. Als Alternative fände ich den lediglich beschreibenden Ausdruck "übergesetzt" eine gute Lösung.

Was mir an Makron (Unterzeichen) auch nicht so gefällt, ist, dass der Leser meinen könnte, beim Makron selbst handle es sich um ein Unterzeichen, was natürlich falsch ist. Korrekter wäre deshalb meiner Meinung nach das Lemma Makron als Unterzeichen. Gismatis 03:15, 13. Jun. 2007 (CEST)

Verzeiht mir, wenn ich Euch ins Wort falle. Der Vorschlag von Gismatis macht Sinn. Es ist ein Ausdruck, der sich sowohl von Microsoft als auch von Unicode losgelöst hat. Plastisch, leicht zu merken. Der Ausdruck "Verbindungszeichen", den Microsoft hier bei der Benennung dieses Zeichens mitverwendet (und auch für viele andere Zeichen), und der an sich nicht schlecht ist, ist in diesem Fall überflüssig, da die diakritischen Zeichen sowieso Verbindungszeichen bzw. "kombinierende Zeichen" (ein holpriger Ausdruck) sind. Das Wort "Verbindungszeichen" wäre prima dafür geeignet, ein oben, unten, rechts, links, Mitte usw. nachzustellen (statt Überzeichen, Unterzeichen, Mittezeichen (?) usw.). Das Problem sehe ich bei den Symbolen, die an mehreren Stellen vorkommen (die Möwe fliegt ja nur unten herum). Wie, lieber Gismatis, würdest Du mit der Möwe umgehen, gesetzt den Fall, sie würde auch oben und in der Mitte vorkommen, wie beispielsweise bei meinem (qualitativ minderwertigen und sicherlich noch umzubenennenden) Testballon Tilde (IPA)? Viele Bezeichnungen bei Unicode und Microsoft sind ja nur deshalb umständlich, weil sie sich von vielen ähnlichen Zeichen irgendwie abheben mussten. Irgendwie sollten wir uns deren Erfahrungen im Umgang mit der riesigen Zeichenmenge auch zunutze machen. Die bei "Tilde (IPA)" aufgeführten Beispiele für das Vorkommen in den Unicode-Namen sind keineswegs vollständig. --Reiner Stoppok 17:52, 11. Jun. 2007 (CEST) PS: Suchwort: RING (Unicode)

Welchen Ausdruck meinst du jetzt? Diakritisches Zeichen? Ich habe dir weiter oben in diesem Abschnitt schon geschrieben, dass ich diakritische Zeichen und Verbindungszeichen nicht wirklich für dasselbe halte. Es ist zwar oft dasselbe, weil für die Darstellung am Computer meist ein Verbindungszeichen zur Anwendung kommt. Der Ausdruck diakritisches Zeichen bezieht sich meiner Ansicht nach auf die Verwendung als Schriftzeichen, völlig unabhängis vom verwendeten Zeichensatz und von der Kodierung. Das bedeutet, das Zeichen ^ in â ist zwar ein diakritisches Zeichen, aber es ist kein Verbindungszeichen, da â als ein Zeichen kodiert ist. Der Begriff Verbindungszeichen (combining characters) bezieht sich demnach ausschließlich auf die Art des Zeichens am Computer, jedenfalls taucht der Begriff nur in dieser Verwendung in der Unicodetabelle auf. Dort bezieht er sich auf Zeichen, die mit dem Trägerzeichen verschmelzen.  ̂ (U+0302, COMBINING CIRCUMFLEX ACCENT) ist somit ein Verbindungszeichen ("kombinierendes Zeichen" gefällt mir übrigens besser). Für die Darstellung muss man es auf ein Leerzeichen setzen. Das Zeichen ^ (U+005E, CIRCUMFLEX ACCENT) braucht kein Trägerzeichen. Es kann zur Darstellung des abstrakten Zeichens Zirkumflex dienen, das heißt, wenn man einfach ein einzlnes Zirkumflex darstellen will. Oder liege ich hier falsch? Anders gefragt, bezieht sich "combining character" ausschließlich auf Unicode oder nicht?

Nun zu deiner Frage. Wenn ein diakritisches Zeichen in unterschiedlichen Plazierungen vorkommt (was meistens der Fall ist), würde ich zuerst die Verwendung in bestimmten Bereichen behandeln und innerhalb dieser Bereiche nach Plazierung, oder umgekehrt, je nach dem, was sinnvoller ist. Die Plazierung würde ich nur mit beschreibenden Worten behandeln. Für die Kodierung in Unicode würde ich einen separaten Abschnitt oder eine Tabelle einrichten, wo erläutert wird, welche Plätze das Zeichen in Unicode belegt. Was dein Artikel Tilde (IPA) betrifft, so frage ich mich, ob man nicht einfach im Artikel Tilde einen entsprechenden Abschnitt einrichten könnte. Alle Angaben zu Unicode würde ich sowieso im Artikel Tilde unterbringen, weil es um das Zeichen an sich ausschließlich im Hauptartikel gehen soll. Gismatis 03:15, 13. Jun. 2007 (CEST)

Wie weit soll man sich im Deutschen aber von ISO/CEI 10646 und Unicode selbst und von der offiziellen französischen Übersetzung von ISO/CEI 10646 und Unicode (Traduction française officielle de l’ISO/CEI 10646 et Unicode) entfernen? Und von den deutschen Microsoft-Bezeichnungen (Zeichentabelle: Arial Unicode MS)? Ich finde, es müsste bei de.wikipedia eine Art Metaebene für die deutschen Unicode-Bezeichnungen geben, um nicht völlig ins internationale teminologische Abseits zu geraten. Von dieser Ebene aus könnte man dann ja sehen, wo das Zeichen überall in Einzelartikeln vorkommt. Zugegebenermaßen sind nicht alle Symbole lexikontauglich für einen Einzelartikel. Wir müssen die Unicode-Zeichen doch aber des öfteren irgendwie benennen, ohne für sie gleich einen Artikel schreiben zu wollen. Lieber Gismatis, für mich wird das hier immer verwirrender ... --Reiner Stoppok 17:27, 13. Jun. 2007 (CEST) PS: "DIACRITIQUE MOUETTE SOUSCRITE" heisst das Verbindungszeichen Möwe unten (Combining seagull below) übrigens auf französisch.

Der Gegenstand ist komplexer, als wir gedacht haben. Zu deinen Fragen: Um die deutsche Übersetzung der Unicode-Bezeichnungen zu besprechen, ist die Diskussionsseite des Artikels Liste von Unicode-Zeichen geeignet. Außerdem empfehle ich die Schaffung einer Namenskonvention für Schriftzeichen. Wie weit soll sich die deutsche Bezeichnung der Unicode-Zeichen von der Originalbezeichnung entfernen? Antwort: So wenig wie möglich! Wo etablierte deutsche Bezeichnungen existieren, können wir diese verwenden. Wo dies nicht der Fall ist, halten wir uns am besten möglichst eng an die englische Originalbezeichnung. Dann können wir nichts falsch machen und die Gefahr des Vorwurfs der Begriffserfindung wird mit dem Hinweis begegnet, es handle sich lediglich um Übersetzungen, was aus dem Artikel auch klar werden muss. Alles andere ist nach den Wikipedia-Richtlinien nicht gestattet. Inwiefern diese Übersetzungen als offizielle Bezeichnungen aufgefasst werden und Eingang in die Fachsprache finden, ist nicht unser Problem. Die Wikipedia beeinflusst den Sprachgebrauch sowieso, indem sie zur Verbreitung von Begriffen und Bezeichnungen beiträgt. Und noch was: Vergiss Arial Unicode MS. Die dortigen Bezeichnungen können allenfalls als Inspiration dienen. Zuerst muss jetzt der Artikel Liste von (nicht der?) Unicode-Zeichen ausgebaut werden. Ich selbst werde mich bei der Artikelarbeit wahrscheinlich eher zurückhalten. Ich werde mich aber gerne an der Übersetzungsdiskussion beteiligen. In der neu zu schaffenden Namenskonvention Schriftzeichen kann diskutiert werden, wie verwandte Unicode-Zeichen in einem Artikel zusammengefasst werden, und wie die Lemmas lauten sollen. Soviel zu meinen Empfehlungen.

Ich hoffe, ich konnte mit dieser Antwort deine Verwirrung lindern. Die ganze Arbeit wird viel Zeit brauchen. Es gibt keine einfache Lösung. Wir werden noch viel diskutieren und überlegen müssen, und viele Fragen werden erst mit der Zeit beantwortet werden können. Gismatis 05:33, 16. Jun. 2007 (CEST)

Welcher Weg führt zu solch einer Namenskonventionfür Schriftzeichen? - Noch ein kurzer Zwischenruf: Liste von Unicode-Zeichen nur solange, wie sie nicht vollständig ist. Dann soll sie natürlich "Liste der Unicode-Zeichen" heissen! Die Arbeit daran schreitet ja bereits munter fort ...--Reiner Stoppok 11:32, 16. Jun. 2007 (CEST)

Zum Lemma äußere ich mich noch auf der Diskussionsseite. Was die Schaffung einer Namenskonvention betrifft, empfehle ich folgendes Vorgehen:

1. Richte eine Unterseite in deinem Benutzernamensraumm ein, z. B. Benutzer:Rainer_Stoppok/Baustelle, auf der die Namenskonvention aufgebaut werden kann
2. Lade auf Wikipedia_Diskussion:Namenskonventionen Interessierte dazu ein, bei der Schaffung der Namenskonvention mitzuarbeiten
3. Wenn die Namenskonvention Gestalt angenommen hat, kann sie nach Wikipedia:Namenskonventionen/Schriftzeichen verschoben werden

Gismatis 18:33, 16. Jun. 2007 (CEST)

Voilà! Bitte optisch und inhaltlich verbessern. --Reiner Stoppok 23:26, 16. Jun. 2007 (CEST) PS: Siehe auch Löschdiskussion 7.6.2007

ǃ versus ! (bitte anklicken)

Das erste Symbol ist kein Ausrufezeichen, das zweite kein Postalveolarer Klick. Soll man das erste Zeichen unter dem zweiten behandeln? --Reiner Stoppok 21:45, 10. Jun. 2007 (CEST)

Natürlich nicht! Ein Verweis auf das ähnlich/gleich aussehende (und wahrscheinlich auch aus dem Ausrufezeichen hervorgegangene) IPA-Zeichen für den Klicklaut ist aber durchaus angebracht, so wie es derzeit ja im Artikel ! auch gemacht worden ist. --RokerHRO 22:24, 10. Jun. 2007 (CEST)

ähem, toll, und wie hast Du das gemacht, bei mir hat das nicht geklappt - würd mich aber nicht wundern, wenn die MS-zeichentabelle das zeichen irgendwie verschluckt.. -- W!B: 06:56, 11. Jun. 2007 (CEST)

• [3]

Grundsatzdiskussion

Eigentlich sollte eine grundsätzliche Diskussion darüber geführt werden, ob Unicodezeichen als Einzellemma überhaupt relevant sind und danach unter welcher Bezeichnung. Eine Abstimmung über den Namen eines einzelnen Zeichens halte ich in diesem Zusammenhang offengesagt für Unsinn. Ich habe mich mal hier [4] dazu geäussert. Alauda 18:35, 9. Jun. 2007 (CEST)

Dieser Vorschlag kann übergangen werden und ist schon dadurch überholt, dass es bereits seit langem jede Menge Artikel dazu gibt. Offenbar hast Du die Diskussion hier obendrüber nicht verfolgt. Falls Dich das Thema überhaupt interessiert, schlage ich Dir vor, Dich zunächst einmal an den Standpunkten von Benutzer:Gismatis in dieser Diskussion zu orientieren. --Reiner Stoppok 18:58, 9. Jun. 2007 (CEST)

Hast Du eigentlich übersehen, dass dauernd Löschanträge gegen Unicodeartikel gestellt werden? So ganz überholt ist dieser Vorschlag wohl nicht, es sei denn, man will über jeden einzelnen Unicodeartikel eine Löschdiskussion führen, wie das jetzt der Fall ist und noch schlimmer werden könnte, wenn noch mehr Artikel angelegt werden. Scheinbar ist das auch kein Dauerstreit zwischen dir und Benutzer:Achim Jäger, da auch andere Benutzer Löschanträge gestellt haben. (Anmerkung: Stimmt. Die anderen aber aus (berechtigten) inhaltlichen Gründen. Nicht wegen der Überschrift des Lemmas. --Reiner Stoppok 20:27, 9. Jun. 2007 (CEST))

Im Prinzip ist es wichtig, dass

• Ein klarer Konsens über die Relevanz von Unicodeartikeln erzielt wird
• Ein klarer Konsens über die Bezeichnung der entsprechenden Lemma erzielt wird

Auf diesen Konsens kann man sich dann in Löschdiskussionen beziehen. Erst dann macht es Sinn weitere Artikel anzulegen. Ich habe auf der Löschseite z.B. den Vorschlag gemacht prinzipiell nur maximal 2-Byte-Zeichen als lemmatauglich anzusehen, damit es ein generelles und objektives Kriterium gibt, unter welchen Bedingungen Zeichen relevant sind und wir nicht 190000 Unicodeartikel verfassen. Alauda 19:19, 9. Jun. 2007 (CEST)

Wenn Du mein Freund sein willst, liest Du jetzt bitte, was Gismatis hier oben drüber so alles gesagt hat. (Ich selber war manchmal zu aufgeregt und habe mich von Studenten im Grundstudium und kräftigen Jünglingen, die hier nicht her gehören, zu weitschweifigen Diskussionen verleiten lassen. Das hier ist aber Männersache, da müssen echte Kerle ran.) Vielleicht schreibst Du mal einen Artikel zu den "2-Byte-Zeichen", damit Dir alle folgen können. Wir waren hier obendrüber bereits schon so weit, die wesentlichen Standpunkte umrissen zu haben, daher war ein neuer Absatz überflüssig. Oben liegt ein Wahlzettel aus. Bitte verfeinere den mal mit. Dann können "wir" später sagen: Wir (der egal-jetzt-mal-wie-viel-Unicode-Zeichen-Fan-Club) haben uns auf diese Richtlinien in der Diskussion geeinigt. Und wer dagegen anstinken will, der bekommt dann von allen eins auf die Nase, bis das Blut spritzt. --Reiner Stoppok 20:12, 9. Jun. 2007 (CEST)

Den Artikel zu Zwei-Byte-Zeichen gibts schon: [5]. Alauda 20:41, 9. Jun. 2007 (CEST)

Ich hatte angenommen, darin seien schon alle Zeichen erfasst?! Bitte Sprache "entinformatiken". --Reiner Stoppok 21:04, 9. Jun. 2007 (CEST)

Beitrag zur Diskussion: U+033C bei decodeunicode: *[6]

Ich glaube aber kaum, dass sich da die englische Benennung nach der deutschen gerichtet hat ... --Reiner Stoppok 03:02, 23. Aug. 2007 (CEST)

Redirects von den Unicode-Zeichen auf die beschreibenden Artikel

Ich möchte vorschlagen, dass von jedem Unicode-Zeichen ein Redirect auf den beschreibenden Artikel angelegt wird. igel+- 17:01, 3. Jun. 2007 (CEST)

Behalten. --Reiner Stoppok 17:08, 3. Jun. 2007 (CEST)

Okay, dann fang doch schonmal mit U+0000 bis U+0031 an und trage mehr Informationen zusammen, als bereits bei Steuerzeichen steht. :-/ --RokerHRO 22:31, 3. Jun. 2007 (CEST)

Da sind doch viele nützliche Redirects gerade in der Löschdiskussion. - Wer bereinigt denne mal die technischen Schwierigkeiten bei: Liste von Unicode-Zeichen? --Reiner Stoppok 00:11, 4. Jun. 2007 (CEST)

Ich zweifele ein wenig an dem Nutzwert dieser Liste... --RokerHRO 11:51, 4. Jun. 2007 (CEST)

Es geht bei dieser Liste nur um eine Demonstration für die Diskussion hier drüber (siehe oben). --Reiner Stoppok 17:07, 4. Jun. 2007 (CEST)

Beitrag zur Diskussion: *[7]

 ;) -- W!B: 14:57, 5. Jul. 2007 (CEST)

Eine Katastrophe mehr! --Reiner Stoppok 17:12, 5. Jul. 2007 (CEST)

Wieso?

Siehe Anm. oben. --Reiner Stoppok 03:03, 23. Aug. 2007 (CEST)