Portal Diskussion:Unicode/Archiv/2012

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/2012#Thema 1]]

oder als Weblink zur Verlinkung außerhalb der Wikipedia

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

Revision 6.0.3

Jetzt habe ich ein wenig aktualisiert. Nun kann auch nach den Blocknamen sortiert werden, was das Finden eines gesuchten Blocks erleichtern kann; dabei stört dass erst alle geplanten kommen, dann alle nicht-definierten, und dann erst die richtigen Blöcke (mittendrin die Ebenen). Ein erster Versuch das besser zu reihen ging schief, einstweilen lasse ich es mal so.

Noch fehlen die Blöcke

• 02A00 Unicode-Block Zusätzliche Mathematische Operatoren
• 16800 Unicode-Block Bamum, Ergänzung
• 1F0A0 Unicode-Block Spielkarten
• 1F700 Unicode-Block Alchemistische Symbole

die es schon länger gibt; es sind immer noch rote Links. Auch in der Buncic-Baugrube ist erst der 2A00 angefangen.

Es wäre doch sinnvoll, in diesen vier Stellen einstweilen einen "leeren" Artikel anzulegen, wie im Beispiel der Spielkarten; damit kommt man zumindest direkt zum Unicode chart. Falls das gegen die Wikipedia-Strategie ist habe ich nichts gegen Schnelllllllöschung. -- sarang♥사랑 14:02, 12. Jan. 2012 (CET)

Mir wäre es ja fast lieber solche Stummeltabellen wieder bei jemandem im BNR anzulegen und die dann mit Inhalt zu füllen. Frage ist, wer das machen soll. -- Liliana • 14:27, 12. Jan. 2012 (CET)

Das ist allerdings die Frage. Vielleicht komme ich in den nächsten Wochen mal dazu. Jedenfalls werde ich keine weiteren Platzhalter im ANR anlegen, die Dinger bleiben halt weiter noch eine Weile rot. Irgendwie scheint der Eifer der Unicode-Betreuer nachgelassen zu haben? -- sarang♥사랑 17:07, 12. Jan. 2012 (CET)

Ich kann nur sagen, dass die fehlenden Blöcke vor allem Themen betreffen, wo ich mich so gar nicht auskenne. -- Liliana • 11:52, 13. Jan. 2012 (CET)

Hallo Liliana, die Spielkarten waren sehr einfach und systematisch und daher schnell erzeugt. Eventuell meckert noch jemand wegen der Übersetzungen, andernfalls sind sie fertig. Bei den anderen Blöcken sind vor allem die korrekten Übersetzungen das Problem, daran liegt auch die Verzögerung (seit 2007!) beim 2A00-Block. In der nächsten Zeit werde ich noch die viel größeren Tabellen in Bamum und Alchemie einbauen, einstweilen mit leerer Übersetzungsspalte. -- sarang♥사랑 14:19, 13. Jan. 2012 (CET)

Ein Problem wäre noch, dass viele sogenannte Übersetzungen eigentlich keine sind, sondern erst einmal hemdsärmelig in Pionier-Stimmung aus dem Englischen übernommen worden sind. Da müßte noch fleißig eingedeutscht werden. Das können aber dann wirklich nur Experten in den jeweiligen Themengebieten. --Reiner Stoppok 00:12, 18. Jan. 2012 (CET)

Siehe dazu auch Portal Diskussion:Unicode/Archiv/2011#Deutsche Bezeichnung und Portal Diskussion:Unicode/Archiv/2011#Deutsche Namen der Unicode-Block Verschiedene piktografische Symbole. Bin immer noch etwas irritiert über den gewählten Übersetzungsansatz der Portalkollegen ("hemdsärmelig"), denn wissenschaftliches Arbeiten sieht diesbezüglich für mich anders aus. Revertgefahr geht von mir aber trotzdem keine aus. --RonaldH 00:56, 18. Jan. 2012 (CET)

Nur Geduld! Schließlich blicken ja nicht alle Philologien auf eine lange und gut dotierte Erfolgsgeschichte (oder Diskussionsgeschichte) zurück. --Reiner Stoppok 00:27, 30. Jan. 2012 (CET) PS: Oder auf so gute nachbarschafltiche Beziehungen.

Liste der Unicodeblöcke

Ich halte den Zustand der Tabelle für nicht besonders gut:

1. Die gemeinsame Auflistung der Einträge für ganze Ebenen mit denen für einzelne Blöcke macht die Tabelle unübersichtlicher. Besser wäre eine zweite Tabelle.
2. Spalte "Verfügbar" ist überflüssig. Nimmt man Einträge für ganze Ebenen heraus, so kann man die Spalte Verfügbar weglassen, denn bei den anderen einträgen ist "verfügbar" mit "undefiniert" identisch. Man kann diese Werte auch unter "undefiniert" auflisten.
3. Spalte "undefiniert" ist indirekt redundant. Der Wert ergibt sich bei berücksichtigung von Punkt 2 aus der Differenz von Gesamtgröße und "definiert". Kann man notfalls weglassen, wenn es Probleme mit der Tabellenbreite gibt.
4. Die Schreibrichtung sollte eine eigene Spalte bekommen. Es ist genug Platz dafür.
5. Syntax: Die SortKeys werden recht umständlich erstellt. Das geht bestimmt auch eleganter.
6. Die Vorlage:Ubz nimmt viel zuviele Eingriffe in die Gestaltung vor. Border-Angaben sind z.b. nicht erforderlich. Damit bevormundet man die Benutzer bei deren Skin-Einstellungen und ihren Benutzer-CSS-Angaben.
7. Die Tabelle enthält einen Fehler: die beiden letzten Points einer Ebene (FFEF und FFFF) sind nicht Bestandteil des (letzten) Blocks, denn diese werden für die Byte Order Mark benötigt und sind "gesperrt".

Ich biete an, hier eine konkrete Umgestaltung auszuarbeiten und vorzuschlagen, wenn ich für diesen Versuch nicht gleich virtuell gesteinigt werde... ÅñŧóñŜûŝî (Ð) 19:05, 1. Feb. 2012 (CET)

Der Unterschied zwischen "undefiniert" und "verfügbar" ist wohl, dass ersteres nur auf bestehende Blöcke zutrifft und letzteres nur auf freie Flächen. Wobei ich mich hier auch frage, für was die ganzen Planungen in der Liste sein müssen, denn sie sind hochspekulativ und können sich ziemlich schnell ändern. -- Liliana • 14:55, 2. Feb. 2012 (CET)

Verfügbare Points sind logischerweise auch undefiniert, also eher eine Übermenge im mathem. Sinne. Diese Unterscheidung würde ich zwecks besserer Breitennutzung weglassen. die spekulativen Planungen stören mich mittendrin auch. Die würde ich aber in einer separaten Tabelle darstellen. Das gliedert die Seite auch viel besser. Ich überlege mir was. ÅñŧóñŜûŝî (Ð) 20:33, 3. Feb. 2012 (CET)

Ich habe jetzt mal eine Version erstellt (Doku für die Vorlage fehlt noch). Ich halte das für ausreichend. ÅñŧóñŜûŝî (Ð) 23:10, 5. Feb. 2012 (CET)

Ich bin entsetzt

Diese gewaltige Änderung umfasst einiges, das diskutierbar ist, und vieles das IMHO eine wesentliche Verschlechterung der vorherigen Darstellung bedeutet.

• Die Umbenennung/Verschiebung ist diskutierbar; dabei ist aber zu beachten, dass es über 200 Artikel "Unicode-Block xxxxx" (nicht "Unicodeblock  xxxxx"!) gibt, und es jetzt inkonsistent wirkt. Womöglich bin ich von der englischen Originalbezeichnung, nun eben Unicode Block, beeinflusst – für mein Sprachgefühl ist die vorige Bezeichnung passender, und ich plädiere schon mal dagegen, alle Artikel umzubenennen.

Zu den oben angeführten Punkten (Zustand der Tabelle):

1. Ich fand die Integrierung der Ebenensummen in die Tabelle der Blöcke ganz gut; optimal war es nicht, aber recht informativ und übersichtlich, und durch die Farbgebung nicht nur gut unterscheidbar, diese Zeilen bildeten auch eine unaufdringliche Abgrenzung zwischen den Ebenen.
   Die neue Ebenentabelle bietet Informationen von wesentlich geringerer Wichtigkeit, sie sollte nicht vor der Blöcketabelle stehen.
2. Die Trennung zwischen "verfügbar" und "undefiniert" hatte nur Sinn für die Summenzeilen. Wenn Ebenenzeilen und Gesamtsumme nicht mehr in der Tabelle dargestellt werden ist diese Trennung überflüssig. Allerdings werden damit andere Spalten für die Ebenentabelle erforderlich, als sie für die Blöcketabelle sinnvoll sind.
3. Die Spalte "undefiniert" war, ebenso wie "verfügbar", vor allem informativ als Sortierkriterium: wo gibt es noch viele „freie“ Codepoints, wo sind die großen „Löcher“ in den Ebenen. Das war bei geeigneter Sortierung sofort zu sehen, falls es jemand wissen wollte.
   Diese Information ist nun verloren gegangen. Eine Sortierung nach der Spalte "definiert" bringt überhaupt keine sinnvolle Information, unsortable wäre sinnvoll.
