Wiktionary:Beer parlour/2010/August

August 2010

Conjugation/declension ending

Do we treat word inflection endings (eg -ων the Greek genitive plural ending) as suffixes and create entries for them? —Saltmarsh^{απάντηση} 06:07, 1 August 2010 (UTC)

I think so. --Yair rand (talk) 06:25, 1 August 2010 (UTC)

Yes and no. Some languages have entries for inflection endings and call them "suffixes", but that is not at all what we mean on Wiktionary with a "Suffix" part of speech header. On Wiktionary, a "suffix" is a component added to a word to create a new word. An inflectional ending merely adjusts the grammar. In early days of Wiktionary, this distinction was never made, so we do have many old entries for inflectional endings. However, given our larger base of knowledge now, we should probably revisit that and decide (1) whether these inflectional endins belong in the main namespace, and (2) how should they be labelled? To my mind, they belong in an appendix, since they are not words and do not form words. They are part of a form of a word, not much different from the English practice of capitalizing the first word in a sentence. I'm not 100% opposed to them in the main namespace, but I am quite certain they should not be labelled "Suffix", since that's not what they do. --EncycloPetey 18:59, 2 August 2010 (UTC)

What about endings that are both? For example, in Dutch, the infinitive ending for verbs is -en, so in that sense it is inflectional. However, it is commonly added to other words to turn them into verbs, which would class it as derivational. —CodeCat 19:04, 2 August 2010 (UTC)

The latter usage is clearly a suffix, since it creates new words. It should certainly have an entry. The former instance is the questionable one, since it's simply a standard word ending, and not formative. See -ārius and -tor as examples of how I've been formatting Latin (formative) suffixes. There are a few that have etymologies as well, but not many yet. --EncycloPetey 03:43, 3 August 2010 (UTC)

But my point is that the two instances are one and the same suffix. In both cases it's the infinitive suffix; first case it's attached to a verb (which is accepted to be a verb) and second case it's attached to something else. It would be the equivalent of being able to turn anything into a verb by attaching -re to it in Latin. —CodeCat 09:03, 3 August 2010 (UTC)

But that point isn't entirely valid. The fact that an ending is common to many (or all) forms of a particular part of speech does not make it a suffix. It is a suffix only if a new word was formed by the addition of that suffix. This is what we use "suffix" to mean on Wiktionary in categories, in etymologies, and everywhere else. A suffix creates a new lemma form, with new senses. An inflectional ending creates a form of an existing lemma where the result has the same senses, merely with modification of the grammar. Consider that -ar is a very common ending for Spanish verbs, but it's not necessarily a suffix. The word cantar (“to sing”) was not formed by the addition of a suffix "-ar", but rather descends from Latin cantāre (pres. act, inf. of cantō (“I sing”)), which already had the ending attached in the parent language. That's not to say that some new Spanish verbs haven't been formed by the addition of "-ar" to another word, but cantar does not have a suffix. This distinction is rather important. So, what you call "one and the same suffix" are not actually the same. One is a suffix, and both are endings whose result implies the same grammar, but the label of "suffix" implies something that is true for only one of the two situations. --EncycloPetey 17:44, 3 August 2010 (UTC)

Surely by this logic, English plurals that add -s are just changing the grammar of the word from singular to plural and thus should not be in the main namespace? Thryduulf (talk) 14:52, 3 August 2010 (UTC)

This discussion is about the suffixes themselves, as far as I know. Not the words that have the suffix in them. —CodeCat 15:56, 3 August 2010 (UTC)

m:Requests for comment/Global banners

^ --MZMcBride 22:35, 1 August 2010 (UTC)

does every change to a policy page, no matter how small, need a vote?

Per the edit summary of this edit to the CFI, "Undo revision 9643986 by Yair rand (talk) everything, even adding two commas, requires a vote.", I'm wondering if that (a) really is the case and (b) if so, whether it should be the case.

Obviously, significant changes (no matter the size) should be discussed, and agreed; similarly new policies must also be fully discussed before being implemented and I'm not suggesting otherwise. However, does the addition of two commas that improve the grammar but don't change the meaning, really require a formal vote?

I don't actually know where the requirement for every change requiring a vote comes from, it isn't in WT:POLICY (which is woefully out of date and explicitly discourages voting), nor from WT:VOTE. The best I can find is that it was introduced by user:Connel MacKenzie with this edit to {{policy}}. This was when three older templates for "official policies", "semi-official policies" and "policy think tank" were merged into one (the last was used as the base it seems). However the now-deleted template:Policy-O did not have this requirement (nor did it apparently have a talk page). There is no mention of it at Wiktionary talk:Policy, which, based on the wording of Template:Policy-O, is where any such change should have been discussed before being implemented based on consensus (note, not a formal vote).

I have found [[1]], where at the end Ruakh notes "we never actually approved the current editing-is-forbidden text atop these documents, and a quick glance at the edit history of any of them suffices to show that said editing-is-forbidden attitude was never thoroughly accepted by the community" (that vote ended 16-7-1 (69.565% in favour), but there was not consensus that this was a strong enough majority to achieve consensus to overturn). Thryduulf (talk) 14:47, 3 August 2010 (UTC)

Re: the vote that you link to: Conrad.Irwin told me once that he thought the "support" and "oppose" voters were talking at cross-purposes. Specifically, he argued that the "support" voters were talking about edits to policy pages, whereas the "oppose" voters were talking about changes to policy. I'm not sure whether he was right about that, but we already know we have a problem from the fact that those are two different things! —Ruakh_TALK 18:52, 3 August 2010 (UTC)

As the one who requested the addition of those two commas, I'm quite confused by the rationale behind the reversion to which Thryduulf links. How and why is it a good idea to require formal votes for every little issue, especially since nobody would say that the comma-less version is more grammatical? No question that formal votes are a good thing for substantive changes, but such small changes as this aren't going to affect anything policy-wise. Nyttend 19:11, 3 August 2010 (UTC)

IMO, we should not be requiring a vote for this. —Internoob (Disc•Cont) 01:59, 5 August 2010 (UTC)

I don't think we should either, which is why I brought this discussion up. How about changing the requirements to something like:

Type of change	Minimum support required
Minor edits that do not change the meaning of the policy (e.g. clarification of grammar)	Proposer + two independent users. At least one of the independent users must be an administrator. Discussion should be on or linked to from the policy talk page, Changes must not be made until at least 48 hours after the proposal is made. If two administrators disagree with the proposals (or disagree they do not change the meaning) before the changes are made, then the proposal should be treated as a minor change to the policy. If two administrators disagree with the changes within one week of them being made, the changes should be undone with an edit summary that states or links to the reason. The administrator who made the changes (and the proposer, if different) must be notified on their talk page(s). The changes should not be remade without consensus at a formal discussion per minor changes to the policy.
Minor changes to policy, especially to bring it into line with common practice	Consensus, including a majority of administrators, at a formal discussion lasting at least one week The discussion must be held on the policy talk page and linked to from Wiktionary:Beer parlour or vice versa. If consensus cannot be reached after a reasonable length of time, then changes should not be held without a formal vote per significant changes to policy.
Significant changes to policy	Formal vote with at least two thirds in favour
New policy	Formal vote with at least 75% in favour

How does that all sound? Thryduulf (talk) 09:28, 5 August 2010 (UTC)

