Portal Diskussion:Unicode/Archiv/2008

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

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

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Name des Code-Blocks U0000

Hi. Der Unicode-Block Basis-Lateinisch enthält auch die Steuerzeichen und heißt im Original C0 Controls and Basic Latin. Wäre eventuell „Unicode-Block C0-Steuerzeichen und Basis-Lateinisch“ eine bessere Übersetzung? Bin mir auch nicht sicher, ob das Basic nicht als Adjektiv gedacht ist, im Sinne von „einfaches Lateinisch“, „elementares Lateinisch“ oder „grundlegendes Lateinisch“. --j ?! 14:44, 2. Jan. 2008 (CET)

Sowohl meine Zeichentabelle als auch decodeunicode nennen den Block Basic Latin, der Name dürfte auch gebräuchlicher sein. Aber "Basic" mit "Basis" zu übersetzen, ist so nicht korrekt. Ich wäre für die letzte Option (grundlegendes Lateinisch), da einfaches Lateinisch irreführend ist (die Zeichen sind nicht unbedingt einfach), genau wie elementares Lateinisch (also ist z. B. das Þ nicht mehr elementar?). -- Prince Kassad 14:55, 2. Jan. 2008 (CET)

Also das Original-PDF [1] hat die Überschrift „C0 Controls and Basic Latin“. --j ?! 15:22, 2. Jan. 2008 (CET)

Ebenfalls vom Unicode-Konsortium: [2] - da wird auch die Bezeichnung Basic Latin verwendet. -- Prince Kassad 13:19, 3. Jan. 2008 (CET)

Ich sehe da die C0 Controls links neben Basic Latin. --j ?! 14:30, 3. Jan. 2008 (CET)

Verlinkung

Hi. Mir ist bewusst, dass man in Fließtexten einen Begriff normalerweise nur beim ersten Auftreten verlinkt. Bei sortierbaren Tabellen handhabe ich das anders, weil nicht vorhersehbar ist, welcher der Begriffe nach Sortierung oben steht. Ich hoffe, das ist okay so. --j ?! 14:26, 2. Jan. 2008 (CET)

(von Diskussion:Unicode-Block Lateinisch, erweitert-A verschoben.--Τιλλα 2501 ^± 13:49, 6. Jan. 2008 (CET))

Suche 2 Zeichen

Hallo, ich suche diese 2 Zeichen: [3] Wenn jemand sagt wo man diese Zeichen als Textzeichen hier auf wikipedia oder woanders finden kann, bin ich sehr dankbar. mfg (Der vorstehende, nicht signierte Beitrag stammt von 89.55.226.172 (Diskussion • Beiträge) 19:55, 18. Dez 2007) --Τιλλα 2501 ^± 14:15, 6. Jan. 2008 (CET)

Das sind Han-Ideographen, da brauchst du die Tabelle im Unicode-Block Vereinheitlichte CJK-Ideogramme. Das rechte Zeichen ist 七, das linke hab ich bisher noch nicht finden können. -- Prince Kassad 20:20, 18. Dez. 2007 (CET) (Nachtrag: Das linke Zeichen hab ich auch noch gefunden, es ist 去)

danke dir für die schnelle Hilfe! (Der vorstehende, nicht signierte Beitrag stammt von 89.55.226.172 (Diskussion • Beiträge) 20:30, 18. Dez 2007) --Τιλλα 2501 ^± 14:15, 6. Jan. 2008 (CET)

(von Diskussion:Unicode-Block Hiragana verschoben.--Τιλλα 2501 ^± 14:15, 6. Jan. 2008 (CET))

Đ und đ

Hi. In Ð ist von einem „durchgestrichenen D“ die Rede. Daher frage ich mich, ob latin capital letter D with stroke nicht besser als „Lateinischer Großbuchstabe D, durchgestrichen“ zu übersetzen ist, statt als „Lateinischer Großbuchstabe D mit Strich“. Analog đ. Was meint Ihr? --j ?! 14:30, 2. Jan. 2008 (CET)

Zwischen Đ und D gibt es allerdings einen kleinen Unterschied. "Strich" hört sich trotzdem merkwürdig an, da sollte ein besserer Begriff gefunden werden. -- Prince Kassad 14:34, 2. Jan. 2008 (CET)

(von Diskussion:Unicode-Block Lateinisch, erweitert-A verschoben.--Τιλλα 2501 ^± 13:49, 6. Jan. 2008 (CET))

Nennen wir D mit Querstrich. Siehe Übersetzungsvereinbarungen auf dieser Seite. Ich hab's im Artikel entsprechend geändert. Gismatis 14:57, 6. Jan. 2008 (CET)

Oh, die Übersetzungsvereinbarungen hatte ich noch gar nicht gesehen. Sollten die nicht auf der „Vorderseite“ stehen statt hier in der Diskussion? --j ?! 17:44, 6. Jan. 2008 (CET)

Meinst du mit Vorderseite Wikipedia:WikiProjekt Unicode? Vielleicht. Ursprünglich ging es ja nur um die Listen. Inwiefern diese Vereinbarungen auch Eingang in die Einzelartikel finden sollen, ist noch gar nicht festgelegt worden. ich habe es ersetzt, weil "durchgestrichen" wirklich nicht optimal war. Aber zwingend ist das nicht. Das kam in meinem vorherigen Beitrag wohl falsch rüber. Gismatis 21:22, 6. Jan. 2008 (CET)

Ja, ich meine genau das mit Vorderseite. Soll ja auch kein Zwang sein, sondern eine Empfehlung. In Unicode-Block Lateinisch, erweitert-A habe ich jetzt sechsmal „Querstrich“ und zweimal „Schrägstrich“ verwendet und das gefällt mir so ganz gut. --j ?! 15:33, 7. Jan. 2008 (CET)

Danke für den Vorschlag. Hab ihn umgesetzt. Gismatis 11:38, 9. Jan. 2008 (CET)

Schutzschrift gegen erneutes Löschen?

Hallo Leute, mir ist in den Sinn gekommen, dass alle wiederhergestellten Artikel eigentlich einen Hinweis über Löschung und Wiederherstellung vertragen könnten. Es gibt ja die Vorlage:War Löschkandidat. Die passt aber in diesem Fall weniger. Benutzer:Manuel Heinemann machte auf hier den Vorschlag für eine Vorlage:Wurde wiederhergestellt. Das wäre doch etwas für uns. Dadurch könnten potenzielle Löschwütige gleich abschätzen, ob sich ein neuer Löschantrag lohnt. Gismatis 12:01, 6. Jan. 2008 (CET)

Wenn alle wiederhergestellten Artikel diesen Baustein erhalten sollen, kann man ihn gleich in Vorlage:Unicodediskussionszentralisierungshinweis einbauen. Prinzipiell bin ich für den Vorschlag. -- Prince Kassad 12:06, 6. Jan. 2008 (CET)

Erledigt. Habe die neue Vorlage:Wurde wiederhergestellt bei allen betroffenen Artikeln eingefügt. Gismatis 21:40, 13. Jan. 2008 (CET)

griechische Buchstaben in Unicode-Block Lateinisch, erweitert-B

Hallo, dass die Zeichen dorthin gehören und die Nummern stimmen, glaube ich. Dass Sigma und Lambda hier als "lateinische" Buchstaben bezeichnet werden, verwundert mich aber.--Ulamm 22:19, 18. Jan. 2008 (CET)

Das Esh (dein sogenanntes "Sigma") wird in einigen lateinischen Alphabeten verwendet und kann daher durchaus als lateinischer Buchstabe bezeichnet werden. Das Lambda mit Querstrich allerdings ist nur ein phonetischer Buchstabe. Trotzdem würde ich es weiterhin "lateinischer Buchstabe" nennen, analog zu den IPA-Buchstaben im darauffolgenden Block, die auch nicht wahlweise "lateinisch", "griechisch" oder "kyrillisch" sind. -- Prince Kassad 22:34, 18. Jan. 2008 (CET)

Ich glaube, die Bezeichnung “Latin letter” ist hier ein Hinweis auf die typographische Gestaltung in Schriftarten. In den meisten Schriftarten werden nämlich in der Tat z. B. das griechische Gamma (γ) und der „lateinische Kleinbuchstabe Gamma“ als IPA-Zeichen (ɣ) unterschiedlich dargestellt, Letzterer halt mit einem an das lateinische Alphabet angepassten Schriftduktus. --Daniel Bunčić 06:20, 19. Jan. 2008 (CET)

‎Unicode-Block Vereinheitlichte CJK-Ideogramme, Erweiterung B aufteilen