4. Die Schreibrichtung war in einer eigenen Spalte dargestellt. Es ist eine Information die innerhalb der Blöckeartikel angeführt werden muss, in der Tabelle ist sie eher unwesentlich. Deshalb sollte sie, wenn überhaupt, recht diskret dargestellt werden und keinesfalls so wuchtig und aufdringlich wie jetzt! Auch eine Sortierung nach dieser Spalte bringt nun weniger Information, höchstens dass viele Zeilen der 3. Kategorie "unbestimmt" angehören - was auch nicht viel hilft.
5. Die SortKeys mussten recht umständlich erstellt werden, weil nun mal Hexadezimalzahlen für den Tabellensort nach alphabetischer Ordnung gereiht würden. Die Sortierung nach "von" ist der wesentlichste Sortierbegriff: entweder wird diese Spalte unsortable, die umgekehrte Reihung gibt es einfach nicht mehr, und zur Wiederherstellung muss der Artikel neu aufgerufen werden; oder es ist ein SortKey zu verwenden der die richtige Sortierung gewährleistet.
   Gegenwärtig ist in der reduzierten Tabelle die Übergabe eines SortKeys an die Vorlage überflüssig, der Key ist durch einfaches Padding des "von"-Wertes ermittelbar.
   Das ist sofort zu sehen wenn nach der (nun völlig unnötigerweise sortable) Spalte "bis" sortiert wird, da hier kein SortKey zur richtigen Sortierung hilft hat es nun z.B. die unsinnige Reihenfolge 1BBF - 1BCAF - 1BCFF - 1BFF. Eigentlich kann die "bis"-Spalte nur die Sortierung voll-identisch zur Spalte "von" liefern.
   Ähnlich ist es mit der Spalte "Unicode Blockname": da kommen nun zwischen "Georgisch…" und "Glagolitisch" alle geplanten, und zwischen "Keilschrift …" und "Kharoshthi" alle kein Block-Zeilen. Das wa vorher wesentlich besser!
6. Die Vorlage Ubz hat bisher die wesentliche Arbeit geleistet. Die unlängst eingebauten Border-Angaben waren erforderlich um die Pseudo-Spalte für die Schreibrichtung so zu gestalten, dass sie möglichst unauffällig bleibt. Nun ist die Hauptarbeit in den Artikel verlagert, die Vorlagenaufrufe passen nicht mehr in eine Zeile was das Editieren unübersichtlicher macht. Bezeichnenderweise ist der Artikel auf mehr als das Doppelte des ursprünglichen Umfanges (23.441 → 47.384) angewachsen, die Vorlage hingegen auf fast die Hälfte (1.927 → 1.027) geschrumpft. Erfahrungsgemäß gibt es sehr unterschiedliche Ansichten, was von der Aufbereitung eines Artikels in eine Vorlage ausgelagert werden sollte.
   Ob die Border-Angaben bei verschiedenen skins stören habe ich nicht untersucht, das mag jetzt besser sein.
7. Die Byte Order Mark-Sache hatte gefehlt. Das hätte irgendwo erklärt werden sollen, auch auf die Gefahr hin dass es sehr wenige interessiert.

Zusammenfassend sehe ich, dass mit grossem Arbeitsaufwand viel vernichtet worden ist.

1. Die IMHO viel zu grellen Farben lassen sich schnell ändern.
2. Die sinnlosen Sortierungen nach Ebene, "bis" und "definiert" lassen sich schnell abschalten.
3. Die Spalte "definiert" ist in der jetzigen Tabelle völlig unübersichtlich. Besser wäre, stattdessen die noch freien Stellen anzuzeigen, mit Null-Unterdrückung wie vorher.
4. Die wenig sinnvollen Einschübe der geplanten und Nichtblöcke lassen sich durch einen von der Vorlage aufbereiteten SortKey verlagern, z.B. ans Tabellenende.
5. Wenn die Schreibrichtung überhaupt angegeben werden soll, dann keinesfalls so wie jetzt, wo sie den Eindruck des allerwichtigsten Kriteriums erweckt. Besser wäre es, auf diese Information zu verzichten.
6. Die Informationen über geplante Blöcke war vorher so eingepflegt, dass nicht hochspekulative sondern „ausgereifte Planungen“ über bereits „formell akzeptierte“ Erweiterungen, die also unmittelbar bevorstanden, direkt aus der Tabelle zugänglich waren. Diese Information wird nun bedauerlicherweise nicht mehr geboten. Es mag ja nicht so toll viele interessieren, doch mir erschien mir diese Info hilfreich.
7. Die Prozentzahlen in der Summenzeile fand ich recht informativ. Jetzt fehlt diese übersichtliche Info, die auf den ersten Bick die Verhältnisse erkennen ließ; die Fließtextangaben oberhalb des Blockes sind wesentlich weniger gut erfassbar.

Die Änderungen enthalten einige gute Ansätze, doch in Summe überwiegen die Nachteile. Ich schlage vor, auf den Stand des 2. Februar zu revertieren und vor solchen Änderungen die Pro- und Contra-Argumente abzuwägen und zu diskutieren. -- sarang♥사랑 19:32, 12. Feb. 2012 (CET)

(Ich habe bei deinem Text mal nummeriert, um besser Bezug nehmen zu können, Ok ?)

1. Ein Revert bewirkt aller Erfahrung nach, das gar nichs mehr geändert wird. Eine Diskussion vom Typ "Behalten wir gemachte Änderungen ?" ist meist besser als eine Diskussion vom Typ "Ändern wir etwas ?", weil User, welche den Status quo behalten wollen, bei der zweiten Methode einfach schweigen.
2. Die Vorlage:Ubz war ein fürchterliches Kauderwelsch aus Konstanten, Ausnahmen und Workarrounds, verursacht durch nachträgliche Erweiterungen. Deshalb war sie auch so groß. Diesen Zustand sollten wir auf keinen Fall wiederherstellen. Welche Arbeiten soll sie denn erledigt haben, welche sie jetzt nicht erfüllt ? Der Quelltext ist jetzt übersichtlicher.
3. Insgesamt solltest du bedenken, dass die Vorlage Ubz nur selten neu eingefügt wird. Da kann die Einbindung ruhig etwas mehr Arbeit sein.
4. Die undefinierten Codepoints ergeben sich schlichtweg durch die Subtraktion "Umfang minus Definiert". Das ist daher indirekt redundant, lässt sich aber auch trotzdem in die Vorlage:Ubz und damit in die Tabelle einbauen. M.E. also kein Problem.
5. Die Vermengung von Ebenenangaben und Blockangaben war m.E. unübersichtlich. Weil zudem andere Spalten benötigt werden, ist eine Aufteilung auf separate Tabellen sinnvoll. Welche Informationen sollen da deiner Meinung nach verloren gegangen sein ?
6. Den Unterschied zwischen "undefiniert" und "verfügbar" habe ich im Artikel dargestellt: Verfügbar bedeutet "nicht in einem definierten Block", undefiniert bedeutet "in einem Block, aber noch nicht genutzt". Das ist ein Unterschied, den man bei den Ebenen darstellen sollte. In der Liste der Blöcke macht "verfügbar" natürlich keinen Sinn, denn da ist nichts verfügbar. Das ist aber auch nicht enthalten. Gerade hier zeigt sich der Vorteil getrennter Tabellen, da die Spalten verschieden sind.
7. Die Nullunterdrückung ist nicht gut, denn in der WP werden leere Zellen von Lesern oft als "noch fehlend" ausgelegt. Es kann ruhig drin stehen, wenn ein Wert Null ist. Das ist genauer.
8. Eine Sortierung nach "definiert" ist genauso sinnvoll wie eine Sortierung nach "undefiniert". Das du eine Sortierung nach "bis" oder "definiert" für unnötig hältst, bedeutet nicht, dass auch andere Leser das für unnötig halten. Diese Möglichkeit zu entfernen, schränkt Leser unnötig ein.
9. Die Schreibrichtung ist Bestandteil der Informationen zu einem Block. Auch hier gilt: Was du für unwichtig hältst, muss für andere nicht gelten. Ebenso die Sortierung danach, was z.B. die geplanten und fehlenden Blöcke heraussortiert. Eine aufwändige Bordersyntax, nur um das optisch zu unterdrücken, ist jedenfalls unpraktisch. Eine eigene Spalte darf das ruhig Wert sein.
10. Die Prozentzahlen kann man wieder einfügen, aber die stehen schon im Text. Man muss nur lesen. Ich traue den Lesern auch zu, diese zu finden.
11. Alle Blöcke sortieren jetzt bei "Von" schlichtweg nach Text, da der Schlüssel immer mit "U" beginnt. So einfach sind Lösungen wenn man nur etwas überlegt. Da gibt es m.E. keine Probleme mehr.
12. Die Weblinks sind, wie der Beitrag von Liliana zeigt, umstritten. Ein allgemeiner Link am Ende der Seite reicht aus.

ÅñŧóñŜûŝî (Ð) 21:08, 12. Feb. 2012 (CET)

Nachtrag: Ich habe einiges angepasst:

1. dezentere Farben
2. Ergänzung Spalte "undefiniert"
3. Sortierung bei Schreibrichtung und Name verbessert.

Das waren einige Änderungen zum Besseren. Diese drei angeführten, die Spalte "Ebene" unsortable, und die Verschiebung der Ebenentabelle nach hinten.

Die Sortierung nach Umfang ist sinnvoll, ebenso nach undefiniert - hingegen nach definiert zu sortieren sehe ich keinen Sinn. Diese Spalte sollte IMHO ganz entfallen.

Eine Sortierung nach "bis" bringt überhaupt nichts, das kann immer nur identisch wie bei der "von"-Sortierung sein. Jeder Aufwand dafür ist überflüssig.

Jetzt haben einge Spalten mit sehr kurzen Elementwerten sehr breite Überschriften; ein Problem das oft bei Tabellen vorkommt, und für das eine Lösung schwierig ist: die "Schreibrichtung" (vorher 2, jetzt 3 Ausprägungen) ist zur wesentlichsten Spalte der Tabelle geworden, ebenfalls sehr breit ist "undefiniert" mit überwiegend dem Wert Null, hingegend die eigentlich wesentliche Spalte für den Blocknamen ist so schmal, dass viele Namen auf zwei und auf drei Zeilen gesplittet werden müssen; sehr auf Kosten der Leserlichkeit.

