Jump to content

User talk:ChristTrekker/UnicodeSymbol

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
This is an old revision of this page, as edited by DePiep (talk | contribs) at 17:01, 12 December 2012 (re by request). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.
(diff) ← Previous revision | Latest revision (diff) | Newer revision → (diff)

My comments

Allow me to write in telegraph style.

  • Concept: good plan to use specialised font selections per Unicode character group (whichever group that is). Good to aim for a single complete template that covers all.
Commons.css encoders (those who have to enter and maintain the font set per class) might not be happy with:
-Non-stable groups, class-names and asp font-sets. IOW: they should work well in most/all of the browsers, they should not change too often (any more), and they shouolld not be too many especially if they can be correctly grouped (e.g., when some different groups can share a font set). Also the number of classes can become an issue (it could grow to 100 or 200).
  • User input (editors input): use #switch to its best: it allows many inputs. Still ambiguous input should give a warning.
  • Class naming: I suggest to use all lc and use underscore "_" to suggest a space character. So that would be "unicode_emoticon" not "UnicodeEmoticon". I think the prefix "unicode_" is fine, maybe a shorter one can be found.
-When it applies, use the proper formal Unicode block name or the Unicode script name or via. These are well defined. If there is such a name, there is no need to introduce a new name.
-If block or script name does not covert the characger set ("card suits" "ipa"), first look if Unicode does use a subsection title in a block. ""card suits" is not a block name, but is is a section title in b;lock "Miscellaneous symbols" [1]. So then namme the class "unicode_card_suits".
-If that not covers it, find a good short descriptive name. (I wouldn't use abbreviations like "PoliReli" or "poli_reli"). Remember you have to convince high level editors who do not like more jargon.
  • The process of introducing the classes. Now this is a more difficult part. It is nigh impossible to get the font set right first time, let alone for 100 or 200 classes. Unless you found a commons.css editor who will enter you first proposal of ~100 classes with preferred font sets ;-). I suggest you contact the class editors by now, ask what and what not they can implement.
-My appproach was (at least, in theory) is to first use subtemplates per fontset (your class name) that has the fonts written down. Using <span style="font-family:...>" (minor start in {{script}}, with Cyrl example). These can be edited, tested, and when stable turned into a class. One by one.
  • Another thought: naming the classes is overseeable. Another issue can arise when character sets are to be combined (into one class). We definitely do not want knots in the future. I have no solution for this.
  • Of course the class should have the fallback font(s) too, and maybe somne generic ones like for diacritics ("common script").
  • Question for commons.css editors (maybe you are): how does the "lang" affect this? I have the impression that browsers (HTML, CSS) try to wringe a font (-family) out of a language. That would turn the table upside down.
That's all ;-) Have a nice edit. -DePiep (talk) 17:01, 12 December 2012 (UTC)[reply]