Open main menu

Wikimedia Commons β

User talk:LiliCharlie



SVG of Nôm character U+2B1A1Edit

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)

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)
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)

Shuowen Jiezi radicalsEdit

Thank you for your pictures of Shuowen Jiezi radicals. Great job! I used them in the article List of Shuowen Jiezi radicals (russian version), if you don't mind. --Dimitrius (talk) 09:21, 26 December 2013 (UTC)

Troublesome Extension C characterEdit

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)

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)
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)
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)
No, the bottom line is that HAN NOM B only covers Extension B and the other characters are “fillers used by font designers on purpose.” LiliCharlie (talk) 02:44, 6 January 2014 (UTC)


Hi LiliCharlie, you uploaded a lot of Chinese letters, e.g. The 214 Kangxi radicals in the dictionary’s own style (in SVG format), and others. May be you don't know yet, each Chinese character should be properly categorized. I did it just for one of your graphics, for Kangxi Style Kangxi Radical 009.svg, with {{Rcat}} which is IMHO the best possibility. As a suggestion, I licensed it also for {{PD-Unicode}} which seemded better than the license you took.
The necessary categorization will best be done by a bot. If you need more explanation or some hints, you may ask me. But please care for the categorization, anyway. sarang사랑 12:21, 16 February 2014 (UTC)

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)
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)
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)

Picture of the Year 2013 R2 AnnouncementEdit

Round 2 of Picture of the Year 2013 is open!Edit

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.

Round 2 will end on . Click here to learn more and vote »

the Wikimedia Commons Picture of the Year committee

You are receiving this message because you voted in the 2013 Picture of the Year contest.

This Picture of the Year vote notification was delivered by MediaWiki message delivery (talk) 19:22, 22 February 2014 (UTC)

About Logographic Vietnamese Terminology.svgEdit

chữ Hán = chữ Nho = Hán tự;

Hán Nôm = chữ Hán + chữ Nôm

Please make sure the definition of each term. Thanks.-서공/Tây Cống/セイコゥ (talk) 03:10, 25 February 2014 (UTC)

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)
The explanation under the picture should be modified, as the first 3 words have the same meaning but the last one is different. --서공/Tây Cống/セイコゥ (talk) 05:12, 25 February 2014 (UTC)
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)

Picture of the Year 2013 Results AnnouncementEdit

Picture of the Year 2013 ResultsEdit

The 2013 Picture of the Year. View all results »

Dear LiliCharlie,

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:

  1. 157 people voted for the winner, an image of a lightbulb with the tungsten filament smoking and burning.
  2. In second place, 155 people voted for an image of "Sviati Hory" (Holy Mountains) National Park in Donetsk Oblast, Ukraine.
  3. In third place, 131 people voted for an image of a swallow flying and drinking.

Click here to view the top images »

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.

the Picture of the Year committee

You are receiving this message because you voted in the 2013 Picture of the Year contest.

Delivered by MediaWiki message delivery (talk) 23:00, 26 March 2014 (UTC)

User pageEdit

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)

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)

Which toolEdit

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)

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)

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)

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)

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)

Path text SVG for WelcomesEdit

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)

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)
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)
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)
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)

MuMarzog MuK55aaalid (talk) 05:48, 28 January 2017 (UTC)


I am preparing another appeal: I hope you can comment. Several editors have provided testimonials already, as you can see from the link. Kauffner (talk) 10:53, 11 January 2015 (UTC)
Für mich - jemand dessen Muttersprache Deutsch ist - ist diese Variante angenehmer zum Lesen; da sie den Text besser formatiert.
--Tobias B. Besemer (talk) 23:11, 4 April 2016 (UTC)

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)

File:Je suis Charlie - Wo shi Chali.svgEdit

File:Je suis Charlie - Wo shi Chali.svg has been listed at Commons:Deletion requests so that the community can discuss whether it should be kept or not. We would appreciate it if you could go to voice your opinion about this at its entry.

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 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!