1. Oppose -. Even inserting a single comma can drastically change the meaning of a sentence. Therefore, a vote is necessary to see whether or not there's consensus for inserting the comma. -- Prince Kassad 09:36, 5 August 2010 (UTC)

   For starters this is not a vote, it's the discussion that precedes one. Secondly, if you actually read the criteria you will note that they explicitly say that three people, including at least one administrator, need to agree that it does not change the meaning before it can be edited without formal discussion. If a formal discussion comes to a clear consensus that a minor change (and such things do exist) is warranted then we don't need a vote to confirm this. If there isn't clear consensus then we have a vote if people think it likely that it will produce a result (if people don't think it will produce a clear result there is no point in having the vote). Thryduulf (talk) 14:04, 5 August 2010 (UTC)

IMO "everything" should not require a vote (e.g., if adding a comma does not change the meaning), but if we want to move this way, then let me say that I don't think that the last two should be separated. This proposal says (unintentionally, I'm sure) that completely replacing all of the text on an existing policy page with something new ("Significant changes", no?) requires less support than creating a new policy page -- even if the text is identical. WhatamIdoing 20:37, 10 August 2010 (UTC)

Good point, and yes it was unintentional. Which level of support do you think is preferable? Thryduulf (talk) 10:12, 11 August 2010 (UTC)

I think it better that all changes to policy pages require a vote, regardless how minor the changes are. If a change is very minor, it improves the policy only insignificantly. Thus, either the minor change is given up altogether and no significant loss ensues, or the minor change is performed in a vote running for only one week rather than one month. --Dan Polansky 12:01, 1 September 2010 (UTC)

Wiktionary talk:Criteria for inclusion#Generic use

Come and have a go if you think you're hard enough. Mglovesfun (talk) 08:39, 4 August 2010 (UTC)

Long lists of cognates in etymologies

Do what extent do we want long lists of cognates in our etymologies? Sure they're interesting, but they take up a lot of space. what was really need is more proto- appendices. Also can someone read my comment at {{proto}}? Right now the template only links if the appendix exists, which makes it harder to create them. How about linking them with black links, like {{fr-conj-table}} does? It would make it easier even just to create redirects for proto forms that are equivalent. See my changes to sweostor and sweoster for examples. Mglovesfun (talk) 09:52, 5 August 2010 (UTC)

See the discussion #Re-thinking etymology format further up this page,where this was being discussed (until the discussion fizzled out) recently. Thryduulf (talk) 14:23, 5 August 2010 (UTC)

Right now the purported advantages for principal namespace entries such as hail of having something like Appendix:Proto-Germanic *haglaz have not been realized. [[hail]] presents the proto-Germanic etymon in two form from a different script and contains half a dozen cognates from an unlinked PIE root. And this is from the documentation example for {{proto}}. The end result is an etymology section that shows a careless disregard of the needs of any users other than etymology fans.

[[sweoster]] would further benefit from having a link to an Appendix for its proto-Germanic root.

Any changes to the templates that would facilitate the work of rationalizing the long, duplicative and conflicting lists of cognates would be useful. I would think that a worker in the Etymology vineyards could tolerate, or even welcome, a red-link indicating work to be done. Could the display of redlinks for missing proto appendices be an option for registered users? DCDuring TALK 14:57, 5 August 2010 (UTC)

I would like such a feature, and I'm reasonably familiar with the etymologies of many Germanic words, so I would like to help improve things for Proto-Germanic. However, to answer the original question: The problem with replacing cognate lists with a page for the common ancestor is that in some cases the proper form in that ancestor language may not be precisely known or be disputed. So it may happen that we know that some terms are cognates, but we may not be able to provide a proto-language ancestor for them. —CodeCat 15:47, 5 August 2010 (UTC)

I seem to think I found an Old English entry this morning that had 23 cognates, I'll be damned if I can remember what it is. Mglovesfun (talk) 16:22, 5 August 2010 (UTC)

Is it not possible to include in the Appendix for each disputed ancestor term links to competing forms? We often have alternative spellings of Middle English, Anglo-Norman, and Old French ancestors of English words, so alternatives are not without precedent. All of the unattestable Proto appendix entries are really hypotheses subject to disproof or at least diminished acceptance, aren't they? DCDuring TALK 16:43, 5 August 2010 (UTC)

We should fix the {{proto}} instances where alternative forms are specified as the target (eg {{proto|Germanic|askaz, askiz}}) which I've noted at WT:Todo/proto problems#Multiple forms in target. We can note the alternative forms in the appendix pages. This should allow us to enable black-linking. --Bequw → τ 20:10, 5 August 2010 (UTC)

Another issue: We should break all the pages like Appendix:List of Proto-Indo-European nouns into individual entries and categories (that way they can automatically be linked to). --Bequw → τ 20:22, 6 August 2010 (UTC)

Perhaps a related issue: Inflection table templates and form-of entries for proto-languages. Yes or no? The inflection of Proto-Germanic at least is well-reconstructed with few disputed forms, so for the tables I'd say yes at least. Not sure if the form-of entries would ever be used however. —CodeCat 20:24, 5 August 2010 (UTC)

Inflections - yes (several proto-terms already have them), inflected forms on separate pages - no, I see no point in having them. --Ivan Štambuk 09:11, 10 August 2010 (UTC)

Allright. That brings up the next question: how do we name the inflection table templates? We normally prefix them with the language code, but since proto-languages don't have such codes (I think) we need something else. Ideas? —CodeCat 09:52, 10 August 2010 (UTC)

Use codes for language families. Indo-European: ine ({{ine-decl-noun}}), Germanic: gem, Slavic: sla, Semitic:sem and others on this list marked as "collection". Language families usually correspond with genetic classifications, and these codes, which otherwise wouldn't have any useful purpose, can be used for proto-langs. --Ivan Štambuk 10:30, 10 August 2010 (UTC)

Usability Initiative (Vector) Rollout Coming

I'm not sure if this is the right place to post, but I wanted to let people know that the Usability Initiative is continuing the rollout of Vector and the new editing features. The goal of this initiative is to make it easier for new editors to contribute to Wikimedia projects. To date, we've rolled out the changes to approximately 100 projects, including the 10 largest Wikipedias, Commons, and various "back-office" projects such as Meta. We are planning on completing the rollout for the remaining projects sometime in late August.

We wanted to reach out to the Wiktionary community for help in identifying bugs and for general feedback about the new features. It would be very helpful for us to have folks test popular gadgets and other customizations on Wiktionary for Vector compatibility. Information on how to test may be found on our FAQs page. Please post any bugs either in Bugzilla (please file under "Usability Initiative") or on our bug report page on meta. We also welcome general feedback on our feedback page. We'll be monitoring these pages and look forward to your feedback. Howief 22:23, 6 August 2010 (UTC)

Inquiry - Archive.org versus webcitation.org

This is an inquiry about sources which are suitable for use in Wiktionary. The background materials are a diff for the entry "hardlines" and a thread on a user talk page.

I think the main point of discussion here is whether a page archived via http://www.webcitation.org has the same validity as a source / reference as one archived via http://www.archive.org . Assume that it is the same webpage involved which has been archived via each of the two methods.

webcitation.org and archive.org are certainly NOT the same by any means. The main negative point regarding webcitation.org is that anybody can archive most any webpage (barring technical issues, which are manifold), whereas archive.org archiving is a 3rd party activity.

There is a second topic in the background materials shown at top and that is the matter of whether a particular website can be considered a reliable source or not, but I'd like to set that second topic aside for the moment and concentrate on the archiving method.

My personal bias is that the method of archiving is secondary to the value of the source: if the source is not considered suitable for use, then it should not be used regardless of the archiving method; however, if the source is considered suitable for use, then webcitation.org should be an allowed archiving resource alongside archive.org.