(Pause) sarang♥사랑 22:52, 12. Feb. 2012 (CET)

Vorlagen für das Portal, aktuelle Fonts

Kategorie Unicode (Diskussion ▪ Anzahl Artikel ▪ Neue Artikel ▪ Löschanträge ▪ Karte mit allen Koordinaten: OpenStreetMap, GoogleMaps oder Bing ▪ Fehlende Artikel ▪ Wartungsbausteine ▪ Bewertungen)

Hallo miteinander, wollte man wieder reinschauen. Ist die Problematik mit den mathematischen Symbolen inzwischen gelöst? Was ist mit Benutzer:Buncic/Unicode/Zusätzliche mathematische Operatoren los? – Simplicius → Autorengilde № 1 11:21, 9. Feb. 2012 (CET)

Da jemand klammheimlich nachts den Artikel Unicode-Block Zusätzliche Mathematische Operatoren erstellt hat, hab ich die Tabelle dorthin kopiert. -- Liliana • 11:42, 9. Feb. 2012 (CET)

Ich habe mal einen Blick auf Benutzer:Buncic/Unicode/Alchemistische_Symbole geworfen. Mozilla Firefox zeigt mir die Symbole nicht an. Welches ist im Moment der geeignete Schriftfont, den man am besten installieren sollte? – Simplicius → Autorengilde № 1 05:23, 17. Feb. 2012 (CET)

Symbola -- Liliana • 05:27, 17. Feb. 2012 (CET)

Danke, das ist nützlich. Ein Artikel darüber dürfte sich wohl nicht recht lohnen. Jemand schreibt [1], die Symbole seien ein ripoff von den Symbolen, die in den pdf-Dateien vom Konsortium dargestellt werden. – Simplicius → Autorengilde № 1 12:50, 17. Feb. 2012 (CET)

Unicode-Block Hoch- und tiefgestellte Zeichen

Hier fügen manche Leute immer wieder die hochgestellten Ziffern ² und ³ ein, obwohl sie gar nicht in dem Block enthalten sind. Ist das gewünscht? -- Liliana • 17:40, 17. Feb. 2012 (CET)

Ich habe die Ergänzungen revertiert und den User auf seiner Diskseite angesprochen. Grüße --RonaldH 18:36, 17. Feb. 2012 (CET)

Neue Seiten über Blöcke

Hallo. Ich habe ein paar fehlende Seiten über Blöcke erstellt:

• Unicode-Block Pollard-Schrift
• Unicode-Block Alchemistische Symbole
• Unicode-Block Bamum, Ergänzung
• Private Unicodeblöcke (Zusammenfassung von "Private Use Zone", "Supplementary Private Use Area - A" und "Supplementary Private Use Area - B")

1. Bei Unicode-Block Alchemistische Symbole konnte ich nicht alle Bezeichner übersetzen. Da könnte noch jemand weitermachen.
2. Unicode-Block Pollard-Schrift Da wäre ein Weblink auf eine kostenlose Fontdatei, welche diesen funkelnagelneuen Block enthält, nützlich.
3. Unicode-Block Bamum, Ergänzung hat noch keine Tabelle, weil ich auch mal in die Koje muss. Wer hat Lust ?
4. Private Unicodeblöcke ist ein Stub. Auch da wären weitere Autoren nett.

ÅñŧóñŜûŝî (Ð) 14:54, 19. Feb. 2012 (CET)

Willst Du die fehlenden Beschreibungen gleich selber ergänzen (oder das auf die QS setzen)? --Reiner Stoppok 01:02, 25. Feb. 2012 (CET) PS: Ähm, auf die QS gehören strenggenommen natürlich auch noch viele andere ...

Die WP ist ein Gemeinschaftsprojekt. Sei mutig und mache es gleich selbst, wenn es dir auffällt... Gruß von ÅñŧóñŜûŝî (Ð) 14:43, 25. Feb. 2012 (CET)

Diejenigen, die dieses Unicode-Gemeinschaftsprojekt initiiert haben, hatten sich auch schon ein paar Gedanken gemacht. Und ich sage Dir: Du tanzt damit den Qualitäts-Limbo. --Reiner Stoppok 01:00, 26. Feb. 2012 (CET)

Willst du damit sagen, dass das Thema Qualität bei diesen Seiten gestorben ist ? Um so mehr ein Grund, selbst aktiv zu werden und eine Reanimation zu versuchen, falls der Patient doch noch nicht ganz tot ist... ÅñŧóñŜûŝî (Ð) 10:37, 26. Feb. 2012 (CET)

Du hast das gerade eingestellt, deshalb fange ich mit der Qualitätstherapie gleich bei Dir an. --Reiner Stoppok 13:22, 26. Feb. 2012 (CET)

Zugriffszahlen

Die Zugriffszahlen auf das Portal:Unicode sind mau. http://stats.grok.se/de/latest90/Portal:Unicode

Das sieht auch nicht viel besser bei Portalen aus, wo es mehr Mitarbeiter gibt: http://stats.grok.se/de/latest90/Portal:Sauerland

Das Problem ist eben auch, dass eine Rückverlinkung in der Navi-Leiste verboten ist. – Simplicius → Autorengilde № 1 09:11, 26. Feb. 2012 (CET)

Das Portal ist ja im Grunde nicht so wichtig wie die einzelnen Blöcke (und deren Qualität). --Reiner Stoppok 13:27, 26. Feb. 2012 (CET)

Es geht darum, dass man ein Portal als Schnittstelle hat, um auch neue Mitarbeiter zu gewinnen. Für 1 Millionen Zeichen mit fünf Personen, manchmal auch nur zwei oder einem, die komplette Übersetzung zu machen, hat Schieflage. – Simplicius → Autorengilde № 1 09:09, 10. Mär. 2012 (CET)

Darstellbarkeit von Unicode-Zeichen

Die Frage ist, wozu definiert man so viele Zeichen, wenn man sie eigentlich gar nicht benutzen kann. Zumindest nicht im Web. Oder gibt es einen Browser, der alle Unicode-Zeichen anzeigen kann? Also ich sehe mit Opera im Unicode-Block Verschiedene piktografische Symbole nur kleine Rechtecke, ebenso mit dem Internet Explorer. K-Meleon zeigt stattdessen Fragezeichen an, was auch nicht besser ist. Gibt es denn keine Möglichkeit, diese Zeichen zu Gesicht zu bekommen, außer in der unten verlinkten PDF-Datei? Im Übrigen habe ich noch weitere Unicode-Blöcke gefunden, die ebenfalls nicht oder nur teilweise angezeigt werden. Da wäre beispielsweise die untere Hälfte vom Unicode-Block Verschiedene Symbole, weiterhin Unicode-Block Diskos von Phaistos, Unicode-Block Allgemeine indische Ziffern, Unicode-Block Mahjonggsteine, Unicode-Block Linear-B-Silbenzeichen, Unicode-Block Alchemistische Symbole und Unicode-Block Vedische Erweiterungen. Soll erstmal reichen. -- ⌂ herein... 07:32, 31. Mär. 2012 (CEST)

Habe die Antwort im Portal etwas hervorgehoben. – Simplicius → Autorengilde № 1 08:31, 31. Mär. 2012 (CEST)

Hier sind noch ein paar Stichwörter zu weiteren Unicode-Fonts: http://orwell.ru/test/download/ Ich weiß nicht, wie aktuell das ist. – Simplicius → Autorengilde № 1 09:44, 31. Mär. 2012 (CEST)

Was es die Liste angeht: dort habe ich den Zellen mit den Symbolen die CSS-Klasse "unicodesymbol" zugewiesen. Damit kann man in der eigenen CSS eine geeignete Schrift (z.B. Symbola) zuordnen. ÅñŧóñŜûŝî (Ð) 12:50, 31. Mär. 2012 (CEST)

Nur mal so nebenbei, müssen es wirklich 400% sein? Hätte nicht auch etwas weniger gereicht? -- Liliana • 13:33, 31. Mär. 2012 (CEST)

(BK) Die Liste soll das Symbol beispielhaft möglichst deutlich darstellen. Da ist eine große Skalierung sinnvoller als die Schönheit der Tabelle. ÅñŧóñŜûŝî (Ð) 13:48, 31. Mär. 2012 (CEST)

Meine Schriftempfehlungen (Monospace in kursiv) :

• Verschiedene Symbole (Miscellaneous Symbols): "Unicode Symbols", Symbola
• Diskos von Phaistos (Phaistos Disc): Code2001, Aegean, Everson Mono
• Mahjonggsteine (Mahjong Tiles): "Unicode Symbols", Symbola,Everson Mono
• Linear-B-Silbenzeichen (Linear B Syllabary): Code2001, Aegean, Everson Mono
• Alchemistische Symbole (Alchemical Symbols): Symbola, Everson Mono (nur ein Teil)
• Verschiedene piktografische Symbole (Miscellaneous Symbols And Pictographs): Symbola

Für "Vedische Erweiterungen" und "Allgemeine indische Ziffern" kenne ich keinen Font. ÅñŧóñŜûŝî (Ð) 13:48, 31. Mär. 2012 (CEST)

Ach ja: hier gibt es ein gutes Tool, um für jeden Block die richtige Schrift zu finden. ÅñŧóñŜûŝî (Ð) 13:52, 31. Mär. 2012 (CEST)

Welche Liste meint ihr? – Simplicius → Autorengilde № 1 17:52, 31. Mär. 2012 (CEST)

Letztlich komme ich mir bei der Frage, wie es mit den Fonts für Unicode aussieht, etwas allein auf weiter Flur vor. Wäre es sinnvoll, mal eine Tabelle über die verfügbaren Fonts anzulegen, damit man etwas über sie schreiben kann? Was liefert Microsoft per Windows7 selbst? Was bietet sich für Linux-Anwender an? Wäre eine Tabelle sinnvoll, welcher Font was kann? – Simplicius → Autorengilde № 1 17:56, 31. Mär. 2012 (CEST)