Nachdem es in den Fragen zur Wikipedia aktuell gerade um die Probleme, die lange Artikel verursachen, geht (Wikipedia:Fragen zur Wikipedia#Probleme mit sehr langen Artikeln) und der ‎Unicode-Block Vereinheitlichte CJK-Ideogramme, Erweiterung B ‎mit 285.319 Bytes zurzeit der zweitlängste Artikel überhaupt ist, möchte ich das Problem jetzt ein für allemal entschärfen. Ich möchte die Tabelle aufteilen und in zwei Unterseiten verschieben. Unter dem eigentlichen Lemma verbleiben würden nur der Einleitungstext und die Links. Hinzu kämen einfach noch die Verweise auf die zwei Unterseiten, das heißt Lemma plus /20000 bis 2536F und /25370 bis 2A6DF. Wenn ihr damit einverstanden seid, werde ich das so umsetzen. Gismatis 20:59, 9. Jan. 2008 (CET)

Nachdem sich niemand dagegen ausgesprochen hat, habe ich obigen Vorschlag soeben umgesetzt. Die Zeichentabelle befindet sich jetzt aufgeteilt unter

• Unicode-Block Vereinheitlichte CJK-Ideogramme, Erweiterung B/20000 bis 2536F
• Unicode-Block Vereinheitlichte CJK-Ideogramme, Erweiterung B/25370 bis 2A6DF

Nachdem der Ursprungsartikel jetzt einige Tage längster Artikel überhaupt war, kann er jetzt nun auch bequem von denen aufgerufen werden, die nur der einleitende Text interessiert, bzw. die Zeichen gar nicht sehen können. Gismatis 05:15, 20. Jan. 2008 (CET)

Unicode-Block Halbbreite und vollbreite Formen

Ich habe eben die Einleitung geändert: Die Sache mit den Bytes hat meines Wissens mit der Bezeichnung „breit“ nichts zu tun, auch wenn die halbbreiten Terminal-Zeichen ursprünglich aus 1-Byte-Zeichensätzen stammen. -- Olaf Studt 17:39, 7. Jan. 2008 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: Prince Kassad 17:35, 19. Mär. 2008 (CET)

Formatvorlage für Code-Block

Hi. Gibt's schon irgendwo eine Formatvorlage für Artikel, die einen Code-Block beschreiben? Ich frage das, weil ich einen Ort suche, wo die Tabellenspalten diskutiert werden. --j ?! 14:17, 2. Jan. 2008 (CET)

weil ich einen Ort suche, wo die Tabellenspalten diskutiert werden - Willkommen auf Portal Diskussion:Unicode/Archiv/2008. Die Codeblockartikel werden automatisch generiert, eine Formatvorlage ist bisher nicht erhältlich. -- Prince Kassad 14:37, 2. Jan. 2008 (CET)

Na dann, hier meine Vorschläge:

1. Die Dezimalzahl hinter die Unicode-Blocknummer in Klammern zu schreiben, widerspricht für mich der Idee einer Tabelle. Wie wäre es mit zwei Spalten?
2. Die Semantik der Spalte Beschreibung ist unklar. Soll dort wirklich eine Beschreibung stehen? Oder nur die deutsche Übersetzung des offiziellen Namens inklusive Link? Wie wäre es statt dessen mit einer Spalte für den übersetzten deutschen Namen und einer anderen für eine echte Beschreibung mit Anwendungsbeispielen?

--j ?! 15:35, 6. Jan. 2008 (CET)

Zum ersten: da beides ja der Codepunkt ist (nur in einem anderen Format), sollten sie auch zusammen in einer Spalte auftauchen, um die Tabelle nicht unnötig aufzuteilen.

Zum zweiten: Ursprünglich sollte in die Beschreibung wirklich nur die Übersetzung (mit Link). Daher wäre ich für eine neue Spalte "Beschreibung", wo man das Zeichen näher beschreiben kann. -- Prince Kassad 18:13, 7. Jan. 2008 (CET)

Ich schliesse mich Jpp hinsichtlich der Kritik an der Klammernschreibweise an. Man sollte Tabellen datentechnisch lesbar halten, d. h. ein Wert pro Spalte und nix, was letztendlich nur auf eine Zeichenkette hinausläuft. – Simplicius ☺ 18:43, 7. Jan. 2008 (CET)

Ursprünglich dachte ich auch an eine separate Spalte für echte Beschreibungen. Allerdings frage ich mich, ob eine Verlinkung auf einen Einzelartikel – sofern vorhanden – nicht ausreichend ist. Es beträfe dann nur noch diejenigen Zeichen, die keinen Einzelartikel hätten. Dann allerdings hätte man eine ganze Spalte, in der viele Zellen leer wären. Wie wäre es mit einer Spalte "Beschreibung/Beispiel", in der man auch ein erläuterndes Beispiel aus einer bestimmten Sprache mit diesem Zeichen aufführt, ähnlich wie in der Liste der IPA-Zeichen? Gismatis 17:50, 12. Jan. 2008 (CET)

Vorlage:Unicode-Block einbinden (erl.)

Die Vorlage:Unicode-Block einbinden wird, sobald der neue Parser aktiviert ist, wohl nicht mehr ordentlich funktionieren. Die Gleichheitszeichen werden (der Beschreibung nach) wenn nur sofort und auch nur wenn sie am Anfang der Zeile stehen als Überschriften ausgewertet. Die bessere Alternative wäre vielleicht einen Parameter mit h1-h6 zu übergeben. So erstellte Überschriften sollten auch keine Bearbeiten-Links mehr tragen, was ja auch nicht weiter schlimm wäre. Soll ich es abändern? Gruß, --Revolus Echo der Stille 04:27, 6. Feb. 2008 (CET)

Danke für den Hinweis; ja, gern! --Daniel Bunčić ^? ♥ ± 06:14, 6. Feb. 2008 (CET)

Habe es abgeändert; es sollte keine merkbaren Änderungen geben. --Revolus Echo der Stille 14:53, 6. Feb. 2008 (CET)

Schützen der Seiten

Evtl. sollte mal drüber nachgedacht werden, ob die Unicode-Seiten nach und nach vor weiteren Bearbeitungen geschützt werden sollten, wenn wir uns hier über deren definitive Form einig geworden sind. Ich fände z.B. gut, falls wir uns darauf verständigen könnten, dass sie später nur dann bearbeitet werden dürfen, wenn hier auf dieser Seite ein solider Änderungsvorschlag unterbreitet wurde. --Reiner Stoppok 22:03, 5. Mär. 2008 (CET)

Ich bin ein Anhänger des Wikiprinzips. Lasst uns verschiedene Varianten ausprobieren und in einem Jahr nochmal über einen Standard diskutieren. Einheitlichkeit ist kein Heiligtum. --j ?! 22:38, 5. Mär. 2008 (CET)

Bei einigen Blöcken hier gibt es aber m.E. schon nicht mehr besonders viel dran zu rütteln. --Reiner Stoppok 23:11, 5. Mär. 2008 (CET)

Problem mit Komma im Blocknamen

Liste der Unicode-Zeichen/3400 bis 9FFF landet zweimal auf der selben ausgelagerten Seite.

Ich kann auf der Seite keinen Fehler entdecken. Was soll falsch sein? -- Prince Kassad 15:40, 19. Mär. 2008 (CET)

„in einem eigenen Artikel.“ zeigt beide Male auf die selbe Seite. Rainer Seitel 16:00, 19. Mär. 2008 (CET)

Sollte jetzt behoben sein. -- Prince Kassad 16:04, 19. Mär. 2008 (CET)

Arabisch-Blöcke

Bei den "Arabisch"-Unicode-Blöcken stockt seit längerem der Arbeitsprozess (siehe Arabisch, Arabisch, Ergänzung, Arabische Präsentationsformen-A und Arabische Präsentationsformen-B).

Nach reiflicher Überlegung würde ich vorschlagen, die Buchstabenbenennungen alle nach der englischen Unicode-Version zu übernehmen (!) und nur das "Drumherum" um die eigentlichen Buchstabenbezeichnungen jeweils zu übersetzen (so wie hier gerade: Benutzer:Buncic/Unicode/Arabische Präsentationsformen-A‎ ). Daneben kann man ja in Klammern weitere nützliche Hinweise (bzw. die deutschen Namen für die Wörter setzen (soweit vorhanden!) - mit Angabe ob die Benennung des Buchstabens/diakritischen Zeichens aus dem Pers./Urdu/Arab./Sindhi/einer afrikan.Sprache usw. stammt - versteht sich. Ferner halte ich die Anlage einer Liste arabisch-basierter Alphabete (nach dem Vorbild der Liste lateinisch-basierter Alphabete und der Tabellen in Indische Schriften für wünschenswert.

Wie findet ihr diesen Vorschlag? --Reiner Stoppok 17:16, 12. Mär. 2008 (CET)

Von einem Stocken beim Übersetzungsprozess hab ich noch nichts bemerkt (zwei Blöcke sind vorhin sogar fertig geworden). Ich würde weiterhin alles übersetzen, um uns nicht noch mehr LAs einzufangen. Eine Liste arabisch-basierter Alphabete halte ich deswegen nicht für sinnvoll, weil die meisten arabischen Zeichen nur in einer einzigen Sprache verwendet werden. -- Prince Kassad 17:27, 12. Mär. 2008 (CET)

Dann sollte aber auch immer dazugeschrieben werden, in welcher! --Reiner Stoppok 18:15, 12. Mär. 2008 (CET)

Nur wenn es gar nicht anders geht, z. B. falls wir nicht herausfinden, wofür die originale Schreibung steht (ARABIC SIGN SALLALLAHOU ALAYHE WASSALLAM), sollten wir die englische Form übernehmen. Wobei ich den Eindruck habe, dass das Unicode-Konsortium bei den Einzelbuchstaben die ein oder andere Schreibweise erfunden hat, um keine Diakritika verwenden zu müssen. Ein noch ungelöstes Problem sind unterschiedliche Buchstaben, die in der Umschrift identisch sind, bzw. sich nur durch ein Diakritikum unterscheiden. So werden in Meyers großem Taschenlexikon Ha und Ta jeweils zweimal aufgeführt. Vorschlag:

• U+062A ت ARABIC LETTER TEH: Arabischer Buchstabe Ta
• U+062D ‎ح ARABIC LETTER HAH: Arabischer Buchstabe pharyngales Ha
• U+0637 ط‎ ARABIC LETTER TAH: Arabischer Buchstabe emphatisches Ta
• U+0647 ه‎ ARABIC LETTER HEH: Arabischer Buchstabe Ha

Auf diese Weise könnten wir das Schmema mit -a wahren und müssten trotzdem keine Diakritika verwenden. Gegenvorschläge? Außerdem schlage ich vor, englisches -eh immer mit -a und -eheh entsprechend mit -aha wiederzugeben, also auch Pa, Tscha, Taha etc. Noch etwas: Müsste es nicht eher Initialform, Medialform und Finalform statt initiale Form etc. heißen? Gismatis 09:35, 17. Mär. 2008 (CET)

als Laie: ohne zusätzliche Zeichen kann man keine Umschrift in diesen Fällen machen Ha und Ta für ه bzw. ت ist in Ordnung. Beim Rest geht es nicht. Auch bei ظ werdet Ihr Probleme haben.--Orientalist 16:43, 19. Mär. 2008 (CET)

Vergessen wir doch mal kurz die ganze bisherige verbildete und verquere akademische Transkriptionsscheiße: Auf zu neuen Ufern! --Reiner Stoppok 20:36, 19. Mär. 2008 (CET)

Also ظ heißt Za oder Tsa. Da kommt es zu keinem Konflikt. Und ich schließe mich Reiner an. Zwar habe ich nichts gegen exakte Transkriptionen. In bestimmten Fällen haben sie ihre Berechtigung. Jedoch halte ich sie für laienfeindlich, wenn sich Schreibweisen nur aufgrund diaktritischer Zeichen unterscheiden. Undeutliche Zeichen wie z. B. untergesetzte Punkte können leicht übersehen werden. Gismatis 01:20, 20. Mär. 2008 (CET)

Bei Hatschek und Cedille ist uns das schließlich auch gelungen ... --Reiner Stoppok 16:26, 20. Mär. 2008 (CET)

Zu Initialform etc.: das würde ich so machen, wenn es nicht auch die isolierte Form gäbe, die man nicht zusammenschreiben kann. -- Prince Kassad 07:07, 19. Mär. 2008 (CET)

Das spielt doch keine Rolle! Jedenfalls kommen mir die zusammengesetzten Formen bekannt vor, weshalb ich dachte, es seien die offiziellen Bezeichnungen. Gismatis 01:20, 20. Mär. 2008 (CET)

Ich schließe mich dem vollinhaltlich an. Ist es denn ok, wenn wir jetzt z.B. Ta und emphatisches Ta unterscheiden? Diese Bezeichnung ist ja nicht aus den Fingern gesogen, sondern entspricht dem, was man im Arabischunterricht lernt. -- Arne List 14:08, 20. Mär. 2008 (CET)

Genau das war ja Gismatis’ Vorschlag, den finde ich auch optimal. --Daniel Bunčić ^? ♥ ± 15:35, 20. Mär. 2008 (CET)

Wir müssen natürlich ausschließen, dass gleiche deutsche Namen für unterschiedliche Zeichen verwendet werden (richtig: Arabischer Buchstabe Ta z.B. wird gerade noch für "U+062A (1578) ت‎ ARABIC LETTER TEH" und "U+0637 (1591) ط‎ ARABIC LETTER TAH" verwendet). Das muss bei anderen Blöcken (auch blockübergreifend) natürlich auch gewährleistet sein. --Reiner Stoppok 16:13, 19. Mär. 2008 (CET)

Mir scheinen Initialform, Medialform, Finalform und isolierte Form aber tatsächlich die üblichen Termini zu sein, auch wenn ich gerade kein Buch zur Hand habe, aus dem ich sie zitieren könnte. Hier sollten wir nicht andere Termini prägen, nur weil diese vier nach unterschiedlichen Wortbildungsmustern gebildet sind. --Daniel Bunčić ^? ♥ ± 09:08, 19. Mär. 2008 (CET)

Korrekt -- Arne List 14:11, 20. Mär. 2008 (CET)

Ok. Ich ändere das um. --Reiner Stoppok 16:00, 20. Mär. 2008 (CET)

Übersetzungsvereinbarungen

(Nach Wikipedia Diskussion:WikiProjekt Unicode#Übersetzungsvereinbarungen verschoben. Gismatis 11:36, 9. Jan. 2008 (CET))

Jetzt: Portal:Unicode/Übereinkünfte. – Simplicius ☺ 21:38, 13. Apr. 2008 (CEST)

Löschantrag auf Unicode-Block Pfeile

War ja zu erwarten, dass sobald ein neuer Block eingerichtet wird, der nicht zu den wiederhergestellten gehört, ein Löschantrag dazu eingereicht wird: Wikipedia:Löschkandidaten/16._Februar_2008#Unicode-Block_Pfeile. Gismatis 04:56, 17. Feb. 2008 (CET)

ok. – Simplicius ☺ 15:01, 14. Apr. 2008 (CEST)

"Arabisch"-Blöcke

Bitte kommt mal rüber zur Diskussion:Liste der Unicode-Zeichen. Gruß --Reiner Stoppok 17:18, 12. Mär. 2008 (CET)

Jetzt weiter unten auf dieser Seite. – Simplicius ☺ 15:03, 14. Apr. 2008 (CEST)

Löschprüfung Unicode-Block Pfeile

Ich möchte darauf aufmerksam machen, dass sich der Unicode-Block inzwischen in der Löschprüfung befindet. --Reiner Stoppok 16:52, 7. Mär. 2008 (CET)

Unicode-Block Pfeile sind vorhanden. Typischer Löschantrag von P.Birken. – Simplicius ☺ 15:00, 14. Apr. 2008 (CEST)

Portal:Unicode

Hinweis an die Mitarbeiter:

• Bislang fanden die Besprechungen vor allem auf der Diskussionsseite der Liste der Unicode-Zeichen statt. Die neun Listen, generiert über Vorlagen, wurden mit Billigung des redaktionellen Teams heute gelöscht.
• Damit entfällt auch der Sinn für die alte Übersicht über die Listen (damit auch der Mittelpunkt für die Arbeit, die Diskussionen und die Diskussionsarchive).
• Ich habe die Vorlage für die einzelnen Artikel überarbeitet, einen Verweis auf das Portal eingefügt und dieses Portal erstellt.
• Auf der bisher weniger genutzten Projektseite lag die Zusammenstellung von Aufgaben, Mitarbeitern, Hinweise usw. Sie befindet sich nun auf Übereinkünfte. Das ist auch ganz oben neben den Archiven für 2007 und 2008 noch einmal verlinkt.
• Die Diskussionsbeiträge von dort habe ich auf dieser Seite eingefügt. Somit sind fast sämtliche Diskussionen hier an 1 Stelle vereint.

Ich hoffe, das war jetzt nicht zu kompliziert... – Simplicius ☺ 21:50, 13. Apr. 2008 (CEST) ergänzt

Kritik

Unabhängig vom Ergebnis finde ich, Du hättest diese Vorgehensweise vorher mal an den üblichen Stellen ansprechen können. --Reiner Stoppok 00:58, 14. Apr. 2008 (CEST) PS: Die Übersichtsleiste unten sollte auf die ganze Breite gebracht werden, so wie sonst überall auch.

Ich habs am 11. April 2008 16:41 Uhr angesprochen. Du findest es hier auf der Seite unter ...#Gesamtliste. Vielleicht war das ja nicht deutlich genug formuliert.

Aber soweit kann man ja mitdenken, dass der Übersichtsartikel [4] durch den Löschantrag durch Prince Kassad, der auch deine Unterstützung fand [5], somit zwangsläufig wegfällt und die Diskussionen samt Archiv dann verloren gehen würden.

Auf der verwiesenen Diskussionsseite von Prince Kassad steht es jedenfalls. – Simplicius ☺ 01:24, 14. Apr. 2008 (CEST)

Danke für die Anregung. Irgendwie muss man ja halt erst einmal anfangen. Unten ist es nun breit. – Simplicius ☺ 01:30, 14. Apr. 2008 (CEST)

Mitdenken ist nicht meine Stärke ... Das Beispiel Dingbats ist schlecht gewählt, da die noch größtenteils unübersetzt auf der Benutzerseite Buncic stehen. --Reiner Stoppok 14:07, 14. Apr. 2008 (CEST) PS: Wer sich drum kümmern möchte: hier die notwendigen Infos.

Qualitätssicherung Portale

Bitte erstellt die Unterseite Portal:Unicode/Info und tragt alle notwendigen Informationen ein, siehe Anleitung ff. -- Cherubino 17:27, 13. Apr. 2008 (CEST)

Zur Relevanz von Portalen siehe Wikipedia:Portale/Wikipedia:Portale#Relevanzkriterien und Wikipedia:WikiProjekt_Portale/Baustelle#Portal:Unicode -- Cherubino 18:07, 13. Apr. 2008 (CEST)

Der Kommentar, dem man dort hinterherklicken soll, lautet:

Die Liste der Unicode-Zeichen (16. Sep. 2007 erstellt) wurde von Simplicius zum Portal:Unicode verschoben. Die Relevanzkriterien für Portale sind nicht erfüllt. Cherubino 18:05, 13. Apr. 2008 (CEST).

Grüsse, – Simplicius ☺ 20:02, 13. Apr. 2008 (CEST)

Hinterherklicken wär ratsam, denn das ist die Seite wo alle(!) neue Portale zur Diskussion gestellt werden. Leider hat kein Listen/Portal-Verantwortlicher dort reagiert (nur keine Angst). Also dann hier das Wesentliche freundlicherweise nochmal vorgekaut: Die Relevanzkriterien für Portale wurden per Meinungsbild festgelegt. Hier greifen sie nicht automatisch. Bleibt entweder Formalitätendingsbums-2 wie jüngst vom Portal:Inseln oder Portal:BDSM problemlos gemacht (siehe „Ist dein Thema nicht enthalten?“ Wikipedia:Portale#Ein_Portal_gründen - Schritt 1 - Punkt 2. Kurz: drei feste Betreuer und eine Mehrheit von mindestens zehn Befürwortern), zurückverschieben zur Liste oder ein LA. Bitte jetzt nicht groß lamentieren, Formalitätendingsbums-2 läuft regelmäßig und meist ohne Probleme.

Grüsse Cherubino 23:58, 13. Apr. 2008 (CEST)

Könnte man das nicht umbenennen in "Unicode deutsch" oder so ähnlich? --Reiner Stoppok 16:34, 14. Apr. 2008 (CEST)

Keine Ahnung was du meinst. Ist aber nicht normal, dass sich beim Wikiprojekt:Portale keiner äußert. Bei eurem Projekt seid ihr doch schon sieben Mitarbeiter, wo ist der Haken? -- Cherubino

Es gibt keinen. Es will sich nur aus irgendwelchen Gründen keiner äußern. -- Prince Kassad 22:10, 15. Apr. 2008 (CEST)

Jo. Und ich bin nicht von Adel... ☺ – Simplicius ☺ 23:34, 15. Apr. 2008 (CEST)

Neue Gestaltung Vorlage

Die Vorlage:Navigationsleiste Unicode wurde von Caesium137 umstrukturiert, alt, neu. Sie allerdings auch nicht mehr so kompakt. Meinungen? – Simplicius ☺ 21:09, 15. Apr. 2008 (CEST)

Diese Fassung besonders neu ist riesengroß, trotz kleiner Schrift und es ist zuviel Fäche einfach weiss. Der Vorteil ist natürlich: Man sieht, wie ungeheuer viele Teillisten da sind. Einen Versuch war's ja wert. Ich find es trotzdem nicht so praktikabel. – Simplicius ☺ 23:52, 15. Apr. 2008 (CEST)

Auf meinem heimischen Computer, der noch mit 1024 x 768 Pixeln Auflösung läuft, passen die beiden neuen Versionen der Navigationsleiste nicht einmal mehr auf den Bildschirm (Nachtrag: gilt übrigens auch für meinen Bürocomputer mit 1280 x 1024 Pixeln). Und scrollen innerhalb einer Navigationsleiste kann nun wirklich nicht der Sinn der Sache sein. Abgesehen davon sehe ich den Gewinn nicht. Die Liste ist nicht übersichtlicher, da immer noch alles kreuz und quer (in der Reihenfolge der Blöcke im Code) steht und man sich durch alle drei Spalten genauso durcharbeiten muss wie zuvor durch den Fließtext. Abgesehen davon finde ich diese neue Lösung, wenn ich mir die Spaltenbreiten ansehe, auch designmäßig nicht gelungen. Bitte revertieren. --Daniel Bunčić ^? ♥ ± 07:18, 16. Apr. 2008 (CEST)

Bin genau derselben Meinung. Ich würde nochmal revertieren, möchte mich aber nicht an einem Editwar beteiligen. -- Prince Kassad 07:33, 16. Apr. 2008 (CEST)

+1, bitte revertieren. – Simplicius ☺ 09:38, 16. Apr. 2008 (CEST)

Na, dann habe ich das doch einfach mal gemacht. --Daniel Bunčić ^? ♥ ± 09:44, 16. Apr. 2008 (CEST)

Fehlende Blöcke

Für Mitmacher, Neugierige & Besserwisser: Die noch fehlenden Blöcke stehen hier. --Reiner Stoppok 14:36, 14. Apr. 2008 (CEST)

...und die Möglichkeit, sich in die Liste der Mitwirkenden einzutragen, besteht hier. – Simplicius ☺ 11:58, 18. Apr. 2008 (CEST)

Halbleerschritt

Wie heisst der Unicode für einen Halbleerschritt, der untrennbar sein soll? Gibt e s so was in Unicode? Danke! – Simplicius ☺ 01:17, 18. Jan. 2008 (CET)

Die Leerzeichen sind alle hier spezifiziert, vermutlich meinst Du das NARROW NO-BREAK SPACE. Morty 17:30, 18. Apr. 2008 (CEST)

Dingbats (2700–27BF)

Ich habe mich des Hinweise von Rainer in Sachen Dingbats mal angenommen. Folgende Fragen habe ich:

• die genannte zip-Datei existiert am genannten Ort nicht mehr
• der Artikel Benutzer:Buncic/Unicode/Dingbats enthält den Hinweis „Der Unicode-Block Dingbats (2700–27BF) enthält die Zapf-Dingbats.“ Ist das wirklich belegt, dass es sich um die Sammlung von Symbolen von Hermann Zapf handelt und nicht irgendwelche Symbole?

Danke – Simplicius ☺ 14:58, 14. Apr. 2008 (CEST)

Benutzer:Prince Kassad hatte mir irgendwo mal geschrieben: "http://unicode.org/versions/Unicode5.0.0/ch15.pdf#G12378: „The Dingbats are derived from a well-established set of glyphs, the ITC Zapf Dingbats series 100.“" --Reiner Stoppok 15:12, 14. Apr. 2008 (CEST) PS: Wer die Dingbats bearbeiten möchte, soll sich bitte an Benutzer:Rainer Zenz wenden, der hat die Originalbezeichnungen irgendwoher.

Auf deutsch? Ich fürchte, ich muss mir hier sonst mal ein technisches Wörterbuch besorgen. – Simplicius ☺ 16:11, 14. Apr. 2008 (CEST)

So habe ich es in Erinnerung. --Reiner Stoppok 16:27, 14. Apr. 2008 (CEST)

Ich habs bekommen und schon entpackt. Danke. Sieht nach einer verlässlichen Quelle aus. Ein Umarbeitung werde ich in den nächsten Tagen machen - gerade ist es für mich zeitlich etwas eng.

Wenn ich das richtig sehe, wurde im gesamten Internet noch keine deutsche Übersetzung veröffentlicht, obwohl es sich bei Zapf-Dingsbats um einen Industriestandard (für Laserdrucker usw.) handelt.

Somit ist das Portal eine Art Vorreiter, oder? – Simplicius ☺ 10:49, 15. Apr. 2008 (CEST)

Du meinst eine deutsche Übersetzung der englischen Übersetzung der deutschen Bezeichnungen des Unicode-Konsortiums? --Reiner Stoppok 14:49, 15. Apr. 2008 (CEST)

Nun ja, ich orientiere mich besser zusätzlich auch an [6] bzw. [7].

Dies ist ein hartes Brot.

Hier müsste man einen gelernten Schriftsetzer oder Typografen kennen.

Gibt die ISO 10646 die Bezeichnungen in Deutsch her? Das wäre dann doch eine gute Referenz. – Simplicius ☺ 21:40, 18. Apr. 2008 (CEST)

Wenn es die Unicode-Bezeichnungen auf Deutsch gäbe, könnten wir uns die ganze Mühe mit den Unicode-Tabellen sparen. Im Klartext: nein, gibt es nicht. -- Prince Kassad 22:53, 18. Apr. 2008 (CEST)

Ok. Hab hier noch was gefunden, was sehr substantiert aussieht, von Rainer Seitel [8]. – Simplicius ☺ 23:57, 18. Apr. 2008 (CEST)

Mathematische Symbole (2200–22FF)

Im Portal:Mathematik habe ich mal auf der QS um Amtshilfe gebeten, hier. – Simplicius ☺ 11:18, 17. Apr. 2008 (CEST)

Eine Diskussion mit den Mitarbeitern dort wurde schon mal geführt. Vermutlich habe ich da irgendeinen Hinweis übersehen, aus dem das schon hervorging. Die neuerliche Antwort hat bei mir einen Denkprozess ausgelöst:

• Ein Symbol kann mehrere Bedeutungen tragen und daher mehrere Namen.
• Darum ist es nach einer philosophischen Strömung (Nachweis?) besser, es trägt überhaupt keinen Namen.
• Zumal können ja auch mehrere Symbole das Gleiche ausdrücken.

Es ist daher besser, wir schaffen die Listen über Unicode ab, Unicode selbst und Schriftsysteme generell. Diese Probleme erstrecken sich auch über unsere Sprachen, denn sie sind ebenfalls nicht eindeutig. Wir sollten also auch die Sprachen abschaffen. Ich werde gleich einen Schnelllöschantrag auf das Universum stellen, vorher aber noch zum Mittagstisch gehen. – Simplicius ☺ 12:23, 17. Apr. 2008 (CEST)

Das habe ich schon mal getan (siehe hier und direkt darüber). Der Aufpasser dort ist ein wikipediabekannter Feind unseres Anliegens. --Reiner Stoppok 16:47, 17. Apr. 2008 (CEST)

Die dortigen Argumente fand ich wenig substantiiert. Aber Löschantrag auf die Welt greift schon, merkst du wie hier seit 1 Tag die Datenbank immer mehr Probleme kriegt? – Simplicius ☺ 14:55, 18. Apr. 2008 (CEST)

Gesamtliste in 16er-Spalten

Ich kenne die genauen Motive nicht, die zum Wunsch nach einer Gesamtliste führten. Geht es vor alllem darum, zu sehen, welche Zeichen das eigene PC-System darstellen kann? Dies könnte ich auch lösen, in dem ich eine Tabelle generiere, die 16 Zeichen pro Tabellenzeile enthält (Beispiel Testseite, mit Plane 0, Rest noch aussen vor). Das ist mal nur 'ne Frage. – Simplicius ☺ 14:50, 17. Apr. 2008 (CEST)

Nein, dafür gibt es andere Websites. Es gibt aber keinen Ort, an dem man nach deutschem Text suchen kann (und z.B. "Gravis" eingeben und dann alle Zeichen finden, die einen Gravis enthalten). Aber das ist wegen der technischen Beschränkungen derzeit wohl wirklich nicht zu machen. Einstweilen bin ich schon recht zufrieden damit, einzelne thematisch zusammenhängende Unicode-Blöcke in solchen Seiten wie Lateinische Buchstaben in Unicode oder Kyrillisch und Glagolitisch in Unicode zu sammeln, das ist für die meisten Zwecke wohl völlig ausreichend. --Daniel Bunčić ^? ♥ ± 15:28, 17. Apr. 2008 (CEST)

Ok, ich wusste gar nicht, dass wir solche Zusammenstellungen auch noch hatten.

Eine wirklich vollständige Gesamtliste mit erläuternden Texte dürfte jedoch einen Artikel mit mehreren Megabyte Umfang ergeben.

Die Tabelle für Plane 0 ohne Bezeichnungen ergibt bereits etwa 1 MB. – Simplicius ☺ 12:07, 18. Apr. 2008 (CEST)

Diese Seiten gibt es ja auch erst seit kurzem. Und die Idee einer Gesamtliste mit deutschen Bezeichnungen ist (derzeit; aber warten wir mal drei Jahre...) einfach technisch unmöglich, während ich bei der Gesamtliste ohne Bezeichnungen noch den Verwendungszweck nicht sehe. --Daniel Bunčić ^? ♥ ± 12:13, 18. Apr. 2008 (CEST)

Mir hat sie gezeigt, dass ich dringend bessere Fonts brauche. – Simplicius ☺ 12:27, 18. Apr. 2008 (CEST)

Kleine Nebenfrage: was hat es mit den beiden letzten Zeichen in Plane 0 auf sich?

FFFE und FFFF laufen in der Darstellung aus dem Ruder. Werden sie von UTF beansprucht? – Simplicius ☺ 12:07, 18. Apr. 2008 (CEST)

Zu der kleinen Nebenfrage schau mal unter Byte Order Mark. --Daniel Bunčić ^? ♥ ± 12:13, 18. Apr. 2008 (CEST)

Oh, danke. Und was ist mit FFFF? – Simplicius ☺ 12:27, 18. Apr. 2008 (CEST)

Die letzten beiden Zeichen jeder Plane sind ausdrücklich als ungültige Zeichen ausgewiesen. Siehe Kapitel 2 des Unicode-Standards (bei Bedarf kann ich den Link suchen) -- Prince Kassad 13:47, 18. Apr. 2008 (CEST)

FFFF ist EOF, Dateiende, meist −1. Nicht FFFD, sondern FFFE ist BOM. FFFE und FFFF dürfen nicht vorkommen! Rainer Seitel 13:50, 18. Apr. 2008 (CEST)

Danke, mit dem FFFD habe ich mich in der Tabelle vertan.

Das sind mentale Abnutzungserscheinungen. – Simplicius ☺

Fonts thematisieren

Können wir hier mal über Fonts sprechen? Mit was für Fonts habt ihr welche Erfahrungen gemacht? Wenn man eine Website betreibt, Seiten in XHTML und UTF-8, welche Fonts kann man den Lesern empfehlen? Und in Sachen Barrierefreiheit, wie gut kommen Sprachprogramme noch durch die Texte, wenn besondere Umlaute auftauchen? – Simplicius ☺ 23:39, 17. Apr. 2008 (CEST)

Also hier mal was aus eigener Sicht (Win2K):

• In den Microsoft-Produkten dürfte man dem Trend soweit folgen, dass zumindest die europäischen Variationen angezeigt werden. Ferner gibt es den Arial Unicode MS, der in der englischsprachigen Wikipedia beschrieben wird (hier). Das Ganze ging wohl schon 2003 kommerziell in andere Hände über.
• Ich habe den Code2000 von James Kass runtergezogen (Website), in Windows installiert und im Firefox als Standard eingestellt. Er ist entpackt 8.377.136 Bytes groß. Bei regelmässigem Gebrauch möchte Kass eine einmalige Beihilfe in Höhe von 5 USD. Der Font ist auf der englischsprachigen Wikipedia beschrieben (hier). Es handelt sich um eine serifenbetonte Schrift, also so ähnlich wie Times. Ich musste zunächst noch folgenden Schritt manuell durchzuführen (Win2K): Desktop, Rechtsklick, Eigenschaften, Effekte, Bildschirmschriftarten glätten. Ich hab nun wieder eine andere Schrift als Standard einstellt, aber dieser Font hilft dort, wo er gebraucht wird. Das ist doch nett.
• Momentan bin ich bei der Lektüre auf einer Seite von Alan Wood, der sich viel mit dem Thema auseinandersetzt (Website). In der englischsprachigen WP gibt es eine schöne Seite über die Unicode Typefaces (hier).

Mit besten Wünschen für das Wochenende – Simplicius ☺ 14:41, 18. Apr. 2008 (CEST)

Alte "Liste von Unicode-Zeichen" (erl.)

Die Versionsgeschichte der alten "Liste von Unicode-Zeichen" (die Ur-Liste) gehört hier m.E. auch noch irgendwo erwähnt bzw. hineinimportiert. Wo ist die eigentlich geblieben? --Reiner Stoppok 22:21, 20. Apr. 2008 (CEST)

Wir sitzen drauf [9]. – Simplicius ☺ 15:48, 21. Apr. 2008 (CEST)

Nein. Die ursprüngliche Liste hiess Liste von Unicode-Zeichen. Unter diesem Namen befanden sich auch die ganz alten Versionen der Liste. --Reiner Stoppok 16:08, 21. Apr. 2008 (CEST)

Da sind Sachen auch in der Vorzeit mal angelegt, verschoben,

zurückverschoben, gelöscht und wiederhergestellt worden:

• Liste von Unicode-Zeichen [10].
• Liste der Unicode-Zeichen [11]
• Liste der Unicode-Blöcke [12]

Die Versionshistorie hier reicht auf den 16. September 2007 zurück.

Ich dachte schon, eine der älteren Sachen in der Versionshistorie bewahrt zu haben.

Alles Weitere wäre noch mal eine Recherchefrage. – Simplicius ☺ 16:28, 21. Apr. 2008 (CEST)

Die ursprüngliche "Liste von Unicode-Zeichen" war schätzungsweise ein halbes Jahr älter (d.h. ungefähr ein halbes Jahr vor dem 16. September 2007). Vielleicht holt das gelegentlich noch mal ein Admin aus dem Archiv. --Reiner Stoppok 16:44, 21. Apr. 2008 (CEST)

Erledigt. Danke, Tilla! --Reiner Stoppok 16:04, 26. Apr. 2008 (CEST)

Also: History – Simplicius

Neuer Artikel: Unicode-Block Geometrische Formen

Hier habt ihr einen ehemaligen SLA-Kandidaten, ich hab mal das gröbste getan, um uns hier den üblichen Hexentanz aus Löschung, Wiederherstellungswunsch, … zu ersparen. Jetzt ist weitere Überarbeitung notwendig. --32X 15:25, 25. Apr. 2008 (CEST)

Das sollte später aber mal aussehen wie hier angedeutet! --Reiner Stoppok 20:02, 25. Apr. 2008 (CEST)

Was darf man sich unter „In der Tabelle sind lediglich alle html-Entities des genannten Unicode-Bereichs aufgeführt, sodass man – abhängig von den verfügbaren Fonts – wenigstens die graphische Darstellung auf dem jeweiligen Bildschirm sehen kann.“ denn genau vorstellen? Was bedeutet „lediglich alle html-Entities“? – Simplicius vier Jahre 13:34, 1. Mai 2008 (CEST)

Ich hab das zuerst für nen Scherz gehalten. Ich finde, das sollte zurück auf die Benutzerseite. --Reiner Stoppok 02:15, 2. Mai 2008 (CEST)

Ich bin auch der Meinung, dass nur übersetzte Tabellen in den Artikelraum geschoben werden sollten. – Simplicius vier Jahre 18:59, 6. Mai 2008 (CEST)

Unicode-Block Tags (E0000–E007F)

Was genau kann man sich darunter vorstellen? Sie befinden sich in Plane 14 (Ebene 14), die für für spezielle kodierungsinterne Aufgaben vorgesehen ist. Bedeutet das, dass die Zeichen nicht sichtbar sind? Wie genau werden diese Zeichen angewendet? – Simplicius vier Jahre 13:31, 1. Mai 2008 (CEST)

Soweit ich weiß, handelt es sich hierbei um Sprachtags, um die Sprache in Textdateien zu markieren, was z. B. bei Nutzung von chinesischen und japanischen Schriftzeichen nebeneinander nötig ist. Dabei wird zunächst mit dem Sprachtag (U+E0001) eine Sprachangabe eingeleitet, und dann der ISO-Code der Sprache mit den Tags eingegeben. Der nachfolgende Text wird nun entsprechend der eingestellten Sprache z. B. in einer anderen Schrift angezeigt. -- Prince Kassad 15:37, 1. Mai 2008 (CEST) (Nachtrag: siehe Unicode 5.0, Kapitel 16.9)

Anwendungsbeispiel für Sprachtags

Das klingt interessant, aber ich fühle mich da selbst völlig überfordert.

Ein erläuternder Text mit einem Beispiel wäre da vielleicht gut.

Und wie ist in diesem Falle zum Beispiel TAG DIGIT TWO zu übersetzen? – Simplicius vier Jahre 19:42, 1. Mai 2008 (CEST)

Hilft das Beispiel rechts? -- Prince Kassad 21:18, 1. Mai 2008 (CEST)

Hilft das hier zum Verfassen eines "Sprach-Tags"-Artikels? Gruß --Reiner Stoppok 02:26, 2. Mai 2008 (CEST)

Sorry, ich halte mich da lieber raus, das ist nicht genügend meine Materie. – Simplicius vier Jahre 18:56, 6. Mai 2008 (CEST)

Unicode-Zeichen VS HTML-entities

Beim bearbeiten einiger Artikel ist mir aufgefallen, dass manchmal Unicode-Zeichen, manchmal aber auch HTML-Entities verwendet werden. Gibt es da irgendeine Konvention, wann man was benutzt? Zeichen nur bis U+007F, U+00FF, U+FFFF und darueber HTML-Entities oder so etwas in der Art? Und wenn es eine Konvention gibt, wie ist diese begruendet? Ich habe Schwierigkeiten zu verstehen, warum man noch HTML-Entities benutzen sollte, wenn die Wikipedia doch eh Unicode verwendet. RedNifre 13:31, 6. Mai 2008 (CEST)

Bei den Unicode-Listen werden aus technischen Gründen (das Skript, das die Tabellen generiert, mag keine Nicht-BMP-Zeichen) für Zeichen über U+FFFF HTML-Entitäten verwendet. Bei anderen Artikeln wird die Entität wohl entweder aus historischen oder ästhetischen Gründen benutzt, eine Regel gibt es nicht. -- Prince Kassad 13:35, 6. Mai 2008 (CEST)

@RedNifre: Hier geht's vermutlich um den Quelltext der Wikipedia-Seiten. Für HTML-Entitiäten spricht ganz klar, dass sie von Browser, Server und Skripten nicht zerschossen werden können. Wenn ich etwa im Artikel ß das Zeichen für Großes ß einfügen will, gebe ich die HTML-Entität ein[13]. Du hast dann den HTML-Code durch das Zeichen ersetzt[14], was ich für sinnlos halte:

• Erstens wüsste ich nicht, wie ich das Zeichen sonst auf meinem Computer erzeugen könnte.
• Zweitens geht beim Editieren und Upload im Browser sowieso immer etwas schief. Manche Betriebssystems denken auch bei Copy-and-Paste mehr mit, als ich es haben will.
• Und wer weiß, ob auf den Wikipedia-Servern alles erhalten bleibt?
• Nebenbei erleichtern HTML-Entities die Berechnung von Diffs in der Versionsgeschichte.
• Vor allem erleichtert HTML die Fehlersuche. Wenn das große ß in meinem Browswer nicht angezeigt wird, könnte es ja auch an einem fehlerhaften Zeichen im Quelltext liegen! Aber wie sollte ich das herausfinden, wenn da nur ein nicht darstellbares Zeichen steht?

HTML-Entitäten funktionieren. Zeichen würde ich nur für geläufige Buchstaben verwenden. Umlaute, griechische oder chinesische Buchstaben halte ich für kein Problem, solange aus dem Kontext klar wird, dass der jeweilige Text in einer dieser Sprachen geschrieben ist. Aber wenn ein exotisches Zeichen einzeln irgendwo im Text auftaucht, wäre mir eine HTML-Entity lieber. Da kann ich notfalls nachschlagen, was das eigentlich für ein Zeichen sein soll. --plauz 20:34, 6. Mai 2008 (CEST)

• Nimm eine geeignete Zeichentabelle und kopiere das Zeichen von dort ab.
• Bei mir geht nie etwas schief, alles klappt perfekt.
• Das Argument hat mich zum Aufheitern gebracht...
• Dafür sind HTML-Entitäten größer und machen den Quelltext in Massen unlesbar.
• In MS Word kopieren und Alt+C drücken, und tada, dir wird der Unicode-Codepunkt angezeigt.
• Netscape 4 z. B. mag keine HTML-Entitäten...

Allerdings ist ein Editwar zwischen HTML-Entität und Zeichen absolut sinnlos. Man sollte es wie in der en.wp handhaben: Wer zuerst kommt, darf auch bleiben. -- Prince Kassad 21:05, 6. Mai 2008 (CEST)

"Erstens wüsste ich nicht, wie ich das Zeichen sonst auf meinem Computer erzeugen könnte."

Das verstehe ich nicht. HTML-Entities funktionieren doch nur in sehr speziellen Bereichen?

"Zweitens geht beim Editieren und Upload im Browser sowieso immer etwas schief. Manche Betriebssystems denken auch bei Copy-and-Paste mehr mit, als ich es haben will."

Browser, die Unicode-Zeichen zerfetzen sind doch aus der Wikipedia ausgeschlossen. Schliesslich betrifft das alle Zeichen ueber U+007F, also sogar schon die Umlaute und das kleine Eszett. Wenn ein Browser die Umlaute nicht kaputt macht dann hat er auch keine Probleme mit anderen Unicode-Zeichen (korrigiert mich wenn ich mich irre)

"Und wer weiß, ob auf den Wikipedia-Servern alles erhalten bleibt?"

Die deutsche Wikipedia (und die meisten anderen) verwenden UTF-8, also gibt es auf den Servern keine Probleme

"Nebenbei erleichtern HTML-Entities die Berechnung von Diffs in der Versionsgeschichte."

Diesen Punkt verstehe ich nicht. Kannst du das noch etwas genauer erklaeren?

"Vor allem erleichtert HTML die Fehlersuche. Wenn das große ß in meinem Browswer nicht angezeigt wird, könnte es ja auch an einem fehlerhaften Zeichen im Quelltext liegen! Aber wie sollte ich das herausfinden, wenn da nur ein nicht darstellbares Zeichen steht?"

Ich glaube nicht, dass die Wikipedia der geeignete Ort ist, um zu ueberpruefen, ob man eine Schriftart richtig installiert hat. Ich wuerde erst sicherstellen, dass die Schrift installiert ist und danach den passenden Wikipedia-Artikel lesen.

"HTML-Entitäten funktionieren. Zeichen würde ich nur für geläufige Buchstaben verwenden. Umlaute, griechische oder chinesische Buchstaben halte ich für kein Problem, solange aus dem Kontext klar wird, dass der jeweilige Text in einer dieser Sprachen geschrieben ist. Aber wenn ein exotisches Zeichen einzeln irgendwo im Text auftaucht, wäre mir eine HTML-Entity lieber. Da kann ich notfalls nachschlagen, was das eigentlich für ein Zeichen sein soll. "

Fuer benannte HTML-Entities mag das stimmen aber meistens findet man doch HTML-Entities die statt eines Namens bloss eine Unicode-Nummer enthalten. Ob man die jetzt auf unicode.org nachschlaegt, oder das Zeichen selbst, macht doch keinen Unterschied? RedNifre 01:24, 8. Mai 2008 (CEST)

Ich habe in 25 Jahren Informatik zu oft erlebt, wie Murphys Gesetz zuschlägt. Wenn ich also mit wenig Aufwand eine potentielle Fehlerquelle ausschließen kann, tue ich das auch. Wenn bei dem Zusammenspiel aus Benutzer, Betriebssystem und Browser auf Endnutzerseite, Betriebssystem, Server und Skripten auf Wikipedia-Seite etwas schief geht, bist du für jede Arbeitserleichterung dankbar. Es macht das Leben so viel einfacher, wenn dann im Quelltext der Wikipedia etwas steht, was ich unabhängig von meinen (fehlerhaften?) Browsereinstellungen zuverlässig und einfach prüfen kann.

Mit HTML-Entity meine ich beides, benannte Zeichen wie ß und Unicode-Zeichen wie ẞ.

Die Frage, wie ich etwa ein großes ß in Wikipedia eingeben soll, ist nicht so trivial, wie sie klingen mag. Wo soll ich das Zeichen denn kopieren? Ich habe keine Zeichentabelle, die funktioniert. Oder soll ich's aus der Wikipedia kopieren, wo aber vielleicht ein falsches Zeichen steht, ich es aber nicht gemerkt habe?

Wenn ich statt dessen ẞ eingebe, kann ich selbst und andere im Quelltext auf einen Blick erkennen, dass das richtige Zeichen da steht. Beim Versionsvergleich ist das auch hilfreich. Denn wenn im Diff steht "?" wurde durch "?" ersetzt, sagt mir das garnix. Wenn dort aber steht "ẞ" wurde durch "ẟ" ersetzt, sehe ich sofort, dass da einer das Zeichen verhunzt hat.

Mir geht's hier ja nur um einzelne, freistehende, unübliche oder leicht verwechselbare Zeichen, wie großes ß oder langes s. Ich würde also auch kyrillische oder chinesische Einzelzeichen in einem deutsch- oder englischsprachigen Text in der Form &#x....;" codieren. In einem chinesisch-sprachigen Artikel fände ich dagegen Zeichen für den chinesischen Text passender. Diese Vorgehensweise erleichtert einfach die Korrektur.

Die Probleme mit Copy and Paste dürftest du vielleicht von Texteditoren kennen. Hast du schon mal einen 15 Jahre alten DOS-Text unter Linux oder Mac OS X geöffnet? Und dann versucht zu konvertieren, dass alle Sonderzeichen und Umlaute hinterher wieder stimmen? Da geht einfach sehr schnell sehr viel schief. Oder hast du schon mal in deinem Browser von Hand eine andere Textcodierung einstellen müssen, weil die Webseite anders codiert war, als es der Header behauptet? Meine Meinung ist also: im Zweifel eine Notation verwenden, die mit simplen ASCII-Zeichen auskommt. --plauz 16:30, 8. Mai 2008 (CEST)

Steuerzeichen

Hi. Ich bin noch nicht ganz glücklich mit der Behandlung der Steuerzeichen in Unicode-Block Basis-Lateinisch, Unicode-Block Lateinisch-1, Ergänzung. Es ist zwar korrekt, dass diese keine offizielle Bezeichnung haben, aber sie haben zumindest Alternativnamen. Jetzt stelle ich mir folgende Fragen:

1. Ist es sinnvoll, in der Spalte „Offizielle Bezeichnung“ den Alternativnamen einzutragen? Vielleicht mit erläuternder Fußnote oder sonstiger Markierung?
2. Ist es sinnvoll, in der Spalte „Zeichen“ das passende Code-Kürzel hinzuschreiben (z. B. „NUL“ oder „STX“)? Vielleicht mit erläuternder Fußnote oder sonstigem Hinweis? -- j ?! 12:55, 4. Jan. 2008 (CET)

Ok. Simplicius 10:59, 25. Mai 2008 (CEST)

Probleme mit Quellenangaben

Liste der Unicode-Zeichen/1000 bis 1FFF#1800–18AF Mongolisch - wie man sieht, werden alle Quellen einer Übersichtsseite immer in dem Block angezeigt, in dem als letztes Quellen verwendet werden, was aber sicherlich nicht gewünscht ist. Wie beheben wir das Problem? Mein Vorschlag wäre, mit einem <references/> die Referenzen ganz unten auf der Seite anzuzeigen, nur da wäre wiederum keine Abgrenzung vom letzten Block sichtbar. -- Prince Kassad 07:16, 11. Feb. 2008 (CET)

Ok. Simplicius 10:59, 25. Mai 2008 (CEST)

Unicode-Block Spacing Modifier Letters und Unicode-Block Verschiedene technische Zeichen

Bitte weiter vervollständigen. --Reiner Stoppok 20:43, 15. Mär. 2008 (CET)

Ok. Simplicius 10:59, 25. Mai 2008 (CEST)

Benutzer:Buncic/Unicode/Modifizierende Tonzeichen

Ich bitte um Korrekturvorschläge (ich habe U+A71B bis U+A71F entfernt). --Reiner Stoppok 20:45, 15. Mär. 2008 (CET)

Ok. Simplicius 10:59, 25. Mai 2008 (CEST)

www.decodeunicode

Bitte nur anführen, wenn dort auch was steht. Wenn nicht, dann bitte löschen. --Reiner Stoppok 22:55, 15. Mär. 2008 (CET)

Ok. Simplicius 10:59, 25. Mai 2008 (CEST)

UTF-8-Byte-Sequenzen in Zeichen-Artikeln komplett sinnlos?

(Ich habe das hier gerade von Wikipedia:Fragen zur Wikipedia hierher kopiert, da es hier wohl besser hinpasst) RedNifre 13:05, 6. Mai 2008 (CEST)

In vielen Wikipedia-Artikeln die sich mit Schriftzeichen befassen finden sich UTF-Hexadezimal-Sequenzen (hauptsaechlich UFT-8). Ich halte das fuer vollkommen sinnlos und wuerde mir eine Wikipedia-weite Richtlinie zur Vermeidung von UTF-Sequenzen wuenschen. Wo ist der richtige Ort, um darueber zu diskutieren? Hier? RedNifre 20:39, 5. Mai 2008 (CEST)

Vorerst kann man darüber ja mal hier sprechen (ob es überhaupt Änderungsbedarf gibt), ansonsten vielleicht Wikipedia Diskussion:UTF-8-Probleme; falls eine Entscheidung der Community notwendig sein sollte vllt. auch ein Meinungsbild. Für die technisch weniger versierten: Was genau meinst du denn mit UTF-Hexadezimal-Sequenzen? So lustige Sonderzeichen wie in meiner Signatur? Oder die &irgendwas;, wie z.B. † bzw.  ? --Church of emacs ツ ⍨ 21:14, 5. Mai 2008 (CEST)

Hier ist mal ein Zitat aus dem Eszett-Artikel:

Internationaler Zeichenkodierungsstandard Unicode,
Kodierung im Internet-Dokumentenformat HTML und in UTF-8

Zeichen	Unicode Position	Unicode Bezeichnung	Bezeichnung	HTML hexadezimal	HTML dezimal	HTML benannt	UTF-8 hexadezimal
ß	U+00DF	LATIN SMALL LETTER SHARP S	Lateinischer Kleinbuchstabe Eszett	ß	ß	ß	C3 9F
ẞ	U+1E9E	LATIN CAPITAL LETTER SHARP S	Lateinischer Großbuchstabe Eszett	ẞ	ẞ	-

Ich beziehe mich hier auf das "C3 9F" in der letzten Spalte, bzw. die komplette UTF-8-Spalte. In sehr vielen Artikeln zu Sonderzeichen steht die UTF-8-Byte-Sequenz. Ich halte das aus folgenden Gruenden fuer unsinnig:

• In der Praxis wird diese Sequenz von einem Programm automatisch aus dem Unicode-Zeichen generiert und auch wieder automatisch dekodiert. Ein Benutzer sieht diese Sequenz eigentlich nie.
• Man kann solche Sequenzen auch nirgends eingeben. Moechte man ein Unicode-Zeichen eingeben, so gibt man dessen Nummer ein und nicht eine Byte-Folge aus irgend einem UTF
• Mir leuchtet auch nicht ein, warum man gerade UTF-8-Bytes schreibt, nicht aber die zugehoerige UTF-16-Sequenz oder UTF-32
• Man kann bei UTF-8-Sequenzen auch kaum nachvollziehen, wie diese Byte-Sequenz mit dem Zeichen zusammenhaengt. Dies vermittelt meiner Meinung nach den Eindruck, als haette jedes Zeichen eine wahllos festgelegte Byte-Folge zugewiesen bekommmen. (Was ja Unsinn ist)
• Ich kann mir absolut keine Situation vorstellen, in der man diese Byte-Folge gebrauchen koennte.

RedNifre 23:20, 5. Mai 2008 (CEST)

Verstehe ich es richtig, dass du die Angaben der UTF-8-codierten Bytefolgen in solchen Zeichentabellen für unnötig hältst? Du hast natürlich recht, dass dies nur eine Umkodierung der Unicode-Angabe ist und somit überflüssig. Auch die Wahl von UTF-8 (und nicht UTF-16 oder -32) ist natürlich in gewisser Hinsicht willkürlich. Wenn man aber bedenkt, dass vermutlich 95% aller Unicode-Texte in UTF-8 kodiert werden, ergibt dies wieder halbwegs Sinn. Ich finde, die Angabe stört nicht wirklich und kann daher ruhig stehen bleiben, da sie ja nicht stören. --APPER\^☺☹ 23:26, 5. Mai 2008 (CEST)

Hm, wenn ich es richtig verstehe ist deine Einstellung "Wenn es nicht schadet kann es bleiben". Ich hingegen bin der Meinung "Wenn es niemandem nuetzt sollte es weg". Wenn ich dich richtig verstehe wuerde es dich auch nicht stoeren, wenn da auch UTF-16 und UTF-32 stehen wuerde.

"Wenn man aber bedenkt, dass vermutlich 95% aller Unicode-Texte in UTF-8 kodiert werden, ergibt dies wieder halbwegs Sinn." Das sehe ich nicht so. Man liest ja UTF-8-Texte nicht, indem man sich die Bytes anschaut, sondern indem man es automatisch konvertieren laesst.

Und selbst WENN man sich die Bytes als Hexadezimalwerte anschaut: Man wuerde dann auch nicht die UTF-8-Sequenzen in der Wikipedia nachschlagen (Wie auch?). Wenn man keinen Dekoder hat wuerde man es von Hand dekodieren um auf das Unicode-Zeichen zu kommen und dann wuerde man das dekodierte Zeichen direkt nachschlagen.

Also, ich bin jedenfalls der Meinung, dass "schadet nicht" nicht ausreicht um etwas in die Wikipedia zu schreiben. Es sollte "mindestens irgendjemandem in irgendeiner Situation nuetzlich sein". Und ich kann mir beim besten Willen keine Situation vorstellen, in der man zu einem ganz bestimmten Zeichen die zugehoerige UTF-8 Sequenz nachschlagen wollte. RedNifre 23:54, 5. Mai 2008 (CEST)

So what? Es gibt hier keinen Speicherplatzmangel, so dass es wegmüsste, und soweit ich weiß haben wir hier noch immer die Prämisse, dass wir Informationen behalten, als dass wir sie einfach auslassen und jemand kommt und dann Fragen stellt. --87.168.54.114 01:02, 6. Mai 2008 (CEST)

What? That: wir haben als Enzyklopädisten die Aufgabe, aus der Masse an Information das relevante Wissen herauszuarbeiten und für unsere Leser verständlich und sinnvoll aufzubereiten. Sinnlose und irrelevante Information (wenn das hier der Fall ist, zum konkreten Fall habe ich keine Meinung) sollte selbstverständlich verschwinden, damit es weniger rauscht. --elya 07:04, 6. Mai 2008 (CEST)

Ich bin normalerweise auch immer für Behalten, aber in dem Falle kommt mir das auch recht unnütz vor. Außerdem müsste das sonst noch jemand für das große Eszett ausrechnen.

Wenn jemand einen UTF-8-Codierten Text lesen wollte, würde er seine Werkzeuge habe, um die Zeichen zu (de)kodieren. Allerdings macht das Lesen als Sedezimalcode wenig Sinn, wenn man nicht gerade irgendwelche Steuerzeichen bearbeiten will, die nicht angezeigt werden. Ansonsten ist das Bearbeiten mit einem normalen Plaintexteditor viel einfacher und effektiver. --Nico Düsing (Diskussion) 12:12, 6. Mai 2008 (CEST)

@RedNifre: "Ich kann mir absolut keine Situation vorstellen, in der man diese Byte-Folge gebrauchen koennte." -- Geht mir auch so. Die eigentliche Unicode-Nummer ist wichtig, um das Zeichen zu identifizieren. Die HTML-Codes sind praktisch, wenn man die Zeichen in Webseiten einbauen will. Beides brauche ich häufiger. Aber UTF-8? Ich kann mir auch keine Situation vorstellen, wo ich UTF-8 von Hand codieren oder decodieren würde.

@elya: Volle Zustimmung. Ich sehe den Wert einer Enzyklopädie ebenfalls in der klugen Auswahl relevanter Informationen.

Von mir aus kann die UTF-8 Darstellung aus Zeichenbeschreibungstabellen durchaus weg, solange keine konkreten Anwendungsfälle bekannt sind. --plauz 18:49, 6. Mai 2008 (CEST)

Da ich mir momentan ziemlich sicher bin, dass UTF-8-Hexadezimal-Byte-Sequenzen niemandem etwas nuetzen, werde ich sie in Zukunft loeschen und einen Link auf diese Diskussion als Edit-Kommentar angeben. Falls es jemanden gibt, der einen Sinn im UTF-8-Kram erkennt, wird er so auf diese Diskussion aufmerksam gemacht und kann seine Argumente hier einbringen. RedNifre 01:07, 8. Mai 2008 (CEST)

Ich finde die Diskussion sehr seltsam; meiner Ansicht nach sind gerade die UTF8-Sequenzen die Form, in der einem diese Unicode-Zeichen am häufigsten unterkommen. Beispielsweise in den URLs in der Wikipedia: http://de.wikipedia.org/wiki/%C3%9F ist eben das ß, und wenn mir mal bei einem Artikel statt eines Zeichens nur ein Kästchen dargestellt wird, weil mir irgendein Font fehlt, kann ich mit der UTF8-Sequenz aus der URL wunderbar nachschlagen, welches Zeichen denn da zu sehen sein soll. Damit wäre bewiesen, dass diese Angaben nicht sinnlos sind, q.e.d., und ich hoffe das massenhafte Entfernen entfällt nun und mit der Zeit wird was besseres angefangen? — ^PDD — 19:07, 8. Mai 2008 (CEST)

Aehm, wie kannst du denn nachschlagen, was eine UTF-8 Sequenz bedeutet? (Die umgekehrte Richtung ist mir klar) RedNifre 21:19, 8. Mai 2008 (CEST)

So wie ich alles in der Wikipedia nachschlage, mit Google (in diesem Fall z. B. mit [15]). — ^PDD — 00:38, 9. Mai 2008 (CEST)

Ah, okay. Dann gibt es wohl doch eine Moeglichkeit, einen Nutzen aus den UTF-8-Sequenzen zu ziehen. Ich habe mich geirrt. RedNifre 01:14, 9. Mai 2008 (CEST)

Wenn ich nach eigentlich schon abgeschlossener Diskussion auch noch meinen Senf dazugeben darf: Zufällig schreibe ich gerade an einem CGI-Skript in Perl, das ein Formular auswerten und die Daten in einer in UTF-8 kodierten E-Mail versenden soll (und dies inzwischen auch tut). Dabei war ich sehr froh, dass unter UTF-8 eine Tabelle verlinkt ist, in der die UTF-8-Werte für alle Zeichen aufgelistet sind, weil das Skript zum einen die UTF-8-kodierten Eingaben teilweise ‚von Hand‘ in HTML-Entities zur Anzeige auf einer automatisch generierten Antwortseite oder in entsprechende ASCII-Zeichen zur Erzeugung von Dateinamen umwandeln (also z. B. aus dem UTF-8-Kode von <č> ein <c> machen) muss und weil ich zum anderen gern selbst Text in ein UTF-8-kodiertes E-Mail schreiben würde, wozu ich folgende Variablen festgelegt habe:

$Ae = chr(0xc3) . chr(0x84);
$Oe = chr(0xc3) . chr(0x96);
$Ue = chr(0xc3) . chr(0x9c);
$ae = chr(0xc3) . chr(0xa4);
$oe = chr(0xc3) . chr(0xb6);
$ue = chr(0xc3) . chr(0xbc);
$ss = chr(0xc3) . chr(0x9f);

Ich weiß nicht, ob diese Informationen deshalb unbedingt auch in der Wikipedia stehen müssen, aber dass es sie irgendwo gibt, fand ich jedenfalls sehr sinnvoll. --Daniel Bunčić ^? ♥ ± 10:16, 11. Mai 2008 (CEST)

Ich musste die UTF-8-Sequenzen schon benutzten, es gibt gelegentlich Texte, die sind als UTF-8 deklariert aber tatsächlich als ISO-8859 oder CP1252 gespeichert. Da hilf nur noch ein HEX-Editor um nachzuschauen (oder zumindest abzuschätzen) in welcher Kodierung der Text vorliegt. Wernfried 14:24, 30. Mai 2008 (CEST)

Gesamtzahl an Zeichen (NICHT Code-Points)

Oft liest man, Unicode haette Platz fuer 1.114.112 "Zeichen". Das ist aber auf jeden Fall falsch, es sind definitiv weniger. Zieht man die Surrogates (2048) und die Nonchars(66) ab bleiben maximal 1.111.998 Unicode-Zeichen. Allerdings bin ich mir auch nicht sicher, ob 1.11998 wirklich die korrekte Anzahl an theoretisch moeglichen Zeichen darstellt, oder ob es noch weniger sind. Was meint ihr? RedNifre 00:36, 8. Mai 2008 (CEST)

Im Standard steht: "The Unicode Standard contains 1,114,112 code points, most of which are available forencoding of characters." So ähnlich sollte man es auch hier schreiben. Der grösste Teil der verfügbaren Code-Points ist ja nicht definiert, d. h. man weiss heute noch gar nicht ob dafür später einmal Zeichen oder anderes definiert werden. Aktuell werden diese Zahlen aufgelistet:

Graphic: 100.507, Format: 141, Control: 65, Private Use: 137.468, Surrogate: 2.048, Noncharacter: 66, Reserved: 873.817, Summe: 1.114.112 :http://www.unicode.org/versions/Unicode5.1.0/

Im Artikel Unicode steht, es seien 100.713 Zeichen, weshalb "Format" und "Control" dazu gezählt sind weiss ich nicht.

Wernfried 11:20, 14. Mai 2008 (CEST)

100713 ist aber bloss die Anzahl der bereits definierten Zeichen. Ich frage mich nur, wie viele Zeichen man maximal definieren koennte. 1.111.998 oder weniger? RedNifre 13:33, 14. Mai 2008 (CEST)

Es sind 1.114.112 Code-Points definiert, davon sind noch 873.817 frei. Es ist also noch Platz für 873.817 Zeichen, obwohl man davon ausgehen kann, dass auch noch "Noncharacters" oder "Surrogates" definiert werden. Wernfried 14:39, 30. Mai 2008 (CEST)

Pressemitteilung auf Wikipedia:Kurier

Hab's gerade gelesen. Tolle Sache. – Simplicius 2004-2008 19:18, 5. Jun. 2008 (CEST)

축하합니다, 恭喜恭喜, Glückwunsch --chrislb 13:57, 7. Jun. 2008 (CEST)

Unicode-Block Kangxi-Radikale

Da ich so eine Liste vermisste (die die handlichen Kurzbezeichnungen mit dem Zugriff auf die ausführlichen Artikel verbindet), habe ich sie gestern kurzerhand selber gebastelt, ohne mich vorher mit dem Procedere vertraut zu machen – zuerst ohne deutsche Bezeichnungen, aber dann hat mich Reiner überzeugt, die enlischen zu übersetzen. Dabei bin ich bei folgenden Übersetzungen noch unsicher:

• Radikal 23 hiding enclosure „Versteck“
• Radikal 29 again „erneut“
• Radikal 34 go „gehen, fahren“, Radikal 162 walk „gehen“
• Radikal 35 go slowly „langsam gehen / fahren“ vgl. Radikal-Einträge!
• Radikal 37 big „groß“, Radikal 189 tall „hoch“
• Radikal 49 oneself „selber“, Radikal 132 self „selbst“
• Radikal 58 snout „Schnauze, Schweinerüssel“
• Radikal 66 rap „klopfen“
• Radikal 77 stop „Halt“, Radikal 138 stopping „aufhören“
• Radikal 91 slice „Schnitte“
• Radikal 113 spirit „Geist“, Radikal 194 ghost „Gespenst“
• Radikal 149 speech „Sprache, Rede“

Ein oder zwei davon habe ich auch in Benutzer:Buncic/Unicode/CJK-Radikale, Ergänzung verwendet. Da interessiert mich aber mehr, ob die Zusätze „(links), (rechts), (oben), (unten)“ so verständlich sind oder näher erläutert werden müssen. -- Olaf Studt 16:58, 15. Apr. 2008 (CEST)

Langfristig sollte sich die Übersetzung noch stärker an den englischen Originalbezeichnungen orientieren, also immer mit "Kangxi-Radikal" davor. (Es gibt ja viele weitere Radikalsysteme mit x, y, z Radikalen, z.B. im Cihai, im Xiandai Hanyu cidian usw.) Auch sollte m.E. bei stärkeren Abweichungen von Unicode - die fachlich berechigt sein mögen - dann in Klammern o.ä. darauf hingewiesen werden. --Reiner Stoppok 15:36, 18. Mai 2008 (CEST)

Fragwürdige Übersetzung

Ich habe mir erlaubt, am 17. Juni 2008 so einfach etwas zu ändern, wie ich meinte zum Deutlicheren; damit habe ich Missfallen erregt, siehe die Versionsgeschichte (Radikal 44 bedeutet in 1.Linie Körper vs. "corpse" ist eindeutig "Leiche"). Nach wie vor bin ich der Meinung, dass die Semantik unter "Offizielle Bezeichnung (KANGXI RADICAL)" wohl nicht so ganz dogmatisch eng genommen werden darf; und "Leiche" finde ich als zu eng gefasst für Radikal 44. Deshalb wollte ich zur Diskussion stellen, ob gelegentlich eine grosszügigere Interpretation besser sei als die wörtliche Übersetzung; siehe auch Diskussion:Liste_traditioneller_Radikale#Radikal_44_bedeutet_in_1.Linie_K.C3.B6rper_.3F.

Viele Zeichenverbindeungen mit 尸 haben überhaupt nichts mit "Leiche" zu tun, aber sehr wohl mit "Körper". Zum Beispiel die Glyphen 尿 (Wasser 水 unter 尸) für Miktion, und 屎 (Reis 米 unter 尸) für Defäkation beschreiben Vorgänge, die doch nun wirklich mehr mit (lebenden) Körpern, als mit Leichen zu tun haben.

Ich kann gut damit leben, wenn 尸 für tot erklärt wird; aber stur, wie ich bin, meine ich einstweilen immer noch, dass "Körper; Leiche" oder dgl. besser sei als nur "Leichnam". Freundliche Grüsse, wdh --193.196.166.161 13:20, 20. Jun. 2008 (CEST)

Weblinks nach decodeunicode

Hiermit schlage ich vor, die Weblinks nach Grafische Informationen des Wiki-Projekts decodeUnicode überall herauszunehmen. Ich habe einfach zu oft dabei in informationslose Leere geklickt. --Reiner Stoppok 21:54, 26. Jun. 2008 (CEST)

Auf einzelne Zeichen verweisen wir ja nicht, und zu den Blöcken ist in den allermeisten Fällen dort etwas eingetragen (auch wenn vor allem die neuen Blöcke aus Unicode 5.1 noch fehlen). Aber um den Text geht es mir gar nicht so sehr, der Link-Text sagt ja deutlich: "Grafische Informationen". Das ist der Mehrwert für die Wikipedia-Leserin: ein schönes, großes Bild jedes einzelnen Zeichens, ohne dass man erst umständlich ein PDF herunterladen, den Adobe Reader starten (oder gar erst noch installieren?) und dort die entsprechende Stelle heranzoomen muss. (Außerdem: Allein schon weil es auch ein Wiki ist, sollte man solidarisch sein... ;-) ) --Daniel Bunčić 07:28, 27. Jun. 2008 (CEST)

Das bekommt man woanders doch genauso. Entweder, die da strengen sich etwas mehr an und bringen da wesentlich mehr Vollzähligkeit rein, oder es sollte verschwinden. --Reiner Stoppok 23:44, 28. Jun. 2008 (CEST)

In den Unicode 5.1-Blöcken kann der Link wirklich raus (was ich größtenteils bereits erledigt habe), aber in den anderen Blöcken bietet der Link einen Mehrwert gegenüber den PDFs, vor allem, da auch die Zeicheneigenschaften erwähnt werden (das vermisse ich in den Unicode.org-PDFs) -- Prince Kassad 00:34, 29. Jun. 2008 (CEST)

Wenn man es anderswo genauso bekommt, können wir meinetwegen auch gern auf eine andere Seite verlinken. Wo gibt es das denn noch? --Daniel Bunčić 07:56, 29. Jun. 2008 (CEST)

Wenn ich es richtig sehe, gibt es das hier doch auch. Mich hat einfach der zu kleine Zeichenbestand gestört. --Reiner Stoppok 13:09, 29. Jun. 2008 (CEST)

Unicode-Block Vai

Ich bin mit den jüngsten Versionen des Unicode-Block Vai nicht einverstanden. Wir hatten doch bereits darüber den Konsens erzielt, die Sonderzeichen gänzlich zu vermeiden (oder falls unumgänglich, in Klammern eine wissenschaftliche Transkription dahinter zu setzen, vgl. Unicode-Block Kyrillisch). --Reiner Stoppok 03:30, 13. Jun. 2008 (CEST)

Ich dachte nur, weil die deutsche Spalte 1:1 gleich der englischen war ... -- Olaf Studt 08:53, 27. Jun. 2008 (CEST)

Tja. - Was nun? --Reiner Stoppok 23:35, 28. Jun. 2008 (CEST)

So, wie du es jetzt gemacht hast, finde ich es ganz gut. Eine Variante wäre höchstens, dass man die "Afrika-Schreibweise" übernimmt, solange sie keine Sonderzeichen enthält. Allerdings wäre die Benennung dann bemerkbar uneinheitlich. Aber warum sind die Namen in Klammern denn kleingeschrieben? Muss das so sein? Und noch etwas: Hieltet ihr es für sinnvoll, die Tabelle in den Artikel Vai-Schrift zu integrieren? Ein Unicode-Listen-Gegner (weiß nicht mehr wer's war) forderte dies ja bereits für einen anderen Block, der so wie dieser hier nur eine einzige und wenig bekannte Schrift enthielt. In einem solchen Fall wäre die Abhandlung in einem einzigen Artikel ja durchaus möglich. Oder soll alles besser separat bleiben? Gismatis 00:59, 29. Jun. 2008 (CEST)

Die Buchstabennamen sollten auch in den Klammern groß geschrieben werden. Auf keinen Fall darf ein Durcheinander entstehen zwischen den verschiedenen Schreibweisen, da ist die jetzige Lösung m.E. optimal. In einigen Artikeln sind die entsprechenden Unicode-Tabellen ja bereits integriert. Der Block sollte aber auch für sich bestehen bleiben. (Ich nehme an, das war hier auch so gemeint.) --Reiner Stoppok 13:17, 29. Jun. 2008 (CEST)

Von Benutzer Diskussion:Olaf Studt#Unicode-Block Vai kopiert --Gismatis 02:50, 8. Jul. 2008 (CEST): Hallo Olaf, ich bin das ganze Silbenalphabet durchgegangen und habe deine eingetragenen Schreibweisen mit den angegebenen Quellen verglichen. Dabei habe ich viele Unterschiede ausgemacht. Einige Schreibweisen habe ich überhaupt nicht gefunden. Die beiden Übersichten unterscheiden sich ebenfalls. Wie war es dir also möglich, diese Schreibweisen einzutragen? Gismatis 01:03, 7. Jul. 2008 (CEST)

Meine Version ist sozusagen einen Synthese aus SIL (ɔ, ɛ, ~, ŋ) und Omniglot (mɓ, ɖ); für das bei Omliglot als c und bei SIL als ch angegebene Phonem habe ich in Afrika-Alphabet in der Spalte LR das č gefunden. Da ich mit der Schrift nicht vertraut bin, können mir dabei Fehler unterlaufen sein. Wie ich grad sehe, müssten nach Omniglot die ndV-Silben eigentlich nɖV lauten. -- Olaf Studt 10:58, 7. Jul. 2008 (CEST)

Wenn das so ist, würde ich die Schreibweisen lieber wieder herausnehmen, wenn du nicht wahnsinnig daran hängst. Denn es bleibt unklar, inwieweit das Afrika-Alphabet als Transkription der Vai-Schrift überhaupt eine Rolle spielt, bzw. ob es überhaupt einen Standard für die Transkription gibt. Gismatis 02:50, 8. Jul. 2008 (CEST)

Tja, da ist mir die Recherche wohl unter der Hand zur Theoriefindung ausgeartet. Ich werde dann mal ein paar Beispiele zur Umschrift in Vai-Schrift ein- und die Afri-Klammern aus Unicode-Block Vai ausbauen. -- Olaf Studt 09:36, 9. Jul. 2008 (CEST)

---

Unicode-Block Kangxi-Radikale (2)

Hier kommt ein etwas längerer Text, mit Untersuchungsergebnissen, Vorschlägen etc. zur Diskussion.

IST-Zustand

Die Radikalen-Artikel enthalten viel Wichtiges in recht gutem Aufbau, allerdings sind Informationen, die immer wieder in den einzelnen Artikeln vorkommen, unterschiedlich dargestellt. Hier wäre einiges zu verbessern. Das aktuelle Layout der Radikale 1 bis 214 ist uneinheitlich gehalten.

Meist werden unter "Literatur" die üblichen drei Verdächtigen genannt; manchmal auch keiner, nur einer oder zwei, selten auch vier oder fünf. Lindqvist wird durchgängig mit 'q' geschrieben; Li Leyi manchmal auch 'Leyi Li' (52mal). Mal werden die Bücher italic angegeben, mal bold, mal mit Gänsefüsschen, mal ohne all das; Die ISBN-Nummern werden uneinheitlich geschrieben, also nicht mit den WP-Regeln konform. Es sind auch nicht immer dieselben ISBN zitiert. Relativ selten sind die Seitennummern angegeben; manchmal steht hier nur '(Seite )' (als Absichtserklärung?); auch hier uneinheitlich: manchmal italic, manchmal bold, manchmal regulär. Einige der Seitennummern sind falsch. Oft ist Fazzioli verlinkt, aber nicht immer (die beiden anderen natürlich nicht, da es die Artikel Li Leyi und Cecilia Lindqvist noch nicht gab).

Die Häufigkeit erwähnt relativ oft die Zahl aus Mathews', eher selten jene im Kangxi-Buch. In vielen Fällen stehen bei Mathews' statt der Zahl nur zwei Pünktlein als Platzhalter; allerdings sind diese Mathews-Zahlen in der Übersicht vollständig eingetragen.

Immer wieder mal wird auf die unterschiedliche Position in den verschiedenen Radikalenlisten hingewiesen - auch dieser Hinweis ist in mehreren Varianten vorhanden.

Mögliche Angaben

Zu den Infoboxen ist als Anleitung vermerkt, sie seien

„eine Möglichkeit zur einheitlichen und einfachen Verwendung von Tabellen, die bei einigen Artikeln am Anfang stehen und grundlegende Daten enthalten; Die Infoboxen sollen ein anschauliches Hilfsmittel zum Fließtext sein und diesen nicht ersetzen, sondern lediglich ergänzen. Alle zur angemessenen Erklärung des Begriffs nötigen Informationen müssen deshalb auch im Fließtext vorhanden sein“

– Hilfe:Infoboxen

.

Dieser Anleitung entsprechend, könnten einige weitere Angaben in die zu erweiternde Infobox aufgenommen werden:

Als Referenzen die Seitennummern bei

• Fazzioli,
• Li und
• Lindqvist;

zusätzlich die Position in folgenden Büchern (das machet en.WP so):

• Kangxi-Buch (Seite, Zeichen),
• Dai Kanwa Jiten (Zeichen),
• Dae Jaweon (Seite, Zeichen),
• Hanyu Da Zidian (Band, Seite, Zeichen).

Unicode/Unihan verweist noch auf Positionen in

• Morohashi (Nummer)
• Nelson (Nummer)
• Meyer-Wempe (Nummer);

die Häufigkeiten in

• Mathews' Chinese-English Dictionary und im
• Kangxi-Wörterbuch;

• die Anzahl der Striche;
• die Position in der Liste im Neuen chinesisch-deutschen Wörterbuch aus der Volksrepublik China.

Neben dem traditionellen System mit 214 Radikalen gibt noch weitere Listensysteme für Radikale, mit (unvollständige Aufzählung)

• 187, 188, 189 (erwähnt), aber auch 224 und 227 Radikalen (letztere wird in Gegenüberstellungen angesprochen).

Interessant sind die Codepoints im

• "Block der Kangxi-Radikale (2F00-2FDF)" sowie im
• Block der "CJK Unified Ideographs (4E00-9FBF)", jeweils hexadezimal und dezimal.

Die Eingabe-Codierung nach der

• "KangXi(Cangjie) Eingabe-Methode" (Eingabe mit Standard-Tastatur; Latein und chinesisch) und nach der
• "4 Ecken-Methode" wären auch noch weitere mögliche Angaben.

Mit all diesen Angaben würde die Infobox heillos überladen und der Effekt wäre Unübersichtlichkeit.

SOLL-Zustand

Die aktuell versorgten Infobox Parameter erscheinen genau richtig; mehr trägt kaum zur Übersichtlichkeit bei (die Angabe zu Vorgänger und Nachfolger ist weniger Information, sondern die Möglichkeit, durch die Radikalen zu blättern). Als einzige eventuelle Erweiterung würde die Angabe des Hex-Codepoints im Block 4E00-9FBF sinnvoll erscheinen; bei bis zu drei Zeichen sollten dann auch die zusätzlichen Codepoints erscheinen. Die Werte im Block 2F00-2FDF sind hier wohl nicht so interessant.

Den Informationen im Fliesstext würde eine einheitlicheres Layout gut tun. Es ist unvermeidbar, dass jeder einzelne der 214 Artikel geändert wird. Manches liesse sich automatisieren, infolge des einstweilen noch sehr unterschiedlichen Aufbaues aber nur mit so hohem Aufwand, dass die manuelle Editierung sinnvoller erscheint.

Natürlich werden als Folge auch die Sichtungen für alle Artikel erforderlich.

Verweis auf allgemeine zentrale Informationen

Einige Informationen sind allgemeiner Natur, es erscheint der Übersichtlichkeit dienlicher, in jedem einzelnen der 214 Radikalenartikel den einheitlich gehaltenen Hinweis/Link auf die zentrale Stelle zu geben, wo die zusätzlichen, allgemeinen Informationen einmal gegeben werden. Dafür bietet sich der Artikel "Liste traditioneller Radikale" an, eventuell auch ein eigener neuer Artikel zur Radikalen-Literatur; dieser könnte vielleicht auch einige Bildchen der Bücher, wie es sie in den Commons bereits gibt, zeigen.

Dass die Position in anderen Radikalenlisten anders sei, müsste nicht in jedem Radikalen-Artikel von 1 bis 214 so ausführlich erwähnt werden. Die jeweils anderen Positionsnummern wären statt im Fliesstext übersichtlicher in einer zentralen Tabelle untergebracht.

Verweis auf zentrale Informationen zur Literatur

Anstelle der Literaturangaben erscheint ein Verweis an eine solche zentrale Angabe ausreichend und sinnvoller: Liste_traditioneller_Radikale#Literatur, habe ich unlängst bereits erweitert und begradigt.

Falls als Ergebnis der Diskussion die Beibehaltung der Literaturangaben in der aktuellen Form opportun erscheint, sollten zumindest in den einzelnen Radikalenartikeln keine Seitennummern stehen, diese sollen besser ebenfalls in eine zentrale Tabelle ausgelagert werden. ISBN sollten richtig und die Abgaben einheitlich standardisiert sein.

Bilder

Bei den en:WP-Radikalen werden animierte GIF-Bilder aus den Commons verwendet, die die Strichfolge zeigen. Siehe Image:永-order.gif.

Zusätzliche Angaben

Einige der Daten sind im bereits bestehenden Artikel Unicode-Block Kangxi-Radikale sehr übersichtlich in einer sortierbaren 4spaltigen Tabelle dargestellt. Allerdings sind in der Spalte "Beschreibung" gleich vier Elemente vereint (Radikal-Nr., Kurzübersetzung, die Glyphe und der Codepoint 4E00-9FBF), mithin 8 Elemente in den vier Spalten.

Es gibt nun die Möglichkeit, diese Tabelle zu erweitern; die Folge wäre eine recht arge Überladung. Ausserdem scheint es nicht so erstrebenswert, die bestehende Tabelle in noch höherem Ausmass unterschiedlich zu all den anderen Unicode-Tabellen zu gestalten; die Zusatzinformationen für doch recht spezielle Interessen gehören an eine andere Stelle, an die hier nur verwiesen werden sollte.

Die andere Möglichkeit ist, einen weiteren Artikel zu erstellen mit all den oben genannten Tabellendaten. Auch das ist zwiespältig und kann kontrovers beurteilt werden. Die normale Seitenbreite sollte möglichst nicht überschritten werden. Die etwa 25 Spalten liessen sich bei geeigneter Darstellung noch mit der Seitenbreite harmonisieren, einige der in der aktuell bestehenden Tabelle vorhandenen Daten müssten nicht nochmals aufgenommen werden.

Die dritte Möglichkeit, alles so zu belassen, erscheint am wenigsten attraktiv.

Beispiel für neue Tabellendarstellungen

Eine sinnvolle Aufteilung in mehrere Tabellen eröffnet die Möglichkeit, die Informationen vom Allgemeineren ins Speziellere zu vertiefen. Bei entsprechendem Tabellendesign ist es sehr einfach, Tabellen aus Wikipedia zu entnehmen, um sie auf dem eigenen Rechner beliebig zusammenzusetzen.

Die Reihung der Tabellenspalten ist hier noch zufällig. Als einzig sinnvolles Sortierkriterium erscheint hier die Radikalnummer, die Tabelle bleibt deshalb nicht sortierbar.

Die Tabelle könnte etwa folgende Daten (Spalten) enthalten (Beispiel der ersten paar Zeilen):

Legende

• A Nummer des Radikals im traditionellem System; verlinkt.
• B das Zeichen, die Glyphe in der CJK-Schrift
• C Anzahl der Striche
• D hexadezimale Codierung des Zeichens im Unicode-Block Kangxi-Radikale für CJK-Schriften (2FF0 bis 2FD5)
• E hexadezimale Codierung des Zeichens im Unicode-Block Vereinheitlichte CJK-Ideogramme (4E00 bis 9FBB)
• - Pinyin (eher nur eine Schreibung? - es gibt manchmal mehrere)
• F Nummer von Seite/Zeichen im alten chinesischen Schriftzeichenlexikon Kangxi zidian
• G Nummer des Zeichens im japanischen Wörterbuch Dai Kan-Wa jiten
• H Nummer von Seite/Zeichen im koreanischen Wörterbuch Dae Jaweon
• I Nummer von Band-Seite/Zeichen im Neuen chinesischen Zeichenlexikon Hanyu da zidian
• - Nummer des Zeichens bei Morohashi
• - Nummer des Zeichens bei Nelson
• - Nummer des Zeichens bei Meyer-Wempe
• J Eingabe nach der Cangjie-Methode (chinesische Tastatur)
• K Eingabe nach der Cangjie-Methode (US-Tastatur, Latein)
• L Eingabe/Darstellung nach der Viereckenindexmethode (gibt es nicht für alle Radikale)
• M textuelle Kurz-Beschreibung
• N Seitennummer bei Fazzioli
• O Seitennummer bei Lindqvist
• P Seitennummer bei Li
• Q Häufigkeit der Zeichenverbindungen im Kangxi-Wörterbuch
• R Häufigkeit der Zeichenverbindungen im Mathews-Wörterbuch
• - Nummer des Radikals im 227er System
• - Nummer des Radikals im 189er System

A B  C    D      E	F	G	H	I	J	K	L	M	N	O	P	Q	R
001 一 01 2F00 4E00	75/1	1	129/1	1-1/1	一	M	0-1000	eins	236	336	407	42	27
002 丨 01 2F01 4E28	78/20	67	157/45	1-28/2	中	L	-	Linie	197			21
003 丶 01 2F02 4E36	80/12	91	162/14	1-42/8	戈	I	-	Punkt	247			10
004 丿 01 2F03 4E3F	81/6	106	164/7	1-31/2	竹	H	-	Schrägstrich	246			33
005 乙 01 2F04 4E59	83/15	161	167/7	1-47/4	弓山	NU	0-1771	Zweiter	142		4	42
006 亅 01 2F05 4E85	85/9	224	173/18	1-28/3	中戈	LI	-	Haken	144			19
007 二 02 2F06 4E8C	86/1	247	175/6	1-2/1	一一	MM	0-1010	zwei	237			29	14
008 亠 2 2F07 4EA0	88/2	286	184/12	1-279/4	戈一	IM	-	Deckel	80			38
009 人 2 2F08 4EBA	91/1	344	190/1	1-101/10	人	O	0-8000	Mensch	24	25		794	320
010 儿 2 2F09 513F	123/1	1336	257/21	1-264/4	中山	LU	0-2201	Beine	74			52
011 入 2 2F0A 5165	125/32	1415	266/18	1-102/1	人竹	OH	0-8000	betreten	85			28
012 八 2 2F0B 516B	126/26	1450	274/13	1-241/3	竹人	HO	0-8000	acht	238			44
013 冂 2 2F0C 5182	128/30	1506	289/9	1-96/13	中尸	LS	-	Kasten unten offen	115			50
014 冖 2 2F0D 5196	130/12	1565	292/12	1-302/14	戈弓	LN	-	bedecken	91			30
015 冫 2 2F0E 51AB	131/15	1607	294/11	1-295/1	戈一	IM	-	Eis	192			115
016 几 2 2F0F 51E0	133/57	1737	299/8	1-275/19	竹弓	HN	0-7721	Tisch	140	245		38
017 凵 2 2F10 51F5	134/39	1800	300/25	1-306/15	女中	VL	0-2277	Kasten oben offen	104			23
018 刀 2 2F11 5200	135/24	1845	304/4	1-319/2	尸竹	SH	0-1722	Messer	129	250		377
019 力 2 2F12 529B	146/5	2288	327/31	1-364/4	大尸	KS	6-2002	Kraft	55		165	163
020 勹 2 2F13 52F9	150/18	2493	339/6	1-254/13	竹尸	HS	-	einwickeln	59			64

An diesem Entwurf, mit dem Beispiel einiger Zeilen und Spalten, lässt sich noch viel verbessern. Ich muss noch Daten sammeln und, vor allem, auch prüfen. Dies hier ist Beispiel und Diskussionsgrundlage. Gruss, wdh --193.196.166.161 09:45, 3. Jul. 2008 (CEST)

Diskussion

Auf die schnelle:

1. Allzuviele Daten finde ich ungeschickt, da der Leser eher erschlagen wird mit Information, die er in 99,9% der Fälle nicht benötigt. Also Index in den verschiedenen Wörterbüchern wäre etwas für eine Datenbank, aber eher weniger für die Wikipedia.
2. Radikal-Animationen können gerne eingebaut werden, das ist händisch aber sicherlich ein wenig Arbeit.

Ich möchte erstmal nicht mehr schreiben, zur Zeit ist mein Interesse in diese Richtung nicht so stark. Falls es aber weitere Fragen gibt, würde ich noch einmal drüber schauen. Frag auf jeden Fall auch in der Redaktion Ostasien. --chrislb 18:42, 3. Jul. 2008 (CEST)

Danke, chrislb; ist mal ein ein guter Anfang der Diskussion.

Natürlich wollen 99,9% das alles gar nicht wissen - es erhebt sich die Frage, ob es Aufgabe der WP ist, den 0,1% irgendwie die Info anzubieten, ohne andere damit zu erschrecken? Ich als Angehöriger dieser 0,1% habe vergeblich nach einer solchen Kollektion gesucht. Das Zeug ist sehr verstreut und unübersichtlich, meist nur in Ansätzen vorhanden, und mühsam zu finden. Bei einigen Büchern gelingt es mir nicht, Zugriff zu bekommen.

Mir schwebt als Möglichkeit vor, die Info anzubieten, auffindbar aber ohne dass jeder daran nicht interessierte darüber stolpert. Ich werde an dieser Sammlung auf jeden Fall weitermachen; es ist vor allem Diskussionsthema, ob nur für mich auf meinem Rechner mache, oder in einer abzuklärenden Form auch für Wikipedia. wdh -- 193.196.166.161 10:25, 4. Jul. 2008 (CEST)

Was benutzt du für Quellen für deine Daten? Die Unihan-Datenbank? Eigene Verknüpfungen? Mir fällt gerade auf, dass du eine Verknüpfung vom Radikal-Codepoint zu "equivalentem" Zeichen hast, also 2f00 zu 4e00. Die Zuordnung zu den verschiedenen Systemen für vereinfachte Radikale würde mich auch interessieren (227/189). --chrislb 14:23, 4. Jul. 2008 (CEST)

Ausser in der Unihan_db forsche ich nach Informationen in en.wiktionary, wie ich in Wikipedia:Redaktion_Ostasien#Frage_zu_Pinyin-Quelle ausgeführt habe.

In Unicode-Block Kangxi-Radikale ist bereits die Verknüpfung (2F00 zu 4E00 etc.) dargestellt; ich würde das hier in diese globale Zusammenfassung nochmals reinstellen. In den einzelnen Radikalenartikel könnte man die Erwähnung des 2F00ff-Codes für informativ ansehen, immerhin ist es eine alternative Unihan-Darstellung des Zeichens, doch halte ich den ganzen Unicode-Block der Kangxi-Radikale(2F00-2FDF) für nicht wichtig genug, um die einzelnen Artikel noch damit zu befrachten.

Die Gegenüberstellung mit anderen Radikalensystemen habe ich möglichst vollständig ermittelt, aber wir werden damit leben müssen, dass es Zeichen ohne Entsprechnung im jeweils anderen System gibt (klar, bei unterschiedlicher Anzahl!).

Hingegen ist der Codepoint 2F00ff in dieser Tabelle hier am richtigen Platz. --193.196.166.161 12:52, 5. Jul. 2008 (CEST)

Die Beschreibung sollte hier schlicht und übersichtlich ausfallen und sich irgendwie an der von Unicode orientieren. Wir brauchen in der Spalte Beschreibung lediglich einen deutschen Begriff dafür (immer mit Kangxi-Radikal davor, z.B. "Kangxi-Radikal Vogel" für die Nr.196), keine Zeichen oder dergleichen. Alle anderen Angaben sind wichtig, wären aber prima in einem eigenen Artikel zu den Kangxi-Radikalen bzw. verschiedenen Radikalsystemen aufgehoben. --Reiner Stoppok 17:28, 4. Jul. 2008 (CEST)

Ich denke, ich habe als Beschreibung (im Beispiel oben Spalte "M") das Schlagwort entsprechend dem offiziellen Unihan-Text genommen.

Redundante Bestandteile, wie den von dir gewünschten Textvorsatz "Kangxi-Radikal", würde ich in der ohnehin schon sehr breiten Tabelle nicht noch in jede Zeile aufnehmen.

Da deutsche Bezeichnungen aus dem Englischen übersetzt werden müssen, können sie streng genommen ohnehin nicht als offiziell angesehen werden.

Vorschlag: eine Spaltenüberschrift der Tabelle wie z.B. "KangXi Radical ...", und darunter den englischen Text (ohne den Vorsatz), und ein deutsches Wort; zusätzlich könnte man an geeigneter Stelle darauf hinweisen, wo die offiziellen Unicode-Tabellen mit offiziellen Namen zu finden sind.

Die Tabelle/der Artikel/die Liste wäre doch gut aufgehoben bei Wikipedia:Informative Listen und Portale?

Jedenfalls bezieht sie sich ganz eindeutig auf das traditionelle System der Kangxi-Radikalen, und wer zB bei Unicode-Block Kangxi-Radikale oder Liste traditioneller Radikale sucht, sollte diesen Artikel mit der Monstertabelle auch finden können. -- 193.196.166.161 12:52, 5. Jul. 2008 (CEST)

Ich finde, das Erscheinungsbild sollte einheitlich bleiben. Bei den Unicode-Blöcken mit den lateinischen Buchstaben haben wir schließlich auch immer "lateinischer Buchstabe" davor ;-). Hier bei den Unicode-Blöcken gehört die ganze, m.E. nur in einem eigenen Artikel sinnvolle und wünschenswerte Information nicht hin. Schau Dich bitte auch mal bei den anderen Blöcken um, wie da verfahren wurde (Kyrillisch, Arabisch etc.)! --Reiner Stoppok 16:24, 5. Jul. 2008 (CEST)

Nein, zu den Unicode-Blöcken gehört das nicht; es sollte aber von anderen relevanten Artikeln, also auch aus den betreffenden Block-Artikeln, darauf verwiesen werden.

Reiner, ich schau mal wie sich die Übersichtstabelle entwickelt; und welche Spalten m.E. reinkommen sollen. Gedacht ist, dass die 214 traditionellen KangXi zwar der Ausgangs- und Bezugspunkt sind, doch ist die Tabelle keine Unicodetabelle, auch wenn sie einige Daten daraus zitiert. Können wir einstweilen so verbleiben? Ich sammle mal Daten, die mir wichtig erscheinen, ich versuche einen möglichst ausgereiften Artikel zu bauen, und alle anderen werden dazugeben oder wegnehmen, wie es ihnen sinnvoll erscheint. So verstehe ich Wikipedia. Mit Gruss, wdh -- 193.196.166.161 10:01, 7. Jul. 2008 (CEST)

Und wenn das dann fertig ist, endlich mal eine ordentliche Tabelle zu allen Phonetika der chinesischen Schrift (die seltsamerweise immer vernachlässigt werden). --Reiner Stoppok 14:12, 2. Sep. 2008 (CEST)

Von sarang♥사랑 einstweilen ins Archiv ausgelagert -- sarang♥사랑 11:25, 4. Sep. 2008 (CEST)

---

Liste der Unicode-Blöcke mit Anzahl

Archivierung dieses Abschnittes wurde gewünscht von: -- sarang♥사랑 11:49, 6. Sep. 2008 (CEST)

Zusätzlich zu den Spalten 'Bezeichnung', 'von', 'bis' und 'Anmerkung' wäre in dieser Übersicht noch die Mächtigkeit des jeweiligen Blocks interessant. Das müsste sich doch relativ einfach automatisiert einfügen lassen. Platz ist noch da, die Überschaubarkeit würde nicht leiden, und eine wesentliche Information wäre auf einen Blick zu sehen. Gruss, wdh -- 193.196.166.161 10:45, 27. Jun. 2008 (CEST)

Was soll mit Mächtigkeit gemeint sein? Die Anzahl der Zeichen im jeweiligen Block? -- Prince Kassad 11:00, 27. Jun. 2008 (CEST)

Ich bedaure wenn ich unverständlich war; ich meine die (theoretische) Anzahl in jedem Block, also 'bis' minus 'von' + 1, am besten wohl in dezimaler Form. wdh -- 193.196.166.161 11:22, 27. Jun. 2008 (CEST)

Das könnte dann für Blöcke wie Alte Symbole irreführend wirken, die zwar nur wenige Zeichen haben, aber einen großen Bereich zugeteilt wurden (in diesem Fall sind erst neun von 64 zugewiesenen Zeichen belegt). -- Prince Kassad 11:37, 27. Jun. 2008 (CEST)

In solchen Fällen würde ich die 64 nennen, und nicht die 9. Beide Zahlen anzuführen halte ich für weniger sinnvoll, und die 9 wäre auch nicht automatisiert machbar. -- 193.196.166.161 12:02, 27. Jun. 2008 (CEST)

Na ja, dann könnte man ja so etwas wie „(9/64)“ schreiben, in anderen Fällen so etwas wie „(256/256)“. Bei neu zu erstellenden Blöcken (in Unicode 5.2) könnte ich diese Information in der Tat in mein Makro einbauen, bei den alten dürfte aber der Taschenrechner das einfachste sein: nur zu! --Daniel Bunčić 12:00, 27. Jun. 2008 (CEST)

Zum Beispiel 'Alte Symbole': das liesse sich doch, wenn es für sinnvoll gehalten wird, bespielsweise so schreiben

Unicode-Block Alte Symbole

10190

101CF

64

Antike Symbole, derzeit (2008) römische Währungssymbole; 9 Zeichen belegt

Mit bestem Gruss, wdh --193.196.166.161 12:19, 27. Jun. 2008 (CEST)

Soviel bräuchte man da gar nicht zu rechnen, da man die meisten Zahlen bereits mit BabelMap auslesen kann. Eine Erwähnung in der Form „(9/64)“ halte ich ebenfalls für am sinnvollsten. -- Prince Kassad 00:38, 29. Jun. 2008 (CEST)

Inzwischen habe ich die Gesamtzahlen automatisch ermittelt, es ergibt eine recht interessante Übersicht.

Noch ehe ausdiskutiert ist, wie es weitergehen könnte, habe ich schon wieder was ausgeheckt (--193.196.166.161 19:33, 30. Jun. 2008 (CEST)):

Wie viele Zeichen sind denn nun offiziell in den einzelnen Planes vergeben?
Ferner habe ich mal gehört, insgesamt seien anderthalb Millionen Zeichen bereits verzeichnet.
Dann müsste ja noch einiges auf uns zukommen. – Simplicius 16:19, 29. Jul. 2008 (CEST)

Hallo Simplicius, die folgende Übersicht sollte deine Fragen beantworten. Quelle sind die offiziellen Unterlagen von Unicode.

Entwurf

Die Tabelle könnte etwa so aussehen:

Unicode Block Name	von	bis	Blockl.	def.	frei
Plane 0	0000000 ! 0000	FFFF	65.536	59.177	6.359
Basic Latin	0000001 ! 0000	007F	128	128	0
Latin-1 Supplement	0000128 ! 0080	00FF	128	128	0
Latin Extended-A	0000256 ! 0100	017F	128	128	0
Latin Extended-B	0000384 ! 0180	024F	208	183	25
IPA Extensions	0000592 ! 0250	02AF	96	96	0
Spacing Modifier Letters	0000688 ! 02B0	02FF	80	80	0
Combining Diacritical Marks	0000768 ! 0300	036F	112	107	5
Greek and Coptic	0000880 ! 0370	03FF	144	120	24
Cyrillic	0001024 ! 0400	04FF	256	246	10
Cyrillic Supplement	0001280 ! 0500	052F	48	16	32
Armenian	0001328 ! 0530	058F	96	86	10
Hebrew	0001424 ! 0590	05FF	112	82	30
Arabic	0001536 ! 0600	06FF	256	227	29
Syriac	0001792 ! 0700	074F	80	77	3
( unused - no Block)	0001872 ! 0750	077F	48	0	48
Thaana	0001920 ! 0780	07BF	64	50	14
( unused - no Block)	0001984 ! 07C0	08FF	320	0	320
Devanagari	0002304 ! 0900	097F	128	105	23
Bengali	0002432 ! 0980	09FF	128	90	38
Gurmukhi	0002560 ! 0A00	0A7F	128	77	51
Gujarati	0002688 ! 0A80	0AFF	128	83	45
Oriya	0002816 ! 0B00	0B7F	128	81	47
Tamil	0002944 ! 0B80	0BFF	128	69	59
Telugu	0003072 ! 0C00	0C7F	128	80	48
Kannada	0003200 ! 0C80	0CFF	128	82	46
Malayalam	0003328 ! 0D00	0D7F	128	78	50
Sinhala	0003456 ! 0D80	0DFF	128	80	48
Thai	0003584 ! 0E00	0E7F	128	87	41
Lao	0003712 ! 0E80	0EFF	128	65	63
Tibetan	0003840 ! 0F00	0FFF	256	193	63
Myanmar	0004096 ! 1000	109F	160	78	82
Georgian	0004256 ! 10A0	10FF	96	80	16
Hangul Jamo	0004352 ! 1100	11FF	256	240	16
Ethiopic	0004608 ! 1200	137F	384	345	39
( unused - no Block)	0004992 ! 1380	139F	32	0	32
Cherokee	0005024 ! 13A0	13FF	96	85	11
Unified Canadian Aboriginal Syllabics	0005120 ! 1400	167F	640	630	10
Ogham	0005760 ! 1680	169F	32	29	3
Runic	0005792 ! 16A0	16FF	96	81	15
Tagalog	0005888 ! 1700	171F	32	20	12
Hanunoo	0005920 ! 1720	173F	32	23	9
Buhid	0005952 ! 1740	175F	32	20	12
Tagbanwa	0005984 ! 1760	177F	32	18	14
Khmer	0006016 ! 1780	17FF	128	114	14
Mongolian	0006144 ! 1800	18AF	176	155	21
( unused - no Block)	0006320 ! 18B0	18FF	80	0	80
Limbu	0006400 ! 1900	194F	80	66	14
Tai Le	0006480 ! 1950	197F	48	35	13
( unused - no Block)	0006528 ! 1980	19DF	96	0	96
Khmer Symbols	0006624 ! 19E0	19FF	32	32	0
( unused - no Block)	0006656 ! 1A00	1CFF	768	0	768
Phonetic Extensions	0007424 ! 1D00	1D7F	128	108	20
( unused - no Block)	0007552 ! 1D80	1DFF	128	0	128
Latin Extended Additional	0007680 ! 1E00	1EFF	256	246	10
Greek Extended	0007936 ! 1F00	1FFF	256	233	23
General Punctuation	0008192 ! 2000	206F	112	97	15
Superscripts and Subscripts	0008304 ! 2070	209F	48	29	19
Currency Symbols	0008352 ! 20A0	20CF	48	18	30
Combining Diacritical Marks for Symbols	0008400 ! 20D0	20FF	48	27	21
Letterlike Symbols	0008448 ! 2100	214F	80	75	5
Number Forms	0008528 ! 2150	218F	64	49	15
Arrows	0008592 ! 2190	21FF	112	112	0
Mathematical Operators	0008704 ! 2200	22FF	256	256	0
Miscellaneous Technical	0008960 ! 2300	23FF	256	209	47
Control Pictures	0009216 ! 2400	243F	64	39	25
Optical Character Recognition	0009280 ! 2440	245F	32	11	21
Enclosed Alphanumerics	0009312 ! 2460	24FF	160	160	0
Box Drawing	0009472 ! 2500	257F	128	128	0
Block Elements	0009600 ! 2580	259F	32	32	0
Geometric Shapes	0009632 ! 25A0	25FF	96	96	0
Miscellaneous Symbols	0009728 ! 2600	26FF	256	145	111
Dingbats	0009984 ! 2700	27BF	192	174	18
Miscellaneous Mathematical Symbols-A	0010176 ! 27C0	27EF	48	28	20
Supplemental Arrows-A	0010224 ! 27F0	27FF	16	16	0
Braille Patterns	0010240 ! 2800	28FF	256	256	0
Supplemental Arrows-B	0010496 ! 2900	297F	128	128	0
Miscellaneous Mathematical Symbols-B	0010624 ! 2980	29FF	128	128	0
Supplemental Mathematical Operators	0010752 ! 2A00	2AFF	256	256	0
Miscellaneous Symbols and Arrows	0011008 ! 2B00	2BFF	256	14	242
( unused - no Block)	0011264 ! 2C00	2E7F	640	0	640
CJK Radicals Supplement	0011904 ! 2E80	2EFF	128	115	13
Kangxi Radicals	0012032 ! 2F00	2FDF	224	214	10
( unused - no Block)	0012256 ! 2FE0	2FEF	16	0	16
Ideographic Description Characters	0012272 ! 2FF0	2FFF	16	12	4
CJK Symbols and Punctuation	0012288 ! 3000	303F	64	64	0
Hiragana	0012352 ! 3040	309F	96	93	3
Katakana	0012448 ! 30A0	30FF	96	96	0
Bopomofo	0012544 ! 3100	312F	48	40	8
Hangul Compatibility Jamo	0012592 ! 3130	318F	96	94	2
Kanbun	0012688 ! 3190	319F	16	16	0
Bopomofo Extended	0012704 ! 31A0	31BF	32	24	8
( unused - no Block)	0012736 ! 31C0	31EF	48	0	48
Katakana Phonetic Extensions	0012784 ! 31F0	31FF	16	16	0
Enclosed CJK Letters and Months	0012800 ! 3200	32FF	256	241	15
CJK Compatibility	0013056 ! 3300	33FF	256	256	0
CJK Unified Ideographs Extension A	0013312 ! 3400	4DBF	6.592	6.582	10
Yijing Hexagram Symbols	0019904 ! 4DC0	4DFF	64	64	0
CJK Unified Ideographs	0019968 ! 4E00	9FFF	20.992	20.902	90
Yi Syllables	0040960 ! A000	A48F	1.168	1.165	3
Yi Radicals	0042128 ! A490	A4CF	64	55	9
( unused - no Block)	0042192 ! A4D0	ABFF	1.840	0	1.840
Hangul Syllables	0044032 ! AC00	D7AF	11.184	11.172	12
( unused - no Block)	0055216 ! D7B0	D7FF	80	0	80
High Surrogates	0055296 ! D800	DB7F	896	896	0
High Private Use Surrogates	0056192 ! DB80	DBFF	128	128	0
Low Surrogates	0056320 ! DC00	DFFF	1.024	1.024	0
Private Use Area	0057344 ! E000	F8FF	6.400	6.400	0
CJK Compatibility Ideographs	0063744 ! F900	FAFF	512	361	151
Alphabetic Presentation Forms	0064256 ! FB00	FB4F	80	58	22
Arabic Presentation Forms-A	0064336 ! FB50	FDFF	688	595	93
Variation Selectors	0065024 ! FE00	FE0F	16	16	0
( unused - no Block)	0065040 ! FE10	FE1F	16	0	16
Combining Half Marks	0065056 ! FE20	FE2F	16	4	12
CJK Compatibility Forms	0065072 ! FE30	FE4F	32	32	0
Small Form Variants	0065104 ! FE50	FE6F	32	26	6
Arabic Presentation Forms-B	0065136 ! FE70	FEFF	144	141	3
Halfwidth and Fullwidth Forms	0065280 ! FF00	FFEF	240	225	15
Specials	0065520 ! FFF0	FFFF	16	5	11
Plane 1	0065535 ! 10000	1FFFF	65.536	2.128	63.408
Linear B Syllabary	0065536 ! 10000	1007F	128	88	40
Linear B Ideograms	0065664 ! 10080	100FF	128	123	5
Aegean Numbers	0065792 ! 10100	1013F	64	57	7
( unused - no Block)	0065856 ! 10140	102FF	448	0	448
Old Italic	0066304 ! 10300	1032F	48	35	13
Gothic	0066352 ! 10330	1034F	32	27	5
( unused - no Block)	0066384 ! 10350	1037F	48	0	48
Ugaritic	0066432 ! 10380	1039F	32	31	1
( unused - no Block)	0066464 ! 103A0	103FF	96	0	96
Deseret	0066560 ! 10400	1044F	80	80	0
Shavian	0066640 ! 10450	1047F	48	48	0
Osmanya	0066688 ! 10480	104AF	48	40	8
( unused - no Block)	0066736 ! 104B0	107FF	848	0	848
Cypriot Syllabary	0067584 ! 10800	1083F	64	55	9
( unused - no Block)	0067648 ! 10840	1CFFF	51.136	0	51.136
Byzantine Musical Symbols	0118784 ! 1D000	1D0FF	256	246	10
Musical Symbols	0119040 ! 1D100	1D1FF	256	219	37
( unused - no Block)	0119296 ! 1D200	1D2FF	256	0	256
Tai Xuan Jing Symbols	0119552 ! 1D300	1D35F	96	87	9
( unused - no Block)	0119648 ! 1D360	1D3FF	160	0	160
Mathematical Alphanumeric Symbols	0119808 ! 1D400	1D7FF	1.024	992	32
( unused - no Block)	0120832 ! 1D800	1FFFF	10.240	0	10.240
Plane 2	0120833 ! 20000	2FFFF	65.536	544	64.992
CJK Unified Ideographs Extension B	0131072 ! 20000	2A6DF	42.720	2	42.718
( unused - no Block)	0173792 ! 2A6E0	2F7FF	20.768	0	20.768
CJK Compatibility Ideographs Supplement	0194560 ! 2F800	2FA1F	544	542	2
( unused - no Block)	0195104 ! 2FA20	2FFFF	1.504	0	1.504
( unused - Plane 3 ... 13)	0196608 ! 30000	DFFFF	720.896	0	720.896
Plane 14	0917503 ! E0000	EFFFF	65.536	337	65.191
Tags	0917504 ! E0000	E007F	128	97	31
( unused - no Block)	0917632 ! E0080	E00FF	128	0	128
Variation Selectors Supplement	0917760 ! E0100	E01EF	240	240	0
( unused - no Block)	0918000 ! E01F0	EFFFF	65.040	0	65.040
Plane 15	0983039 ! F0000	FFFFF	65.536	2	65.534
Supplementary Private Use Area-A	0983040 ! F0000	FFFFF	65.536	2	65.534
Plane 16	1048575 ! 100000	10FFFF	65.536	2	65.534
Supplementary Private Use Area-B	1048576 ! 100000	10FFFF	65.536	2	65.534
Summen Plane 0 ... 16	1048578 ! 000000	10FFFF	1.114.112	62.190	1.051.922

Ich werde noch die dezimalen Zahlenwerte rechtsbündig ordnen, ev. bessere Texte und Farben wählen, und weitere Anregungen sind willkommen. Auch muss ich noch alle Daten ein weiteres Mal kontrollieren. Weil mit den drei zusätzlichen Spalten (Blocklänge, definiert, frei) die Originaltabelle der 'Liste der Unicode-Blöcke' wohl zu breit würde, wird diese Tabelle hier besser irgendwo anders angeboten - nur: wo? Auch da braucht es noch Ideen der Codefachleute. -- sarang♥사랑 17:57, 11. Aug. 2008 (CEST)

1. fehlen mir in der Tabelle die Unicode 5.1-Blöcke (ist aber sowieso nur ein Entwurf), 2. kann die Liste der Unicode-Blöcke ruhig zwei Tabellen enthalten, falls das nötig ist. -- Prince Kassad 19:34, 11. Aug. 2008 (CEST)

Schon beim ersten Überarbeiten des Entwurfs habe ich gemerkt, dass meine Quelle unvollständig war und sehr viele Blöcke verschweigt; die haben in meinem Entwurf z.T. das 'unused'-Attribut erhalten. Ich habe also noch einiges zu tun.

Davon abgesehen, dass die Tabelle noch viele weitere Zeilen bekommen wird, bleibt die 'wohin'-Frage. Natürlich kann sie nach der bestehenden Tabelle in 'Liste der ..' angefügt werden, doch vorerst erscheint mir das suboptimal. Vielleicht hat jemand eine noch bessere Idee?

Übrigens, falls die zusätzlichen Informationen doch als drei weitere Spalten die Originaltabelle erweitern sollen, müssten dann auch noch einige Zeilen für die unused-'Löcher' dazu. Es erscheint mir zweifelhaft, dass die auch in die Originalliste der Blöcke gehören. Auch fände ich es ganz gut, eine weitere Art der tabellarischen Aufstellung anzubieten, wie es im Entwurf versucht ist. -- sarang♥사랑 10:16, 12. Aug. 2008 (CEST)

Hallo Prince, da das Ganze dein Thema ist und du ohnehin bisher der einzige Ansprechpartner bist, direkt an dich:
Die Tabelle ich nun schon seit längerem fertig (vorbehaltlich ev. Verbesserungen). Der Aufbau entspricht im Wesentlichen dem obigen Beispiel; ich könnte sie nochmals reinstellen, aber das ist wohl nicht so sinnvoll, und es handelt sich ja um gewaltige Datenmengen. Eventuell könnte ich bei mir eine Unterseite bauen, von der dann verschoben wird.

Ich bin etwas skeptisch, ob das mehr als zwei oder drei interessiert, weltweit gesehen; dennoch meine ich, dass diese Übersicht bereitgestellt werden sollte. Immerhin hat zumindest Benutzer:Simplicius oben Interesse gezeigt.

Skeptisch bin ich auch, ob diese grosse Tabelle zu den tw. auch schon grossen Tabellen in der 'Liste der U-Blöcke' gestellt werden sollte. Zwar wäre dann dort alles nahe beinander, aber der ohnehin schon grosse Artikel wird noch grösser werden. Natürlich kann ich das mal machen, es kann ja jederzeit geändert werden.

Falls nicht noch jemand mit ganz anderen Ideen kommt, sag mir doch deine Meinung, wohin ich das Zeug stellen soll - ich mach das dann so. Gruss -- sarang♥사랑 12:03, 27. Aug. 2008 (CEST)

Ja, stell mal die fertige Tabelle in eine Benutzerunterseite, ich schau dann, wie ich das in die Liste der Unicode-Blöcke einbaue. -- Prince Kassad 15:57, 27. Aug. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: sarang♥사랑 19:02, 28. Aug. 2008 (CEST)

Tabellenaufbau der Artikel "Unicode Blöcke"

Archivierung dieses Abschnittes wurde gewünscht von: -- sarang♥사랑 11:49, 6. Sep. 2008 (CEST)

Alle Tabellen sind übersichtlich und sortierbar gestaltet. Dank des Designs lassen sich gut Daten entnehmen, um sie auf dem eigenen Rechner beliebig zusammenzusetzen.

Die Tabellen bestehen aus vier sortierbaren Spalten, wobei in der ersten Spalte zwei Datenspalten zusammengefasst sind: generell steht in der ersten Spalte der Unicode in hexadezimal und dezimal. In der zweiten Spalte wird das Zeichen selbst angeführt, in der dritten Sortierspalte steht eine individuelle Beschreibung, und in der vierten die Offizielle Bezeichnung.

Die Zusammenfassung in der ersten Spalte "Unicode-Nummer" der Codepoints in hexadezimal und dezimal reduziert die Sortiermöglichkeiten nicht, da diese Werte auch in getrennten Sortierspalten identisches Sortierergebnis liefern. Von der Sortiermöglichkeit her gesehen, können auch die Daten der zweiten Sortierspalte zur ersten genommen werden, da sie ebenfalls identisch sortieren.

Tabellenaufbau Unicode-Block Kangxi-Radikale

Diese Tabelle kann noch leicht verbessert werden. In der dritten Spalte "Beschreibung" sind gleich vier Elemente vereint: (Radikal Nr., Kurzübersetzung, die Glyphe und der Codepoint 4E00-9FBF). Sowohl die Glyphen, als auch die Codepoints würden ebenfalls identisch zu den Sortierspalten 1 und 2 sortieren; das würde auch für die Radikalen-Nummer gelten, jedoch wird infolge des Datentyps "Text" diese Spalte in der Reihenfolge 1, 10, 100, 101 etc. sortiert, was überhaupt keinen Sinn ergibt.

Die vierte Sortierspalte wird nach dem Text sortiert, der auf 'KANGXI RADICAL ' folgt.

Es gäbe eher noch einen gewissen Sinn, die 3. Spalte nach der Kurzübersetzung unter "Beschreibung" zu sortieren, was aber bei diesem Tabellenaufbau nicht möglich ist. Um es zu ermöglichen, muss der Spalte ein Sortierschlüssel vorangestellt werden, damit nach der textuellen Kurzbeschreibung sortiert werden kann. Für die dritte Spalte der ersten Zeile würde das etwa so aussehen:

 | {{SortKey|eins}}[[Radikal 1]] „eins“ = {{lang|zh-Hant|一}} (U+4E00)

Es bietet sich an, diese Erweiterung weitgehend automatisch durchzuführen. Ich habe das vorbereitet und könnte es in den nächsten Tagen mal schnell machen. Gruss, wdh -- 193.196.166.161 19:33, 30. Jun. 2008 (CEST)

Nachtrag

Die Änderung/Erweiterung, wenn für die 3. Spalte eine vernünftige Sortierung ermöglicht wird, lässt das Erscheinungsbild wie es ist, ohne die geringste Sichtbarkeit nach aussen. Ganz anders ist die Wirkung, wenn die Sortierung dieser Spalte angestossen wird.

Ich denke, ich baue die sortkeys mal ein. Weil ich das aber nur offline weitgehend automatisch machen kann, muss ich im Quelltext des Artikels die gesamte Tabelle austauschen; als Versionsunterschied werden aber nur die Einfügungen in den 214 Zeilen erscheinen. Also, ich mach das nun bald. Gruss, wdh -- 193.196.166.161 16:18, 7. Jul. 2008 (CEST)

Zeichen für Bergwerk?

Archivierung dieses Abschnittes wurde gewünscht von: -- sarang♥사랑 11:49, 6. Sep. 2008 (CEST)

Gibt es ein Zeichen für Bergwerk und andere geografische Symbole? – Simplicius 13:46, 5. Aug. 2008 (CEST)

Evtl. ist was im Unicode-Block Verschiedene Symbole -- Prince Kassad 17:18, 5. Aug. 2008 (CEST)

Joa: U+2692 (⚒) :-) --RokerHRO 17:40, 5. Aug. 2008 (CEST)

TXJ-Darstellung

Archivierung dieses Abschnittes wurde gewünscht von: -- sarang♥사랑 11:49, 6. Sep. 2008 (CEST)

Hallo Daniel/Prince/...,
ich bin gerne bereit mich der schon länger brachliegenden Tai-Xuan-Jing-Symbole anzunehmen. Und dazu habe ich Fragen. Jeder Artikel zu einem Unicodeblock sollte die einheitliche Tabellendarstellung (hex-Cod und dez-Code | Zeichen | Beschreibung | offizielle Bezeichnung) enthalten. Das hat schon bei der Tabelle der Kangxi-Radikale nicht so streng eingehalten werden können, erst durch die Aufnahme zusätzlicher Elemente in die Beschreibung bietet der Artikel sinnvolle Information. Mit dem TXJ-Artikel könnten wir es halten wie mit dem IGing-Artikel: strikt nach obiger Vereinbarung, so dass die meisten Leser nicht sehr viel sehen werden, und den Verweis auf andere Artikel, die durch Substitutionen einen Eindruck vermitteln. Die substitutive Darstellung mit den senkrechten Strichen | (007C) und ¦ (00A6) wie in den Artikeln I Ging bzw. 64 Hexagramme müsste zur Darstellung der zweimal gebrochenen Linie behelfsmässig das Zeichen ┆ (2506; passt leider nicht so ganz dazu) verwenden, etwas anderes habe ich nicht gefunden; zumindest wäre das bei wesentlich mehr Lesern sichtbar, hoffe ich. Was hältst du davon, diese behelfsmässige Darstellung zur Beschreibung dazuzunehmen?

Die Tabelle könnte etwa so aussehen (wobei die Hangeul-Zeichen in der Beschreibung hier eher wegbleiben können):

Unicode-Nummer   Zeichen  Beschreibung                            Offizielle Bezeichnung     
U+1D300 (119552) 𝌀       팀 ┆    Monogramm für Erde              MONOGRAM FOR EARTH 
U+1D301 (119553) 𝌁       팁 ┆|   Digramm für himmlische Erde     DIGRAM FOR HEAVENLY EARTH 
U+1D302 (119554) 𝌂       팂 ┆¦   Digramm für menschliche Erde    DIGRAM FOR HUMAN EARTH 
U+1D303 (119555) 𝌃       팃 |┆   Digramm für irdischen Himmel    DIGRAM FOR EARTHLY HEAVEN 
U+1D304 (119556) 𝌄       팄 ¦┆   Digramm für irdischen Mensch    DIGRAM FOR EARTHLY HUMAN 
U+1D305 (119557) 𝌅       팅 ┆┆   Digramm für Erde                DIGRAM FOR EARTH 
U+1D306 (119558) 𝌆       팆 |||| Tetragramm für Mitte            TETRAGRAM FOR CENTRE 
U+1D307 (119559) 𝌇       팇 ¦||| Tetragramm für Vollkreis        TETRAGRAM FOR FULL CIRCLE
. . . 

Oder willst du hier strenger sein, d.h. Zeichensubstitution in einer anderen Tabelle, aber nicht hier im UnicodeBlock-Artikel? Mir ist alles recht, nur sollte der TXJ-Artikel bald verschiebefertig sein. Mit Gruss, -- sarang♥사랑 18:30, 18. Aug. 2008 (CEST)

Das hier hast Du schon gesehen? --Reiner Stoppok 23:40, 20. Aug. 2008 (CEST)

Ja, das war/ist mein Ausgangspunkt. Ich werde auch dort erweitern, und irgendwann wird (von mir oder sonst jemandem) verschoben werden.

Eventuelle Erweiterungen von mir sind ja nicht für die Ewigkeit; aber ehe ich mir einen abbreche würde ich sehr gerne einen gewissen Konsens (mit den für dieses Thema üblichen Verdächtigen) herstellen, ob ich die Strichlein hier reinnehme, oder nur in einem weiteren Artikel; wo dann auch die Hangeul-Silben gezeigt und erläutert würden. Die Strichlein wären übrigens auch wegen der Sortierung der 'Beschreibung'-Spalte interessant! Weisst du, wie ich das mit dem unterschiedlichen Spacing besser hinbekommen könnte?

Aber es ist vielleicht ganz sinnvoll, wenn ich einfach mal erweitere, wie es mir gut erscheint, und wir dann weiterdiskutieren, vor dem Verschieben. Gruss -- sarang♥사랑 10:02, 21. Aug. 2008 (CEST)

So eng wie möglich am Original orientieren, ich hab's oben bei den Kangxi-Radikalen schon gesagt (auch wenn da bis jetzt nichts zurechtgerückt wurde). Den ganzen (sinnvollen) Rest kann man ja in einem eigenen Artikel dazu unterbringen. Hier sollte dagegen auch etwas auf Einheitlichkeit geachtet werden. Klicke auch mal auf die anderen Blöcke. --Reiner Stoppok 12:45, 21. Aug. 2008 (CEST)

Hallo Reiner, am Kangxi-Block werde ich nichts zurechtrücken! Das habe ich wohl missverständlich formuliert; ich spreche die ganze Zeit von einem erweiternden (eigenen) Artikel als Ergänzung zum Kangxi-Block. Also wohl kein Grund, uns zu befehden. Ich habe lediglich die Sortierung der 'Beschreibung' im Kangxi eingebaut, am 7. Juli 2008, noch als IP 193.196.166.161.

Ich kann mich gerne auf die vereinbarte einheitliche Darstellung beschränken, dann ist TXJ schnell fertig & verschiebebereit - sobald es auch noch begutachtet worden ist; hast du es auf Beobachtung, oder soll ich dir Nachricht geben? -- sarang♥사랑 14:50, 21. Aug. 2008 (CEST)

Nach meiner Feststellung bleibt hier schwerlich etwas geheim. --Reiner Stoppok 19:43, 21. Aug. 2008 (CEST)

Dann ist es ja gut. -- sarang♥사랑 10:30, 25. Aug. 2008 (CEST)

So, jetzt habe ich den Buncic'schen TXJ-Block soweit fertiggestellt.
Reiner, vermutlich wird es dir eher missfallen, dass ich zur offiziellen Bezeichnung noch Infos aus den offiziellen Texten gestellt habe; ich bin auch bereit, diese Infos in die Beschreibung zu verschieben, wenn du das für richtiger hältst.

Wie wir wissen, ist bei den TXJ einiges sehr verworren und widersprüchlich. Ich habe versucht, das etwas aufzuklären, und hoffe es ist mir halbwegs gelungen. Weil ich meine, dass solche Korrektheit kaum jemanden interessieren wird, aber in der WP doch sein sollte, habe ich diese Anmerkungen an das Ende der Seite gestellt, um nicht jeden Leser gleich damit zu überfallen.

Sobald ich eine Meinung zu meinen Zusatzinfos (in off. Bez., oder nicht) habe, kann TXJ meinetwegen verschoben werden. Gruss -- sarang♥사랑 10:30, 25. Aug. 2008 (CEST)

Ich finde die jetzige Lösung bei Benutzer:Buncic/Unicode/Tai-Xuan-Jing-Symbole ok (vom TXJ verstehe ich allerdings nichts). Eventuell sollte bereits in der Einleitung ein kurzer fettgedruckter Hinweis auf die Anmerkungen stehen. Vielleicht kann man die chin. Zeichen auch oben rausnehmen und nur den Anfang der Tabelle dann in ihrer jetzigen Form (dann mit den chin. Zeichen) in die Anmerkung setzen. Allerdings schreien die ersten Zeichen ja quasi nach einer Kommentierung; daher ist dieses Sonderlayout m.E. gerechtfertigt. --Reiner Stoppok 01:33, 30. Aug. 2008 (CEST) PS: Die Bezeichnungen des Unicode Consortiums sind m.E. schon darin problematisch, dass chinesische Schriftzeichen leichtfertig als "Ideographs" bezeichnet werden.

Hallo Reiner, deiner Anregung (danke!) folgend, habe ich ganz am Anfang einen fettgedruckten Hinweis eingefügt; zwar nicht in der Einleitung, aber unübersehbar in der ersten Tabellenzeile. So entspricht es mehr dem allgemeinen Layout, auch sind die chin. Zeichen nicht mehr im offiziellen Bereich.

Den Artikel habe ich in den Artkelnamensraum rübergeschoben, damit endlich der rote Link weg ist, und bei Daniel aufgeräumt.

Jetzt kann auch endlich die Diskussion ein Stück aufgeräumt werden: :Archivierung dieses Abschnittes wurde gewünscht von: -- sarang♥사랑 11:11, 1. Sep. 2008 (CEST)

Als nächstes werde ich den zugehörigen Artikel Taixuanjing gründlich überarbeiten; und auf Seite 602 werde ich auch noch nachsehen. Übrigens, von TXJ verstehe ich auch nichts, ich bin kein Fan von Esoterik etc, mich interessiert es eher vom Binären und Kombinatorischen, sowie als SO-asiatisches Kulturgut. Gruss -- sarang♥사랑 11:11, 1. Sep. 2008 (CEST)

Von Artikelraum war noch keine Rede! ("Lösung" bezog sich auf eine mögliche optische Gestaltung.) --Reiner Stoppok 00:56, 2. Sep. 2008 (CEST) PS: Für eine Überarbeitung der Übersetzungen ist das hier sicherlich hilfreich.

Da war ich wohl voreilig - aber ich finde den doch recht fortgeschrittenen Artikel im ANR besser als den roten Link. Nächstes Mal werde ich das besser mir dir abstimmen.

Danke für den Hinweis, in N2416.pdf finde ich endlich die gesuchten Informationen. Ich rätsle noch, wieweit ich denen vertrauen kann, denn es werden (chinesisch-Original) die später 'inkorrekt' genannten Bezeichnungen angeführt.

Die Unicode-Diskussion ist seit längerem völlig unübersichtlich, wegen der langen Textbeiträge. Die angeforderte Archivierung ist bisher noch nicht erfolgt; ich erwäge, demnächst manuell (copy/paste) ins Archiv zu übertragen, damit es hier wieder leserlicher wird. Wäre das schlimm - oder geht es anders? Gruss, -- sarang♥사랑 10:45, 4. Sep. 2008 (CEST)

Bereich D800 ff

Archivierung dieses Abschnittes wurde gewünscht von: -- sarang♥사랑 11:49, 6. Sep. 2008 (CEST)

In der Liste der Unicode-Blöcke ist der Bereich so beschrieben:

High Surrogates        D800    DB7F    Bereich für UTF-Kodierung
High Private Use Surrogates 	DB80 	DBFF 	Bereich für UTF-Kodierung
Low Surrogates         DC00    DFFF    Bereich für UTF-Kodierung
Private Use Area       E000    F8FF    Benutzerdefiniert

Hingegen sagen die Unicode-charts, dass es eher so aussieht:

High Surrogates        D800    DBFF    Bereich für UTF-Kodierung
Low Surrogates         DC00    DFFF    Bereich für UTF-Kodierung
Private Use Area       E000    F8FF    Benutzerdefiniert

Ist die 2. Variante richtig, oder gibt es mir unbekannte Quellen für die 1. Variante? -- sarang♥사랑 11:20, 2. Sep. 2008 (CEST)

Ich schätze, da hat jemand mal auf die Schnelle einen neuen Block kreiert. -- Prince Kassad 16:40, 2. Sep. 2008 (CEST)

Denk ich auch, da ist was beim Editieren gedoppelt worden; ich entferne die Zeile demnächst. -- sarang♥사랑 18:21, 2. Sep. 2008 (CEST)

Verweise auf andere Zeichen

ebenfalls bei den Dingbats ist die frage aufgetaucht, ob, und wenn ja wie und wo, die verweise auf ähnliche zeichen mitaufgenommen werden - die UCC-pdfs geben ja selber in der detailbeschreibung jeweils hinweise auf verwandte und verwechselbare zeichen

1 in der Spalte Beschreibung (so hab ichs jetzt in Dingbat und Miscellaneous Symbols gemacht)

U+2713 (10003)

✓

Häkchen (→ U+2611 BALLOT BOX WITH CHECK)

CHECK MARK

2 in einer eigenen spalte Anmerkungen

U+2713 (10003)

✓

Häkchen

CHECK MARK

→ U+2611 BALLOT BOX WITH CHECK

erfordert aber umbau des allg. schema

3 mit Fußnoten

U+2713 (10003)

✓

Häkchen⁠

CHECK MARK

¹³ 

→ U+2611 BALLOT BOX WITH CHECK

die verlinkung erfolgt übrigens imho jeweils auf die liste des UC-Blocks, weil eh die Beschreibung auf den artikel ziel, in dem (hoffentlich) eine liste der UC-Zeichen zu finden ist
auch dieses problem wohl primär bei den ganzen zier- und symbolfonts --W!B: 03:24, 3. Sep. 2008 (CEST)

Variante 1 gefällt mir am besten. Aber ich denke, dass man den Verweis kommentieren sollte, beispielsweise so:

U+2713 (10003)

✓

Häkchen; ein ähnliches Zeichen ist U+2611, das abgehakte Kästchen.

CHECK MARK

Den englischen Originalnamen finde ich im Fließtext entbehrlich. --j ?! 14:03, 3. Sep. 2008 (CEST)

stimmt: ich hatte an straff gedacht, weil das einer liste besser entspricht: wär dann

U+2713 (10003)

✓

Häkchen; ein ähnliches Zeichen ist das abgehakte Kästchen ☑ (U+2611)

CHECK MARK

also mit angabe des zeichens sinnig, damit der leser (sofern es dargestellt wir) gleich weiss von was die rede ist? --W!B: 14:25, 3. Sep. 2008 (CEST)

Ja. --j ?! 15:07, 3. Sep. 2008 (CEST)

DINGBATS: Alternative Tabelle

befindet sich in der Version http://de.wikipedia.org/w/index.php?title=Dingbats&oldid=50230793, falls sie jemand nutzen möchte.. --W!B: 05:48, 2. Sep. 2008 (CEST) (hierher verschoben)

Der ursprüngliche Artikel sollte wiederhergestellt werden, nicht nur als Redirect rumstehen. -- sarang♥사랑 11:09, 4. Sep. 2008 (CEST)

Wie besprochen: der begriff existiert nur für den UC-Block, und die Zapf-Schrift: formal wäre eine BKL das richtige --W!B: 18:05, 4. Sep. 2008 (CEST)

sortable

fand ich letzhin - nur ist es weder sinnig, die erste spalte zu sortieren (die ist es), noch die zweite (die sortiert sich nach unicode, ist es also auch), noch die dritte (die ja nur beschreibende texte enthält), die vierte aber: da ists sinnig.. - dann braucht die erste aber wieder eins zum zurücksortieren.. code:

{| class="wikitable sortable"
|- class="hintergrundfarbe5"
! Unicode-Nummer
!! class="unsortable" | Zeichen
!! class="unsortable" | Beschreibung
! Offizielle Bezeichnung

--W!B: 03:44, 2. Sep. 2008 (CEST)

Nun, die Sache mit dem Sort habe ich schon vor längerer Zeit untersucht (#Tabellenaufbau der Artikel "Unicode Blöcke"), dass da nicht alles so sinnvoll sei. Aber, es kann ganz gut so bleiben, die redundanten Sortieroptionen stören doch nicht. -- sarang♥사랑 11:20, 2. Sep. 2008 (CEST)

ok, Deine argumente waren überzeugend: ich hab jetzt übrigens die beschreibungsspalte in Unicode-Block Dingbats 2700–27BF mal versuchwesie recht aufwändig mit SortKey präpariert

• die sortierung folgt dem UCC-pdf, und das schema läuft Stern 6 (sechzackiges), Kreuz lateinisch, Ziffer 3, Pfeil gekerbt usw
• die Nomenklatur (insb. Sterne) hält sich an die in der deutschen Ikonographie/Kunstgeschichte üblichen sitten etwa für die benamsung von Kreuzen und anderen Dekorelementen (in die bin ich gerade recht eingearbeitet)

ich denke, so lässt sich am besten ein überblick gewinnen, ob die benennungen konsistent und schlüssig sind
das problem tritt imho sowieso nur bei Zierat-Glyphen auf, wo die bennenung schon im original eher deskriptiv ist, also nur in einer handvoll blöcken - dort wo fachliche begriffe bezeichnet sind, ergibt sich die sortierung meist eh von selbst sauber - ich bin aber nicht dran, eine genau beschreibung der ITC Zapf Dingbats aufzutreiben, ob dort noch präziseres zu finden ist (keine ahnung, inwieweit die UCC-benennung darauf bezug nimmt) trotzde bitte, wer interressiert ist, drüberschauen und um kritik wird natürlich herzlich gebeten (auch, ob es mit den anderen blöcken so konsistent ist) --W!B: 03:02, 3. Sep. 2008 (CEST)

Anerkennung: die Sortierung der Dingbat-Beschreibung ist jetzt wirklich sehr sinnvoll. Ganz ohne was meckern zu wollen: wenn ich sortiere, und dann über einen der Anker (auch eine gute Sache!) hinverlinke (zB auf 'Pfeile'), komme ich statt auf den 1. Pfeil irgendwohin, weil dann der Anker nach hinten sortiert wurde. Aber vermutlich fällt sowas nur mir auf. Eine Lösung wäre, einen Bereich ab dem Anker so zu sortkeyen, dass die Sortierfolge erhalten bleibt. Weiter so! -- sarang♥사랑 18:18, 5. Sep. 2008 (CEST)

LA Ꜩ

wieder mal, zur kenntnisnahme --W!B: 00:40, 18. Sep. 2008 (CEST)

nachtrag: Wikipedia:Löschkandidaten/18. September 2008#Ɑ, jetzt Lateinisches Alpha, da is aber ein böser schnitzer passiert.. --W!B: 10:03, 19. Sep. 2008 (CEST)

(Nachfrage) Habe ich richtig verstanden: Du bezeichnest diesen ganzen Artikel als "unnütz (bzw. langfrist[i]g schädlich)"? --Reiner Stoppok 03:41, 23. Sep. 2008 (CEST)

korrekt --W!B: 03:52, 23. Sep. 2008 (CEST)

Ich sage es mal durch die Blume: ich habe gerade mal bei Benutzer:Marcus Cyron wegen der ägäischen Zahlzeichen nachgefragt. ;-) --Reiner Stoppok 14:07, 23. Sep. 2008 (CEST)

danke Dir.. --W!B: 11:35, 25. Sep. 2008 (CEST)

Unicode-Block Kangxi-Radikale (2)

Der sehr umfänglichen Beitrag von Anfang Juli 2008 wurde einstweilen in das Archiv/2008 ausgelagert. Die Arbeit an diesem U-Block verzögert sich noch, und Diskussion findet auch nicht mehr statt. Wenn es wieder weitergeht, wird hier auch die Diskussion fortgeführt werden, gegebenenfalls mit Bezügen auf dort. -- sarang♥사랑 11:40, 4. Sep. 2008 (CEST)

Und wenn das dann fertig ist, endlich mal eine ordentliche Tabelle zu allen Phonetika der chinesischen Schrift (die seltsamerweise immer vernachlässigt werden). --Reiner Stoppok 14:12, 2. Sep. 2008 (CEST)

Ich habe jetzt mal »Radikal 94 „Hund“« duch »Kangxi-Radikal Hund« usw. ersetzt (verlinkt nach wie vor auf Radikal 94). Die zugeordneten Zeichen aus Block 4E00–9FFF stammen ja aus dem PDF des Unicode-Konsortiums, sind also quasi offiziell. -- Olaf Studt 15:15, 3. Okt. 2008 (CEST)

Entsprechendes auch im Unicode-Block CJK-Radikale, Ergänzung. -- Olaf Studt 15:38, 3. Okt. 2008 (CEST)

Konsonantzeichen oder Konsonantenzeichen

Welches Wort ist besser? (vgl. Vokalzeichen) --Reiner Stoppok 00:12, 20. Okt. 2008 (CEST)

Ich würde sagen, Konsonantenzeichen ist die Pluralform, weswegen Konsonantzeichen die bessere Wahl ist. -- Prince Kassad 12:28, 20. Okt. 2008 (CEST)

Das en kommt nicht von einer Pluralform, es ist IMHO eher ein Fugenlaut. --RokerHRO 13:04, 20. Okt. 2008 (CEST)

Müsste m.E. an verschiedenen Stellen verbessert werden. --Reiner Stoppok 15:32, 20. Okt. 2008 (CEST) PS: Auch bei den Währungszeichen müsste noch mal drübergeschaut werden.

Naja, die Übersetzung ist zumindest nicht falsch... -- Prince Kassad 16:59, 20. Okt. 2008 (CEST)

Ich sach nur: Semmelnknödeln! - Olaf Studt 23:13, 8. Nov. 2008 (CET)

Ersatz für Wikipedia:UTF-8-Probleme

Ich bastle im Moment an einem Ersatz für die wenig hilfreiche Seite Wikipedia:UTF-8-Probleme. Unter anderem plane ich, Links zu Schriftarten für jedes Schriftsystem in Unicode (falls vorhanden) zu platzieren. Die Baustelle findet sich unter Benutzer:Prince Kassad/Wikipedia:Unicode, wer Verbesserungsvorschläge hat, soll sie hier schreiben. -- Prince Kassad 21:03, 18. Nov. 2008 (CET)

Als große Schriftart würde ich auf jeden Fall noch Sun-ExtA empfehlen. Sie ist zwar nicht ganz so umfangreich wie Code2000, dafür kostenlos. Außerdem funktioniert sie auch bei mir auf dem Mac einwandfrei, während die Zeichen von Code2000 zu tief und manchmal abgeschnitten erschienen. Diese Schriftart scheint wirklich nur auf Windows zu funktionieren. Gismatis 22:33, 18. Nov. 2008 (CET)

erledigtErledigt -- Prince Kassad 22:43, 18. Nov. 2008 (CET)

♁

Eine Begriffsklärung ist das jedenfalls nicht! -- Olaf Studt 23:14, 8. Nov. 2008 (CET)

Ich sehe keinen Unterschied zwischen ♁ und bspw. ₡. Gibt es einen Grund, wieso letzteres gültig ist, ♁ aber nicht? -- Prince Kassad 18:58, 9. Nov. 2008 (CET)

Hi Olaf. Begründe bitte etwas genauer, warum ♁ aus deiner Sicht keine Begriffsklärung ist. Ich kann dein Problem so nicht nachvollziehen. --j ?! 17:25, 10. Nov. 2008 (CET)

Ich sehe das Problem auch nicht. --Reiner Stoppok 22:49, 15. Nov. 2008 (CET)

seht ihrs jetzt? --W!B: 17:01, 22. Nov. 2008 (CET)

Was fehlt denn noch?

Ausgehend von einem Problem mit der Futhark-Darstellung habe ich inzwischen etliche TTF-Dateien nachinstalliert, darunter Arial Unicode MS und Junicode. Nun stelle ich auf der weiteren Suche fest, daß immer noch etliche Zeichen nicht angezeigt werden, zB auf der Seite Unicode-Block Dingbats. Gibt es irgeneine "Grundmenge" an Schriften/Dateien, bei denen davon auszugehen ist, daß so ziemlich alle Unicode-Zeichen dargestellt werden können? Hybscher 23:08, 11. Nov. 2008 (CET)

Diese Grundmenge wäre ziemlich groß, da man viele verschiedene Schriften für eine vollständige Unicode-Unterstützung braucht. -- Prince Kassad 14:02, 13. Nov. 2008 (CET)

Vorlage mit Bild

übrigens würde ich anlässlich der zunehmende anzahl an für den normalsterblichen leser nicht mehr lesbaren zeichen folgendes projekt ins auge fassen:

1. wir bauen den baustein Vorlage:Unicode mit einem zusätzlichen parameter um, der das einbinden einer svg-grafik erlaubt
2. wir erstellen für die „unleserlichen“ zeichen svg-graphiken
3. wir räumen dazu commons:category:Unicode auf (indem wir die zeichen nach nummer sortieren, und dazu etwa eine kat commons:category:Unicode glyphs erstellen, oder auch dort nach blöcken ordnen)
4. wir beantragen für Hilfe:Einstellungen einen eintrag für einen parameter, in dem der leser angeben kann, ob er die zeichen oder die grafik angezeigt haben will - das ginge etwa, mit stufen, "0. nur grafiken", "1. nur grundzeichensatz", "2. satz der heutigen weit verbreiteten, auf betriebsystemen handelsüblich vorinstallierten Unicodefonts wie Arial Unicode oder Bitstream Cyberbit", "3. alle zeichen der fünfstelligen blöcke grafisch", "4. immer zeichencodierung"
5. und die vorlage wertet diese variable aus, und stellt je nachdem die grafik dar, default wäre 2., größe der graphik wäre dieselbe wie die derzeitige TeX-darstellung, weil dann allfällige kritiken in einen topf fallen - und nicht aufs projekt zurückfallen ;)

--W!B: 01:54, 16. Nov. 2008 (CET)

Deine Idee, exotische Zeichen auch als Grafik anzubieten, gefällt mir. Das wäre eine gute Dienstleistung für die Leser. Ein Gedanke: Könnte für diese Funktion nicht die TeX-Erweiterung verwendet werden? Ich weiß, dass da sehr viele Zeichen zur Verfügung stehen. Man müsste prüfen, was alles dargestellt werden kann, und ob eine Erweiterung möglich ist. Damit könnten wir uns einen Riesenaufwand ersparen. Gismatis 04:36, 16. Nov. 2008 (CET)

Eine wunderschöne Idee. Nur wie soll sie mit komplexen Schriftsystemen funktionieren? -- Prince Kassad 09:59, 16. Nov. 2008 (CET)

Hierbei müsste XeTeX zum Einsatz kommen. Aber ein anderes Problem: Würden unsere Unicode-Tabellen teilweise nicht arg groß werden, wenn die Zeichen als Grafiken übertragen werden? Ich denke, bei den CJK-Blöcken wäre diese Funktion nicht anwendbar. Wieviele einzelne Grafiken dürfen auf einer Seite vorhanden sein, damit sie ein durchschnittlicher Rechner darstellen kann? Wie ist die Geschwindigkeit beim Laden? Mein Rechner braucht für die CJK-Tabellen teils recht lange. PDF braucht weniger lang. Also offenbar braucht das Rendern von Text nicht unbedingt weniger lang als das Rendern von Grafik. Gismatis 15:09, 16. Nov. 2008 (CET)

Naja, ein CJK-Zeichen als Grafik in Größe 16x16 Pixel wird bis zu 200 Byte groß sein. Bei den CJK-Tabellen könnte es also wirklich zu Problemen kommen, da würde sich das ganze zu 4 MB summieren. -- Prince Kassad 15:59, 16. Nov. 2008 (CET)

stimmt, ich hätte auch gar nicht an unsere Haupt-Listen gedacht: dort ist es viel sinniger eine ganze plane als bild alternativ anzugeben (ich hab gesehen, Du hast eh schon welche, auch auf en, gemacht, falls Dein name dort Du bist), die erledigen das als png oder besser svg mit 20-40 kB.. --W!B: 17:58, 28. Nov. 2008 (CET)

Könntest du mir angeben, wo sich diese Grafiken befinden? Was die Dateigröße betrifft, so darfst du nicht vergessen, dass es die Größe der aus der SVG-Grafik erzeugten PNG-Grafik ist, auf die es letztendlich ankommt. Gismatis 23:00, 28. Nov. 2008 (CET)

Die müssten irgendwo in meiner Bildergalerie zu finden sein... -- Prince Kassad 10:25, 29. Nov. 2008 (CET)

ich würde etwa für die vorlage so etwas vorschlagen (kompatibel mit dem jetzigen zustand erweiterbar):

{{Unicode|⊕|22|95|name=CIRCLED PLUS|img=Simple crossed circle|tex=oplus|full=true|link=Addition #Pluszeichen}}

kanonisch wie bisher:

1= Zeichen

2= Plane (vordere 2/3 stellen)

neu

3= hintere zwei stellen

name=UC-name

img= name eines bildes (ohne svg, um svg zu forcieren?), alt-text bei darstellung ist "name (U+/1/2/)":

tex= texname ohne \ .. darstellung als $\oplus$

full= .. darstellung als ⊕ CIRCLED PLUS (U+2295)

link=true .. darstellung als ⊕ CIRCLED PLUS (U+2295)

    =artikelziel ⊕ CIRCLED PLUS (U+2295)

oder mit img/tex /$\oplus$ CIRCLED PLUS (U+2295)

hab eh testweise in ♁ damit angefangen: da sind UCs und andere zeichen-bildchen vereint --W!B: 17:58, 28. Nov. 2008 (CET)

Was mir noch nicht klar ist:

1. Worin genau besteht der Sinn, die Angabe der Zeichennummer aufzuteilen?
2. Muss man bei der Größenangabe immer zuerst die TeX-Darstellung prüfen, oder geschieht dies automatisch? Wie funktioniert das Zweite?
3. Habe ich das richtig verstanden, dass entweder eine Grafik oder TeX verwendet werden soll?
4. Könnte man die Darstellung mit TeX eventuell automatisieren, sodass auf die Angabe des TeX-Codes verzichtet werden kann? Das würde die Benutzerfreundlichkeit der Vorlage enorm erhöhen.

Gismatis 23:00, 28. Nov. 2008 (CET)

Verweis in der Vorlage

Ein Problem ist, dass jemand meinte, er müsse den Verweis auf das Portal:Unicode aus der Vorlage Vorlage:Navigationsleiste Unicode herausnehmen. In der Folge erscheint im Artikel Liste von Unicode-Zeichen kein Verweis mehr auf das Portal, als Beispiel für die Folgen. Ich finde, man sollte den Verweis in die Vorlage wieder reinnehmen.
Ich finde es ärgerlich, dass einige es nicht schnallen, dass diese Artikel auch nur deshalb vollständig und gut zustandekommen, weil ein Team dahinter steht, das sich organisieren muss und auch Zuwachs an Mitarbeitern benötigt.
Falls das also nicht durchsetzbar ist, hätte ich auch Lust, für genau dieses Link in der Vorlage ein Meinungsbild zu machen - zu verlieren hat man dabei nichts. – Simplicius 11:33, 8. Dez. 2008 (CET)

Hach, diese Emotion! - Bei den anderen ist die Luft anscheinend völlig raus. --Reiner Stoppok 21:39, 17. Dez. 2008 (CET) PS: Ist hier noch jemand?

Metrische Zeichen in Unicode

Hallo, kann mir einer von Euch sagen, ob es auch einen Unicode-Block mit metrischen Zeichen gibt, wie sie zB hier und hier verwendet werden? [ˈjoːnatan gʁoːs] (ad fontes) 08:45, 20. Dez. 2008 (CET)

Im Unicode-Block Verschiedene technische Zeichen sind einige metrische Symbole enthalten. -- Prince Kassad 12:59, 20. Dez. 2008 (CET)

Ja, danke! Aber gibt es auch ein Längenzeichen, oder nur das Breve? [ˈjoːnatan gʁoːs] (ad fontes) 17:51, 20. Dez. 2008 (CET)

So wie ich [16] verstehe, soll als Längenzeichen der normale Bindestrich verwendet werden. -- Prince Kassad 19:24, 20. Dez. 2008 (CET)

Unicodes von 10000 - 10FFFF ???

Hi! Also ich hab keine Unicode-Zeichen ab dem Hex-Wert 10000. Wo kann ich mir diese downloaden?

Hängt davon ab, was du genau suchst - 10000–10FFFF sind immerhin etwas mehr als eine Million Zeichen. Wenn die Unterstützung für diesen Bereich aktiviert ist, würde ich z. B. hierhin gehen. -- Prince Kassad 17:04, 8. Okt. 2008 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: – Simplicius → Autorengilde № 1 11:21, 9. Feb. 2012 (CET)

TOC in Unicode-Block Tai-Xuan-Jing-Symbole

Für das Layout dieses Artikels gilt, was in WP:TOC zu den Überschriften, die nicht im Inhaltsverzeichnis erscheinen sollen ausgeführt wird: die Unterüberschriften sind nicht so bedeutend, dass sie im Inhaltsverzeichnis mit einer eigenen Gliederungsnummer erscheinen sollen; vielmehr wäre dies eher irritierend als hilfreich, angesichts der nur sehr kurzen Paragraphen nach der Tabelle. Das Thema ist a.a.O. ausführlich diskutiert. Aus den dort angeführten Gründen wird die Anzeige des Inhaltsverzeichnisses wieder abgeschaltet. Ich bitte, das auch so zu belassen. -- sarang♥사랑 18:23, 8. Okt. 2008 (CEST)

Kann man nicht auch die Ebenen-Anzahl einstellen? – Simplicius → Autorengilde № 1 11:21, 9. Feb. 2012 (CET)