Thanks for your input. I will send a note to the two folks who were involved in the background material momentarily indicating that I've opened this thread. --Ceyockey 03:09, 8 August 2010 (UTC)

Your post is unclear (to me). You ask whether webcitation.org has "validity as a source / reference", seemingly meaning, whether it's good as a source of attestation and also whether it's good as a reference. These are of course two different issues (though some of the same considerations affect them). Another point of inclarity in your post is that it seems to be assuming archive.org (the Internet Wayback machine) is accepted as a source, and arguing that webcitation.org is no worse; in fact, though, we don't accept the Wayback Machine as a source of attestation.​—msh210℠ (talk) 15:21, 9 August 2010 (UTC)

As i see it, the underlying issue that Ceyockey is raising is that our non-prescriptive rationale for the decision to exclude websites is that they are not durably archived. As we have known for some time, virtually the entire web is now durably archived (though I'm not sure how usefully accessible the archives are. How do I get a "permanent address" for material found on a given website?). Previously our preference for edited sources led us to Newspapers, Books, and Scholarly journals. The need to accommodate more casual and slang speech led us to accept Usenet. Google has enabled us to bypass print for the print sources. Thus we have a big corpus of relatively high-quality sources justified without much of a hint of prescriptivism.

The durably archived web forces us to re-examine our rationale. Are websites and user forums as good a source as any? AFAICT, the only major problem with using the web as a whole is the existence of search-troll sites that contain meaning lists of words, word groups, or grammatically correct, but otherwise, random phrases. If we could solve that problem, we might then be able to broaden our corpus. Broadening the corpus might warrant some lesser weighting for attestation of sources other than our traditional ones, at least for a transitional period. Or is there another non-prescriptive rationale for staying with our current approach? Or do we want to abandon or qualify our non-prescriptive approach to inclusion? DCDuring TALK 16:25, 9 August 2010 (UTC)

Let me try to be clearer. I do believe that professionally edited content (e.g. non-vanity press books) remains the gold-standard for any supporting citation. I am not arguing that any old website (like the random word lists DCDuring mentioned) automatically becomes valid for use as a supporting citation just because it is durably archived; on the other hand, I am arguing that the method of durable archiving should not automatically lead to rejection of content as being invalid for use here.

A positive example ... A newspaper article can be durably archived as a) physical form (e.g. microfiche) in a library, b) a record in archive.org (rare due to robots.txt blockage), or c) a record in webcitation.org (only existing if technically feasible and a person manually archived via the site). I would not consider archiving at the publisher's site (as in article archives) should be considered durably archived, as this is a self-published archive, only as durable as the publisher's whim to maintain it. In each of these four cases, however, the content should be the same. A newspaper article is a reliable source regardless of how it is durably archived.

A negative example ... the Library of Congress is getting into the business of archiving twitter (or so it seems). That does not mean that twitter posts, as being durably archived (assuming LoC does durably archive them), become fair game for use in reference and attestation. In fact, I would argue that a twitter post should pretty much never be used for either reference or attestation.

Therefore, I'm not arguing for the expansion of scope of what is acceptable content-wise by arguing for relaxation of the scope of what is acceptable based on the medium of archiving, presuming that medium has consensus support as being 'durable'. Thanks for considering this --Ceyockey 01:03, 10 August 2010 (UTC)

Feel free to add Web pages as sources of citations. I've been doing it for years and there was never any problem. Olden guys try to scare you as if the Web content is somehow "inferior" to that of paper, where in fact there is no policy that explicitly forbids it. Paper medium is doomed and there is nothing that can be done to reverse that trend. Amazon sold more Kindle e-books than paper books in the first half of this year. Eric Schmidt says that we generate more content in two days in 2010 than we did since dawn of time till 2003. Get real folks, this is the 21st century. --Ivan Štambuk 08:56, 10 August 2010 (UTC)

It is the 21st century, and one of the features of the 21st century that we're learning is that editors and proofreaders are still needed to get good prose. Random unedited webpages are inferior to stuff that's been feed through an editor whose job is to not waste money by printing material with misspellings and random unneeded neologisms.--Prosfilaes 19:47, 10 August 2010 (UTC)

Wiktionary is not "an arbiter of what is good English, correct English, acceptable English, suitable English, grammatical. Wiktionary is simply documenting, explaining what is in use in English, and other languages." Why should we restrict ourselves to document what has been fed through an editor? Nadando 19:59, 10 August 2010 (UTC)

Editors and proofreaders are obsolescent as the paper medium itself. There is no such thing as "good prose", inasmuch as there is no such thing as "bad prose". These are all arbitrarily defined value judgments on language use usually from the perspective of people who get paid by "correcting" words on the basis of "rules" which are merely generalizations of regularity of occurrence in some preferred register, or simply made up. We should open-mindedly embrace billion+ content creators that the Web enables us to harvest for new and previously unrecorded lexemes. It is a unique opportunity to detach from the sterile and painfully slow process of traditionally lexicography, as well as pretentious institutes and "language governing bodies" which waste taxpayer's money on politically charged decision making on what constitutes a "proper language". There are countless superb writers on the Web, just as good as any paper-only writer. If a word is used informally, colloquially, dialectally or by any other means in a substandard register - it should simply be marked as such, not avoided like plague pretending that it doesn't exist or is of no interest. While the written content of the Web on average is likely to depart from the paragon of literacy (and I remember reading recently that Web 2.0 content, i.e. blogs, forums, social networks etc., now account for more than 50% of all new Web content), it is by no means an excuse of itself not to tap into such vast resource that could provide numerous benefits to the project, particularly in regard to keeping track of new words. --Ivan Štambuk 20:35, 10 August 2010 (UTC)

As Ivan almost says, you should feel free to add citations from high-quality Web-pages. I add a lot of citations from Hebrew print newspapers' online news articles, for example, even when the articles aren't in the print editions. If a word comes up for RFV, such citations don't count toward meeting the CFI's attestation requirement; but most words don't come up for RFV. (Of course, if you think a word doesn't actually meet the CFI, then don't add it. But it's fair game to add CFI-meeting words without simultaneously adding proof that they meet the CFI, unless they've previously failed RFV.) —Ruakh_TALK 19:54, 10 August 2010 (UTC)

If we do get rid of the durably archived criterion (or (my preference) replace it with something like "durably archived works are preferable") we should still imho require citations to be from works that are verifiable without registration (free or otherwise) and require permalinks wherever possible. This will make verification of the quoted material by others very significantly easier. Thryduulf (talk) 10:18, 11 August 2010 (UTC)

I think there are classes of sources that are subject to change by the author or others that are problematic. Doesn't usenet have a provision for posts that are not to be kept for longer than some period, for example? If so, I would assume that the archiving organizations would respect that. What about moderated content such as user comments on blogs and forums?

If we broaden our sources, then we may need a means of generating permanent links from what are likely to turn out to be temporary ones. Among other things I suppose that we definitely need to have access date information at least for websites other than Google and probably for Google as well. Any means of simplifying date and time stamping would encourage compliance.

In addition, the "permanent" links might need to be verified periodically.

The generation of permanent links, the verification of their continued existence, and the verification of a match between the citation as recorded at wikt and at the permanent link all seem important candidates for automation. DCDuring TALK 11:16, 11 August 2010 (UTC)