Wo sollte diese Tabelle dann sein? -- Liliana • 18:32, 31. Mär. 2012 (CEST)

Vorerst einmal auf Portal:Liste von Unicodeschriften sammeln. ÅñŧóñŜûŝî (Ð) 00:08, 1. Apr. 2012 (CEST)

Bei geeigneten (= freien) Schriftarten könnte man auch darum bitten, sie in die mw:Extension:WebFonts aufzunehmen, und diese hier dann zu aktivieren (bugzilla:34982, mit einem Bug spezifisch für de.wikipedia, aufbauend auf einem erkennbarem Konsens, ginge es vermutlich schneller), dann würden die entsprechenden Zeichen für alle Benutzer mit zeitgemäßem Browser angezeigt, ohne dass sie irgendwelche Schriften installieren müssten. --Schnark 09:28, 2. Apr. 2012 (CEST)

Verschoben von Portal:Liste von Unicodeschriften zu Portal:Unicode/Liste von Unicodeschriften -- Cherubino (Diskussion) 17:05, 2. Apr. 2012 (CEST)

Was ist mit Arial Unicode MS? --RonaldH (Diskussion) 17:09, 2. Apr. 2012 (CEST)

Ist Bestandteil von MS Office. Daher für viele nicht nutzbar. Die aufgeführte Font-Version ist ziemlich alt, da sie zu einer alten Office-Version gehört, welche ich nicht mehr nutzte oder aktualisiere. ÅñŧóñŜûŝî (Ð) 19:55, 3. Apr. 2012 (CEST)

Programm zur Erzeugung von Unicode-Tabellen

Liebe Unicode-Enthusiasten,

nachdem ich schon seit längerem nicht mehr die Zeit gefunden habe, Unicode-Tabellen zu erstellen, habe ich nun meine inzwischen gestiegenen PHP-Kenntnisse genutzt, um ein kleines Hilfsprogramm zu schreiben, mit dem sich die nötigen Quelltexte sehr einfach herstellen lassen. Probiert es aus: http://wp.buncic.de/unitable.php. Um die gleichen Ergebnisse zu bekommen wie bisher, muss man als Spaltenköpfe "Unicode-Nummer", "Zeichen", "Beschreibung" und "Offizielle Bezeichnung" (und keine Kommentarspalte) eingeben, als Textvorlage vor der Tabelle:

Der '''[[Unicode]]-[[Liste der Unicode-Blöcke|Block]] ZZZZ ()''' (XXXX–YYYY)

und nach der Tabelle:

