Could you make another Han-Nom svg: 𫆡 (U+2B1A1). I know Babelstone doesn't believe in making images for encoded characters. But very few readers can view Extension C characters otherwise. Not only that, but I can't use vi-nom on the Vietnamese Wiki. Kauffner (talk) 11:18, 16 December 2013 (UTC)[reply]
File name is “Nom Character U+2B1A1.svg” 1. When writing articles on simple.WP, imagine you are explaining the world to a young child. — 2. The ideographic description of 爸 is ⿱父巴 (top to bottom), not ⿰父巴 (left to right). —LiliCharlie (talk) 20:40, 16 December 2013 (UTC)[reply]
Could you make the change yourself? The edit history would look better if more than one person was involved. I noticed that càng (U+2B2D9), giàu (V04-405E) and béo (V+604ea) are in en:Chữ nôm. I checked several Nôm dictionaries, including Truong and Le's 19,000-character doorstop. But I didn't find any of these characters. So I don't think they should be presented as Nôm characters. They could be the equivalent of typos that somebody found in a manuscript. On another issue, do you think it would be a good idea to put vi-nom on Vietnamese Wiki? Kauffner (talk) 02:52, 17 December 2013 (UTC)[reply]
U+2A74C (𪝌) is supposed to look like ⿰亻𤰻. Or so says the Nom Foundation and the Chinese Text Project. Check out Fileformat, which gives me different results depending on what browser and system I use. Any idea what the problem is? Note that VNPF gives the radical/stroke count as 9.9, while Unihan and CTP give 9.10. I assume this character is a manuscript variant of 備. Kauffner (talk) 18:27, 4 January 2014 (UTC)[reply]
File name is “Nom Character U+2A74C.svg”
1. On my system all browsers except IE show the same character shape on the Fileformat page. I tested Firefox, Opera, IE and Crome. IE didn’t show any character.
2. The sources all say 𪝌 is radical 人/亻+ 9 strokes. (On the Unihan page look for the box with data type kRSUnicode.)
3. Ideographic description of 𪝌 as ⿰亻𤰻 is clearly correct.
4. Judging from the Vietnamese readings given by the Nom Foundation 𪝌 should be some variant of 備 (=⿰亻𤰇) in Vietnamese, at least in certain words and phrases. Note however that this Unicode character also has a T-source, and whatever 𪝌 is used for in Taiwan it need not be a variant of the common character 備 there. LiliCharlie (talk) 20:13, 4 January 2014 (UTC)[reply]
P.S.: The font HAN NOM B has the wrong character encoded at u+2A74C; it shows ⿰木汁 instead of ⿰亻𤰻. Care should be taken to use the template {{Vi-nom-CJK-C-D}} instead of {{Vi-nom}} for characters of extensions C and D, because they differ in the fonts listed in their source code. LiliCharlie (talk) 22:56, 4 January 2014 (UTC)[reply]
So ⿰木汁 must be some PUA character floating around in HAN NOM B, encoded before Extension C existed. I wonder what it is. I put the svg you made into simple:Sino-Vietnamese characters. The bottom line seems to be that Extension C is still not ready for prime time. Kauffner (talk) 02:36, 5 January 2014 (UTC)[reply]
As a font designer I contest the claim that all representations of Unicode characters are per se in the public domain. The glyphs of my typefaces aren’t. Please allow me to continue selling the fonts I designed and revert your edits. LiliCharlie (talk) 13:02, 16 February 2014 (UTC)[reply]
Of course, if its your development, and a font designed by you, the license belongs to you; please forget my suggestion.
Another thing is the categorization of the radicals, not only to your font, but additional to all the single radical categories. This should be done for all glyphs representing a radical or a variation of it. sarang♥사랑08:06, 18 February 2014 (UTC)[reply]
I noticed this when I was checking this page before unwatching it. FYI, the tag in question would be for bitmap versions of glyphs, not SVGs. Bitmap representations of fonts cannot be copyrighted in the U.S., but vector versions can be. The difference is that one is just an image, while the other are the actual programmatic instructions on how to make the font. The program is copyrightable; the actual typeface is not. That said, typefaces are patentable, so if you are worried about the ability to sell your fonts, you might want to consider doing that. Trlkly (talk) 22:33, 9 June 2014 (UTC)[reply]
2012 Picture of the Year: A pair of European Bee-eaters in Ariège, France.
Dear Wikimedians,
Wikimedia Commons is happy to announce that the second round of the 2013 Picture of the Year competition is now open. This year will be the eighth edition of the annual Wikimedia Commons photo competition, which recognizes exceptional contributions by users on Wikimedia Commons. Wikimedia users are invited to vote for their favorite images featured on Commons during the last year (2013) to produce a single Picture of the Year.
Hundreds of images that have been rated Featured Pictures by the international Wikimedia Commons community in the past year were entered in this competition. These images include professional animal and plant shots, breathtaking panoramas and skylines, restorations of historical images, photographs portraying the world's best architecture, impressive human portraits, and so much more.
There are two total rounds of voting. In the first round, you voted for as many images as you liked. The top 30 overall and the most popular image in each category have continued to the final. In the final round, you may vote for just one image to become the Picture of the Year.
This is just an illustration of how the terms are written using Nôm characters (with corresponding Quốc ngữ). An explanation of the terminology should be given in the Wiki projects that use this image. At this point the German, English, Spanish, French, Italian, Japanese, Dutch and Portuguese Wikipedias use it, and if I modify its contents these articles will need modification without their authors knowing that it does – there would be no warning, as no edits are made to the articles themselves. This doesn’t seem a good idea, does it? LiliCharlie (talk) 03:36, 25 February 2014 (UTC)[reply]
What I uploaded is community-owned, not my private property, and I am not a Nôm expert either. Being part of our community you are invited to edit this explanation in any way that helps users understand what is shown. Of course you can also add explanations in other languages if you like. If the words in different languages do not exactly match it doesn’t really matter; someone can improve some particular translations later. Thanks for your interest, BTW. LiliCharlie (talk) 10:26, 25 February 2014 (UTC)[reply]
The 2013 Picture of the Year competition has ended and we are pleased to announce the results:
We shattered participation records this year — more people voted in Picture of the Year 2013 than ever before. In both rounds, 4070 different people voted for their favorite images. Additionally, there were more image candidates (featured pictures) in the contest than ever before (962 images total).
In the first round, 2852 people voted for all 962 files
In the second round, 2919 people voted for the 50 finalists (the top 30 overall and top 2 in each category)
We congratulate the winners of the contest and thank them for creating these beautiful images and sharing them as freely licensed content:
We also sincerely thank to all 4070 voters for participating and we hope you will return for next year's contest in early 2015. We invite you to continue to participate in the Commons community by sharing your work.
Thanks, the Picture of the Year committee
You are receiving this message because you voted in the 2013 Picture of the Year contest.
A little too many pictures on your user page I think. It crashed my Chrome and froze Firefox for about 20 or 30 seconds. Safari seems to have no trouble with it though -- well done Safari! — Lfdder (talk) 13:21, 27 March 2014 (UTC)[reply]
I wasn’t aware that my user page caused such trouble. It has grown too long anyway, and I will split it into several sub-pages some day soon. Thanks for your hint. LiliCharlie (talk) 13:32, 27 March 2014 (UTC)[reply]
Hi, you created a lot of fine SVG pics, e.g. the Kangxi and the Shuowen. I assume that you used a tool, like Inkscape+Scour, or something else, but I cannot find out. Would you mind to tell me? sarang♥사랑07:35, 14 April 2014 (UTC)[reply]
I usually use (a developer version of) Inkscape, but I also frequently edit my SVGs in a text editor. Notepad++ allows bulk replacements for hundreds of files. — Und gerade habe ich bei einem Blick zwei Zeilen nach oben festgestellt, dass du ja auf eine Benutzerseite von de.WP linkst, wo steht, dass deine Muttersprache Deutsch ist. Die haben wir gemein. Greetings from Cologne, LiliCharlie (talk) 09:54, 14 April 2014 (UTC)[reply]
Diese Entwicklerversion scheint recht effizienten, fast redundanzfreien Code zu erzeugen, oder musst du nachträglich noch den Code glätten?
Ich denke die Kombination Inkscape plus Notepad++ ist optimal für SVG-Code.
Ich verwende schon lange Notepad++ aber längst noch nicht alles was dieser Editor kann. Mir macht er noch Probleme weil ich ihm einfach nicht verklickern kann dass er exotischere Fonts akzeptiert, er kennt diese Zeichen nicht und macht draus "?". Wahrscheinlich geht das ganz einfach zu vereinbaren wenn man weiss wie. Gruss an den Rhein! sarang♥사랑12:07, 14 April 2014 (UTC)[reply]
Mit Inkscape speichere ich hochzuladende Grafiken nicht als Inkscape SVG (*.svg) sondern als Optimised SVG (*.svg) und schmeiße da alle von mir nicht gewünschten Informationen raus. Später entferne ich noch die wenigen verbliebenen überflüssigen Informationen mit Notepad++, in der Regel gleich für viele SGVs auf einen Schlag, was perfekt geht, da in allen genau derselbe Ballast verblieben ist.
Das mit den Fragezeichen in Notepad++ hört sich für mich so an, dass nicht der richtige Zeichensatz gewählt wurde (Menü: Encoding/Kodierung). Ist die Datei z. B. für den „ANSI“-Zeichensatz (d. h. ISO 8859-1) kodiert, so können auch keine exotischen, nicht in ISO 8859-1 vorhandenen Zeichen angezeigt oder gespeichert werden. — Meine Standard-Kodierung für neue Dateien ist UTF-8 (eine Kodierung des internationalen Unicode-Zeichensatzes) mit einem BOM, das Programmen, die die Datei öffnen, die Kodierung verrät (Menü: Settings/Einstellungen → Preferences/Optionen → New Document/Neue Dateien → UTF-8). — Bildschirm-Schriftarten werden über Settings/Einstellungen → Style Configurator/Stile eingestellt, aber das dürfte dein Problem nicht lösen, da bei im gewählten Font fehlenden Zeichen keine Fragezeichen dargestellt werden sollten, sondern Zeichen aus einem Font, den das Betriebssystem aufgrund der verfügbaren PANOSE-Informationen (oder wenn vorhanden der Schriftenersetzungs-Einträge in der Registry) auswählt. — Entschuldige diese ziemlich technischen Betrachtungen mit ebensolchen Links; im Endeffekt gilt aber: Probieren geht über studieren. Ganz liebe Grüße zurück ins Schwabenland, LiliCharlie (talk) 05:07, 15 April 2014 (UTC)[reply]
Danke für den Expertenrat! Ich werde es demnächst versuchen, du lieferst mir ja ein sehr brauchbares Rezept. Das meiste ist mir bekannt, aber in Bezug auf Notepad habe ich die Anwendung zur Änderung der Grundeinstellungen nicht gleich hinbekommen und es dann gelassen. Nun werde ich sehen das richtig zu machen. Gruss sarang♥사랑16:06, 15 April 2014 (UTC)[reply]
While I really think your Welcome images are awesome, they would be even better if you would not convert the text to path. As you can see, at least one of your images is listed at .
I realize that finding the fonts so you can test them on your system can be difficult. But if you'll use Arial, it will usually work out, even if the image will look a little different. (The Arial will be replaced with Liberation Sans.)
You don't have to use text for the the non-alphabetic ones if they cause you problems (Like Chinese or sign language). But text would be a lot better for all the rest. Cheers. Trlkly (talk) 08:53, 15 April 2014 (UTC)[reply]
I don’t consider these images to convey a purely textual message, as in a map or a statistician’s chart. Rather I have chosen fonts that convey a warm, welcoming sentiment. Both Arial and Liberation Sans are far too matter-of-fact and spoil the message. It is best to regard the images as pieces of art that shouldn’t be forged.
On the other hand I understand the advantages of embedded text. (Cf. what I wrote 2½ weeks ago on this talk page.) All I can offer at this point is uploading additional versions in PDF format, with embedded text and a much reduced file size — for all practical purposes the only drawback is the background isn’t transparent. How about that? LiliCharlie (talk) 03:39, 17 April 2014 (UTC)[reply]
Unfortunately, a PDF with embedded fonts would probably still be a problem, as only free fonts can be uploaded here for copyright reasons, and at least some of your fonts don't seem to be free (as in liberty--e.g. open source). If you can't find a suitable font in the list of Wikimedia's fonts, the usual workaround is a bit more complicated.
What you do is duplicate every text object. You leave one as text, but convert the other to path. Then you hide all the text elements. Yes, the file is still large, but that's not the point of including text. You include it so it's easy for others to modify and make their own stuff. That's part of the point of Wikimedia commons. We host images that you are free to do whatever you want with.
If the actual text is hidden, it won't matter if it says to use a font that Wikimedia doesn't have. But it allows the actual text to be available in the file for easy modification. Trlkly (talk) 07:10, 20 April 2014 (UTC)[reply]
I have already uploaded PDF versions of these images. They are text versions with embedded font (the default for PDF), so it is possible to copy text from them, or edit it. Unfortunately the MediaWiki software renders PDFs rather poorly, but I hope it will be replaced by better rendering software before long.
I’ve never produced an SVG that has the same information as both path and text. Do you mean I should include the text elements in a comment (between <!-- and -->), or is there another way to hide them? LiliCharlie (talk) 07:44, 20 April 2014 (UTC)[reply]
Yes, there's another way to hide them. I'm not sure which editor you use, but, in Inkscape, you right click an object, choose Properties, and click the "hide" checkbox. In Illustrator, you can click on the eye icon in the objects panel. If you are editing by hand, you add "visibility:hidden" to the style attribute.
As for your PDFs, I'm just worried that they may get deleted in the future for containing embedded non-free fonts. Plus Commons really prefers SVGs for images, using PDFs for documents. Trlkly (talk) 09:49, 25 April 2014 (UTC)[reply]
1. Meine Muttersprache ist auch Deutsch (im Gegensatz übrigens zu meiner Vatersprache). 2. Wir haben wirklich wochenlang um diese Formulierung gestritten, und ich habe keine Lust darauf, das Fass erneut aufzumachen. Das raubt mir zu viel Zeit. 3. Ich bin in typographischen Fragen nicht gerade unbedarft, halte aber deine Behauptungen der Annehmlichkeit im Lesen und der verbesserten Formatierung für unnachgewiesen. LiliCharlie (talk) 23:25, 4 April 2016 (UTC)[reply]
If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.
Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Hallo J-m.s, alle Benutzerseiten der Wiki-Projekte, in denen ich aktiv bin, verweisen nach User:LiliCharlie hier bei den projekt- und sprachübergreifenden Commons, weil es mir zu viel ist, überall Seiten anzulegen und bei Bedarf aktuell zu halten. Der zweite Grund ist, dass ich meine Vektor-Grafiken präsentieren mag und auch finde, dass sie etwas über mich aussagen.
Die Frage nach dem Wikilove-Icon verstehe ich nicht, wo soll ich was hinbekommen haben? — Solltest du das Anti-Nazi-Symbol hier auf dieser Diskussionsseite rechts unten gemeint haben, kannst du einfach ganz oben auf Edit klicken und dir die erste Zeile Quelltext ansehen, den ich von de:Benutzer:Sänger übernommen habe. Unter de:Benutzer Diskussion:Sänger#Habe von dir geklaut kannst du nachlesen, wie er auf meine Frage nach dem Copyright des Codes geantwortet hat. Lieben Gruß —LiliCharlie (talk) 21:42, 15 August 2016 (UTC)[reply]
The Unicode character U+076E (“Arabic letter hah with small Arabic letter tah below”) in Naskh script style. This letter is used for writing the Khowar language. Created using the font Noto Naskh Arabic.
@LiliCharlie: Sir, this special character of Khowar language is not joining to other letter i.e. ݮنݮیر the result is ݮ ن ݮ ی ر please check this, why this khowar language letter is not joining to other letter, please help us, if you need some screen shots i'll provide you via email, Regards --Raki04:38, 19 April 2017 (UTC)[reply]
No, seriously, who are you. I noticed your work on Chinese characters and i'am fan . I also love animated CJK characters, CJK radicals and co. I discovered your work while cleaning up the ACC project. The ACC project aims to create and store in an organized fashion CJK characters, with a priority on CJK radicals, the 214 Kangxi ones being the top priority.
The ACC has put in place simultaneous human and computer friendly naming convention using CJK(V) unicode characters, something like {character}-{style}.ext. This allow smoother predictability and integration into Wikipedia and Wiktionary articles. While I see it may not fit the Shuowen's 540 characters, this unicode {character}-{style}.ext naming convention would suit the Kangxi's 214 radicals for the files you shared on commons. I will not push for this right now as i'am not sure there is an unicode for them all, and if not how to handle the exception. But I would like to rather start with you this discussion of renaming files using unicode-based naming convention. This may apply to your Kangxi rads uploaded with their Songti-Kangxi-variant, to rename such as {character}-kangxi.svg, but also on other of your datasets. I also keep in mind that your datasets should keep harmonized, so we cannot rename only a large part of a dataset and leave the other part with another naming convention. We need a migration to either work for the full dataset or to not be implemented.
Last, as for the gallery below on Kangxi radicals, my old visual may worth deletion so your more recent illustrations can take over. --Yug(talk)15:35, 28 December 2017 (UTC)[reply]
LiliCharlie 214 + ext, svg. Hans
LiliCharlie 214 + ext, svg. Hant
Yug, Kangxi 214 + ext, png. (outdated)
Yug, Kangxi 214 + ext, svg. (outdated)
LiliCharlie, Kangxi 214 + ext.
LiliCharlie, Shuowen 540.
LiliCharlie, Shuowen 540 numbered.
The short answer is: I'm a German linguist.
Unfortunately I don't have much time for contributions here — and I can hardly believe I've already created so many SVGs and uploaded them to the Commons —, though I'm nearly done with a series of Chinese-Pinyin-German SVGs illustrating characters representing things like numbers, the five traditional elements, the ten heavenly stems and so forth (in 楷 style). As always I tried to be exhaustive and to provide national and other variants for both Chinese and German. —LiliCharlie (talk) 16:41, 28 December 2017 (UTC)[reply]
Oh ok. If in Chinese circle, we may both know few Chinese teachers (Andreas GUDER 顾安达 from the Freie Universität Berlin, or Joel Bellassen in France). I love the German Chinese Language Teacher Association, sharp and sound. Anyway, thanks for the upload here :)
I'am checking up here the compatibility of your work and the ACC project. When you uploaded your illustrations to commons, were you aware of the ACC project ? Was your naming convention a willful choice to be different from the ACC project conventions, and if so, why ? I need insight to lead a smart convergence and align theses datasets. PS: the ACC project contains about 15.500 files, thus the reason why I try to align your dataset with the ACC naming conventions. Yug(talk)21:14, 28 December 2017 (UTC)[reply]
Non, à cette époque-là je n'avais pas la moindre idée de l'existence du projet ACC, autrement j'aurais sans doute baptisé mes fichiers selon les règles proposées par ce projet. — Renommer tant de fichiers ici et sur les autres projets Wiki où ils sont utilisés est une tâche très pénible devant laquelle je recule. —LiliCharlie (talk) 23:01, 28 December 2017 (UTC)[reply]
Source
LiliCharlie hello, I just shared the reference of the book I use to familiarize myself with 5 major styles. I though it may interest you :
Copybook of Common Characters (pocket format). Available on Amazon EN and CN :
常用字字帖 / Copybook of Common Characters[1] (in Chinese), 1st edition edition, Shanghai Painting and Calligraphy Press, 1990, pages 490.
Hello Lili, In past days I noticed there is a large amount of backlog on the ACC and SO (Stroke Order) projects, so I requested admin abilities to be able to delete or merges files. Your vote would be helpful, as I'am in difficulty in that vote. It would help these projects to keep clean and sorted. Yug(talk)18:39, 29 December 2017 (UTC)[reply]
Hello LiliCharlie. As the vote is not going well due to my low activity and the community sharper selection process on Requests for Administratorship, I'am scaling down my project of clean up and leading a convergence of ACC files and yours. My apologize for that. Yug(talk)20:37, 29 December 2017 (UTC)[reply]
font in exactly the same style. This might also provide us with the possibility of automated conversion to SVGs. Is there is a possibility to be funded a suitable licence? —LiliCharlie (talk) 19:28, 10 January 2018 (UTC)[reply]
P.S.: If you're looking for a free font that closely follows Kangxi conventions, download
Hello LiliCharlie, Thanks for these info. I'am not sure
漢喃明B
is open license. For any font, if truly based on Kangxi scans, we could assume the glyph to be public domain. It would be faster to have the font and run my script. But given there are scans of the Kangxi pages online, it would be nearly as efficient to just grab this scan into inkscape, and use the "fill bounded area" tool over the character, then save it and upload it, as you just did. The energy I spend to look for open license fonts is not cost-efficient if objective is only the 214 kangxi and you already did it.
As for funding, no, I don't think the Wikimedia Foundation would buy it for us, or not in a time-cost efficient way since needing negotiation with both WMF and font designer. I think I will go for scans, inkscape, and "fill the shape", and that your work on kangxi rads is satisfying the core need. Yug(talk)11:33, 16 January 2018 (UTC)[reply]
As I am also involved in font design I do have a Kangxi scan font with about 17,000 glyphs that I made a couple of years ago when I produced the Kangxi radical SVGs. I'm not going to give it away for free though, and I can't expand it at this point either, as my scanner's lifetime seems to has ended.😞
I have managed to produce SVGs with your font-2-svg-files project, so I could now make Kangxi style images en masse if we could agree on a list of suitable traditional Chinese characters, and also agree on file naming conventions, which shouldn't be much of a problem. Only a minor portion of characters would be missing due to my incomplete font. The five SVGs above were actually already produced with your project; that's why I uploaded a new version of the
中
SVG, in order to start a uniform series and version 1 had been produced otherwise. — As to uniformity, my preferred setting is 640px × 640px (and a margin of 30px), and though this is larger than your default settings this shouldn't really matter for scalable graphics.
"The short answer is: I'm a German linguist." Yeah, *short answer*.
(1)-free kangxi font coming: Nice to learn about it. Quickly, in this field, being approximately translated by "within the next 5 years hopefully" . I guess you know of and considered contacting Bishop & Cook's Wenlin and their CDL project...
(2)-scaning and support: Ok, pretty impressed. RIP to your scanner. Did you got in touch with Wikimedia Germany ? There are avenues to finances or let you use one of WM-DE's scanner for a cleanly stated Wikimedia project, it's just +200€. It's called "Micro financing" in WM-fr. If you think this project worth it, I could support such micro financing request.s to WM-de, WM-fr or WMF.
(3)-NodeJS: OMG I have a Unicode CJK characters AND NodeJS budy !!!
(3a) As for my script, feel free to either request modifications via the issues page, submit modifications or to fork it and develop it your way. It now do its job, is already easy to take over (cf variables at top of index.js), so I'am not sure I will push further, will see on spot.
(3b) As for the list, I would recommend the 1200 most frequent from Cai (2010)'s list (early part of it here), converted from simplified into Traditional Chinese, the easiest being to use google translate. This is an ambitious upper target proposal, you are the chief for deciding what to share. My rational being this 1200 would likely cover 99% of the first 1000 characters of most Chinese frequency lists.
(3c) As for naming convention, Wargaz and myself I've been pushing this fresh draft update : Template:Chinese characters naming. We don't want to rename existing sets of images as of now, nor adopt new proposals immediately for new files. Wargaz and myself are proposing this {zi}-{style}-{period}-{idCode}.ext pattern, where the period can be a dynasty, a calligraphic school, a book or an calligrapher. We debated it on his talkpage and now open it to review for coming weeks, looking for a validation in February (or March).
(4) As for connecting and hacking, since it seems you have both handcrafting and coding capabilities, need connections with and support from the Wikimedia Chapters and community on both awareness about potential grants and maybe on commons bots. Since pushing further your Kangxi font in order to export {1200|a correct number} of characters is a hacking worth a Hackathon scholarship to Barcelona at least. Please consider applying to the following hackathon(s) :
WMF hackathons are a funny heuristic to travel to new places, we get free hosting and|or free travels, coding on project we love, connecting with positive people with valuable information to push further.
Hello LiliCharlie, if my propositions were too pushy my sincere apologizes for it. I use to share the higher possibilities, with implicit that the other end has complete control on declining and going for other ways. My sincere apologizes if my propositions were inappropriate. Feel free to point out your preferences. Yug(talk)10:29, 13 March 2018 (UTC)[reply]
Hi, I was wondering, do you happen to know if illustrations from Luciano Canepari's works can be uploaded to Commons? I thought the sagittal sections of the vocal tract and lip shapes (what he calls "orograms" and "labiograms") would be a great addition to phonetics articles on Wikipedia, but then I wondered if they were compatible with Commons. I can obviously contact Canepari directly, but I figured I'd ask you first since you have uploaded File:Daniel Jones's 18 Cardinal Vowels.svg and File:CanIPA Vocoids.svg, which are under CC-BY-SA-3.0 and include illustrations from his work. I know his website says "Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International", but do you know for sure those illustrations are also free to use under a CC license? Or did you tagged the CC license because you thought the illustrations did not meet the threshold of originality?
Thanks. Nardog (talk) 01:30, 26 January 2018 (UTC)[reply]
As you correctly state, his current download page http://www.canipa.net/doku.php?id=en:pdf carries the note "Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International." Therefore, as there is no statement to the contrary anywhere, everything you can download there may be published here, or anywhere else, under that licence. — If you still entertain some doubt, go ask Professor Canepari and don't forget to tell me what he replied. (It seems his current wiki is maintained by Marco Cerini and not by himself, though.)
I would also be interested in a more or less complete set of Canepari's orograms, linguograms, glottograms, and various other ilustrations, all in SVG format. Maybe we can agree on a uniform set of naming conventions and category folders. — Should we include his transcription symbols or leave them out?
File:Daniel Jones's 18 Cardinal Vowels.svg is not based on anybody's work in particular. In this case I do believe that the illustration doesn't meet the threshold of originality, but summarizes common phonetic knowledge and terminology.
Thank you for your explanation (and sorry for the belated reply). As far as I know, that CC announcement is shown by DokuWiki by default and his works such as Natural Phonetics & Tonetics, which the PDF files on his website are excerpts of, are books published by LINCOM, so I can only imagine the publisher retains some kinds of rights to them and the PDFs are redistributed under some conditions. So, although I could be wrong, I'd like to make sure if they are compatible with Commons should I upload images from them.
I've actually been preparing sagittal sections for vowels and consonants on my own based on File:VocalTract.svg. I've made voiced/voiceless bilabial/labiodental/denta/alveolar/retroflex/palatal/velar/uvular nasal/oral stops so far, but they are not yet ready for publication and also I need to expand them to possibly cover most if not all of the sounds on the IPA chart. Nardog (talk) 11:41, 7 February 2018 (UTC)[reply]
Merging Shuowen Seal Radical files and ACC project Shouwen seal files
Hello, LiliCharlie. Thank you for your remarkable contribution on Shuowen Seal Radical files (file:Shuowen Seal Radical xxx.svg) in 2013. However, they are kind of a duplication of the seal files of ACC project (file:X-seal.svg), for the following reasons:
I just added the function that displaysShouwen radical number to {{ACClicense}};
Shuowen Seal Radical files are mostly used in a few pages, and some of them are needed for ACC Shouwen seal files.
Therefore, I suggest that:
If the corresponding ACC seal file doesn't exist, we move the Seal Radical file to its name in the ACC project.
If the corresponding ACC seal file does exist, we delete the duplicated file.
I sincerely hope that you understand and help me to do this. Your works are much appreciated by me, and it's only for the best Integration of resource of the ACC project and Chinese radicals. --Wargaz (talk) 02:11, 31 January 2018 (UTC)[reply]
Please note that the existing ACC data set for seal has been done by various users and have variations in style (stroke width) and sourcing.
If Charlie's files are more consistent, I see no objection to upload them over the current ones.
On Dec. 28, 2017 I wrote above: « Renommer tant de fichiers ici et sur les autres projets Wiki où ils sont utilisés est une tâche très pénible devant laquelle je recule. » (“Renaming so many files here and on the other Wiki projects where they are used is a very troublesome task that I shrink back from.”) Maybe redirects might be a way to use my files under a new second file name without having to check their global use in every instance.
Please note that my Shuōwén radicals source is Duàn Yùcái's annotated edition
On "1) Renaming", I think Wargaz (as me) was conscious he wanted him and me to lead the move, including the deletion requests when needed. He/We want to go slowly and carefully tho, your feedback are listened and appreciate. @Wargaz: please give me a month before resuming my activity ^^
On 2), I have no expertise on this seal period. I pick the source you find the more solid, and state it somewhere (category page, project page, file page). It should be enough. We could also keep alternatives [File:Shuowen Seal Radical 2-Duan Yucai.svg] and/or [File:Shuowen Seal Radical 2-SWJZ.com.svg].
On 3) SWJZ-176.svg vs 青-seal.svg I see two glyphs so similar that we can say they are in their writer's mind indeed indentica. Also, does « are very similar, but not at all “identical » refers to the xml ? Do you have a preference to which *file.svg* to keep given something I may not know ? PS: I'am would favor keeping your whole set if possible.
Why we could not work together and integrate Shuowen Seal Radical xxx.svg files and x-seal.svg files? They are identical, and it is a waste of resource to have an exclusive set of Shuowen Seal Radical xxx.svg files on Russian Wiktionary. Why couldn't reply and tell me what do you think of this? Why you just simply undid my edit? --Wargaz (talk) 20:39, 28 March 2018 (UTC)[reply]
On sizes, SVG files can be enlarged and narrowed to any size you want. Therefore, a 300 × 300 px 青-seal.svg file and a 640 × 640 px Shuowen Seal Radical 176.svg file have no difference, and it is no need to keep 540 SVG files separately for Shuowen radicals. --Wargaz (talk) 20:44, 28 March 2018 (UTC)[reply]
“two” is shorter that its lower stroke. In the Shuōwén the two strokes of
二
“two” were of equal length while
𠄞
“above” had an upper stroke that was shorter than its lower stroke.)"
2) I don't think it is a good idea to equate seal characters (or pre-Hàn characters in general) with Hàn characters, as many of the seal characters have several and sometimes unexpected Hàn character equivalents. For example, you equate the above File:Shuowen Seal Radical 176.svg with
. All this means that the procedure of converting seal characters to Hàn characters is quite ambiguous and random, and this is why I don't want to have my Shuōwén seal radical SVGs renamed, at least not before the corresponding seal characters are encoded in Unicode's TIP. Love —LiliCharlie (talk) 22:03, 28 March 2018 (UTC)[reply]
On the first matter, I think the only problem is are recording Shuowen Jiezi radicals or Shuowen Jiezi Zhu radicals? If you are recording Shuowen Jiezi radicals, then please use Shuowen Jiezi's seal image whatever it is right or wrong. If you are recording Shuowen Jiezi Zhu radicals, then use the seal images from the annotated edition.
On the second matter, I believe you still have some incorrect concepts on Hàn characters. Firstly, Hàn characters don't mean the characters that characters of Hàn dynasty. This Hàn ≠ Hàn dynasty. Moreover, Shuowen Jiezis seals mainly reflect Han dynasty seals and all of them have corresponding modern Hàn characters. Furthermore, this Hàn equal to ethnic Hàn Chinese, and ancient scripts of Shang, Zhou, Chu or Qin are Hàn characters. Secondly, you misunderstood the variants and the standard script. Indeed, the standard script can be different in historical and geographic extents. However, 青, 靑, 𤯞, 𤯝 are all in modern standard script which is Kaishu. historically, 青 has never written as 青, 靑, 𤯞 or 𤯝 in ancient scripts (Yes! Even and especially 靑, 𤯞, 𤯝), all of them are clericalified, you can check all of ancient scripts of 青 in Xiaoxuetang. Then, in modern scripts which is clerical and standard script, 𤯞 and 𤯝 never was the standard forms, they are variants which are rarely used. You can check the rubbings of 青 chronologically (since Hàn dynasty). In modern script, 青 became the standard form for a long time. However, the printed form of Ming and Qing dynasty modified 青 and created 靑, because 靑 reflects that the bottom came from 丹 rather than 月. Although, handwritten form in Ming and Qing dynasty are still mainly 青, you can check the bottom ones in my second line. Thirdly, The official standard form in Mainland China, Taiwan, Hong Kong, and Japan is 青. In Japan, 靑 is Kyūjitai which is literally "old character form". Kyūjitai is similar to Traditional Chinese characters in Mainland China, and both of them are unofficial. In Korea, although 靑 is the standard form, but please notice that Korea abandoned Hàn characters in most situations, and they they even hardly ever write their names in Hàn characters. Korean standard isn't a widely used and functioning standard that we need to consider.
As I mentioned above, we consider the character standards of regions where currently using Hàn characters, and we choose the standard which is closest to ancient scripts. On 兌 and 兑, 兌 is definitely the closest form to the ancient scrpts. Other sites where studying ancient scripts also hold the same attitude. Multi-function Chinese Character Database is a Hong Kong website founded by the Chinese University of Hong Kong. They use 兌說脫閱稅悅 as the standard form, even they are mostly Hong Kongers.
The main problem that puzzle you is the difference between the Written Form (書體) and the Hàn Character. [https://zhuanlan.zhihu.com/p/19751881 Here is a excellent article that tells about this problem in Chinese. If you can't read Chinese, I will explain the main idea to you:
File:請 written body differences.jpgA image showing the different written forms of the same character "請", including two clerical, cursive, second simplified , semi-cursive, Shuowen seal, clerical again, standard, simplified standard printed, standard printed, three older standard printed with slightly differences.
A Hàn Character is a character which consists of compound(s) and having independent sound(s), form(s) and meaning(s). The Written Form is the specific manifestation of the form of a Hàn Character. The same Hàn Character can be written as different Written Forms, but they are still considered one character in the meaning of graphology. We even can say that 說, 説, 说 are the different Written Form of the same character and three different writing style of the same character, but there are the same character from the perspective of character form and character composition.
This a simple principle which many people don't understand. The author think Unicode holds irrevocable responsibility on this matter. When Unicode started to include the CJK Unified Ideographs, they found that the character forms are slightly different between every land. For example, Mainland China and Hong Kong use 户, Taiwain uses 戶 and Japan uses 戸. Therefore, they came up the Source Separation Rule. This rule means that when one of any source contains two or more character forms, the CJK Unified Ideographs include both (all) of them. However, this rule broke the coding principle of "only for characters, not for forms", and it is hard to implement.
The same component part sometimes are separated and sometimes unified, and the principle isn't always the same. For example, 値 and 值 are separated, but
直
and
直
are unified. 爭争 are separated, but
錚
and
錚
are unified. All in all, Unicode did an awful job on which character forms should correspond the same Unicode codepoint and which should be separated. For version backward compatibility, parts which are already encoded cannot be changed, so such flaws are kept. Later, Unicode invented a brilliant way to solve such problem in the future which are Compatibility Ideographs. From that time, the Glyph of the same character but displays different forms which submitted by every country would be a part of Compatibility Ideographs, and there would only one character in the basic plane.
For example, Japan submitted three "逸", and there are 逸 (U+9038), 逸 (U+FA25), 逸 (U+FA67). In Japanese fonts, normally they will have slightly different, however, when you search "逸" in text retrieval, 逸 and 逸 will also be counted as "逸", because they are the same character. If they submitted before Compatibility Ideographs are introduced, 逸 and 逸 would be also in the basic plane, and therefore redundant codepoints like "青" and "靑", "值" and "値" are produced.
Therefore, regarding the question like two forms are one character or not, are their Unicode separated or not is an inappropriate judging criteria.
The five paragraphs above are the key concepts of that article. I hope you can understand what the article and I said and consider about joining the ACC project.
is selected). And interestingly the HKSCS reference font
華康標準宋體
(English name: DFSongStd) shows identical glyphs for both
兑説脱閲税悦
and
兌說脫閱稅悅
: They all look like
兑説脱閲税悦
.
The article you linked to didn't contain any piece of information I hadn't been aware of before reading it. (It was a bit strange that the Ideographic Rapporteur Group wasn't mentioned, nor the crucial term of roundtrip compatibility with pre-existing standards.)
The more interesting facts are those that are not mentioned, probably because the article is biased towards usage of CJK characters by speakers of Chinese.
In Japanese usage is in many cases confined to a character that is viewed as just a glyphic difference by Chinese speakers, and this is especially true for the orthography of personal names and place names. Japanese are very likely to insist: "This is not my name!" when Chinese speakers don't understand what on earth they are talking about. For example, it is considered plain wrong to write the first character of
on the left side, even though in certain other words
祇
is written with a four stroke
⺭
. To solve such problems Unicode introduced the Ideographic Variation Database (IVD) that uses Variation Selectors at the encoding level. (It took me years to accept this, but there was so much rebellion from Japan that I now consider it justified. It is no coincidence the Japanese always used software like Mojikyo and also started the GlyphWiki project.)
In short: There is by no means a clear and universal answer to the question what are the same CJK characters and what are mere glyphic differences. Love —LiliCharlie (talk) 11:29, 1 April 2018 (UTC)[reply]
Why is not probably because you or some (not all Japaneses are viewed in such biased way) Japanese are biased? 搨本文字データベース is a Japanese website which records most Chinese host-Qin rubbings which I mentioned before, and you can clearly see that 祇 was written as both ⿰⺬氏 and ⿰礻氏. ⺬ and 礻 are both developed from the same character 示 and have the exactly same meanings. Do you EVER know in Japanese kyūjitai 神, 禍, 祈, 社, 祝, 福 were all with ⺬? Do you EVER know in old glyphs of China Mainland (Wikipedia), Taiwan and Hong Kong, all 礻 were displayed as ⺬? Cann't you see "例示字形変更前の字形についても、これを即、間違いとするものではありませんので",it is NOT a mistake, in the The correct writing order of kanji website (「祇」の書き方 - 漢字の正しい書き順(筆順))? You really shouldn't pick several extremely biased and ignorant views of Japanese to prove your weak statements. --Wargaz (talk) 21:13, 1 April 2018 (UTC)[reply]
I was looking for a user like you! You have recently edited some Help:IPA pages and talks, and given your name IPA should be your thing. I would like to ask your opinion about this: in Spanish and Italian Help:IPA pages, the phoneme [ŋ] (a mere allophone of /n/ before velar consonants /k/ and /g/) has got its own place in the phonemes list; on the contrary, the phoneme [ɱ] (a mere allophone of /n/ before labiodental consonants /f/ and /v/) has been de-listed and substituted by [m] with a note in brackets. What do you honestly think about this? On my opinion this distinguishment is pointless, unjustified and confusing, but I would like to hear an expert's opinion. Let me know, thank you in advance ^_^ --Fernityin (talk) 14:38, 4 March 2019 (UTC)[reply]
Let me know what you think, and please make edits on the Protection of varieties of Chinese page as you see fit. It's a sensitive topic kind of, but I think we can make a good article that mirrors the good parts of the Chinese Wikipedia page. Thanks!!! --Geographyinitiative (talk) 05:07, 23 July 2019 (UTC)[reply]
Prof. Myers's next book "The Grammar of Chinese Characters", which I look forward to read, made me visit cjk insitute website for updates in the publishment of the 'CJKI Chinese Learner's Dictionary'.
After reading the DeFrancis' classic "Visible Speech", and the figures about his Chinese "phoneticity" in the second chapter, I unsuccessfully searched for an academic project dealing with a synchronic description, rather than etymological, of characters' "phoneticity" (I am not referring to mnemonic aids).
I do not consider utopian, at least for the purported 80% of phonosemantic compounds out of the approximately 3500 characters necessary for full literacy, to carry out an investigation about synchronic meaningful patterns to arrange useful groups using "objective criteria".
Among such criteria could be radicals (and therir context, such as position), but also their glyphs and stroke orders, as well as various linguistic information of the words that certain morphemes can create.
Furthermore, an index of ambiguity for pinyin homophones, especially monosyllabic particles, would hekp solve the main disadvantage of the pinyin romanization.
Most importantly, therefore, a dictionary of the Chinese language must deal with what Prof. Duanmu's lexical 'elasticity/flexibility',
as well as with the relationship between such "elasticity" and the surviving morphemes in truncated abbreviations and similar phenomena, such as what Prof. Ceccagno coined "metacompounds" – e.g., the apparent surviving morphemes in 卫视 'satellite T.V.' are at least the bound short version of the disyllabic elastic words 卫星 'satellite' and 电视 'television'.
Such elasticity, together with the logico-semantic ordering proposed in the 'CJKI Chinese Learner's Dictionary', would imply a historic pedagogical improvement in lexicophical resources.
Incidentally, elasticity from the Xiandai Hanyu Cidian 2005 has been tabulated in the following open access thesis
In said theses, however, there are some cases where it's impossible to disambiguate what meaning(s) of the words are being referenced. For example, the short version of 生(产), which has the two meanings a) produce b) give birth, is Free or Bound depending on its verbal meaning, yet there seems to be no way to know which is which. Similarly, 看见 appears twice implying two different verbal senses/morphemes.
Therefore additional information is necessary to disambiguate this and similar cases.
Hi, I just stumbled upon your List of obsolete Simplified Chinese characters, which caught my interest. Some of them are still used as radicals, such as in 练. Was that meant for 柬? I can imagine they might have preferred to drop it for fear of confusion with 东; but if that was so, why did they not just replace it with 拣 throughout? Much more reasonable than replacing 隻 with 只!
@SebastianHelm: Yes it would, though many of those characters map to several characters currently in use in Mainland China. However I have no intention of doing so, certainly not before all of the abandoned simplified characters are Unicode-encoded as well.
Thank you! That's indeed a great page; it contains everything I was asking for plus much more. To my surprise, many of these already are coded in Unicode, which even has some alternate simplifications such as wikt:亽. Thank you also for the pointer to Александр Запрягаев. He seems to be an interesting prolific and meticulous researcher.
Some useful things I became aware of thanks to your pointers:
Great job with all the files you've created! I was reading en:Shuowen Jiezi and came across your file there, and was delighted that someone had illustrated the seal script radicals. I see on your user page that you were also the creator of the file showing how katakana forms were derived from their original hanzi, and that was very illuminating as well. Thanks again. Opencooper (talk) 03:18, 4 May 2020 (UTC)[reply]
I would like to use your image DGS.svg ([[2]]) to promote a non-commercial course of German Sign Language without using a Creative Commons License. The course will be financed by the student council of the University of Münster, Germany. I would take your image and build a few graphics for Facebook and Instagram with it. Would that be okay for you? Do you prefer a different means of contact? --LarsvonSpeck (talk) 16:59, 15 September 2020 (UTC)[reply]
My main concern is, that the condition Share Alike can't be met on IG and FB. Also, we usually don't include licensing information for graphics in our posts. A downgrade to CC-BY would already be a great improvement for our use case, I think. We would of course still credit you. --LarsvonSpeck (talk) 23:22, 16 September 2020 (UTC)[reply]
Hello LiliCharlie,
Past days the ACC group did a new push given the arrival of User:Frigoris uploading examples of Category:Clerical Han script characters, based upon academic and historical sources. I continue to push to have harmonized filenames, so the whole ACC 15,000 files forms an an easy to use multi-styles database for Wikimedia projects and others.
I bumped again into your Kangxi and seal uploads, as well as upon our past discussions, where you pointed out renaming was ok for Kangxi but lot of work. (#On_Shuowen_Seal, you were not enthusiast about renaming). Back then I raised that issue and made a proposal but didn't push further. As it comes again to light, I would like to move forward with this "mass" renaming with your Category:The 214 Kangxi radicals in the dictionary’s own style (in SVG format). Renaming would follow existing ACC naming conventions, with the proposed rename and suffixes being such :
I don't mind if the graphics are renamed and get an additional license as long as the new names clearly identify the content and the links in all Wiki projects still work. Love —LiliCharlie (talk) 10:01, 16 September 2020 (UTC)[reply]
Migrating to table is a tidious work I started 2 days ago. I need a wikibreak but I'am still on ACC project. Can't do everything.
en:List of CJK fonts shoudl documents existing CJK fonts. As for download page or exact link, we can put them under the English name (webpage url) and under the filename (font file url).
I found a way to fast rename dozen (hundreds) files programatically, see user:yug/common.js.
A section is open to discuss the suffix to put upon your Kangxi svg : -kangxi, -songti-kangxi, or -mingti-kangxi.
@LiliCharlie, Frigoris, and Sarang: , i just enjoyed this reading about a local Chinese writing system :
"What the world’s fascination with a female-only Chinese script says about cultural appropriation." https://qz.com/1271372
Nice read (<6mins) on cultures, folklorisation, academic projection, aculturisation by modernity. Nice mind travel... For some visuals, see the Unicode document N4697. Wish you all a good day ! Yug(talk)21:37, 3 October 2020 (UTC)[reply]
Hello LiliCharlie,
While speed editing those files I occasionally break apart some characters. I get multiple path elements. Is that an issue ? Should I recombine the shape into one multiline path ? Yug(talk)16:20, 6 October 2020 (UTC)[reply]
I am happy, but appreciate your suggestion. I will keep it in mind if I wind up spending much more time in Mongolia. I am not particularly fussed about it if the issue is simply something about my somewhat outdated and non-standard iPhone settings. If it turns out to be a font that numerous people would not have unless they have tried to, perhaps I should put a little notice on the page like I have seen for Berber, but meanwhile, I appreciate the answer. Elinruby (talk) 17:58, 13 December 2020 (UTC)[reply]
Hallo, LiliCharlie. :-) Ich habe gerade ein neues Bild hochgeladen. Leider ist für mich das Interface zum Hochladen etwas neu, weil ich schon seit einiger Zeit nichts mehr hochgeladen habe. Wie kann ich "Own work" ändern, so daß es auf das orginale Bild File:Toki pona Alphabet.jpg verweist? Gruß --Tlustulimu (talk) 10:51, 15 February 2021 (UTC)[reply]
toki! The German version of Toki Pona: The Language of Good, which was published yesterday, includes this on the copyright page:
Auf Wunsch von Sonja Lang sind das Kapitel „Hieroglyphen“ (Seiten 100 bis 107) und das offizielle Toki-Pona-Wörterbuch (Seiten 120 bis 129) gemeinfrei, entsprechend „CC0 1.0 Universell“: https://creativecommons.org/publicdomain/zero/1.0/deed.de
Hi LiliCharlie, you're now a filemover. When moving files please respect the following advice:
Use the CommonsDelinker link in the {{Rename}} template to order a bot to replace all ocurrences of the old title with the new one. Or, if there was no rename-request, please use the Move & Replace-tab.
Please leave a redirect behind unless you have a valid reason not to do so. Other projects, including those using InstantCommons, might be using the file even though they don't show up in the global usage. Deleting the redirects would break their file references. Please see this section of the file rename guideline for more information.
If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.
Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
If you created this file, please note that the fact that it has been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.
Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
Before asking you a question, let me explain you something: I once wanted to upload the Sitelen Sitelen characters(in my own art style), but I never do it, because the are copyrighted by Jonathan Gabel(I think), here is his page.
Here's Jonathan's site-wide license: https://jonathangabel.com/license/. "You are free to [...] copy and redistribute the material in any medium or format" as well as "remix, transform, and build upon" it. So go ahead.
Once we're at it: If you want to build upon kai-style fonts with an appropriate license, you could use "AR PL KaitiM Big5" and "AR PL KaitiM GB" that were released by Arphic Technology under the Arphic Public License. There are also extended and adapted derivatives under the same license, such as "AR PL UKai", "AR PL UKai-ExtC", "AR PL UKai HK", etc. — The copyright notice of "TW-MOE-Std-Kai" reads: "(c) This license allows for redistribution, commercial and non-commercial, as long as it is passed along unchanged and in whole, with credit to MOE", so you may not modify that one, or use only part it. Love —LiliCharlie (talk) 12:30, 2 November 2021 (UTC)[reply]
Hello LiliCharlie,
We both bumped into cases where we could not upload a file due to a rare unicode character. You yourself met that bug with File:Biáng-order.gif when you tried to use the Chinese character. I'm looking for that log / error page listing those upload failures. Do you have any memory of it ? Any hint ? Yug(talk)07:33, 8 July 2022 (UTC)[reply]
Wikipedia-Lemmata: »Chinesische Sprachen« und »Hochchinesisch«
Some contents have been listed at Commons:Deletion requests so that the community can discuss whether they should be kept or not. We would appreciate it if you could go to voice your opinion about this at their entry.
If you created these pages, please note that the fact that they have been proposed for deletion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with them, such as a copyright issue. Please see Commons:But it's my own work! for a guide on how to address these issues.
Please remember to respond to and – if appropriate – contradict the arguments supporting deletion. Arguments which focus on the nominator will not affect the result of the nomination. Thank you!
If you created this category, please note that the fact that it has been proposed for discussion does not necessarily mean that we do not value your kind contribution. It simply means that one person believes that there is some specific problem with it. If the category is up for deletion because it has been superseded, consider the notion that although the category may be deleted, your hard work (which we all greatly appreciate) lives on in the new category.
In all cases, please do not take the category discussion personally. It is never intended as such. Thank you!
. I also love animated CJK characters, CJK radicals and co. I discovered your work while cleaning up the ACC project. The ACC project aims to create and store in an organized fashion CJK characters, with a priority on CJK radicals, the 214 Kangxi ones being the top priority.
LiliCharlie 214 + ext, svg. Hans
LiliCharlie 214 + ext, svg. Hant
Yug, Kangxi 214 + ext, png. (outdated)
Yug, Kangxi 214 + ext, svg. (outdated)
LiliCharlie, Kangxi 214 + ext.
LiliCharlie, Shuowen 540.
LiliCharlie, Shuowen 540 numbered.
. Yug (talk) 01:51, 8 January 2018 (UTC)
中
那
要
熙
在
.svg){kind=link}
in 练. Was that meant for 柬? I can imagine they might have preferred to drop it for fear of confusion with 东; but if that was so, why did they not just replace it with 拣 throughout? Much more reasonable than replacing 隻 with 只!
, see Andrew West's great webpage BabelStone Fonts : BabelStone Erjian with charts of character correspondences, fonts, historical documents, real-life examples, and a link to Александр Запрягаев's The Chart of Current Status for Second Stage Simplification in Unicode of late December. Love —LiliCharlie (talk) 17:50, 7 January 2020 (UTC)
![[2]](https://commons.wikimedia.org/wiki/File:DGS.svg){kind=link}
Done. I've changed the license to CC BY 4.0. Love —LiliCharlie (talk) 03:11, 17 September 2020 (UTC)
.svg)
.svg){kind=link}
.svg){kind=link}