Where the source is digitally readable it should be possible for verification to be done automatically in many cases (stripping our formatting), but where we omit the middle part of a passage it might cause problems. I suppose we could have stops list (I'm thinking something like User:Robert Ullmann/Mismatched wikisyntax/stops) for these entries, perhaps matched with the entire text or something. Thryduulf (talk) 18:38, 11 August 2010 (UTC)

Re Usenet: There's a way to specify that a post not be archived, and Google respects that, only keeping it for a few days (apparently seven) as if it were a news server.​—msh210℠ (talk) 18:44, 11 August 2010 (UTC)

So, in that case, there is a rather small chance that a cite would be taken during that seven-day window. It would be worse it there were a longer period during which something could be found by someone searching for attestation and then disappeared. DCDuring TALK 20:38, 11 August 2010 (UTC)

Requiring all citations to come from sources greater than say 14 (or maybe even 30?) days old would remove a lot of very volatile sources without impacting on our ability to be covering contemporary language, given that we require uses spanning at least 1 year. Thryduulf (talk) 23:15, 11 August 2010 (UTC)

Verbose usage examples

I've encountered many usage examples in non-Latin scripts that are up to five lines long and I was wondering if we should be so verbose on pages that are already long. The way I see it, for languages not written in Latin, a usex would always show a native script, a transliteration, and an English translation. Japanese entries (e.g. タイ) usually show two native script lines, Kanji and Kana. When the entry is written in one of those, do we need the usex's to show the other? Mandarin entries (e.g. Pinyin), in addition to showing two native script lines, often show two transliteration lines, toneless and toned Pinyin (for a total of five lines per usex). Again, when the entry is written in one transliteration scheme, do we need to show the other? And can we compact the display of the multiple native scripts in these cases? Maybe we could have a template that toggles the display between them or uses a mouse-over. Does anyone else have ideas? --Bequw → τ 04:05, 9 August 2010 (UTC)

Proposal: namespace for reconstructed terms

On one hand, we want to keep hypothetical and reconstructed terms separate from the main namespace, to separate attested fact from scientific reasoning. On the other hand, we currently use the rather generic Appendix: namespace for such terms, which tries to mimic the appendix of a traditional dictionary. The current way of specifying such forms is rather cumbersome IMO, look at a term like Appendix:Proto-Indo-European *só. The only reason we have to specify the whole language name in full and add the asterisk is just to disambiguate it from other articles in the Appendix: namespace. But the page itself also contains the language name like any other main-namespace term would, so having it in the article name is redundant.

Now, with the result of the discussion a bit above, I think it might be better for hypothetical terms to have their own namespace. We could use the new namespace just as we do the main namespace, albeit with some small differences (no form-of pages for example). The term above would then simply become Something:só which is a lot more concise and easier to work with. The namespace name (whatever we choose) should make it immediately clear that the term is reconstructed, as well, so the asterisk can also be left out. —CodeCat 15:08, 10 August 2010 (UTC)

Actually it wouldn't, you'd still need Proto-Indo-European in there to distinguish from other proto 'languages' like Germanic, Norse, etc. At the risk of banging on about it too much, {{proto}} should link even when the appendix doesn't yet exist to allow users to simply start the appendices by clicking on them. Mglovesfun (talk) 15:31, 10 August 2010 (UTC)

Going by that reasoning you could also argue that we need to distinguish languages in the main namespace, i.e. English bed and Dutch bed. But we don't do that, we just have several l2 headers in the page bed, each with the name of the language in question, if the same term appears in more than one language. We can do exactly the same thing with hypothetical terms in the proposed namespace. I see no pressing reason why the article name of a reconstructed term has to contain the name of the language, when the article name of an attested term does not. —CodeCat 15:44, 10 August 2010 (UTC)

I see, so this sort of entry could have several sections? Still, I don't see why these need to be removed from the appendix space. Mglovesfun (talk) 15:47, 10 August 2010 (UTC)

Convenience (shorter names, easier to search) and having a clear and separate purpose for that namespace alone rather than lumping reconstructed terms along with stuff like Appendix:Dutch strong verbs that has little to do with them. As I see it, the Appendix namespace is mostly for 'random stuff we couldn't fit anywhere else'. So it should really be categorised better if we can. Right now I'm saying we can. —CodeCat 15:54, 10 August 2010 (UTC)

We have a lot of namespaces already. Could we use a pseudo namespace, such as Appendix:reconstructed:? Or could we get rid of one of the lesser used namespaces like Concordance: ?--Bequw → τ 20:50, 10 August 2010 (UTC)

Relevant though not strictly on topic, see the latest section of Template talk:proto. Mglovesfun (talk) 14:43, 11 August 2010 (UTC)

Greek transliterations

Wiktionary:About Greek says "The creation of Wiktionary entries for all such romanised forms of all Greek words is not desirable, even when they exist in language textbooks or dictionaries. But it is important to note the existence of the common romanised forms of Greek words which appear in works of literature and to create entries in Wiktionary."

I have found three examples of the transliteration graphein and put them in Citations:graphein (there are very many more on Google books). They are not from language textbooks or from dictionaries. Can I therefore confirm that an entry for this (and similar) word(s) would be acceptable here? If so, what sort of format should it have? SemperBlotto 14:23, 14 August 2010 (UTC)

I thought that "common romanised forms" here suggested English words, let's say Katharevousa. By the way, γράφειν is Ancient Greek. --flyax 15:17, 14 August 2010 (UTC)

It meant Greek words commonly referred to in English texts (most English speakers cannot cope Greek characters). Perhaps most often this will be place names. —Saltmarsh^{απάντηση} 06:20, 19 August 2010 (UTC)

Perhaps as an "English" word, with definition - and etymology saying transliteration of the Greek word. I'll try and think of a good example. —Saltmarsh^{απάντηση} 06:17, 19 August 2010 (UTC)

Patrol right required to test tool

Hi, I have been using this tool on other wikis for patrolling, reverting vandalism and such, and would like to try it out here on Wiktionary if it works properly. It may be specially useful for administrators who need to revert vandalism and delete pages quickly. Thank you! :-) Diego Grez 23:27, 15 August 2010 (UTC)

Custom macros / edit tools?

Hiyas,

I heard rumors (so sayeth EncycloPetey) that one can create custom macros, meaning:

“Create a custom button to push to insert long bits of text”

such as:

{{term||tr=|lang=ja}}

…which would be very useful to me (currently use manual copy/paste, and fast fingers) – any pointers on how to do this? (Thanks!)

—Nils von Barth (nbarth) (talk) 20:42, 17 August 2010 (UTC)

See User talk:Conrad.Irwin/edittools.js. --Harald Khan Ճ 20:49, 17 August 2010 (UTC)

Thanks Harald!

—Nils von Barth (nbarth) (talk) 21:05, 17 August 2010 (UTC)

Works great (thanks Conrad!); I’ve added a link from Help:How to edit a page so future editors will have an easier time.

—Nils von Barth (nbarth) (talk) 23:20, 17 August 2010 (UTC)

εγγονών

Please tell me how you would handle this, perhaps by pointing me to entries in other languages. I have handled it elsewhere by giving each form a separate Etymology heading with level 4 Noun subheads (although they will have etymologies which are almost the same - they will diverge at the final stage). Is it permissable to have three Noun heads under one Language head? Help please! —Saltmarsh^{απάντηση} 05:51, 19 August 2010 (UTC)

"and answer was there none" - I will go with the two etymology version —Saltmarsh^{απάντηση} 05:21, 3 September 2010 (UTC)

