User talk:Nbarth/Archive 2010

This is an archive of past discussions. Please do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

← Archive 2009 |

Archive 2010

| Archive 2011 →

's

Hi, there's some problem with the format of the references you added in this edit - the tags lead nowhere and there's an error message at the bottom of the page. I'd fix it myself, but don't know how. --Thrissel 22:16, 16 January 2010 (UTC)

Oops! Thanks for the catch!

I fixed it in this edit – I’d forgotten to add a <references/> tag and “References” section.

—Nils von Barth (nbarth) (talk) 04:00, 17 January 2010 (UTC)

OIC! I tried the 'pedia's {{reflist}} template, but it didn't work. I'll be wiser next time :-) ! --Thrissel 12:19, 17 January 2010 (UTC)

Header for examples vote changed to "Samples"

As there seemed to a clear majority for a change in the header, it has been changed to "Samples". The vote has been extended 7 days to allow time to (re-)consider one's position. Sorry for the inconvenience. --Bequw → ¢ • τ 03:16, 20 January 2010 (UTC)

No worries – amended, and thanks!

—Nils von Barth (nbarth) (talk) 03:48, 20 January 2010 (UTC)

Hanzi etmology

Nils, thanks for adding constituent elements to the hanzi -- SO useful (kind of like the zipu--I don't know if you use zhongwen.com). Great work! --71.111.229.19 21:30, 22 February 2010 (UTC)

Thanks for the kind words (glad you find them useful) and the tip – I’ll certainly check zhongwen in future!

If you’d like to help and feel energetic, you’re welcome to add constituent elements yourself using the {{Han compound}} template, as documented there and in the examples; I’d be happy to help out if you’d like any help.

Thanks again for the positive feedback, and enjoy!

—Nils von Barth (nbarth) (talk) 02:29, 23 February 2010 (UTC)

Wikisaurus/def

May I ask why are you adding the "/def" subpages to Wikisaurus entries? --Dan Polansky 10:17, 29 March 2010 (UTC)

Hi Dan,

The /def subpage is the default parameter to the {{ws refer}} template (as of this revision by DAVilla in 2007); without it, one must include a “sense” argument manually.

I recently noticed the {ws refer} template, so I started using it, but saw that it required a /def page, so I added some.

As I understand, “how to link to ’saurus” has been an ongoing discussion (e.g., not having banner boxes, because they look like external links) – do you know if there was any consensus, and if {ws refer} is recommended or acceptable (it seems used relatively commonly, but not to be especially documented)?

Another option, rather than including /def or a manual sense argument, would be to omit “in the sense of” if these are both absent, which might be clearer.

Hope this helps!

—Nils von Barth (nbarth) (talk) 02:49, 30 March 2010 (UTC)

I never use {{ws refer}}, and discourage from using it. The template makes things needlessly complicated, also by requiring the existence of the "/def" subpages. I also dislike its use of an icon. The markup "See also [[Wikisaurus:cat]]" works well without need of any special magic.

The template {{ws refer}} is currently used in less than 100 entries, while "See also [[Wikisaurus: ..." is used in over 1800 entries.

There has been no discussion on the use of that template with other Wiktionarians. In the last year, there have been very few contributors to Wikisaurus other than myself. --Dan Polansky 07:30, 30 March 2010 (UTC)

Thanks for clarifying!

Should we RFD {ws refer} then? We really should be consistent, and you’re right, custom is to not use icons for internal links, though they’re ok on non-main space pages, AFAICT.

I’d appreciate a template to save typing – “{{ws see|cat}}” is rather shorter than “See also [[Wikisaurus:cat]]” – and is also good for consistency. Should we create a simple template that just writes “See also [WS:foo]”, or perhaps replace ws refer with this?

—Nils von Barth (nbarth) (talk) 10:00, 30 March 2010 (UTC)

(<--) RFDing the template would be an option. But it means further politics, of which I am a bit tired right now.

I think it would really be best to do without a template. As regards work saving, "{{ws see|cat}}" has 14 characters while "See also [[Wikisaurus:cat]]" has 27 characters, which is admittedly almost two times as many on a short headword such as "cat". Still, from my experience, the hyperlink is mostly created by copying and pasting for a whole set of items, so the typing work is insignificant. On the other hand, using a template would bring about some enforced standardization. I am quite indecisive. I am just continuing with the status quo of using no template, which from my experience has worked without any problems. The amount of research work for setting up one of those Wikisaurus entries that cannot be based on mainspace is so great that the additional mechanical effort of pasting a hyperlink to the concerned entries seems insignificant. Standardization can be enforced also without templates: we have standard headings in the mainspace without using templates for them. --Dan Polansky 10:21, 30 March 2010 (UTC)

No worries – while I’d prefer a template, standard text also works, and it’s really six of one (e.g., French ’tionary uses templates for headings, we use standard text). I’ll defer to you since you’re far more involved in ’saurus than I, and if we ever want to use a template in future, it’s easy to add and an easy bot fix to change.

As a fan of outdenting, perhaps you’d enjoy {w:od2} and {w:od}?

BTW, would you like me to clean up the {ws refer} and /def cruft that I’ve added?

—Nils von Barth (nbarth) (talk) 02:50, 31 March 2010 (UTC)

(<) Thank you. As you said, adding a template in the future should be straightforward if there is a broader wish.

Yeah, I am pondering whether nesting discussion threads should be handled differently. I have recently printed a long discussion, with the result that, at the end of the discusion, I got a lot of indented whitespace at the left and a bit of text at the right.

If you could remove the recently created /defs, that would be great. --Dan Polansky 07:11, 31 March 2010 (UTC)

/defs removed! (Oh, and I fixed the links too, to use “See also”. It was soooo onerous. I mean, I had to copy and paste like 2 or 3 whole times!)

Regarding nesting, agreed that strict nesting is completely unusable for long threads – like, more than 4 posts – and many ’tionary threads are significantly longer than this.

Nesting implies a hierarchy, and makes sense if you can expand/collapse and there really are subthreads, rather than a single thread, but it’s completely unsuited for most ’tionary (and ’pedia and other) discussions.

The only really benefit is in visually separating posts, but that’s more easily done simply by alternating indented or not.

I’d certainly be in favor of replacing current indenting with either alternating in/out, or (more conservatively), consistently out-denting after every 3 levels of indenting, say (so it goes 0,1,2,3, 0,1,2,3, etc.), optionally with {od} (fixed at 3) as a visual guide.

—Nils von Barth (nbarth) (talk) 08:24, 31 March 2010 (UTC)

Etymologies

Please use the lemma form of Latin verbs in etymologies, not the present active infinitive. --EncycloPetey 04:34, 10 April 2010 (UTC)

Ok – apologies for non-standard use; some references (notably Online Etymology Dictionary, I think) use infinitive, and as I don’t know Latin this doesn’t jump out at me.

I’ll make an effort to remember and put in the lemma form.

Is there some particular cleanup I should do?

—Nils von Barth (nbarth) (talk) 07:00, 10 April 2010 (UTC)

The one that count my eye was in the etymology of (deprecated template usage) obdurate. I do not know if there were any other cases (I didn't spot any recent ones). --EncycloPetey 07:03, 10 April 2010 (UTC)

(For terminology, present active infinitive is “second principle form”, while Wiktionary uses the first person present indicative or “first principle form” as lemma.)

durare doesn’t have a Latin entry – I’m assuming the lemma would be (deprecated template usage) dūrō, but I’m guessing.

How should I handle cases when I can’t determine the lemma form?

• Guess?
• Flag it for attention?

—Nils von Barth (nbarth) (talk) 07:40, 10 April 2010 (UTC)

Flagging it for attention when you don't know, or dropping me a note if it's just one item every now and then. You guess about dūrō is correct, and likewise obdūrō. --EncycloPetey 07:47, 10 April 2010 (UTC)

Ok – I’ll flag with {{rfe}} + a comment (in case I forget) and drop you a note.

Thanks for the tips – I’ve fixed (deprecated template usage) obdurate.

—Nils von Barth (nbarth) (talk) 08:23, 10 April 2010 (UTC)

Merging in a revision history

May I ask you a favor? Can you please add the revision history of "Appendix:Latin nouns with English derivatives" to the page "User:Dan Polansky/English derivations"? I started the latter page back in December 2008 by copying the former, but by doing so, the revision history of the source has not been included. I'll be grateful :). --Dan Polansky 13:46, 22 April 2010 (UTC)

Hi Dan,

No problem – I’ve done so as per wikibooks:MediaWiki Administrator's Handbook/Edit History, putting the merged page at Appendix:Latin nouns with English derivatives (since one cannot copy pages). Trust this is ok (your User page is now a redirect); I’ve explained technical details of the merge at Appendix talk:Latin nouns with English derivatives.

Thanks for your great work on this page!

—Nils von Barth (nbarth) (talk) 04:35, 23 April 2010 (UTC)

Ooops, but I did not really want the two pages merged. I wanted only that the history of "Appendix:Latin nouns with English derivatives" up to 19:53, 1 December 2008 was added to the history "User:Dan Polansky/English derivations", while "User:Dan Polansky/English derivations" is kept separate. I wanted the page "Appendix:Latin nouns with English derivatives" remain intact.

The thing is, "Appendix:Latin nouns with English derivatives" is constrained to nouns while "User:Dan Polansky/English derivations" included also other Latin parts of speech.

Anyway, I have renamed "Appendix:Latin nouns with English derivatives" to "Appendix:Latin words with English derivatives", to match the scope of my page that has been merged into it. If someone has an issue with the new page, let us hope the steps can be undone. --Dan Polansky 06:07, 23 April 2010 (UTC)

And I have forgotten: thank you anyway! --Dan Polansky 06:37, 23 April 2010 (UTC)

No worries, and glad it seems to have worked out!

—Nils von Barth (nbarth) (talk) 18:43, 23 April 2010 (UTC)

full bar

Noun defined as if it were an adjective? SemperBlotto 21:44, 13 May 2010 (UTC)

Oops! Thanks, you’re totally right – fixed.

(I was copying from cash bar, which is used differently.)

—Nils von Barth (nbarth) (talk) 21:49, 13 May 2010 (UTC)

birdie

Hi Nils,

Could you {{sense}}-itize birdie#Synonyms?

Thanks in advance!

—Ruakh_TALK 16:12, 18 July 2010 (UTC)

Oops, sorry – done!

—Nils von Barth (nbarth) (talk) 20:28, 18 July 2010 (UTC)

Thanks! —Ruakh_TALK 21:05, 18 July 2010 (UTC)

affix entries

See also: BP

See also: BP

Our affix entries are often dreadful. -ism is an example. I had to remove most of the purported usage examples because the examples were not formed in English by suffixation. I have not yet committed to cleaning up all the etymologies of words ending in "ism". It took a major burst of enthusiasm to clean up -arian, which had truly laughable derived terms (ie, Bulgarian).

As I see it, the senses of affixes are of three types in terms of productivity:

1. Currently productive
2. Not currently productive, but formerly productive in the language in question
3. Never productive in the language in question but productive in another language with English descendants of the words so formed
   1. Productive in the same spelling
   2. Productive in an altered spelling

The first two cases are easily handled, I think. The question is what to do about the last. Subclass 1 could be handled by referring to the entry in the other language, at least in principle. It would be on the same page, so we might be able to finesse the matter somehow. But Subclass 2 (think -isme or -ismus) can't be. Should we have a sense that simply directs users to a suffix entry in the ancestor language. Wouldn't it have to be under a separate Etymology to be true to our system. And it wouldn't really be a morpheme in the language in question, anyway.

Any thoughts? DCDuring TALK 00:28, 3 September 2010 (UTC)

---

Thanks for your dedication DC!

The entire issue of Latin/Greek etymologies for English is a huge mess, since many words and morphemes have been inherited, some productive, some not – and some have come to be productive! It’s very easy to give mistaken etymologies for such classical compounds/inkhorn terms.

E.g., biology is a modern coinage; I’ve tried to give a reasonable explanation there.

Regarding English affixes (esp. from French/Latin/Greek etymons), I agree with your analysis that currently/formally productive affixes are easy, while for non-productive affixes (or morphemes generally), I see two concrete issues:

1. What to put on the affix’s own page?
2. What to put on pages of words that have that affix?

To be concrete, an example is -tomy (is this a legit affix? there’re -otomy, -stomy, -ostomy, -ectomy – but how to sort these is another kettle of fish), with words like anatomy and lobotomy.

This is not productive (outside of medical contexts of coining Grecian/Latinate terms), but there are many terms with this suffix.

I can see two main possibilities:

• Treat it as an ordinary, albeit non-productive, affix (like plural -en)
• Treat it as an foreign term

If treated as an ordinary but non-productive affix:

1. On the affix’s page, discuss etymology, but warn that non-productive
2. On words with this affix, include either an explicit [[Category:English words suffixed with -tomy]] or suitable wording so one can use {{suffix}} or the like, as in “Surface analysis [of anatomy] is ana- ‘apart’ + -tomy ‘cut’.” (here using {{confix}}) – notably, have a category

If treated as a foreign term:

1. On the affix’s page – actually, do not have a page for the affix (unless it is spelt that way in the foreign language), as it is not an English term
2. On words with this affix, discuss their historical etymology, but do not give English forms (at most, give transliterations) – and don’t have an affix category (just list in “Related terms”, say).

In general, this will probably have to be decided case-by-case (and maybe some intermediate cases exist), though for most such affixes (and morphemes with classical roots generally), I think it’s best to treat them in the first way, as “ordinary but non-productive affixes”. My reasoning is that:

• they are meaningful linguistic units (non-productive bound morphemes): there was a regular change from -ismos/-ismus/-isme (in Greek/Latin/French) to -ism in English
• this is actual practice – witness the various pages for -tomy and variants (and -phile, etc.)
• it helps organize what is otherwise a mess – I’d certainly like to have a category for all words ending in -tomy (so I can find out all the bits the cutting off of which has a name)

Another concrete example is (deprecated template usage) -gogue as in (deprecated template usage) pedagogue – I count 5 English words (3 common, 2 pretty rare) that have this suffix. I’d consider this a boundary case; one could probably justify making a -gogue page and category, but as there are (literally) a handful of examples, just listing “Related terms” and giving the same explanation 5 times on each page (which we’d do anyway, to reduce need to click-through) is fine.

More extremely, I really can’t justify having a page or category for cran- or other cranberry morphemes. A complete list of morphemes should include them, but there’s very little value added by this, in my view.

Regarding -ism in particular, it seems it’s become productive in English, as evidenced for instance by vegetarianism (sorry for the -arian example) and many others, though this does not detract from the point you’re making. -ology is also very productive (if wince-inducing in many uses), as for that matter are astro- and bio- but most other classical morphemes probably are not. (-naut is probably barely productive.)

(I really doubt anyone would argue that -gogue is productive, and until (non-Classicist) parents comfort their kids about their *digitotomy when they cut their finger, I think we’re safe in considering -tomy to be non-productive).

To conclude, I think the issue you’re raising is that we need a CFI (and ELE!) for morphemes as well as terms.

What I’d suggest is:

• Any currently or formally productive morpheme should have a page (and affixes at least should have categories);
• Any morphemes with at least 3–5 terms (or so) should have a page (even if non-productive, bound; call it the -gogue test), though cranberry morphemes should not (if only used in 1 or 2 terms, just mention there).

Does this sound reasonable, and shall we raise this on BP?

—Nils von Barth (nbarth) (talk) 06:17, 3 September 2010 (UTC)

I think we have very compatible views. If we simply did it your way in every detail, I would be happy. I will focus on areas of possible difference. To simplify I will drop "language in question" and write "English" as I have no business trying to generalize.

1. Your approach does not explicitly address the use of categories. My ideal would be that each suffix potentially had at least two categories: one for words formed in English and one for other words ending in the same letters not directly formed in English. This would allow us to better support both a diachronic sense of "Derived terms" focused on the historical/etymological process and a synchronic sense focused on the morphology/semantics. I would like this to be supported by a switch in the various affix templates or by one-letter-different variations of the templates.
2. Your approach does not allow for the issue of contributor behavior in some regards (though it does in others). In your approach users will probably add entries for unproductive affixes with even a single English example, if they happen to think of the example.

User-behavior considerations are part of what motivates me to agree with you that we need to have full support for a synchronic/morphological view. My own inclination has been that the morphological view is not very helpful and provides subtly false clues as to the contribution not-currently-productive suffixes make to meaning and, hence, may as well be excluded. But I now view that conclusion as unhelpful to users.

Well-meaning contributors are likely to fill in perceived gaps, sometimes even when the information is elsewhere on the same page (eg, a different etymology or PoS). If we don't have entries for an affix in English, users will add it. If we don't have a complete entry with explanations of look-alike forms, users will enhance entries like -arian with all sorts of nonsense. There is obvious legitimacy to the synchronic view. It needs to be fully supported without interfering with presentation of the diachronic view. The two views need to me presented in a way that doesn't tempt users to add nonsense. For that reason, I would like to suppress multiple etymologies for affixes that actually in some sense have them, eg, -ism from -isme#French, isme in older vintages of French; -ismus#German, -ismus#Latin; and Ancient Greek. Obviously, there has to be shared etymology and semantics to support this presentation and reference needs to be made the various routes by which the affix appears in English.

BP will be necessary to enable us to win technical support for template modification, for the subtle modification of our etymology practice, and the creation of additional categories. In addition, the amount of work required to bring entries into this standard is great. If the presentation is considered good, we may be able to convince folks to devote some energy to the effort. Right now, this class of entries does not have an agreed-on model.

Which entries for English affixes are now closest to being satisfactory that illustrate the issues and our proposed resolution. -ism would be a good example, though we cannot hope to do all the changes to the entries for lexemes that use it. What would have to be done to -arian to make it fully satisfactory? It is too bad that we don't have a good way of search for all entries ending in certain letters. -arian's earlier versions illustrate why this should not be neglected. DCDuring TALK 12:46, 3 September 2010 (UTC)

• A premise of my thinking on these entries is that we should migrate away from hard-coded Derived terms to category-based Derived terms for affixes and, eventually, for words. In order maintain some integrity to the Derived terms heading, I would like all members of the "words suffixed with [suffix]" category to contain all and only words actually formed by affixation in the language of the entry. I would like it if we could show words ending in a suffix but not actually so formed in the language of the entry to appear as Related terms (I have in mind -ism.). A difficulty in achieving either result is that some very important prefixes seem to have multiple etymologies (eg, -er). To show derived terms by etymology would require disciplined use of the appropriate gloss parameter in the affix templates and more categories. Does this seem like a desirable direction? Does it seem worth the work? Can you see how it could be performed by a bot or by AWB? Does the requirement for "discipline" mean that it is likely to become unmaintained over time and then unmaintainable? DCDuring TALK 15:52, 5 September 2010 (UTC)

I think what you’re suggesting is eminently doable – easy to set up, but v. long to make universal – and I agree that it’s a good idea!

As I understand your key concern, it’s about proper etymology and categories. The quick answer is:

“use the ss parameter, and make it change the category”

E.g., {suffix|er|ss=7} would get categorized in “English words suffixed with -er (7)”. (Some wizard could probably make the generated category names prettier and actually readable.)

…and then figure out the best way to cut up etymology – e.g., use Etymology 1 for a productive English suffix, and Etyl 2 etc. for Anglicizations of previous suffixes (if you want to distinguish -ism added in English from -isme added in French and then Anglicized).

For common affixes, having specialized templates (e.g., {suffix-er-1}) to automatically gloss would be really helpful (“frequentive” etc.).

That’s the quick answer; in more detail, I imagine you might want an added elang parameter (Etymological language) or the like to specify in which language a suffix was added, though I wonder if our needs could be met simply by using several etymology sections and ss.

—Nils von Barth (nbarth) (talk) 09:42, 6 September 2010 (UTC)

I would like to use the affix templates to directly distinguish between derived terms and related terms. As we do not have a structure (such as a relational database structure) that would allow category membership to be derived from attributes assigned in the affix entry, I don't think that we can avoid having that assigned explicitly in the template. As we should be using the "gloss" parameter as well, we actually need to specify and coordinate, the link section, the gloss, and the categorization distinction separately. Ridiculous. Perhaps this is yet another aspect of improving Wiktionary that will depend on a radical change in the foundation software.

In terms of priorities among the three parameters, I would rather give up "ss" than the other two. I also believe that "ss" is the hardest to maintain. What if someone decides to reorder the etymologies, or split or combine them? Such a rearrangement could plausibly - likely - be the result of an examination of the results of a successful effort to assign derived terms to etymologies.

I suppose that we could have some obscure template or a bot that maintained the coordination among glosses, "ss", and categories. That seems a rather delicate structure for a volunteer organization to maintain over a long period of time. DCDuring TALK 12:01, 6 September 2010 (UTC)

OIC (re: directly distinguish derived/related in template) – yes, a good point.

The fundamental technological issue, as I see it, is that the basic level of granularity on ’tionary is pages (a spelling of a term). “Language within a page” isn’t a huge problem (b/c languages clearly separate, as in a#English), but etymologies and senses are, both because the separations are sometimes debatable, and because we have lots of incoming links (the big issue with ss).

That is, pages are fine for saying everything you want to about a specific term, but they’re poor for linking to – as you note, if you change the division of etymologies, ss needs massive updating. If it’s re-ordering or merging this can be automated, but for splitting this basically needs to be done by hand.

Some concrete things we can/could do:

1. Have an “ss → (to) gloss & category” table for affixes (probably easily implemented as a template/subpages: e.g., “-ism/gloss 1”, “-ism/category 1”), then have an auto-suffix template that requires ss, and then automatically glosses and categorizes.

   (This could also be done by augmenting {suffix} to use these if present; dunno if that makes {suffix} too complex.)

2. Lock down (multi-etyl/widely used) suffix pages, b/c of delicacy: only registered can edit, have an on-edit/per-page warning “WARNING: Don’t mess with etymology sections (w/o discussion)”, and/or have a bot that checks these.
3. Avoid using ss until etymology divisions for affixes settles down. (Or accept the resulting mess.) Concretely, this can involve requiring well-referenced divisions of etymology before we commit to maintaining it.

This last is a bit disappointing, but seems inevitable: splitting etymologies in principle and in practice requires checking every case of an incoming link, which can be semi-automated (“please check the following list of 2,000 entries ending in -er”, and sort into Germanic/Latin), but can’t be fully automated. It’s not a question of technology limits, but of the structure we’re trying to show.

One alternative is to have maximally fine splitting of affix etymology, so while we may re-order or merge them (which can be fixed automatically), we’re unlikely to split them.

The first two points (have a lil’ lookup table, and some lock-down of these pages) seem easy enough to do.

(As you note, user compliance may be an issue, but if we consider “super-suffix” template to be preferred, we can assume any use of (regular) {suffix||er} requires cleanup (it’s what to use if you don’t know or can’t be bothered with the proper etymology). We can’t ensure everything is clean, but we can mark the dirties and gradually fix.)

—Nils von Barth (nbarth) (talk) 21:23, 6 September 2010 (UTC)

I am intrigued with the idea of hard-to-find/hard-to-edit look-up tables for the complex cases. This would seem likely to have broader application than we are contemplating. If so, it might be useful and interesting enough to attract the attention of our most wizardly types.

While we explore the technical possibilities, we can go ahead and use "ss=" for some cases where there are not too many derived terms and related terms. For example, we could split -arian into at least two etymologies. It only has 30 derived terms and perhaps an equal number of terms that end in -arian and are related. That would be enough for a reasonable field test. The editing activity in setting up all the links should attract some editing attention. We should be able to gauge if structure-disruptive edits are likely to be common. If they are not common we may not have to resort to means that violate the spirit of the place, like locking down this type of entry for reasons that may not seem too compelling to others.

I suggest -arian because we are both somewhat familiar with it. I also know that we can go to the edit history to find a fairly comprehensive list of terms not strictly (diachronically) derived using -arian, but ending in -arian. Most of them are somehow related to one or another etymology of existing senses of -arian and some might fit into the more synchronic concept of affix. I agree that such a concept has some value for some users and for generative morphologists.

If you agree, it seems to be that possible next steps are:

1. Consult with Conrad.Irwin, Bequw, Ruakh, or others of your choice about what we are trying to accomplish and your option 1 ('lil look-up table). They might have other ideas, of course.
2. Work on a limited number of -arian sized, multiple etymology affixes using ss=.
3. Determine how many multiple etymology affixes there are in English and one or more languages of your choice. DCDuring TALK 23:53, 6 September 2010 (UTC)

Sounds good!

—Nils von Barth (nbarth) (talk) 00:09, 7 September 2010 (UTC)

See {{morph}} and referentiality and referentially for simple steps toward morphology distinct from etymology. DCDuring TALK 18:00, 24 September 2010 (UTC)

Looks really good! I’ll add 2¢ at BP – thanks!

—Nils von Barth (nbarth) (talk) 18:22, 24 September 2010 (UTC)

Derived characters

Hello, I noticed you adding derived characters and wonder the following: I would find it extremely useful if the entries for derived characters listed the characters they were derived from, but most are not. For example, at 約 it gives the radical (the left side of the character), but then just says "+ x strokes," without indicating that the character the right side is derived from is 勺. I don't know why whoever created all these character entries in the first place, 6-7 years ago, didn't think of this, because it would be very helpful. Would you let me know what you think? 71.66.97.228 04:35, 31 December 2010 (UTC)

Hi 71,

Thanks for your kind words and interest!

To illustrate what characters a given character is derived from, one uses the “Etymology” section, as described at Wiktionary:About Chinese characters#Etymology.

For compounds, the template to use is {{Han compound}}, as illustrated at 讀#Etymology.

As you know, there’s a lot of work to be done on these – I do what I can, as do a few other editors, but help is certainly appreciated, if you’d like to help!

It is prudent to check an etymology dictionary such as http://www.chineseetymology.org/ (Richard Sears) when doing this, as correct etymologies are not always clear from current forms – what breaks up as a compound today may be a simplification of a different and unrelated character (consider 食).

If you’d like any help with writing these etymologies, please ask – for example, you could write some etymologies and have me check that they look ok.

Hope this helps, and look forward to working together to make the Chinese character sections even better!

—Nils von Barth (nbarth) (talk) 05:23, 31 December 2010 (UTC)

BTW, you can also see User talk:71.66.97.228#Chinese character etymology, where I give more tips.

—Nils von Barth (nbarth) (talk) 05:26, 31 December 2010 (UTC)

Thank you very much; I have been using Mr. Sears' website and even sent him an email, and he was nice enough to write back. I have added a few etymologies and hope you will make sure they are all right. I notice that User:Wihwang used to also add good etymologies. 71.66.97.228 22:03, 1 January 2011 (UTC)

No problem, and thanks for helping – your new contributions look great!

Yeah, I’ve also found Mr. Sears kind and responsive, such as when I send corrections, and Wihwang is another great and interested contributor.

BTW, you may find the alt1= parameter useful when giving etymologies, in case the form of the character that is used is not the standard dictionary form. Most commonly this is |alt1=扌. I’ve given an example of use in this edit to 揀. It’s not necessary to use, but it’s a nice touch – happy edits!

—Nils von Barth (nbarth) (talk) 23:12, 1 January 2011 (UTC)