Afrikaans | العربية | беларуская (тарашкевіца)‎ | български | বাংলা | català | čeština | dansk | Deutsch | Deutsch (Sie-Form)‎ | Zazaki | Ελληνικά | English | Esperanto | español | eesti | فارسی | suomi | français | galego | עברית | hrvatski | magyar | Հայերեն | Bahasa Indonesia | íslenska | italiano | 日本語 | 한국어 | 한국어 (조선) | македонски | മലയാളം | Plattdüütsch | Nederlands | norsk nynorsk | norsk | occitan | polski | پښتو | português | português do Brasil | română | русский | sicilianu | slovenčina | slovenščina | shqip | српски / srpski | svenska | Türkçe | українська | Tiếng Việt | 中文 | 中文(简体)‎ | 中文(繁體)‎ | +/−

George Ho (talk) 01:22, 6 June 2016 (UTC)


Warum zeigt denn ein Pseudonym nach wikimedia statt wikipedia? Und wie hast du das Wikilove-Icon da hinbekommen? J-m.s (talk) 20:26, 15 August 2016 (UTC)

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)

A cookie for you!Edit

  A test of WikiLove J-m.s (talk) 21:50, 15 August 2016 (UTC)

Khowar Special CharacterEdit

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 --Raki 04:38, 19 April 2017 (UTC)
Hi Raki, you might want to join the Unicode Public Email List to ask the Unicode experts how to prevent Khowar letters from joining. I'm sure those peolple know or will find a solution to your problem. I wish you the best of luck! —LiliCharlie (talk) 14:30, 19 April 2017 (UTC)


Hallo LiliCharlie, kann es sein, dass dieser Ping nicht bei Dir angekommen ist? :-) --.js 05:00, 26 May 2017 (UTC)

Who are you !?!Edit

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)

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)
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)
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)

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.

Sample scan. Yug (talk) 15:49, 2 January 2018 (UTC)

Requesting admin abilitiesEdit

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)

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)
Will do without  . Yug (talk) 01:51, 8 January 2018 (UTC)

Kangxi seriesEdit

Hello LiliCharlie, I look for the character zhong (middle) in -kangxi.svg style. Any chance you did it ?

Also, could you share your source for images of Kangxi radicals in Kangxi style ? --Yug (talk) 01:51, 8 January 2018 (UTC)

Kangxi style characters
My Kangxi character SVGs derive from scans which gives them an original feel. However I think the ACC project should preferably use the much clearer
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)
P.S.: If you're looking for a free font that closely follows Kangxi conventions, download
/Han-Nom Minh
and look at the glyphs for characters like
etc. However character
has a more contemporary glyph compared to Kangxi style
. Here you can compare what these characters look like in your default CJK font and in Han-Nom Minh after the font is installed:
那、要、熙、在。LiliCharlie (talk) 18:28, 13 January 2018 (UTC)
Hello LiliCharlie, Thanks for these info. I'am not sure
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)
  1. There is hope that free fonts supporting Kangxi glyphs will be available sometime in the not so far future. Ken Lunde of Adobe, who was and is responsible for the Source Han/Noto CJK font develpoment and at the same time acts as the registrar for the Unicode Ideographic Variation Database (IVD) has submitted a "Proposal to accept the submission to register the “PanCJKV” IVD collection" which defines a way to explicitly encode Kangxi glyphs via Unicode's Ideographic Variation Sequences (IVSs); see his blog entry of February 26, 2016 where I discussed this with him. (Earlier blog entries are those of February 13, 2016 and of February 20, 2016.)
  2. 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.😞
  3. 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.
LiliCharlie (talk) 14:53, 16 January 2018 (UTC)
"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.
Cheers!   Yug (talk) 16:34, 17 January 2018 (UTC)
PS: without going to Barcelona, you still can contact Wikimedia Deutshland/Germany for information on micro-financing. Yug (talk) 12:46, 28 January 2018 (UTC)
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)

Luciano CanepariEdit

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)

  1. Yes, File:CanIPA Vocoids.svg was basically taken from Canepari's former download page, but rearranged and published here under a CC-BY-SA-3.0 licence, as there was no note of exception anywhere.
  2. As you correctly state, his current download page 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.)
  3. 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?
  4. 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.