Sorry; I hadn't seen this. What do you think of this abbreviation? — Raifʻhār Doremítzwr ~ (U · T · C) ~ 08:55, 3 September 2010 (UTC)

FWIW, I'm not happy with the way I've shown the gender. Can you think of a better way of presenting that information? And is it at all necessary, really? — Raifʻhār Doremítzwr ~ (U · T · C) ~ 09:05, 3 September 2010 (UTC)

Well - I think you have solved the problem - at least to my satisfaction, unless there are other ideas out there (Greek cannot be the only language where this might happen). Thanks a lot! —Saltmarsh^{απάντηση} 14:35, 3 September 2010 (UTC)

You're welcome; sorry the input came so late. I don't normally approve of conflating etymological roots, but in this case the divergence is so trivial as to make the etymological split nothing but a waste of screen space. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 15:30, 3 September 2010 (UTC)

Obsolete forms

The Swedish language has undergone two major spelling reforms in 1889 and 1906. The shortest word known to me as having been struck by both reforms is the noun elf/älf/älv. If this was English, we would have three entries and everything would be fine. But Swedish nouns have 8 inflections, so instead we need 24 entries. This opens up a question: Should the obsolete inflection elfvarna refer to the obsolete basic form elf, or to the current basic form älv? In the former case, elf should list the inflections of the obsolete spelling. In the latter case, that chart of inflections should instead be part of the älv entry. Has this kind of issue appeared before in Wiktionary, and how has it been addressed?

To illustrate this, I now put all three inflection charts in the entry älv#Swedish. Good idea or bad idea? --LA2 07:29, 19 August 2010 (UTC)

I think it's better to list the inflections in the entry they belong to. So for inflections of old spellings, they should be listed in the entry using the old spelling. An alternative (which might work even better) is to simply put '{{obsolete spelling of|älvarna}}' on the entry elfvarna. Then you don't need three sets of inflections at all, and people are immediately redirected to the modern form. (As a point of curiosity, what exactly was the rule/motivation behind the change of e > ä?) —CodeCat 09:37, 19 August 2010 (UTC)

I agree that elfvarna > älvarna is a good solution. This also reduces "elf" to a simple {{obsolete spelling of|älv}}. The alternative, to make "elf" a central point for the inflections for elf, is worse. Translations, different etymologies, different meanings, use examples, pronunciation and other notes (none of which were changed by the spelling reforms) should stay in one place, which is the main entry "älv". -- Both reforms were promoted by school teachers, who wanted to focus on more important things than teaching antiquanted spelling. Schooling was made compulsory in 1842. Many teachers wanted more radical reforms, but had to settle for compromises. --LA2 10:54, 19 August 2010 (UTC)

Expanding Proto-Germanic entries

Inspired by the discussion about proto-languages above, I decided to focus some more attention on Proto-Germanic, which has always had a lot of my interest. So I've written a first draft for editing policy for Proto-Germanic. Take a look at Wiktionary:About Proto-Germanic. I've also made a few templates, see Category:Proto-Germanic templates. I'd like some comments on those, and if you have some changes to make in the policy feel free to discuss them; it's only a first attempt to get something down. And of course, if you want to help improve things, please do! —CodeCat 09:42, 19 August 2010 (UTC)

Wiktionary:Conjugation and declension templates

I have created the above page in parallel with Wiktionary:Inflection templates, following an old discussion here. The reason for this is that we already make a clear separation between inflection templates on one side, and conjugation and declension templates on the other side. There was some confusion over the terms used, and the fact that WT:IT still listed both together didn't help either. I've also made an attempt to codify the naming scheme used by many templates across Wiktionary, using Category talk:Conjugation and declension templates as a base. —CodeCat 10:30, 20 August 2010 (UTC)

The redirects Wiktionary:Conjugation and Wiktionary:Declension might be reconsidered. They currently lead to Wiktionary:Entry layout explained#Additional headings, where no ====Declension==== or ====Inflection==== section headings are mentioned. Maybe they should redirect to CDT instead, and maybe that page should mention under which section heading to put the calls to those templates. --LA2 11:13, 20 August 2010 (UTC)

The ELE talk page also mentions this: I propose that all of the "sections" used in the standard entry layout have a page in the "Wiktionary" namespace that either describes that section in more detail or redirects to this page. While that proposition is another matter, it does at least make more sense to redirect it to CDT than to keep it redirecting it to ELE. So I've changed it now. The CDT page already mentions the names of the sections to be used, in the first paragraph. —CodeCat 13:03, 20 August 2010 (UTC)

I'm very much against pages that try to show myriad details for every language. It made sense when the number of languages used on Wiktionary was small, but now these pages are just too big (WT:Inflection templates is already causing Mediawiki problems), incomplete (Category:All languages is quite big), duplicating content with per-language pages (e.g. WT:Swedish inflection templates) and often neglected. I think all the info should be split out into per-language pages. They would of course be linked to from each language's About XXX page, and also, if needed by topic, using Wiktionary: or Category: pages (e.g. Wiktionary:Language considerations and Category:Entry templates). In a few cases these pages are OK, where the content is quite limited per-language (e.g. WT:Babel), but often I think restructuring is better.--Bequw → τ 16:10, 20 August 2010 (UTC)

Bequw's idea sounds good. Inflection templates can link to each language's page.​—msh210℠ (talk) 16:47, 20 August 2010 (UTC)

I agree it is a good idea. But the use of language-specific templates still has some considerations that apply to all languages. Naming is just one of them. My primary intention for creating that page was to serve as a general reference point for conjugation and declension templates in all languages. So while I think the list of templates can go/be moved to a language-specific page, the rest of the information present there should stay or be moved elsewhere. —CodeCat 19:19, 20 August 2010 (UTC)

The following were the most frequent headings of each level in the most recent database dump, all namespaces included (Talk: and User: too). --LA2 03:21, 21 August 2010 (UTC)

Rank   ==Heading==             ===Heading===           ====Heading====
  1     426872 Italian          931775 Verb             107824 Related terms
  2     335710 English          690291 Noun              99214 Declension
  3     220715 Spanish          246205 Pronunciation     80585 Synonyms
  4     171005 French           242278 Etymology         66123 Derived terms
  5      91786 Finnish          200507 Adjective         60322 Translations
  6      52424 Dutch            190518 Anagrams          41555 Conjugation
  7      51662 Mandarin          57934 Proper noun       27078 References
  8      48463 Latin             35424 References        26247 See also
  9      48244 German            33089 Adverb            17221 Inflection
 10      37630 Esperanto         32763 Hanzi             15260 Antonyms
 11      36720 Portuguese        28900 See also          13402 Readings
 12      33293 Bulgarian         25722 Alternative spel  13165 Usage notes
 13      30980 Japanese          25198 Han character     13040 Descendants
 14      30172 Translingual      16824 Alternative form  12253 Noun
 15      27726 Serbo-Croatian    14926 Participle         7752 Verb
 16      26778 Hungarian         14842 External links     4110 Quotations
 17      20533 Lithuanian        13266 Kanji              3446 Compounds
 18      19224 Danish             8953 Hanja              3243 Pronunciation
 19      17973 Galician           8663 Etymology 1        2631 External links
 20      17907 Czech              8655 Etymology 2        2013 Adjective
 21      14594 Korean             6011 Pronoun            1911 Mutation
 22      13090 Russian            4543 Related terms      1606 Alternative spellings
 23      12553 Cantonese          4217 Interjection       1606 Alternative forms
 24      10964 Swedish            3891 Two syllables      1120 Hyponyms
 25       9337 Greek              3438 Phrase              987 Coordinate terms