== Weblinks ==
* [http://www.decodeunicode.org/de/zzzz Grafische Informationen des Wiki-Projekts decodeUnicode] (z. T. deutsch)
* [http://www.unicode.org/charts/PDF/UXXXX.pdf PDF des Unicode-Konsortiums] (englisch)
{{Navigationsleiste Unicode}}

Diese Texte werden, wenn man sie einmal eingegeben hat, in einem Cookie gespeichert, so dass man sie nicht ständig neu eingeben muss. Mir scheint, damit geht die Erzeugung einer Unicode-Block-Tabelle so einfach, dass es sich selbst für Ergänzungen zu bereits existierenden Blöcken lohnt, dieses Progrämmchen zu benutzen und dann nur die neuen Zeilen in das Wikipedia-Bearbeitungsfenster zu übertragen.

Herzliche Grüße! --Daniel Bunčić 16:51, 6. Apr. 2012 (CEST)

Sehr praktisch! Vielen Dank! Wikisteno (Diskussion) 22:53, 7. Apr. 2012 (CEST)

Verbindungszeichen

Ich habe kurz die alten Diskussionen zu dieser Lemmawahl überflogen, und bin mir daher bewusst, dass ich mich auf verminten Gebiet bewege (deswegen frage ich auch ausnahmsweise vorher). google:Verbindungszeichen findet Studentenverbindungszeichen und WP-Mirrors, aber sonst nichts, was etwas mit dem zu tun hat, was ich und Liste der Unicodeblöcke als kombinierendes Zeichen bezeichnen. Wenn also niemand protestiert, würde ich den Artikel gerne nach Kombinierendes Zeichen als den wesentlich geläufigeren (wenn auch bei weitem nicht so schönen) Namen verschieben (und bei der Gelegenheit deutlich ausbauen, einen Entwurf habe ich schon vorbereitet). --Schnark 11:08, 9. Jun. 2012 (CEST)

Ich hab Verbindungszeichen auch noch nie gehört. Von mir aus geht das also in Ordnung. -- Liliana • 11:18, 9. Jun. 2012 (CEST)

"Verbindungszeichen" ist so falsch, als würde man "Stadttor" mit "town fool" übersetzen. Ein Musterbeispiel für eine misslungene Übersetzung. Bitte unbedingt nach Kombinierendes Zeichen verschieben. ÅñŧóñŜûŝî (Ð) 13:34, 9. Jun. 2012 (CEST)

Block: IPA-Erweiterungen

Hi, Wenn es IPA-Erweiterungen gibt wo sind dann die anderen vorher schon dagewesenen IPA-Zeichen?
Gruß, ☺ Bob l´éponge ^Briefkasten _{Eigene Seite} 15:28, 24. Jun. 2012 (CEST)

IPA benutzt auch normale, lateinische Buchstaben. Vermutlich ist die Ergänzung um die Sonderzeichen gemeint. ÅñŧóñŜûŝî (Ð) 17:25, 24. Jun. 2012 (CEST)

Unicodeblock Phonetische Erweiterungen

Was ist denn bitte schön ein “Kapitälchen”?
Danke für eine Antwort, Gruß, ☺ Bob l´éponge ^Briefkasten _{Eigene Seite} 15:31, 24. Jun. 2012 (CEST)

Kapitälchen -- Liliana • 15:51, 24. Jun. 2012 (CEST)

Doppeleintragung

Wenn ich mich recht erinnere wurde da doch mal ein peinlicher Fehler gemacht als ein chinesisches Zeichen zweimal codiert wurde. Was ist daraus geworden?--Antemister (Diskussion) 23:59, 25. Jun. 2012 (CEST)

Ja stimmt, es handelt es sich um 㶷 und 𤈎. Viel machen kann man nicht, denn was einmal in Unicode ist, wird nicht wieder entfernt. -- Liliana • 00:15, 26. Jun. 2012 (CEST)

Könnte jemand das in den Artikel hineinsschreiben? Das ganze Projekt scheint ja in Asien allgemein nicht so gut anzukommen...--Antemister (Diskussion) 21:41, 26. Jun. 2012 (CEST)

In welchen Artikel denn? -- Liliana • 21:43, 26. Jun. 2012 (CEST)

In Unicode halt, in den Kritik-Abschnitt.--Antemister (Diskussion) 21:50, 26. Jun. 2012 (CEST)

Deutsche Übersetzung für: codespace, area, plane, PUA (Private Use Area); eigener Artikel zu letzterer

Bei einer Durchsicht des Artikels habe ich festgestellt, dass folgende Übersetzungen gewählt wurden:

• codespace – "Der Unicode-Standard" (in "Gliederung"; habe ich gestern in "Codepunktumfang" geändert)
• plane – "Bereich" (in "Gliederung")
• area - ? (der Begriff ist auch im Originaldokument (engl. Unicode-Standard 6.1) nicht formell definiert)
• Private Use Area – "privater Nutzungsbereich" (in der Bildlegende der "grafischen Darstellung der Multilingual Plane).

In der Diskussion habe ich zu diesen Übersetzungen nichts gefunden. Ich würde gerne näher am englischen Original bleiben und folgende Übersetzungen wählen:

• codespace – Codepunktbereich (bessere Vorschläge?)
• plane – "Ebene"
• area – "Bereich"
• Private Use Area – den "privaten Nutzungsbereich" finde ich sehr treffend, und würde sich auch nicht mehr mit einer Verwendung von "Bereich" für "plane" beißen.

Nun habe ich gestern einen Abschnitt "Privater Nutzungsbereich (PUA, Private Use Area)" eingefügt und erst danach festgestellt, dass es einen Artikel "Private Unicodeblöcke" gibt, dessen Inhalt sich erwartungsgemäß mit der von mir hier eingetragenen Information überschneidet. Den Titel "Private Unicodeblöcke" finde ich aber unglücklich, denn "Block" hat in Unicode bekanntermaßen eine spezifische Bedeutung, und im Originaldokument taucht "block" niemals im Zusammenhang mit der PUA auf. Entsprechend können PUA-Verwender wie ConScript auch "blocks" innerhalb dieser Bereiche ("ranges" laut entsprechendem Artikel in der englischen Wikipedia) benennen. Der dortige Artikel ist ohnehin überarbeitungsbedürftig, z.B. kommt der Begriff "Private Use Zone" im Originaldokument auch nirgendwo vor.

Was ich tun möchte, ist:

• Hier die deutschen Begriffe wie oben vorgeschlagen verwenden
• Den Artikel "Private Unicodeblöcke" nach "Privater Nutzungsbereich (Unicode)" verschieben (oder wäre "PUA (Unicode)" besser?)
• Den PUA-Artikel überarbeiten, die Information aus dem hiesigen Abschnitt "Privater Nutzungsbereich (PUA, Private Use Area)" dort einarbeiten, und den Inhalt des hiesigen Abschnitts durch eine Kurzfassung mit Verweis ersetzen
• Den Begriffsklärungsverweis "PUA" (den ich gestern auf diesen Artikel gesetzt hatte) auf den umgearbeiteten PUA-Artikel setzen.

Einwände oder bessere Vorschläge? -- Karl432 (Diskussion) 22:47, 22. Aug. 2012 (CEST)

Plane: Auf jeden Fall Ebene.

Area: Auf jeden Fall Bereich.

Private Use Area: Apple nennt dies in der Zeichenübersicht Privat nutzbarer Bereich. Existierende Übersetzungen sind vorzuziehen. Was meint Microsoft?

Aritkel Private Unicodeblöcke: Würde ich auf Privat nutzbarer Bereich oder ähnlich verschieben. Das Unicode in Klammern ist nicht nötig. Klammerzusätze werden nur zur Unterscheidung verwendet, wenn es gleichlautende andere Lemmas gibt.

Wikisteno (Diskussion) 23:24, 22. Aug. 2012 (CEST)

Gute Vorschläge. Weniger gut finde ich die Tatsache, dass Karl432 erst verschoben hat und sich erst Stunden später hier gemeldet hat. Sowas geht gar nicht. Wenn schon ein anderes Lemma, dann kein Deutsch-Englisch-Gemisch und kein Kürzel- oder Klammerlemma. Bitte etwas mehr mühe bei der suche nach einem neuen Lemma. Und zwar ERST HIER!. Plane -> Ebene und Area -> Bereich ist wohl unstrittig. Ich bin für die Zuordnung "Private Use Area" in "Privat nutzbare Unicodeblöcke". Da es hier um mehrere, konkrete Blöcke geht (ein Sammelartikel für drei Blöcke), ist hier ein Plural-Lemma sinnvoll. ÅñŧóñŜûŝî (Ð) 15:21, 25. Aug. 2012 (CEST)

Nur nebenbei, ich habe nicht erst verschoben und mich dann später gemeldet, sondern erst mich hier gemeldet, dann drei Tage abgewartet, dann vor jetzt einer halben Stunde verschoben und innerhalb von zehn Minuten die Rückverschiebung vorgefunden. Zur Sache: Wer sagt, dass »ein "denglisches" Kürzel-Klammer-Lemma nicht in Frage kommt« (in Antonsusi's Rückmeldebegründung)? Wenn es eine klare Wikipedia-Richtlinie gibt, lasse ich mich gerne belehren. – Ansonsten sehe ich, dass zumindest in meinem Umfeld (u.a. DIN-Arbeitsgruppen) jeder von PUA spricht, aber praktisch niemand eine deutsche Bezeichnung verwendet. "Privat nutzbare Unicodeblöcke" ist falsch, da es (wie der Originalstandard sagt) hier um "areas" und nicht um "blocks" gilt, hier möchte ich als Mitglied des zuständigen DIN-Ausschusses auf Präzision bestehen. "Privat nutzbarer Bereich" ist zwar die beste bisher hier diskutierte Übersetzung, ist aber als Lemma ungeeignet, weil es außerhalb von Unicode alles mögliche bedeuten kann. Außerdem sehen mir solche Begriffe nach einer Zwangseindeutschung für Anglizismenfeinde aus, ziemlich nahe an einer in der Wikipedia unerwünschten Begriffsetablierung. Ich sehe PUA für einen im Deutschen etablierten Begriff und bin deshalb nach wie vor für "PUA (Unicode)". -- Karl432 (Diskussion) 15:39, 25. Aug. 2012 (CEST)

Zu Ersterem: Sorry, ich habe das Datum falsch gelesen...

Zur Sache:

In WP:NK steht, dass Klammerlemma möglichst zu vermeiden sind. Da es genug Möglichkeiten gibt, auch ohne Klammerlemma auszukommen (es wird allenfalls etwas länger), kommt ein Klammerlemma nicht in Frage.

Das wir in der dt. WP möglichst dt. Lemmata haben sollten, ist eigentlich so selbstverständlich, dass es nicht explizit erwähnt wird. Wir haben ja auch keinen Artikel Potato, sondern einen Artikel Kartoffel. Solange ein engl. Begriff - so wie hier eindeutig der Fall - übersetzbar ist, gehört der Artikel auch unter ein dt. Lemma. Das Wissenschaftler und DIN-Ausschuss-Mitglieder engl. Begriffe nehmen, liegt an der Internationalisierung und ist eher ein Fall von "Zwangs-Englisch" statt "Zwangseindeutschung".

Dein subjektiver Eindruck, dass "PUA" ein im Deutschen etablierten Begriff sei, liegt vermutlich an deiner Mitgliedschaft im Ausschuss und ist objektiv gewiss nicht richtig.

Wenn dir "Privat nutzbarer Bereich" zu unspezifisch ist, dann kann man auch "Privat nutzbare Unicodebereiche" nehmen (es sind drei Bereiche). ÅñŧóñŜûŝî (Ð) 16:11, 25. Aug. 2012 (CEST)

Mit "Privat nutzbare Unicodebereiche" kann ich leben, solange von der Begriffsklärungsseite PUA eine korrekte Weiterleitung besteht. Wegen übersetzbarer englischer Begriffe gibt es unterschiedliche Ansichten, siehe z. B. Diskussion:Asterism. -- Karl432 (Diskussion) 16:52, 25. Aug. 2012 (CEST)

Okay, dann verschieben wir nach Privat nutzbare Unicodebereiche. Du könntest im Artikel noch etwas dazu schreiben, warum das formal keine "Blöcke" sind. ÅñŧóñŜûŝî (Ð) 18:18, 25. Aug. 2012 (CEST)

«"Privat nutzbarer Bereich" ist zwar die beste bisher hier diskutierte Übersetzung, ist aber als Lemma ungeeignet, weil es außerhalb von Unicode alles mögliche bedeuten kann.» Mehrdeutigkeit ist bei Lemmas die Regel. Das ist aber kein Problem, da das Lemma nur das Mittel darstellt, den Artikel zu bezeichnen. Was das Lemma bedeutet, steht im Text. Gibt es denn einen privat nutzbaren Bereich, der nichts mit Unicode zu tun hat und der relevant für Wikipedia ist? Mir ist keiner bekannt. Solange das so bleibt, braucht es auch keinen Hinweis im Lemma, dass es im Artikel um Unicode geht, denn das steht ja eben im Artikel. «Außerdem sehen mir solche Begriffe nach einer Zwangseindeutschung für Anglizismenfeinde aus, ziemlich nahe an einer in der Wikipedia unerwünschten Begriffsetablierung.» Ich bin verwirrt. Du wolltest doch eine Übersetzung verwenden. «Ich sehe PUA für einen im Deutschen etablierten Begriff und bin deshalb nach wie vor für "PUA (Unicode)".» Bei PUA gibt es das Problem, dass es eine englische Abkürzung ist, und da Abkürzungen in Lemmas generell nicht verwendet werden (keine Ahnung, ob Konvention oder Richtlinie), sondern die ausgeschriebene Form, läuft das auf Private Use Area (Unicode) heraus, womit wir wieder gleich weit wie vorher wären. Begriffsetablierung mag unerwünscht sein, ist aber unvermeidlich, sobald etwas auf mehr als eine Art bezeichnet werden kann. Wikisteno (Diskussion) 00:40, 26. Aug. 2012 (CEST)

Solange es für Private Use Area keine weitere sinnvolle Verwendung als Artikelname gibt, ist der Klammerzusatz nicht angebracht. Die Namenskonventionen sind hier eindeutig. Antonsusis Verschiebevorschlag halte ich für den besten. --RonaldH (Diskussion) 00:48, 26. Aug. 2012 (CEST)

@Wikisteno: gemäß deinen ausführungen würde "Privat nutzbarer Bereich" ausreichen. Es tut aber nicht weh, wenn wir "Privat nutzbare Unicodebereiche" nehmen. 7 Buchstaben für eine genauere Bezeichnung sind nicht falsch. Ich verschiebe den Artikel daher nach Privat nutzbare Unicodebereiche. ÅñŧóñŜûŝî (Ð) 10:58, 26. Aug. 2012 (CEST)

Danke soweit. Ich habe gerade die Einleitung des verschobenen Artikels angepasst. Die versprochene Abarbeitung der Redundanz mit dem Abschnitt im Unicode-Artikel selbst mache ich in den nächsten Tagen, ich bin jetzt erstmal für einige Zeit offline. -- Karl432 (Diskussion) 14:23, 26. Aug. 2012 (CEST)

Wenn es keine deutsche Übersetzung gibt, dann gibt es nun mal keine deutsche Übersetzung und dann wird hier auch nicht eine erfunden. -- Fkljldska89zlakjsd (Diskussion) 20:43, 6. Sep. 2012 (CEST)

Stalking bleibt Stalking, auch wenn du hier so tust, als ob es dir um die Sache geht. Zur Sache: Selbstverständlich kann man sowas in jede andere Sprache übersetzen. Das ist keine TF sondern völlig normal. ÅñŧóñŜûŝî (Ð) 20:50, 6. Sep. 2012 (CEST)

Jaja, der Stalker beklagt sich über angebliches Stalking... Tatsache ist, dass Deine Edits keinen Bestand haben, weil sie nicht sinnvoll sind. Aber Dein Problem war ja schon immer, dass Du die eigene Inkompetenz zu erkennen nicht in der Lage bist.

Nicht dass Du einer Antwort auf der Sachebene wert wärst, aber: Begriffsfindung ist Begriffsfindung. Und das ist nicht normal. -- Fkljldska89zlakjsd (Diskussion) 20:57, 6. Sep. 2012 (CEST)

Begriffsfindung wäre es bei einer willkürlichen, anderen Bezeichnung. Eine Sprachlich korrekte Übersetzung ist keine Begriffsfindung. Aber es geht dir ja gar nicht um die Sache. ÅñŧóñŜûŝî (Ð) 21:08, 6. Sep. 2012 (CEST)

Du müsstest verstehen, was mit dem Wörtchen "Begriff" gemeint ist, um zu verstehen, was eine "Begriffsfindung" meint. Die Übersetzung ist beliebig und besonders gelungen ist sie auch nicht. -- Fkljldska89zlakjsd (Diskussion) 21:18, 6. Sep. 2012 (CEST)

Deine Vorgehensweise disqualifiziert dich mal wieder: Zwecks Stalking ein ganzes Portal überfahren und nach eigenem Gutdünken imperativ revertieren und als Alibi hier melden. Wenn es dir um die Sache ginge würdest du die Wortmeldungen anderer User hier abwarten. Das kommt dir aber nicht in den Sinn, denn du willst bestimmen, was gemacht wird. ÅñŧóñŜûŝî (Ð) 21:26, 6. Sep. 2012 (CEST)

Wenn Dir die Sachargumente ausehen, dann kannst Du das auch einfach so schreiben, Du brauchst nicht zu versuchen, diesen Umstand mit Deinen Küchen-Psychologisierungen zu cachieren. -- Fkljldska89zlakjsd (Diskussion) 21:33, 6. Sep. 2012 (CEST)

Mein Sachargument ist klar und eindeutig Ok. Bleibt also in der Sache nur noch dein Stalking übrig. ÅñŧóñŜûŝî (Ð) 21:36, 6. Sep. 2012 (CEST)

Name des Unicodeblocks "Raumeinnehmende, modifizierende Zeichen" (U+02B0…U+02FF)

Als deutsche Bezeichnung für den Unicodeblock "Spacing Modifier Letters" schlage ich "Unicodeblock Vorschubbehaftete modifizierende Buchstaben" statt "Unicodeblock Raumeinnehmende, modifizierende Zeichen" vor. "Spacing" bezieht sich in Unicode tatsächlich auf den horizontalen Vorschub (d.h. auf die Funktion der "Space"-Taste = Leertaste), und nicht auf irgendeinen Raum, den ein sichtbares Zeichen trivialerweise immer einnimmt. "Buchstabe" statt "Zeichen" ist ohnehin die treffendere Übersetzung für "letter", zumal die meisten Zeichen in diesem Block gemäß ihren Unicode-Properties tatsächlich Buchstaben sind. – Besteht Zustimmung zu einer entsprechenden Verschiebung? -- Karl432 (Diskussion) 11:42, 10. Sep. 2012 (CEST)

vorschubbehaftet? Klingt für meine Ohren merkwürdig. -- Liliana • 16:58, 10. Sep. 2012 (CEST)

Ist "Unicodeblock Freistehende modifizierende Buchstaben" eine Alternative? ("Spacing" bedeutet ja auch, dass diese Zeichen eben nicht als diakritisches Zeichen über oder unter einem anderen Buchstaben angeordnet werden.) -- Karl432 (Diskussion) 18:07, 10. Sep. 2012 (CEST)

Das klingt in der Tat besser. -- Liliana • 18:08, 10. Sep. 2012 (CEST)

Soll mir auch Recht sein. ÅñŧóñŜûŝî (Ð) 18:59, 11. Sep. 2012 (CEST)

Dann mache ich das mal. -- Karl432 (Diskussion) 00:35, 12. Sep. 2012 (CEST)

Hier gilt das selbe wie oben: keine Begriffsfindung bitte. Danke. -- L7kal0932jlaf4 (Diskussion) 21:36, 27. Sep. 2012 (CEST)

Warum nicht erstmal diskutieren, statt mit einem frisch angelegten Benutzernamen hereinzuplatzen und ein über Jahre gewachsenes System von Querverweisen ohne tiefere Sachkenntnis zu beschädigen? Der Benutzername "L7kal0932jlaf4" sieht auch nicht gerade nach der Absicht zu langfristiger kompetenter Mitarbeit aus. Ist das ein Wiedergänger des am 6.9. auf Dauer gesperrten Benutzers "Fkljldska89zlakjsd", der am einzigen Tag seiner Aktivität ähnlich gehandelt hatte (s.o. zu "privat nutzbare Unicodebereiche")? -- Karl432 (Diskussion) 21:46, 27. Sep. 2012 (CEST)

Worüber möchtest Du diskutieren? -- L7kal0932jlaf4 (Diskussion) 22:14, 27. Sep. 2012 (CEST)

gucharmap nennt den Block Nichtkombinierende Zusatzzeichen. --Schnark 10:27, 29. Sep. 2012 (CEST)

Liste der Unicode-Eigenschaften

Sowohl meine Kenntnisse bezüglich ostasiatischer Zeichen als auch meine Motivation auf langweilige Verlinkungsarbeit liegen irgendwo zwischen minimal und nicht vorhanden. Falls also irgendjemand noch etwas zum obigen Artikel beitragen kann und will, wäre ich ihm dankbar; und falls es jemand so langweilig ist, dass er den Artikel in den ANR verschiebt und von allen sinnvollen Stellen aus verlinkt, gleich doppelt. --Schnark 10:03, 13. Okt. 2012 (CEST)

Nachdem ich bemerkt habe, dass das eine Vorlage ist, ich also ziemlich viele Verlinkungen auf einen Schlag herstellen kann, habe ich einfach schon mal verschoben, Ergänzungen sind natürlich immer noch gern gesehen. --Schnark 09:56, 15. Okt. 2012 (CEST)

Ich schau mir das bei Gelegenheit mal an. -- Liliana • 00:37, 18. Okt. 2012 (CEST)

Verkehrs- und Kartensymbole

Was genau ist mit Artikel Unicodeblock_Verkehrs-_und_Kartensymbole, jedes Zeichen ist U+0020 (Leerzeichen), muss das so sein oder sollte man das wieder rückgängig machen? Happygimp0 (Diskussion) 20:33, 18. Okt. 2012 (CEST)

Hilfe was ist da passiert? Ich hab es rückgängig gemacht. -- Liliana • 20:35, 18. Okt. 2012 (CEST)

Die Tabelle war noch nicht an neuere Parameter angepasst. Jetzt erledigt. ÅñŧóñŜûŝî (Ð) 01:05, 19. Okt. 2012 (CEST)

In Unicodeblock Mathematische alphanumerische Symbole war es auch so, ich habe mal umgestellt, allerdings fehlt noch Kat und Bidi. Trägst du die nach? --Schnark 10:24, 19. Okt. 2012 (CEST)

Erledigt. ÅñŧóñŜûŝî (Ð) 23:51, 19. Okt. 2012 (CEST)

Ist die Verwendung von deutschen Namen für Unicodeblöcke usw. eine "Begriffsfindung"?

In den letzten Wochen kam es zweimal vor, dass sich ein frisch angemeldeter Benutzer (Benutzer:Fkljldska89zlakjsd bzw. Benutzer:L7kal0932jlaf4 – ob der zweite ein Wiedergänger des auf Dauer gesperrten ersten Benutzers ist, sei dahingestellt) hier ohne jede vorherige Ankündigung Umbenennungen von deutschen Lemmata in englische vorgenommen hat, obwohl genau die Begriffe hier eine vorangehende Konsensfindung hatten (siehe die beiden vorangehenden Abschnitte); mit der Begründing, die Verwendung deutscher Begriffe sei Begriffsfindung. – Nun finden sich auf Wikipedia:Keine Theoriefindung unter "Begriffsfindung" folgende Formulierung (Hervorhebungen von mir):

• "Bezeichnungen, die weder in der Fachwelt noch im allgemeinen Sprachgebrauch verbreitet sind, sollen weder als Lemma noch in Artikeln verwendet werden. Wann genau eine Bezeichnung als etabliert angesehen werden kann, muss im Einzelfall geprüft werden."

Demzufolge hat jemand wie Fkljldska89zlakjsd-L7kal0932jlaf4 zunächst darzulegen, dass ein von ihm als "Begriffsfindung" angesehener Begriff tatsächlich im Deutschen nicht etabliert ist, dass also praktisch jedermann die englische Originalbezeichnung verwendet. Nun ist es eine Eigenheit der hier diskutierten Begriffe (i.Ggs. z.B. zu "Internet"), dass sie ohnehin nur von sehr wenigen Leuten verwendet werden, sodass es sich kaum behaupten lässt, dass die Verwendung der englischen Fachbegriffe im Deutschen tatsächlich in einer Weise überragt, dass man einen Gegensatz "etabliert"/"nicht etabliert" feststellen kann. Im Gegenteil zeigt allein die Tatsache, dass die deutschen Begriffe jahrelang unter dem Blick der Fachleute (z.B. von mir als Mitglied des zuständigen DIN-Ausschusses und des Unicode-Komitees) unangefochten hier in der Wikipedia stehen, dass sie als etabliert ansehbar sind. -- Karl432 (Diskussion) 23:45, 27. Sep. 2012 (CEST)

Hinter den Benutzernamen steckt der gesperrte Benutzer:Tacuisses. Normalerweise gibt er seine teilweise zweifelhaften Edits im Bereich Astronomie zum "Besten" Zu seinen Aktivitäten gehört aber auch ein gegen mich gerichtetes Stalking. Deshalb wandert er quer über die Themengebiete hinweg hinter mir her und revertiert meine Edits mit z. T. sehr fadenscheinigen Begründungen. So dient seine Behauptung, dass es hier um Begriffsfindungen geht, in erser Linie dem Zweck, meine Mitarbeit hier zu stören. Es ist kein Zufall sondern Systhem, dass er immer die Gegenmeinung zu mir vertritt: Ich habe den dt. Lemmata zugestimmt, also ist er dagegen. Es geht ihm um Stalking, nicht um die Sache. ÅñŧóñŜûŝî (Ð) 01:14, 28. Sep. 2012 (CEST)

Blühender Unsinn ist und bleibt der Zirkelschluß, dass freihändige Eindeutschungen deshalb korrekt und "etabliert" seien, weil sie hier irgendwann von irgendjemandem einfach so eingeführt wurden. 

Das ist natürlich blühender Unsinn. Ich bitte um einen unabhängigen Beleg, daß diese freihändigen Übersetzungen in der Welt da draußen überhaupt existieren und gebräuchlich sind. Ansonsten bleibt nur die Verschiebung auf die Originalbezeichnungen.--Martin Taschenbier 08:45, 28. Sep. 2012 (CEST)

Was bitte ist Unsinn? Unicodeblöcke haben das Problem, dass ihre Namen "in der Welt da draußen" fast überhaupt nicht verwendet werden. Was die Allgemeinheit interessiert, sind die Unicode-Zeichen selbst; die Unicode-Blöcke sind (außer für Leute, die Codierungsanträge verfassen) nur ein Notbehelf zu Gruppierung nach formalen Kriterien (so lange hier nicht nach inhaltlichen Kriterien wie Sortierung nach ISO 14651 oder Berücksichtigung diverser formaler "properties" der Zeichen gruppiert wird). Die Verwendung angemessener deutscher Übersetzungen ist in der Wikipedia durch jahrelangen Gebrauch etablitert – und weil die Wikipedia vermutlich der einzige deutschsprachige Ort ist, an dem Unicodeblock-Namen wirklich regelmäßig verwendet werden, damit auch in der deutschen Sprache. – Dies ist natürlich ein Standpunkt, der diskutiert werden kann, und der richtige Ort für solche Diskussionen ist genau hier. Ich bitte Martin Taschenbier (und, falls zur Diskussion fähig, Benutzer:L7kal0932jlaf4 – inzwischen ist auch dieser Name wegen Sperrumgehung unbefristet gesperrt), hier ihren Standpunkt sachlich und freundlich darzulegen und Verschiebungsaktionen aller Art erst dann durchzuführen, wenn hier Konsens ist. Wenn es ein Meinungsbild o.ä. gibt, ist es durchaus möglich, dass ich für eine Umbenennung auf die englischen Begriffe stimme (s.o. meine zuerst vertretene Ansicht im vorletzten Abschnitt), aber im Moment sollte erst die Überrumpelung durch Benutzer:L7kal0932jlaf4 zurückgenommen, dann diskutiert, und erst nach Erreichen eines Konsens ggf. gehandelt werden. -- Karl432 (Diskussion) 18:17, 28. Sep. 2012 (CEST)

Er wird das Revert seiner Überrumpelung nicht akzeptieren und notfalls EWs führen. Da er sowieso gesperrt ist und andere hier nicht, sitzt er da solange am längeren Hebel, wie die Seiten nicht vollgesperrt sind und die seitensperrende Admins konsequent die Version, welche nicht von Tacuisses sind, einfriert (zumindest außerhalb der Astronomie). ÅñŧóñŜûŝî (Ð) 20:33, 28. Sep. 2012 (CEST)

Blühender Unsinn ist und bleibt der Zirkelschluß, dass freihändige Eindeutschungen deshalb korrekt und "etabliert" seien, weil sie hier irgendwann von irgendjemandem einfach so eingeführt wurden. 

Es ist überhaupt nichts Besonders, dass es für bestimmte Tatbestände oder "Orchideenthemen" keine deutschen Bezeichnungen gibt. So macht sich hier z.B. niemand einen Kopf, einen Artikel Département Moselle -und eben gerade nicht Provinz Mosel- zu nennen. Ich vermag hier nichts zu erkennen, was diesbezüglich eine Ausnahme rechtfertigen würde und wiederhole folglich meine Bitte, unabhängige Belege für irgendwelche deutschsprachigen Bezeichnungen beizubringen. Wo das nicht möglich ist, verbleibt aufgrund der bekannten Prinzipien nur die Verwendung der Originalbezeichnungen. --Martin Taschenbier 22:38, 28. Sep. 2012 (CEST)

PS: Angefragt auf WD:NK#Freihändige Eindeutschungen --Martin Taschenbier 23:02, 28. Sep. 2012 (CEST)

Département Moselle ist ein geogr. Eigenname, und keine allgemeine Bezeichnung. Der Vergleich hinkt gewaltig. ÅñŧóñŜûŝî (Ð) 00:22, 29. Sep. 2012 (CEST)

• Séquentiel couleur à mémoire - Sequenzielle Farbe mit Speicher
• Extended Binary Coded Decimals Interchange Code - erweiterter Austauschcode für binär kodierte Dezimalziffern
• Armenian Standard Code for Information Interchange - Armenischer Standardcode für Informationsaustausch
• ... usw. usf. ...

--Martin Taschenbier 08:58, 29. Sep. 2012 (CEST)

Das sind einfach ausgeschriebene Akronyme - SECAM, EBCDIC und ASCII. -- Liliana • 10:30, 29. Sep. 2012 (CEST)

@Martin Taschenbier: Deine dreiste Revertieraktion ist alles andere als anständig. Du musst Tacuisses nicht nacheifern. ÅñŧóñŜûŝî (Ð) 20:20, 2. Okt. 2012 (CEST)

@Martin Taschenbier (und alle anderen Befürworter von „Unicodeblock Spacing Modifying Letters“): Gibt es irgendeinen Beleg dafür, dass es sich bei dieser Bezeichnung nicht um Theorieetablierung handelt? Der englische Begriff ist Unicode block Spacing Modifying Letters (mit Leerzeichen, oder auch nur Spacing Modifying Letters), während Unicodeblock und Unicode-Block deutsche Wörter sind. „Unicodeblock Spacing Modifying Letters“ suggeriert damit, dass der Block im Deutschen (!) mit seinem englischen Namen bezeichnet wird. Das ist aber meiner Beobachtung nach nicht der Fall, siehe mein Kommentar zu gucharmap weiter oben; auch die mit Windows mitgelieferte Zeichentabelle benennt alle Unicodeblöcke, die sie kennt, deutsch. Eine Googlesuche nach "Unicodeblock Spacing Modifying Letters" findet sehr effektiv Wikipedia-Klone, und sonst eben nichts (außer dem Java-CamelCasing UnicodeBlock). Bei „Unicodeblock Spacing Modifying Letters“ handelt es sich also genausosehr um Theorieetablierung wie bei deutschen Bezeichnungen. --Schnark 09:37, 3. Okt. 2012 (CEST)

die frage ist seinerzeit geklärt worden, unicode.org selbst verlinkte die de:WP als deutsche quelle, wir haben sogar die allerhöchsthoheitliche sondergenehmigung & sanktus, einzudeutschen ;) - war damals ein absolutes neuland und einer der ersten großen etappen der anerkennung der WP in der fachwelt (ich hab aber vergessen, wo das diskutiert wurde) - wie es heute ist, weiß ich auch nicht genau, da die unicode-org zunehmend auch auf wikiartige systeme & forumsdiskussion in der internationalisierung der benamsung setzen, sie uns also vielleicht wieder ausgekoppelt haben: ich finde den link auf die de:WP nämlich auf die schnelle nicht mehr, er stand aber recht prominent --W!B: (Diskussion) 05:34, 25. Okt. 2012 (CEST)

Natürlich darf man Eindeutschen. Es gibt ja sogar für geogr. Eigennamen Bezeichner in anderen Sprachen. (dt: München - engl. Munich; dt. Trier - franz. Trèves;Cz.: Cheb, dt.: Eger; it. Roma, dt. Rom u.v.a). Die sind auch alle zulässig, obwohl nur die Bezeichnung in einer am Ort geltenden Amtssprache "formal richtig" ist. Wen es also für geogr. Eigennamen Übersetzungen gibt, dann darf man erst Recht auch Bezeichner von Unicodeblöcken übersetzen. Wichtig ist nur, dass ein dt. Bezeichner eine wahre Aussage über den Block enthält, und da sind wir teilweise sogar besser als das Original. ÅñŧóñŜûŝî (Ð) 19:48, 26. Okt. 2012 (CEST)

aber so ein blödsinn, ortsnamen sind durch hochkarätigste quellen belegt: nix darf man eindeutschen, ohne quelle, wenn Du das noch nicht gecheckt hast, bist Du schlicht im falschen projekt.

ausser unicode, das darf man eindeutschen, solange sie uns das genehmigen --W!B: (Diskussion) 11:36, 28. Okt. 2012 (CET)

Also zum einen ist die Feststellung richtig, dass es auf der Welt viele Sprachen gibt, nicht nur Englisch (hoppla, jetzt müsste ich English sagen). Der Begriff Theoriefindung ist möglicherweise selbst ein Konstrukt, dass ausserhalb der Wikipedia gar nicht zu finden ist. Auf jeden Fall sollte man Begriffe und Theorien unterscheiden können... denn das hilft schon mal weiter. – Simplicius Hi… ho… Diderot! 12:32, 28. Okt. 2012 (CET)

@W!B: Alles darf man eindeutschen, solange es sinnvoll ist. Das ergibt sich schon aus der Autorenfreiheit. Die Frage lautet daher, ob es sinnvoll ist. Das z. B. der Fall, wenn es - wie bei den geogr. Namen der Fall - bereits seit langem festgelegte Übersetzungen gibt. Ich bezweifle, dass irgendeine it. Behörde mal eine "Genehmigung" erteilt hat, die it. Hauptstadt in dt. Sprache "Rom" und nicht "Roma" zu nennen. Es bedarf also keiner Genehmigung, Eigennamen zu übersetzen. Das gilt auch für das Übersetzen der Namen von Unicodeblöcken. Das es vom Konsortium Zustimmung gibt, ist hier natürlich ein besonderes zusätzliches Argument für die Richtigkeit und die Sinnhaftigkeit der Übersetzung. Spätestens durch diese Zustimmung ist eine Übersetzung legitim.

@Simplicius: Das sehe ich ähnlich. Der Begriff "Theoriefindung" ist gewiss eine Theoriefindung der Wikipedia ... Fast jeder Artikel ist nach den hier üblichen Vorstellungen von "Theoriefindung" eine solche, denn allein schon die etwas andere Zusammenstellung und Darstellung verändert das vorhandenene Wissen, da hier nicht einfach nur eine Summe, sondern auch eine Interpretation entsteht. Hier in unserem Fall geht es sogar um nichts anderes als eine einfache Sprachübersetzung. Jede WP hat das Recht, alle Blockbezeichner sinnwahrend in die eigene Sprache zu übersetzen.

Es gibt auch einen weiteren Aspekt: Das Lemma Private Use Area ist überhaupt kein Blockname, sondern ein Sammelbegriff für drei Blöcke. Damit ist es überhaupt kein Bestandteil der vom Konsortium vorgenommenen Standards und damit garantiert zu 100% übersetzbar. ÅñŧóñŜûŝî (Ð) 13:31, 28. Okt. 2012 (CET)

ÅñŧóñŜûŝî, Dein unwissen um die arbeit in der WP schockiert mich wirklich ein bisserl. Die Behörden, der Ständiger Ausschuss für geographische Namen, die Eu, die UNESCO, und ähnliche kommisionen, sagen, ob „Roma“ deutsch „Rom“ heisst oder nicht, und zwar (zumindest für uns) 99,999738 % verbindlich: es wird zeit, dass Du Dich wieder mal etwas in der WP umschaust, was 2012 sache ist

und die richtlinie WP:TF hier mit windigigen argumenten in frage zu stellen, um andere windige argumente zum thema zu stützen, ist nicht der rechte platz, wenn ihr mit WP:TF nicht leben könnt: löschantrag stellen, die krot fressen, oder anderes hobby suchen, so einfach ist das

es ärgert mich nämlich, dass Du die arbeit dieses projekts hier diskreditierst, in dem Du sie mit den falschen, unrichtigen und untauglichen argumenten zu rechtfertigtigen versuchst: nochmal, es gibt nur einen grund, warum man hier eindeutschen darf, und der ist, das die 1a-top-quelle zum thema es genehmigt (hat)

sollte unicode.org eine standardisierte deutsche bezeichnung publizieren, ist unsere, wenn sie anders ist, übrigens die erste, die rausfliegt, und zwar ersatzlos. egal, ob man dann schon mit zig1000enden WP-klonen und -abschreibern belegen könnte, dass der name "etabliert" sei. ist er nicht, er ist schlicht ein fehler eines wikifanten, und einer menge von leuten draussen, die sich gutgläubig auf einen wikifanten verlassen haben, sonst gar nix: wurde seinerzeit, soweit ich mich erinnern kann, so beschlossen (ich weiß aber nicht mehr wo), und daran ändert sich nix, ob es ein paar dutzend oder 1000ende lemmata sind --W!B: (Diskussion) 20:56, 28. Okt. 2012 (CET)

Unicodeblock Vereinheitlichte CJK-Ideogramme, Erweiterung D

In der Einleitung zu dem Artikel heißt es:

Der Unicodeblock Vereinheitlichte CJK-Ideogramme, Erweiterung D [...] kodiert 222 chinesische Schriftzeichen, die aus Dringlichkeitsgründen bereits jetzt kodiert wurden.

Was soll das bedeuten? --Babel fish (Diskussion) 17:35, 24. Nov. 2012 (CET)

Ja, eigentlich hätten die Zeichen warten müssen, bis sie zusammen mit einer anderen, großen Gruppe von chinesischen Schriftzeichen Eingang in den Standard finden (ist bis heute noch nicht passiert, kann noch einige Jahre dauern). Man fand diese aber für besonders dringend, weil sie jetzt gerade verwendet werden. Das Zeichen 𫟼 z. B. ist der Name des chemischen Elements Darmstadtium, da kann man nicht ein paar Jahre warten, weil chinesische Chemiker das Zeichen jetzt schon benötigen. -- Liliana • 18:20, 24. Nov. 2012 (CET)

Unicode Character 'THREE LINES CONVERGING LEFT' (U+269F)

U+269F ⚟

Die angebotene Abbildung ist unlesbar, die folgende auch, es gibt doch brauchbare, z.B. die bei FileFormatInfo oder bei Unicode direkt. Benhomo (Diskussion) 20:58, 25. Aug. 2012 (CEST)

Dann hast du wohl keinen guten Font dafür. Ich habe eine gute Darstellung vor Augen. Probiere es mal mit Quivira oder Symbola. ÅñŧóñŜûŝî (Ð) 20:57, 19. Jun. 2013 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 12:19, 19. Jul. 2013 (CEST)

Unicodeblock Phonetische Erweiterungen

Wie kann man nur in der Wikipedia für die Wiedergabe eines Buchstabens eine Schriftart wählen, die genau die Charakteristika des Unicode-Terminus nicht zeigt? Das Beispiel: U+1D11 (Phonet. Zeichen, ein auf der Seite liegendes o, angezeigt mit einem völlig runden o, wird also auch für Phonetiker und Typographen unerkennbar und damit sinnlos). Ich möchte da nicht selbst eingreifen, wahrscheinlich gibt es in der Wikipedia weitere Beispiele (ich kenne Typographie-Magazine, die als Brotschrift eine serifenlosen Schriftart verwendeten, so dass etwa etwa eine Abkürzung für Illustrator (Ill.) zu (|||.) wird. Benhomo (Diskussion) 20:02, 25. Aug. 2012 (CEST)

Du kannst auf deinem Betriebssystem eine Schriftart installieren, welche diese Zeichen in guter Qualität enthalten. Ich persönlich empfehle Quivira (Serifenschrift). Anschließend öffnest du die Seite Benutzer:Benhomo/common.css und schreibst dort in eine Zeile:

span.IPA {font-family:Quivira;}

Abspeichern und den Cache des Browsers leeren. Anschließend sind zumindest alle mit der Vorlage:IPA dargestellten Lautschrifttexte in Quivira dargestellt.

ÅñŧóñŜûŝî (Ð) 12:43, 19. Jul. 2013 (CEST)

Artikelbeginn

Irgendwo im Archiv steckt mein Beitrag von vor 100 Jahren zur einheitlichen Gestaltung der Artikeleinleitung. Nun habe ich beispielhaft den neuen Unicode-Block Spielkarten erstellt, in dem (wie in Unicode-Block Tai-Xuan-Jing-Symbole) folgendes realisiert ist

1. der Artikelname ist in Fettschrift wiedergegeben
2. der originalsprachige Blockname steht vor der geklammerten Übersetzung - nicht-fett weil das nicht zum Artikelnamen gehört
   zu diskutieren wäre die Kursivschreibung, ev. mit {{Lang|en|...}}
3. das 2. Wort "Unicode" verlinkt auf Unicode
4. das 2. Wort "Block" verlinkt auf Liste der Unicode-Blöcke
5. der Codepoint-Bereich ist ebenfalls geklammert, die beiden Klammerausdrücke direkt nebeneinander erscheinen mir suboptimal. Da fehlt noch eine zündende Idee, vielleicht findet der Vorschlag in Math Ops mehr Zustimmung.
6. Codepointbereich mit Bis-Strich "–" (U+2013) angegeben

Wenn für diese Gestaltung allgemeines Einverständnis hergestellt ist, könnte ein BOT über die ~205 Blöcke gejagt werden - wenn das für einen BOT zu schwierig sein sollte müssten die Artikel manuell vereinheitlicht werden. -- sarang♥사랑 14:19, 13. Jan. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 21:40, 28. Jun. 2014 (CEST)

/* Eingabemethoden */ Auskommentiert: Falsche Verwendung des Begriffs 'Zwiebelfisch'.

Der Begriff Zwiebelfisch ist ausschließlich im Buchdruck mit Handsatz möglich: Im fertigen Satz befindet sich versehentlich eine Letter (oder mehrere) aus einer anderen Schriftart, die in den aktuell genutzten Letternsatz (Setzkasten) aus aufgelösten Kolumnen falsch abgelegt wurde (siehe auch den Artikel Zwiebelfisch). Darüber hinaus war es und ist es auch heute noch durchaus üblich fremdsprachige Textstellen (wie im erwähnten Beispiel mit dem griechischem Wort) kursiv oder sogar in einer anderen Schriftart zu setzen, insbesondere dann, wenn der Text, wie im Beispiel genannt, ganz andere Schriftzeichen enthält, die im aktuell verwendeten (lateinischen) Schriftschnitt nicht vorhanden sind.
Ich habe deshalb den entsprechenden Textteil im Abschnitt Eingabemethoden auskommentiert und werde, wenn sich kein Widerspruch erhebt oder eine andere Formulierung eingefügt wird, diesen nach einiger Zeit ganz löschen.--Jochen (Diskussion) 11:10, 24. Mär. 2012 (CET)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 21:40, 28. Jun. 2014 (CEST)

Unicode in Japan

Ich habe aus dem Unicode-Artikel die folgende Passage entfernt: "Vor allem in Japan konnte sich Unicode kaum durchsetzen – dies liegt einerseits daran, dass Unicode aufgrund seines Ursprungs als Konsortium amerikanischer Unternehmen ein niederes Image hat". Als Quelle war ein Text aus dem Jahr 2006 angegeben, der unter anderem folgende Aussage enthält: "Modern software based on Windows, Java or XML will usually be using Unicode as UTF-8 or UTF-16, and in practise a high proportion of Japanese text is handled in Unicode already simply because it is handled on Windows.". Die Passage aus dem WP-Artikel ist daher meiner Ansicht nach eindeutig zu hart formuliert. Yaan (Diskussion) 23:54, 31. Mär. 2012 (CEST)

Danke. --RonaldH (Diskussion) 12:05, 28. Jun. 2014 (CEST)

Archivierung dieses Abschnittes wurde gewünscht von: ÅñŧóñŜûŝî (Ð) 21:40, 28. Jun. 2014 (CEST)