LiliCharlie (talk) 15:03, 26 January 2018 (UTC)
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.
As for File:Daniel Jones's 18 Cardinal Vowels.svg, aren't the lip shapes seen on the upper left taken from Canepari's work? If not I would like to extract them and add them to e.g. w:Roundedness.
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)

Merging Shuowen Seal Radical files and ACC project Shouwen seal filesEdit

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:

  1. All of them are seal scripts from Shouwen Jiezi, and they are identical except sizes (see file:Shuowen_Seal_Radical_176.svg and file:青-seal.svg);
  2. I just added the function that displaysShouwen radical number to {{ACClicense}};
  3. 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)

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.
PS: As for my files --just a dozen -seal.svg I think-- I see no objection to remove them when needed  . user:Yug 12:32, 1 February 2018 (UTC)
  1. 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.
  2. Please note that my Shuōwén radicals source is Duàn Yùcái's annotated edition
    which has
    as radical #2, unlike which gives
    . I have uploaded the file File:Shuowen Jiezi, all 10 characters under radical 2.png showing all radical #2 characters in Duàn's edition. According to him
    itself is not radical/
    #2, but only the second character under radical
    . (My guess is that some later Shuowén editors feared that “above” would get mistaken for “two.” Nowadays the upper stroke of
    “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.)
  3. File:Shuowen Seal Radical 176.svg and File:青-seal.svg are very similar, but not at all “identical except sizes.” Love —LiliCharlie (talk) 20:44, 4 February 2018 (UTC)
Hoy !
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].
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.
best regards Yug (talk) 16:48, 5 February 2018 (UTC)

On Shuowen SealEdit

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)

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)
1) I undid your edit on ru.WP for the reason discussed above with Yug as 2.:
"Please note that my Shuōwén radicals source is Duàn Yùcái's annotated edition
which has
as radical #2, unlike which gives
. I have uploaded the file File:Shuowen Jiezi, all 10 characters under radical 2.png showing all radical #2 characters in Duàn's edition. According to him
itself is not radical/
#2, but only the second character under radical
. (My guess is that some later Shuowén editors feared that “above” would get mistaken for “two.” Nowadays the upper stroke of
“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
, but a historically earlier equivalent is
. And you might also have chosen
. 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)
Point 4 of Community vision. We haven't clarified our objectives on this matter, and are now touching it. Yug (talk) 12:14, 29 March 2018 (UTC)
This also touches the question which contemporary national Hàn character standard you choose. In the above example
(Unicode: U+9751) is used in Korean whereas in modern Chinese and Japanese people use
(U+9752). As a radical, however, the Japanese usually still use
(the common Korean character U+9751, which is also used in the Kāngxī Dictionary).
Even within traditional Chinese usage varies: For example, where the Taiwanese use
(U+514C U+8AAA U+812B U+95B1 U+7A05 U+6085) the Hong Kongers use
(U+5151 U+8AAC U+8131 U+95B2 U+7A0E U+60A6). And these are not the only cases where Hong Kong
differ from Taiwanese
, even in terms of Unicode encoding. Love —LiliCharlie (talk) 16:42, 29 March 2018 (UTC)
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. [ 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:
A 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
are unified. 爭争 are separated, but
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.

--Wargaz (talk) 01:18, 30 March 2018 (UTC)

The HK standard corresponding to simplified
is clearly
. My contemporary dictionaries from HK only show forms with
; the site
correctly converts simplified
when the option
is selected (and to
is selected). And interestingly the HKSCS reference font
(English name: DFSongStd) shows identical glyphs for both
: 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
with a four stroke
instead of a five stroke
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)
I NEVER MEANT to say the Hong Kong standard isn't
. You clearly did NOT understand what I said. What I tried to say is Multi-function Chinese Character Database is a Hong Kong website which runs by the Chinese University of Hong Kong, but the Hong Kong website uses
when it comes to the the studies of the Ancient Scripts: See here, here, here, here, here and here for
; in contrast of here, here, here, here, here and here for
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)
Return to the user page of "LiliCharlie".