I have now created Wiktionary:Dutch templates, which should list all Dutch templates in general usage. If people do the same for other languages, we can treat WT:IT and WT:CDT as obsolete and they can be deleted eventually. Note that in many cases, a page named WT:(lang) inflection templates exists. I think they can be moved to just WT:(lang) templates, which allows them to be more general and also reduces clutter and avoids the ambiguity of the term inflection template. I propose that a new page, Wiktionary:Per-language templates, be created. This new page should provide links to all existing WT:(lang) templates pages, and the opening text of both WT:IT and WT:CDT can be placed at the top. —CodeCat 18:22, 21 August 2010 (UTC)

Year numbering system

At Wiktionary talk:Quotations#Year numbering system there's a discussion about whether and how to standardize the year numbering system used for dates. The main choices are BC/AD and BCE/CE (secular alternative to the former). The former is more common in English overall, whereas the latter was more common on Wiktionary. I think it's best to use one system in entries and then have a preference to allow someone to see them displayed in the other system. To that end I created {{B.C.E.}} and {{C.E.}} and a JS PREF that allows someone to see them as BC/AD (it also moves the AD to before the year). What do others think of this mechanism? Additionally, what do people think the default should be? I was probably a bit hasting in converting some entries to use {{B.C.E.}} and {{C.E.}}, but I'll gladly change the entries and JS if the consensus is for AD/BC. My personal preference is for BCE/CE. --Bequw → τ 17:31, 20 August 2010 (UTC)

BCE/CE is slightly less fraught with religion than BC/AD and therefore better suited for our pluralistic times. However, BC/AD is fairly neutral for most people, having lost much of its association with Christianity in most uses.

I personally favor and recommend the BW/AW year-numbering system, taking 2001 AD/CE as year 1 (See w:Wikipedia.) This has the advantage of conserving screen space for many entries, as all years 1992-2009 will only require a single digit, all years 1902-2009 two digits, etc. The savings for citations alone would be considerable. Another possibility is 2003 as year 1. (See w:Wikimedia Foundation.) This would further increase and extend the space-savings. DCDuring TALK 17:54, 20 August 2010 (UTC)

Huh? Why not 2002? On a more serious note, I've already voiced my opinion at the discussion that is now being centralized here, but I'll repeat it here: I don't think we need to use the same notation in all entries, and, if we decide to do so, then don't care whether we use "AD/BC" or "CE/BCE", but (still with the hypothesis that we decide on cross-entry consistency) don't want "AD/BCE" or "CE/BC".​—msh210℠ (talk) 18:25, 20 August 2010 (UTC)

I think Bequw's solution, letting the users choose, is best. However, I am in favour of using BCE/CE, if only as the default setting. —CodeCat 19:23, 20 August 2010 (UTC)

The problem is that, in practice, this lets very few users choose: As a PREF, it is accessible only to registered users who are sufficiently familiar with the way things work around here to find WT:PREFS; the vast majority of our users will not find it. This needs to be an easily-accessed toggle, in the style of those in the visibility box in the left-hand side of our interface. The technicalities of this discussion are better-explored in Wiktionary talk:Quotations#Year numbering system. Finally, FWIW, I prefer AD/BC (for reasons I give on that policy talk page). — Raifʻhār Doremítzwr ~ (U · T · C) ~ 21:28, 24 August 2010 (UTC)

PREFS works for any user (not just those registered). The sidebar "Preferences" link is also visible to everyone. --Bequw → τ 02:26, 25 August 2010 (UTC)

Can the main checkbox that must be checked to allow any PREF to be used also somehow leave a message somewhere (the way the feedback questionnaire does) so we can count how many people actually check it? (I'm guessing next to none do.)​—msh210℠ (talk) 14:53, 25 August 2010 (UTC)

As a cynic (about the number of people who personalise Wikt) I think we should concentrate on the bog standard appearance of Wiktionary. I'm coming up to my 5th birthday here and my occasional sallies into playing with the appearance have been limited - partly because I don't always understand the terminology and perhaps mainly because I can spend too many hours doing it! Hours more usefully spent expanding entries. As far as AD/CE is concerned - I gave up talking about Christian names years ago, but find little to object to about saying AD or BC until the alternatives are more commonly understood. —Saltmarsh^{απάντηση} 16:27, 25 August 2010 (UTC)

Somebody mentioned in the GP about logging the usage frequency of the different prefs. It would require a separate server (eg toolserver). Was it Conrad? I would find this very useful. --Bequw → τ 20:51, 25 August 2010 (UTC)

{{R:autrefois}}

The template {{R:Académie française 8th}} has become useless (the link was to a redirect page), someone with a bot could replace it everywhere with {{R:autrefois}}. H. (talk) 20:08, 20 August 2010 (UTC)

I disagree. The reference is the Dictionnaire de l'Académie française. Dictionnaires d'autrefois is just a Web-site where the reference's entries may be found. {{R:Académie française 8th}} should link to Dictionnaires d'autrefois, but it still needs to mention the actual reference. —Ruakh_TALK 22:39, 20 August 2010 (UTC)

Numbers and numerals

There is some confusion as to how to structure the vote Wiktionary:Votes/pl-2010-06/Number vs. numeral, so to get an idea for people's preferences, I've made a straw poll. Also, what to do with {{cardinal}} and {{ordinal}}? —Internoob (Disc•Cont) 02:53, 21 August 2010 (UTC)

• I have no preference. —Internoob (Disc•Cont) 02:53, 21 August 2010 (UTC)
• Use "numeral" for headers (and categories?) Vahag 07:54, 21 August 2010 (UTC) Vahag 07:53, 21 August 2010 (UTC)
• Use ===Adjective=== as the ordinal number POS header; aside from that, I don't much care, as long as we're either consistently using "number" or consistently using "numeral". —Ruakh_TALK 13:04, 21 August 2010 (UTC)
• I have a mild preference for "number" and a very strong preference that we should be consistently using one or the other. Thryduulf (talk) 14:20, 21 August 2010 (UTC)
• I prefer numeral for the cardinals and adjective for the ordinals, and strongly prefer consistency from one entry to the next within each class (cardinals, ordinals) and language.​—msh210℠ (talk) 17:37, 23 August 2010 (UTC)
• I slightly prefer 'Use "Numeral" for heading and "Cardinal numeral" and "Ordinal numeral" for categories' over other options, or so I think at this stage of discussion. The option 'Use "Numeral" for heading and "Cardinal number" and "Ordinal number" for categories' also looks okay. I am picking from the five options listed in this revision of the vote. As regards the structure of the vote, I prefer the structure in the linked revision, possibly extended with an option like 'Use "Numeral" and "Adjective" for headings and "Cardinal number" and "Ordinal number" for categories' or whatever it is the adjective-supporters actually prefer. --Dan Polansky 18:44, 1 September 2010 (UTC)

  I think that the idea of bringing this straw poll here was to get ideas of what people actually want, so that options can b given in a vote (if a vote is then desired). Picking only from among the options in the draft of the vote somewhat defeats the purpose.​—msh210℠ (talk) 18:50, 1 September 2010 (UTC)

  You are right. The preferences that I have just indicated were actually picked by me some time ago from a larger set of options including those of using "adjective", so my statement above is inaccurate: "I am picking from the five options listed ...". I have known that the five options listed in the draft have already contained my preferred options, as I have taken part on editing that draft; what I have really been picking from the draft has been the wording of the options. --Dan Polansky 19:01, 1 September 2010 (UTC)

  While this poll is running, I have reverted the discussed vote to a revision that has a single list of options. I have added an option for adjective-supporters. Please edit that vote to add any missing preferred options, and please edit the option added by me to fit what you actually prefer. --Dan Polansky 10:09, 2 September 2010 (UTC)

{{look}}

Usage notes

ELE is not helpful on layout for Usage notes. Style is not consistent across the project. Do we prefer bulleted format (they#Usage notes) or free format (neat#Usage notes) —Saltmarsh^{απάντηση} 06:57, 21 August 2010 (UTC)

I have drawn the implication from the usage of the plural in the header that there could be multiple notes. If there are multiple notes, then bullets (or something similar) are needed to mark the start of a new note. If there is only one note, the separation function is not needed, but I usually insert the bullet, partially because I am small-minded, partially to indicate that there is only one subject covered, and partially to indicated that any additional material on a different subject should be so marked. Some folks are annoyed by the appearance of "1." in front of the sole definition of a term and may similarly be offended by what they see as a superfluous bullet. DCDuring TALK 15:13, 21 August 2010 (UTC)

[[they]] arguably covers three topics in the usage notes, which need to be separated IMO. [[neat]] verbosely covers but one topic, so the bullet is more optional. DCDuring TALK 15:17, 21 August 2010 (UTC)

I've taken to using {{sense}} to highlight which sense(s) the usage notes applies to if it doesn't apply to all of them, usually with the bullet. Thryduulf (talk) 00:18, 22 August 2010 (UTC)

That hadn't occurred to me. Could be useful. Thanks for mentioning it. DCDuring TALK 00:41, 22 August 2010 (UTC)

I have placed a suggested addition paragraph at Wiktionary_talk:Entry_layout_explained —Saltmarsh^{απάντηση} 09:56, 24 August 2010 (UTC)

I use the bullets, because it is often necessary to say something like "In senses 1, 2 and 4 the noun .... etc" Which means that a numbered entry format would clutter the section with unnecessary numbers. -- ALGRIF talk 12:37, 25 August 2010 (UTC)

Bot request for LA2-bot

As per the #Open bot request above, I have started to move Swedish conjugation templates to a separate Conjugation heading (see Special:Contributions/LA2-bot). LA2-bot runs the pywikipedia framework and is active on an irregular, semi-automatic basis on dozens of Wikimedia projects and languages (SUL status). --LA2 20:29, 21 August 2010 (UTC)

Now proposed on WT:VOTE and Wiktionary:Votes/bt-2010-09/User:LA2-bot for bot status. --LA2 10:34, 4 September 2010 (UTC)

Dictionaries

Hey guys. I haven't had the time to edit in a while now, but I thought someone might be able to put a couple dictionaries I have to good use. I have an English-Indonesian dictionary and an English-Western Apache dictionary, both picked up at used book sales long ago. If either of these would be helpful to anyone in adding these languages to Wiktionary, I would be happy to send them. The books are [2] and [3]. Dominic·t 12:02, 25 August 2010 (UTC)

Category:Requests for language cleanup

Why is this split by month? It would be much simpler to just have 1 list. Nadando 02:02, 26 August 2010 (UTC)

I believe the primary reason is so we can see how old each request is, and maybe handle the oldest one first. —CodeCat 09:33, 26 August 2010 (UTC)

Because we speedy delete entries that have been around for a month or more. This system saves clicking on every entry separately and viewing its history to see when the entry was tagged. So it saves a lot of work. Mglovesfun (talk) 13:38, 26 August 2010 (UTC)

User:Wonderfool

Hi! I don't really know whether this is the right place to write it or not, but feel free to move it to another page if it is better to have it there.

Anyway, we must be better on blocking Wonderfool's sockpuppets "on sight". As soon as a user expresses a concern that a user may be a sockpuppet of Wonderfool (like in this RFA), if there is an on-going RFA involving that user, then put the RFA on hold and proceed with CheckUser immediately. If a user is determined to be a sockpuppet of Wonderfool, then immediately block the user indefinitely.

We all know that this user will never be away from Wiktionary/Wikipedia, but we have to be better on preventing him to get access to the admin-tools before it is too late. He shouldn't be allowed to repeat his terrible main-page (or deletion) rampage every time, before he is indefinitely blocked by an administrator. Previously, a new bot was an idea, but it's best if we simply prevent this troll from getting the admin-tools at all.

Thank you. /Heymid 13:20, 26 August 2010 (UTC)

With due respect, what are you saying that we don't already know? Mglovesfun (talk) 13:33, 26 August 2010 (UTC)

What I mean is that he shouldn't be given the admin-tools at all. Like you see in that RFA, someone believed it was a sockpuppet of Wonderfool (which later turned out to be correct). /Heymid 13:37, 26 August 2010 (UTC)

I think my question still stands, no? Mglovesfun (talk) 13:39, 26 August 2010 (UTC)

Was a CheckUser made on the latest sock (Vonants)? /Heymid 13:55, 26 August 2010 (UTC)

Also, it really doesn't matter that much. Quite often he does useful work before he deletes the main page, and when he does, he gets blocked and reverted within seconds. I don't really see the big problem. Ƿidsiþ 14:30, 26 August 2010 (UTC)

The checkuser tool isn't particularly effective at identifying WF socks. The most telling signs are his editing patterns - which as Widsith says - aren't disruptive until he deletes the main page. For quite some time, we blocked users who exhibited his non-disruptive editing patterns - but it seemed, well.. foolish... to block productive editors just because they liked to edit the same things as WF. --Versageek 01:35, 27 August 2010 (UTC)

That has always been my feeling on this — his useful edits always far outweigh the destructive effects of deleting the main page for a few seconds-to-minutes a year. Moreover, the less fuss we make of his attacks, the less satisfying, I assume, they will be to WF. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 01:39, 27 August 2010 (UTC)

Thanks for the answers. What I really wanted to know was how you deal with this user. Great answers! /Heymid 12:37, 27 August 2010 (UTC)

Also, does anyone here know that Robdurbar (a known WF-sock) is banned from editing at the English Wikipedia? Also, this proves that CU evidence is possible on WF-socks (as long as the socks have edited at the same university as the one he claims to be editing at). /Heymid 16:01, 30 August 2010 (UTC)

FYI I get frequent emails about WF sock suspects and often I do check them. The above sentiment is true, other admins are better at spotting WF than the CU tool is. The down side of open source software is that anybody can see how it works. That is also the up side, but in this case it works against us. - [The]DaveRoss 19:24, 30 August 2010 (UTC)

German Prefixes Forming Nouns

There are a number of German prefixes that form nouns. Nouns are always capitalized in German orthography. Should entries about those prefixes be capitalized as well, just because the nouns formed by them are capitalized? For example, consider the prefixes (deprecated template usage) Ur- and (deprecated template usage) Ober-, which are used to form the nouns (among others) Ursprache and (deprecated template usage) Oberhaupt, respectively. The nouns are correctly capitalized, but capitalizing the prefixes which are not nouns themselves seems strange to me. (My examples may not be the best, since both ober- and ur- can be used to form not just nouns but also adjectives (which aren't capitalized), but I'm sure there are some prefixes exclusively forming nouns as well.) Longtrend 13:48, 26 August 2010 (UTC)

My first intuition is to say capitalise all suffixes that form nouns, and don't capitalise any others. However, there's always going to be someone who missed out on some rare obscure non-noun use of a suffix, so I'm inclined to say just not to capitalise them. —CodeCat 14:47, 26 August 2010 (UTC)

FWIW we discussed this on the French Wiktionary in 2009 and decided to redirect from uppercase to lowercase when no other languages were on the page, such as Kilo- > kilo-. Mglovesfun (talk) 14:16, 27 August 2010 (UTC)

Thanks! Sounds plausible to me. If there are no objections, I think we should do the same here. Longtrend 14:25, 27 August 2010 (UTC)

That's an inappropriate use of redirects, IMO. If we allow them, they'll end up getting linked to (both from etymology sections and elsewhence), which is not desirable. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 14:35, 27 August 2010 (UTC)

Hm, I agree. So IMO we should just have the lowercase versions. Longtrend 14:39, 27 August 2010 (UTC)

Agreed. — Raifʻhār Doremítzwr ~ (U · T · C) ~ 14:51, 27 August 2010 (UTC)

Yeah delete the lot, I don't object. Mglovesfun (talk) 12:44, 28 August 2010 (UTC)

Category:Etymology

I've been thinking for a while, would it be better to have the subcategories all feed here, or by language family? For example I've set up [[Category:Romansch derivations]] to feed into [[Category:Romance derivations]] instead of into Category:Etymology. Mglovesfun (talk) 12:40, 28 August 2010 (UTC)

IMO it would be better to do it by language family.  — Raifʻhār Doremítzwr ~ (U · T · C) ~ 19:57, 28 August 2010 (UTC)

Sounds like a good idea to me. —CodeCat 20:38, 28 August 2010 (UTC)

Orthographic Change in the Romanian Wikipedia Project: Its Effects on Wiktionary

Hi guys!

I'm not completely sure that I'm in the right forum to discuss this subject, but I hope you guys can help me!

My name is Robert and I'm an administrator at the Romanian Wiktionary. It has been brought to my attention that the Romanian Wikipedia project has for some reason, changed the orthography of the letters "ş" and "ţ". The Romanian Academy (a monstrous institution of bureaucratic character) decided that the correct forms should be "ș" and "ț" (in other words: changed from a cedilla to a comma).

So, this has created an epic debacle because the operative systems of the world do not recognise these letters as being equal. This orthographic change makes almost 11 000 Wiktionary articles in the Romanian version faulty and in need of adjustment (no one with better programming skills is willing to help me; it implies that I have to amend them manually  ). Problem: if someone adds a word here in the English Wiktionary containing the new versions with a comma, the Interwiki robots will not add a link to the very same article in another Wiktionary that contains the old letters in the title.

I've pondered over this subject for quite some time now, because I don't understand why we should implement this ridiculous modification. I've tried to ask for help to create a solution for the Romanian Wiktionary. Needless to say, help is an expensive commodity nowadays. They don't seem to understand my predicament, because their robots automatically change the old letters with the new ones (N.B. I've asked for help in Romanian and in English, though with little luck).

I've told the administrators that I will continue issuing articles using the old orthography unless a "universal" or "pan-Wikipedia" regulation is implemented.

I therefore ask the users and administrators of the English Wiktionary for advice as to what I am to do. Some users around here are issuing articles using the new guidelines, while others are still using the old orthography. This is neither a sustainable nor acceptable practice!

Best Regards

--Robbie SWE 12:05, 29 August 2010 (UTC)

Are you sure that this is a matter of "old" orthography (cedilla) vs. "new" orthography (comma below)? My understanding had been that Romanian has always officially used the comma below, and that that the frequent online substitution of the cedilla was a result of its being easier to type. (And the English Wikipedia seems to have the same notion — see [[w:T-comma]], for example — though the claim there doesn't seem to be well-referenced.)

But anyway, this seems like a perfect use of redirects. We already use them in various similar cases — ASCII apostrophes vs. curly apostrophes ([[don’t]] redirects to [[don't]]), gershayim vs. ASCII double-quotes ([[ח"כ]] redirects to [[ח״כ]]), Cyrillic breves vs. Latin breves ([[чăваш чĕлхи]] redirects to [[чӑваш чӗлхи]]]), and so on. Except with ASCII apostrophes vs. curly apostrophes, we generally redirect from the common/easy/online form to the correct/fancy/print form, but if another Wiktionary chooses the opposite approach, that's fine: our interwiki-links will point to their redirects and vice versa, and everyone will still get to the entry they want.

—Ruakh_TALK 12:34, 29 August 2010 (UTC)

Indeed, Ruakh, this seems like the perfect use for redirects. However, what form do we lemmatise, the one with the cedilla or the form with the comma?  — Raifʻhār Doremítzwr ~ (U · T · C) ~ 13:49, 29 August 2010 (UTC)

My preference is the form with the cedilla, for three reasons:

1. Turkish uses <ş> (s with cedilla), so if we redirect from cedilla spellings to comma spellings, we'll have to figure out a way to address cases like şa/șa: obviously we can't just redirect from [[şa]] to [[șa]] and say too bad for Turkish.)
2. The difficulties with the comma diacritic affect not just input, but also display for many readers: support for the characters depends on browser, OS, and fonts.
3. It's all well and good to say that the comma is more correct, but it seems like a pointless burden to insist that editors use it.

That said, I think my preference is irrelevant: a few editors here already edit in Romanian, so I really think that decision should be made by them, at Wiktionary talk:About Romanian.

—Ruakh_TALK 18:06, 29 August 2010 (UTC)

Hmmm. I see your points. Ultimately, I concur with your final thought, that we relegate this issue to our Romanian editors.  — Raifʻhār Doremítzwr ~ (U · T · C) ~ 18:18, 29 August 2010 (UTC)

Is there a bot that can do these redirects automatically? It seems like a tedious job to make them all manually... —Internoob (Disc•Cont) 17:09, 29 August 2010 (UTC)

As I understand it, both are acceptable as the printed form. I own a Romanian kindergarten-age abecedary, and it has both forms in free variation. ISO-8859-2 (1987) was designed for Romanian and Turkish and included t and s with cedilla for both languages. At that time, t and s with cedilla were the right way to encode the Romanian letters, and the forms with a comma would have been entirely appropriate glyph variants. It wasn't until 2001 that ISO-8859-16 came along and separated t and s with comma below from the cedilla forms, about the same time as they were added to Unicode. I would argue the political reasons outweighed the typographical reasons to encode new characters, but it's water under the bridge. So it's not an orthographic change; it was more a change in how the same characters were encoded.--Prosfilaes 19:00, 29 August 2010 (UTC)

we generally redirect from the common/easy/online form to the correct/fancy/print form If "we" excludes User:Stephen G. Brown, this is a true sentence. -- Prince Kassad 19:29, 29 August 2010 (UTC)

User:Yair rand/adddefinition.js

This script adds "Add definition" and "Add image" buttons to the toolbox. What do people think about enabling it by default? (It's available in WT:PREFS for testing.) --Yair rand (talk) 23:25, 31 August 2010 (UTC)

Nothing appeared on the entry (like a +/-). Nothing happened when I clicked the toolbox. I use Win XP, FF 3.6.8. DCDuring TALK 23:44, 31 August 2010 (UTC)

The buttons go into the bottom of the "Toolbox" section of the sidebar. The additional buttons aren't showing up? --Yair rand (talk) 23:56, 31 August 2010 (UTC)

Strange, I just tried it on Windows XP Firefox 3.6.8, and it works perfectly. You don't have anything in your monobook.js or vector.js, so I don't understand what could be causing the problem. --Yair rand (talk) 00:21, 2 September 2010 (UTC)