As in [1] and [2]. If so, what has 'label' got that 'context' hasn't? Is it just a younger model? I can't keep track of the never-ending cycle of template changes. Kaixinguo (talk) 13:00, 1 December 2014 (UTC)[reply]
The language code goes in the first positional parameter (instead of named |lang=), which some find convenient. Also, there are some definition labels which are not strictly contexts, so the name is a bit more accurate. — Keφr14:10, 1 December 2014 (UTC)[reply]
Allow checking translations with the translation editor[edit]
I think it might be nice if the translation editor could somehow allow translations that need checking to be marked as "checked". That way people won't need to edit the entry anymore, which speeds things up. —CodeCat19:14, 1 December 2014 (UTC)[reply]
As the presence of Chinese entries grows rapidly on Wiktionary, I would like to propose some further changes to the format of Chinese entries. These changes aim to reduce the workload of Chinese-language editors (more specifically, avoid data reduplication and synchronisation hassles) and further neatify the code of Chinese entries. The changes include:
Introduction of "lemma forms" for Chinese entries. This follows from sporadic suggestions and discussions raised before, such as at Talk:個. Copying my post there, the arguments for the introduction of lemma forms are:
... introducing the idea of lemma forms, so that information is all kept centralised and the trad-simp entries do not have to be synchronised. Currently the supposedly established practice of synchronisation is poorly maintained, from what I observe from my bot's sweeping edits. Conceivably the lemma forms should be traditional, since trad-to-simp conversion can be performed reasonably reliably. It's not because I discriminate against simp; I grew up with those characters too. That way we could just enable automatic trad-to-simp conversion in zh-usex, and all the information on the page (with the minor exception of the title) would be di-scripted.
In detail, this lemma form proposal would entail:
Centralising all information (etymology, pronunciation, definitions, "see-also" terms, compounds) at the traditional form, which is considered the lemma form of a Chinese word. If multiple traditional forms exist, the most common form is chosen as the lemma form.
All Chinese text under the Chinese header, including example sentences, related terms, synonyms/antonyms would include both scripts. Example sentences in both scripts can be generated automatically by the template {{zh-usex}}.
Other non-lemma forms will be converted to a soft-redirect - see User:Wyang/历史 and User:Wyang/语. The format of these redirects is negotiable but the principle is they should contain as little information as possible.
Adopting a new neater version of the Hanzi box - {{zh-forms}} (backend is Module:zh-forms). Now that many complex editing tasks could be performed automatically with the Lua language, there is no need for partial manual coding of the Hanzi box as is currently implemented. Instead of the code
(Not an editor of Chinese) I always thought it was interesting but perhaps inconsistent that content has been removed from so-called British entries and focussed on the American spelling, the reason given being that it would be too much work to maintain both entries, whilst having a far greater number of simplified and traditional Chinese entries to maintain. Kaixinguo (talk) 11:24, 2 December 2014 (UTC)[reply]
The idea of centralization sounds logical. I have a couple of questions:
Will the centralized information on the lemma page be too crowded? Since both formats will be displayed.
Will the Hanzi-box still display the characters in the order of simplified-traditional? Would it make more sense to switch the order to trad-simp now that the lemma page will be the traditional?
The soft redirect will not categorize the simplified entries. Is that ok?
Instead of the soft redirect, what about a simple page similar to alternative spelling that we use for other languages?
Support in principle. My preference is simplified for lemmas but if the rest decides traditional, I won't object. (I will give my reasons for preferring simplified over traditional later.)
I also support this proposal in theory. It would save myself and other Chinese editors a lot of time dealing with the synchronising work. Using the traditional form as the lemma makes sense, since mapping from trad->simp can be easily automatised, while simp->trad would require the intervention of human editors. Are we at the stage now where we can see a model of this proposed change? ---> Tooironic (talk)
Another argument for traditional is that it's more widely represented within the time span of the language we call "Chinese". Simplified is only about... half a century old? —CodeCat23:02, 2 December 2014 (UTC)[reply]
Pro-simplified arguments:
Much more common today. Used in (mainland) China (also Singapore, Malaysia, Indonesia) as the obviously biggest user of the Chinese language (in any form). Not sure if there is statistics about it but you can guess that the explosion of Chinese in Internet is due to China proper.
Some will disagree but I doubt China will go back to traditional characters. Traditional characters are used only in Taiwan and Hong Kong. The status of both is less than a fully independent state. Taiwan government is working hard on preservation of traditional characters for a reason. Many Hong Kong citizens are fluent in English, so foreigners don't need to know Chinese (Cantonese or Mandarin) to get by.
Overseas Chinese almost completely switched to simplified. Universities mostly use it in education. Also preferred by learners for practical reasons.
Ancient books are all converted to simplified spellings, including works in Classical Chinese. How often do you need to read ancient books?
Japanese shinjitai is also relatively new but the battle shinjitai vs kyūjitai (pre-reform spellings) is almost over. The simplification process wasn't agreed on with communities outside China, so the resistance is still big and anti-simplification propaganda affects some people. It shouldn't be politicised and there's no need to link simplified Chinese with communism. It has happened, compare with 1918 reform of the Russian spelling. Although there are flaws, there are obvious benefits.
Simplified Chinese jiantizi is standardized much better than traditional Chinese fantizi. It's fantizi that still has more variants, obscure characters and IME (input methods) are better suited for simplified Chinese.
Although traditional Chinese is the original form and links better to Sino-Xenic derivations, it's not always true. Japanese has its own simplification - shinjitai, which matches 30% (I guess) with jiantizi and has its own, Japanese specific forms. Korean and Vietnamese have their variants to some extent and for these languages, Chinese characters are no longer the writing system they use, especially Vietnamese.
Most Chinese contributors are from mainland China, the majority of learners, IMHO, focus on simplified Chinese. I wonder how they feel when they find they have to click on the soft redirect links to get the info. --Anatoli T.(обсудить/вклад)23:42, 2 December 2014 (UTC)[reply]
I wish to stress that I won't object traditional over simplified, if everybody wants so but the choice should be carefully weighed out. Languages and scripts are like currencies, it's not we like but what's more common and practical. --Anatoli T.(обсудить/вклад)01:11, 3 December 2014 (UTC)[reply]
Question: Is there a one-to-many correspondence between traditional and simplified simplified and traditional characters, or is there a many-to-many correspondence? In other words, are there any traditional characters that correspond to more than one simplified character? --WikiTiki8901:24, 3 December 2014 (UTC)[reply]
Usually it's a one-to-many correspondence between simplified and traditional characters (in this order). So a conversion from simplified to traditional would be harder but if traditional characters are used as a source for usage examples, etc, then it would still work. It's quite rare but a simplified version should be manually fed into templates, when there are variants. Automatic conversion tools work better (but not 100%) from traditional to simplified. --Anatoli T.(обсудить/вклад)01:38, 3 December 2014 (UTC)[reply]
Apparently, there are 19 (?) such traditional characters: 沈, 份, 乾, 畫, 夥, 鹼, 藉, 俱, 瞭, 麼, 彷, 卻, 甚, 么, 於, 餘, 摺, 徵, 著. Most common/notable is probably 著. Wenlin editor always asks how you wish to convert the character to simplified. Don't fully trust Wiktionary on this, single-character entries need a lot of attention. --Anatoli T.(обсудить/вклад)01:53, 3 December 2014 (UTC)[reply]
The funniest character is 幹, which, when incorrectly translated causes mistranslations, like "dry food" becomes "fuck food". 干 is both simplified and traditional for this sense. --Anatoli T.(обсудить/вклад)01:59, 3 December 2014 (UTC)[reply]
That explains some of those Chinese mistranslation memes. Anyway, that means that if we have an automatic conversion from traditional to simplified (whatever it is used for), then it should require a manual conversion whenever those characters are present, right? So I have an idea that would let us have the lemmas at the simplified character entries and still make use of automatic conversion: At simplified character entries, we can group the definitions by traditional equivalents that are indicated in the headwords and include HTML anchors. Then the traditional character entries will link to the correct anchor at the simplified character entries, bringing the reader directly to the definitions he was looking for. --WikiTiki8902:17, 3 December 2014 (UTC)[reply]
With automatic conversion it always requires a knowledge/intervention of an editor, whether you create a simplified or traditional character term, character forms and pinyin. See 台湾 (Taiwan) or its traditional equivalents 臺灣 and 台灣. Or others like 什么. The simplified entry could contain a usage example, where traditional character are used with parameters when a different conversion is required: 這是什麼？／这是什么？ ― Zhè shì shén么? ― What is this?--Anatoli T.(обсудить/вклад)02:30, 3 December 2014 (UTC)[reply]
Thank you for the replies. Answering Panda10's questions:
Centralised information on the lemma page will not look crowded - the examples and derived terms will be in collapsed mode. Please see 雨 for an example.
Good point. I have changed the order.
Categorisation will be added.
Personally I think the current format for alternative spellings will be excessive for non-lemma Chinese forms. Pronunciation, definitions, see-also terms will be 100% the same.
Currently both are displayed, but envisageably some sort of gadget could be developed for this purpose, using what the Chinese Wikipedia and Wiktionary do.
@Tooironic The new lemma forms would look like 雨 (with all Chinese text in both scripts), and the non-lemma forms would look like User:Wyang/历史 and User:Wyang/语 (or other formats if people prefer).
I entirely agree with CodeCat's reason that Traditional Chinese's long history is a factor not to be overlooked here. It is the reason that Hanyu Da Cidian, the most inclusive Chinese dictionary produced by PRC and in history, uses traditional forms as headwords and most of its citations. The main advantage would be the automation of the trad-simp conversions. Graphical etymologies and descendants would also be heaps easier when done at the traditional forms - see for example 風#Etymology and 學#Etymology.
The choice of script for the title is IMO not a crucial choice, since the title would be the only Chinese text that is not di-scripted on the lemma pages. (The title may even be di-scripted with gadgets.) Soft redirects shouldn't be too much of a problem - since information is not lost. Wyang (talk) 04:33, 3 December 2014 (UTC)[reply]
I think categorisation should possibly mirror traditional entries, if that's reasonable and possible (without having to edit the entry manually - done and forgotten). A simplified entry should have a definition line, and (IMHO) a short usage note (standard in PRC, Singapore, Malaysia, etc.). I'll give it a thought. --Anatoli T.(обсудить/вклад)05:20, 5 December 2014 (UTC)[reply]
I still find the dark gray template at the simplified entry too different from the current standars. Would it be too complicated to create a template with the below layout? How about adding the Hanzi box? Another topic: As the language develops over time, is there a chance that the simplified character will get a new meaning that the traditional character will not have?
==Chinese==
===Noun===
'''历史'''
# ''simplified form of'' '''[[歷史]]'''
====Usage notes====
* '''[[Simplified Chinese]]''' is mainly used in Mainland China and Singapore.
* '''[[Traditional Chinese]]''' is mainly used in Hong Kong, Macau and Taiwan.
My preference would be to have minimal information on the non-lemma pages, i.e. link only. Definitions and other details (including parts of speech and hanzi box) are covered at the main entry, for clarity and ease of maintenance (e.g. 保险). Answer to the second question: No, they are strictly two versions of the same thing. Wyang (talk) 02:25, 6 December 2014 (UTC)[reply]
Support I support this proposal. I was worried about categorisation but I read above that it will be handled. For the conflict between simplified and traditionnal, is it possible to have a template on the non-lemma page which will parse the lemma page, extract the parts corresponding to the non-lemma word, convert it to the non-lemma script and display it? This way, the lemma and non-lemma page will display the same information. Meihouwang (talk) 15:00, 6 December 2014 (UTC)[reply]
We can use an existing L3 header, which is legal! - ===Hanzi=== and probably not just for simplified but ALL Chinese entries, Wyang, you may get away with the ===Definitions=== idea after all but using ===Hanzi=== instead. Chinese may not need PoS headers:
==Chinese==
===Hanzi===
# ''simplified form of'' '''[[歷史]]'''
...notes follow
Sorry, I don't understand your comment. I think you mean that the singular and plural forms are identical, which is fine, but also irrelevant to my intended point.
To expand upon my earlier question, if ===Hanzi=== has been used primarily in single-character entries as a header indicating information about that specific character that does not belong under any of the other headers (such as character composition, Unicode chart links, historical development), then the sample use above (in a multi-character entry, and not as a header indicating info about these characters, but rather as a generic non-POS header) strikes me as misleading and potentially confusing. ‑‑ Eiríkr Útlendi │ Tala við mig07:11, 7 December 2014 (UTC)[reply]
The information (non-lexical) you're referring it is stored under ==Translingual== L2 header, not under ===Hanzi=== L3 header, everything lexical related to single or multiple character terms is the same - it's lexical, transliterations and pronunciations in the new format are under ===Pronunciation===. Unlike Japanese (also Korean, Vietnamese) - hanzi is the only writing system for standard Chinese, so whether it's a single character (even a component) or a long word, they can all be handled under one header. Rather than using ===Definitions=== (there is no agreement on this heading and an administrator may potentially removed it), I suggest using ===Hanzi=== (which is legal) or we need to promote ===Definitions=== and make it legal. --Anatoli T.(обсудить/вклад)09:34, 7 December 2014 (UTC)[reply]
I'm neutral on the choice of header, if any. My feeling is that this general format gives too little emphasis on the actual link, in that it does not specifically inform readers of where to find definitions and other content instead. I'm quite sure that people might start complaining about "no definition, no pronunciation" in Wiktionary:Feedback, since the redirect appears no different from a normal link and is not conspicuous enough. Wyang (talk) 20:23, 7 December 2014 (UTC)[reply]
You can add the information after the 'simplified form of 歷史' - in the same line - as you planned in the original gray box. --Panda10 (talk) 21:05, 7 December 2014 (UTC)[reply]
First things first. We need descriptive templates for links to traditional and usage notes templates, which can mention that all the info is in the traditional form entry. It's better to split them into two. Simplified characters may be also traditional for some senses or alternative forms, like 台 or 干. "Hanzi" header may be used for both traditional and simplified entries. --Anatoli T.(обсудить/вклад)23:05, 7 December 2014 (UTC)[reply]
Since I am not an editor of Chinese, my apologies for my questions. But when I click on the traditional link in the redirect box, where is it supposed to jump to? To the translingual entry? Or to the Mandarin entry? Currently, it just goes to the top of the page.
Do you need the collapse function for the 2-line simplified/traditional usage note? Could they be centralized? For example: placed into their own box on the right, only once for the entire entry. Or no box, just simple text in small font, right under the Chinese L2 header, before any of the L3 headers start. It's a central note, valid for all ety's.
I agree with Anatoli that the colors may not be necessary in the redirect, just the text, although I understand that the color would highlight the fact that this is a redirect, not just a usual ety. For the text itself, there could be several variations, depending on which part should be first and which second. Just reducing the number of double quotes might help to simplify the look. Two possible examples:
Thank you both for suggestions. My understanding is that Wiktionary:ELE serves as a format guide for normal entries (The first sentence on the page says "While the information below may represent some kind of “standard” form, it is not a set of rigid rules."). Wiktionary lacks policy or even precedents of soft-redirects, for situations where a multi-scripted language consistently redirects forms written in one script to the forms written in the other script. This is of a completely different nature to the "non-lemma forms" commonly mentioned before, which were mostly stylish (naivety), compounding (sockpuppet), historical (anæmia) and erroneous (accomodation) variants, with very few being actual regional variants (compare the non-redirection of colour/color). As a consequence, there is no properly designed layout for this new category of soft-redirects, and existing layout fails to give due emphasis to the link to information, misleading readers to think that the form is an uncommon (and unimportant) alternative variant. In the case of 干, the inconspicuity of the redirections does not create the impression that two thirds of the definitions of the character should actually be found at the respective lemma forms.
Answering Panda10: The link to traditional links to the Chinese section, if it exists. The merger of Chinese variants is ongoing. The box will only show the notes if the variant type is "simplified". It could also be "ancient", "obsolete" or "variant", in which case the notes would not be appropriate. Characters like 干 are very rare - most will have only one note displayed, thus having notes underneath the link might be more explanatory. Wyang (talk) 00:09, 9 December 2014 (UTC)[reply]
I would say {{pinyin reading of}} or {{ja-romaji}} are close equivalents to soft redirects. I personally don't have strong objections to Wyang's suggested format but I'm almost sure, there will be strong opposition to the new format, once we start changing entries. The votes, discussions on Japanese romaji entry format is a good example of that, despite the seeming triviality of romanisation entries. Specifically, the definition line (starting with #, not generated by a template), a PoS header (including "Definitions" or "Hanzi") should be sorted first - need to get some kind of legitimacy. The topic is mostly ignored now by people, who will surely raise their voice later. I don't want to create obstacles, I fully support the change (despite my preference for simplified) but I'm worried about time and efforts that could be spent. --Anatoli T.(обсудить/вклад)21:35, 9 December 2014 (UTC)[reply]
{{pinyin reading of}} and {{ja-romaji}} are not for native scripts, whereas these redirects will be for native scripted forms and therefore need to be more eye-catching. IMO the first step is to make sure the introduction of lemma forms is agreed upon, and further changes to formats can be discussed once the first is established. A vote shouldn't be necessary if there is overwhelming support from related editors - and it seems from the discussion above that we can presume that step 1 is accepted by most, if not all. Wyang (talk) 09:02, 11 December 2014 (UTC)[reply]
I know they are not for native scripts but the lack of "#" on a definition line on romaji entries caused quite a stir (even if it was generated by a template). The new format examples introduces Definitions header as well (when simp./trad. is shared in some cases), for which we still have opposition. I've made some 字 entries with this header, anyway. I think you can proceed. --Anatoli T.(обсудить/вклад)00:47, 12 December 2014 (UTC)[reply]
For the record, I disagree with removing definitions from simplified entries. Let those who want to concentrate on traditional entries do so; they should not be forced to create simplified entries at the same time. --Dan Polansky (talk) 12:13, 14 December 2014 (UTC)[reply]
The problem is not about having or not wanting to create simplified entries but about having them badly out of sync. Long-timers have been putting lots of efforts keeping them in sync but bewcomers often fail to do so, especially with entries with derived terms, see also's, etc. It's admittedly hard to synchronise large entries. Please note that the changes User:Wyang made will allow to show both forms in usage examples, etc. Editors only need to provide the traditional form. For the record, no single published or online dictionary has identical contents of both traditional and simplified Chinese, it's always one or the other. The other form is also provided. Our objective is to have both forms for each user example, synonym, etc. so that there is no information loss and users who have difficulties with traditional Chinese could use simplified right next to it (or below in multiline usexes). The only disadvantage (at this moment) to simplified Chinese users is having to click through the link but even sophisticated electronic ductionaries are not able to show both forms in usexes, users have to set options as in Pleco or Wenlin. --Anatoli T.(обсудить/вклад)10:48, 19 December 2014 (UTC)[reply]
The following is my opinion as an active Chinese editor. According to what Atitarev tells me, we do not currently have a way to store both traditional and simplified Chinese entry content in a central database which can then be displayed at the corresponding trad and simp entries. Given this reality, I would support converting all simplified entries to hard-redirects to their traditional counterparts with the exception of 1) entries which have Japanese/Korean/Vietnamese readings, and 2) simplified entries which have more than one traditional conversion. In the case of these two scenarios, we can still provide the soft redirect. This may involve a bit of stuffing around, but I think it is the best compromise we can reach given the circumstances. I can tell you from personal experience that the hours of work I've spent on duplicating simp/trad entries and synchronising all the content (etymology, example sentences, synonyms, derived terms, etc.) is something I am very keen to say goodbye to. If we can get read of this time-wasting activity altogether, we can boost the efficiency of our Chinese editors, and in turn largely increase our coverage of the Chinese language on the English Wiktionary. ---> Tooironic (talk) 06:05, 27 December 2014 (UTC)[reply]
The conversion to having simplified entries re-direct to traditional seems already to have begun. Should it not wait until the vote is over? Kaixinguo (talk) 02:49, 10 January 2015 (UTC)[reply]
Somewhat similar to the discussion just above and Wiktionary:Tea_room/2014/December#社会 and 社會, I suggest to make some changes to Japanese entries, which are kyūjitai and is not current use (some kind of exceptions can be made for kyūjitai, which are still in use, perhaps. Even the format of 社會 is too much, IMHO. It shouldn't contain translations, romanisation, etc, just a one-line link to lemma - 社会. I have no exact format at the moment, just wish to mention and get opinions. Calling @Eirikr, TAKASUGI_Shinji, Haplology, Whym (please add anyone I missed). --Anatoli T.(обсудить/вклад)03:50, 3 December 2014 (UTC)[reply]
I agree that a one-line link would be sufficient for them. As for the wording, I would prefer saying something like "archaic" (as in the template Takasugi-san suggests) or "rarely used", than "not in current use". At least some words in kyūjitai such as 藝術(gei, “art”), 櫻(gei, “cherry tree”) appear to me more like archaic than obsolete (in the sense that most people, if not all, can understand). This is perhaps because I keep seeing some institutions and people using those forms as part of their names. Whym (talk) 00:19, 4 December 2014 (UTC)[reply]
{{archaic spelling of}} is not the best solution, IMO, as there are archaic spellings, which are not kyūjitai. Kyūjitai merits a separate template, with categorisations. I also support removing all additional infos, definitions, examples to avoid duplications. --Anatoli T.(обсудить/вклад)00:52, 12 December 2014 (UTC)[reply]
Here is a description of the new capability added to OneLook. It already had wildcard searches which allowed searches for words ending in "full" (which we don't as "full" is not a suffix and {{compound}} does not categorize). DCDuringTALK17:02, 2 December 2014 (UTC)[reply]
Using templates to synchronize US-UK spelling[edit]
Esperanto participles - markup in headword lines[edit]
FYI, an editor currently mass replaces "{{head|eo|participle}}" with the likes of "{{eo-part|alĝustig|ite}}", as in diff. I don't know the benefit of such a replacement; if you are an Esperanto editor (User:Mr. Granger?), you might want to have a look and see whether the change seems good to you. --Dan Polansky (talk) 11:03, 6 December 2014 (UTC)[reply]
That sounds like a reasonable goal to me—every participal is either adjectival, adverbial, or nominal, so it's certainly possible to move all of them to the subcategories, and maybe that would be useful in some way. There's no need for User:Embryomystic to do it by hand, though—it could easily be done by bot. —Mr. Granger (talk • contribs) 14:12, 6 December 2014 (UTC)[reply]
Mass or indiscriminate adding of RFE - requests for etymology[edit]
I noticed a user is mass additing RFE tags to Estonian entries; not using a bot but in considerable volumes anyway. My opposition to these requests tags is probably known; I still oppose this practice. If there are other people who like me think that the tags are pointless especially when being added indiscriminately, maybe we could do something to prevent the continuation of addition of these tags. For reference: Category:Estonian entries needing etymology, Recent changes in that category. --Dan Polansky (talk) 15:10, 7 December 2014 (UTC)[reply]
All entries ought to have etymology ultimately, but the absence of an ety section already indicates that it is missing. RFE should be reserved for words that a user has a particularly keen interest in; otherwise we might just as well auto-add it to every entry, which is unhelpful for readers. Equinox◑16:15, 7 December 2014 (UTC)[reply]
My experience is that a notice makes people more likely to add information. It has helped with inflections for example. Furthermore, the category is a to-do list, as it shows all entries that still lack an etymology. Keen interest is irrelevant; for every entry where a user adds a request template to indicate an interest, there are ten more where the user has simply left, disappointed, without adding a notice. —CodeCat16:21, 7 December 2014 (UTC)[reply]
We also (judging from the feedback page) have users who leave disappointed because they literally can't find the definition among all the tables of contents and large ety and pron sections! Equinox◑16:32, 7 December 2014 (UTC)[reply]
But we're talking about a category that would contain millions of entries- entries which require individual attention by human beings with knowledge on how to do etymologies. It would never be cleared in your lifetime or mine- what kind of a motivator is that? Chuck Entz (talk) 22:43, 7 December 2014 (UTC)[reply]
I think you may be right after all. If there are votes for every little issue you have, people will start to ignore those, too. I know I will. —CodeCat17:14, 7 December 2014 (UTC)[reply]
It's not a little issue. It's a deviation from a previous practice. Up to now, we did not try to use RFE (which is still named a "request") to cover all missing etymologies; even right now, it is not our practice. Fact is, you are not very good at creating votes that result in support for your changes. Of the top of my head I don't remember any, but there probably is at least one such vote. One of your recent proposals has a vote which does not show consensus for your change: Wiktionary:Votes/2014-08/Migrating from Template:term to Template:m. --Dan Polansky (talk) 17:30, 7 December 2014 (UTC)[reply]
In my experience, a limited number of requests (of any type) is necessary and most editors and some users do this but when they are too many, it's demotivating (an exception is, obviously when there are known editors who do this on a regular basis or there is a previous agreement). I dislike when people add translation requests to any entry they edit, especially when it is a request of a non-trivial term and into a language we have few contributors for. --Anatoli T.(обсудить/вклад)03:47, 8 December 2014 (UTC)[reply]
A significant number of the 675 uses of {{attributive of}} appear under the Adjective PoS header. The overwhelming majority of these are not adjectives, as the use of the template suggests and as tests for adjectivity would likely show.
Do we want to keep these inane entries and add more to preempt the creation of shoddy, inane Adjective PoS sections by well-meaning contributors?
Do we want to clean them out by RfV to test the validity of their adjectivity?
Do we want to allow contributors to delete all of them that are not attested and do not have any other definition that might warrant inclusion?
There can be no mass deletion. We can rfv them or rfd them all separately. Or change the header and templates to noun. That's the only one that can be done en masse. Renard Migrant (talk) 23:22, 8 December 2014 (UTC)[reply]
There usually already is a Noun PoS. So you think it would be OK to move the offending sense line to the existing Noun header?
Are you at all concerned about the likely re-creation of an Adjective PoS section after the changing-to or merging-into the Noun PoS header? DCDuringTALK23:46, 8 December 2014 (UTC)[reply]
Translations of non-lemma forms (see newest)[edit]
Would a superlative form be considered an "inflected form"? According to Wiktionary:Entry_layout_explained#Translations: "English inflected forms will not have translations. For example, paints will not, as it is the plural and third-person singular of paint. In such entries as have additional meanings, these additional meanings should have translations. For example, the noun building should have translations, but the present participle of build will not." --Panda10 (talk) 16:42, 9 December 2014 (UTC)[reply]
Not in all languages. Latin comparatives and superlatives are considered lemmas in Wiktionary. And in many other languages such as Slovene and Finnish, the comparative and superlative are what you might call a "half-lemma": they have a non-lemma definition, but they also have their own inflection table like a lemma. Participles are treated similarly in many languages. —CodeCat19:40, 9 December 2014 (UTC)[reply]
Because we presumably list the translation at the lemma form, and inflected forms of the foreign word at the foreign-language entry. If you want to know how to say "newest" in Hungarian or Polish, you go to [[new#Translations]], find the Hungarian or Polish word, go to that entry, and see what the superlative of it is. I'd be opposed to listing translations of nonlemma forms, because of the sheer quantity of translations that could theoretically be added, especially for verb forms. I don't relish the idea of seeing an entire translation table of third-person singular forms at [[walks]] and two entire translation tables (one for the past tense and one for the past participle) at [[walked]]; especially not for languages where those forms are not distinct from that language's lemma form in the first place, meaning the entries for those languages would be redundant to the entries at [[walk]]. We'd never be able to keep them coordinated with the translations tables at the lemma form, which is why we already use {{trans-see}} for near-perfect synonyms, alternative spellings, and the like. —Aɴɢʀ (talk) 16:47, 9 December 2014 (UTC)[reply]
It seems to me that it would make it much easier for the reader if they could look up the translation by going to the exact word for which it is a translation. This would be doubly useful for words for which the lemma might have a dozen different meanings, but a particular inflection only occurs for one of those meanings. bd2412T17:26, 9 December 2014 (UTC)[reply]
Let me introduce a radical consideration: resources, ie, contributors. Is this what we would like to either do ourselves, offer to new contributors as a task, or attempt to automate? DCDuringTALK19:28, 9 December 2014 (UTC)[reply]
There are eleven translation tables at [[new]], some with dozens of languages in them. Are we to repeat all of those translations at [[newest]], but using the superlative form, even for languages where the superlative is formed fully regularly, even periphrastically (e.g. leplusnouveau with each word linked separately)? And when someone comes along to [[new]] and adds a new language, say Marathi, to the translations, who's going to go to [[newest]] and add the superlative there? And many languages have multiple past tenses, while English only has one, not to mention multiple persons and numbers; should the French translation for [[walked]] list all of the following: marchais, marchait, marchions, marchiez, marchaient, marchai, marchas, marcha, marchâmes, marchâtes, marchèrent, aimarché, asmarché, amarché, avonsmarché, avezmarché, ontmarché? And then the same thing for all of the polysemous verbs that have more than one French translation; shall we list all 17 forms for each verb that can be used to translate the English word? Lower Sorbian has at least four verbs that mean "go", two past tenses, three persons, and three numbers; should the translation table for [[went]] really list all 72 forms? I don't think that's going to make things any easier for the reader than simply going to [[go]], finding the Lower Sorbian lemmas, and then finding the appropriate inflected form on the Lower Sorbian lemma page. —Aɴɢʀ (talk) 20:52, 9 December 2014 (UTC)[reply]
No one is proposing such a thing any more than they are proposing that "newest" should have eleven senses reflecting the senses at "new" (some of which seem redundant to me, like sense 12 merely being a special case of sense 3). As for conjugations, we can find other ways to deal with those. I am merely proposing that we should give the reader the shortest path to finding what they want. If contributors don't want to add such information, then it won't get added, but that doesn't mean it should be prohibited. We might as well say that etymologies or pronunciations of non-English terms should be prohibited because including them is too daunting a task for contributors to engage in. bd2412T21:17, 9 December 2014 (UTC)[reply]
But indirectly that is what's being proposed, because if we remove the prohibition on inflected forms having translations from WT:ELE, there's nothing to stop someone from adding 72 Lower Sorbian forms in a translation table at [[went]]. And that would not help anyone, not even someone trying to figure out how to say "I went to Cottbus" in Lower Sorbian. Basically, I think it's an illusion that listing the translations for inflected forms will help the reader. It seems at first blush like it will, but in actual practice it won't. —Aɴɢʀ (talk) 21:44, 9 December 2014 (UTC)[reply]
Can we draw a distinction between inflected verbs and inflected adjectives? Are we going to find 72 Lower Sorbian forms of "newest"? bd2412T22:22, 9 December 2014 (UTC)[reply]
We can, but the original question was about English non-lemma forms in general, not English adjective forms specifically. There will only be 15 distinct Lower Sorbian forms of "newest". —Aɴɢʀ (talk) 22:57, 9 December 2014 (UTC)[reply]
A tricky topic. The superlative form [[newest]]] can have a lemma form as well in the Slavic languages - masculine, singular, nominative case, e.g. in Russian it's нове́йший(novéjšij) or са́мыйно́вый(sámyj nóvyj), other genders, plural, cases should not be in the translation, if they are added. If I were to translate the past tense form [[went]] into Russian, then I would use masculine singular - шёлimpf(šol), пошёлpf(pošól) - concrete of идти́(idtí), ходи́лimpf(xodíl), походи́лpf(poxodíl) - abstract of ходи́ть(xodítʹ) (verbs of movement can have concrete and abstract versions in Slavic languages). Plus, there are equivalent verbs to go by a vehicle (perfective, imperfective, concrete, abstract), so there could be, at least eight translation into Russian. See go#Translations, e.g. translations into Russian. --Anatoli T.(обсудить/вклад)23:36, 9 December 2014 (UTC)[reply]
Did the vote explicitly define whether comparatives and superlatives are considered inflected forms? I would say they are, but there doesn't seem to be unanimity on that issue. —Aɴɢʀ (talk) 21:00, 10 December 2014 (UTC)[reply]
In that case, what we need to decide is whether comparatives and superlatives are considered inflected forms in the sense of that vote or not. —Aɴɢʀ (talk) 15:09, 11 December 2014 (UTC)[reply]
For the purposes of translations (and I think most others), I think they should be. Apart from "logistic" issues (i.e. keeping the lists in synch) and redundancy (you can already translate the ungraded form and look up the graded form in the target language's entry), different languages may handle gradation differently (e.g. elative form in Arabic, or several "workaround" constructs for Japanese, which has no proper adjectives to begin with), so often there will not be a good match in the target language. — Keφr18:24, 11 December 2014 (UTC)[reply]
You didn't write that. User:Mglovesfun did. You can't speak for him.
In any event that is how I understood it to apply in English. I was somewhat aware of the complications in Latin with inflected forms of participles and gerunds, but, perhaps unrealistically, did not expect the vote to be applied mechanistically, even in English, let alone across all languages. AFAICT we have never been very good at drafting substantive proposals that anticipated even obvious matters such as this. (Not that we've been much better on procedural matters.) DCDuringTALK14:33, 14 December 2014 (UTC)[reply]
@bd2412: the reason is simple: in most cases, it's meaningless, because inflection rules only depend on the language and on the context in the sentence. An example: if the feminine form of an adjective is used in Italian because the noun is Italian, it must be translated to the masculine form of the corresponding adjective in French is the feminine noun is translated to a masculine noun. This is why the définition should be Feminine form of, not a translation (and, anyway, the translation in English would be the same for all forms of the Italian adjective). For the translation section, this is the same issue. Sometimes, grammatical rules are similar enough (e.g. existence of a plural form meaning the same in two languages), but this is a special case. Lmaltier (talk) 08:56, 20 December 2014 (UTC)[reply]
I don't think there's reasonable doubt over what the vote proposes to cover. You could consider it a loophole; a way to get around the rules like Google avoiding paying corporation tax. But don't pretend it's good faith, it isn't. Renard Migrant (talk) 22:07, 31 December 2014 (UTC)[reply]
A Google News search turns up some reputable media outlets that appear to be using it as a word, though mostly as shorthand in headlines. bd2412T18:42, 11 December 2014 (UTC)[reply]
That would make you an administrator, as those are the only editors able to do so. Based on your length and duration of activity here, I would support you in an adminship bid if you make one. bd2412T18:44, 11 December 2014 (UTC)[reply]
@T Ah, I didn't realize. Thank you. An adminship is probably more responsibility than I'm willing to take on right now, but how might I go about that in the future? By requesting here?
@Kephir I know Anglom from his work on Germanic languages. He's a good and conscientious editor who largely stays away from drama. If this were Wikipedia, his almost complete avoidance of the project namespace would be problematic, but here at Wiktionary I don't think it is. @Anglom, being an admin doesn't actually give you more responsibilities unless you want them. You're not obligated to go vandal hunting, or block people, or protect pages, or anything like that. I'd support you for adminship too. —Aɴɢʀ (talk) 21:09, 11 December 2014 (UTC)[reply]
The gender is hard to find, I assumed it would be a neuter third declension i-stem, but going by the International Code of Zoological Nomenclature "30.2.3. If no gender was specified, the name takes the gender indicated by its combination with one or more adjectival species-group names of the originally included nominal species", I would have to say feminine based on Alca, yes? Anglom (talk) 00:05, 12 December 2014 (UTC)[reply]
Have not seen Flow, but I oppose anyone doing it overnight without a long beta test and discussion. LiquidThreads was horrible. Equinox◑11:59, 14 December 2014 (UTC)[reply]
@Kephir Check out w:User:TheDJ/flowidth (a new userscript that allows drag-to-change width), which I'm currently urging the dev team to incorporate (or at least borrow ideas from) in the extension itself. Some sort of toggle or changer is/was planned for many months, but this has helped push it forward. :-) Quiddity (WMF) (talk) 02:57, 18 December 2014 (UTC)[reply]
Are you kidding me? The looks are the worst part of it. Oversized fonts, gratuitous animations, too much wasted screen space (between lines, padding, empty space to the right of the screen), poor visualisation of discussion structure (posts not clearly separated, who replies to whom only indicated by indentation). Also no pagination, missing basic functionality like deleting threads, and links like w:Topic:S22olnmzgd49twr0 (never mind finding this link in the first place was quite inconvenient). I am no fan of talk pages — they are crappy, monthly subpages here are marginally better, LiquidThreads has a few warts, but Flow is just horrible.
As for archiving, I think the original plan was to render archives obsolete. I think it was planned to make it possible for a single discussion to be visible from two talk pages at once. I have not seen anyone actually working on this, though. Instead WMF seems to concentrate on generating hype to make itself appeal to "OMGJAVASCRIPT" types, as most of its other software projects do. I mean, just look at Media Viewer, or the migration to Phabricator (the latter is not actually bad, but the improvement over Bugzilla is marginal). — Keφr17:28, 14 December 2014 (UTC)[reply]
(I hate Media Viewer too. It looks like a spammy "subscribe to our newsletter" popup, and hides all the useful metadata behind further clicks.) Just played in the Flow sandbox. Personally I could stand the UI but the performance is ridiculously poor, taking 20-30 sec to respond to a button press, with no visual cue that it's doing anything at all. I didn't think my computer was that old. Equinox◑17:32, 14 December 2014 (UTC)[reply]
The looks can be changed, with enough sensible feedback (just like anything onwiki), and enough patience (there are only 3 devs working on Flow at the moment, and a voluminous list/backlog of requested features & changes). I (with my volunteer hat) want more density, too, and I'm pushing phab:M17 to help solve these subjective disagreements in the longterm.
(Tangentially: The benefits of phabricator over bugzilla include: A) it uses SUL (so no need for another account, and no more exposed email addresses), B) it replaces: Bugzilla/Trello/Mingle/RT/Gitblit, and eventually Gerrit, so it will be a lot easier for everyone (every community, and every wmf team) to collaborate on, and track, the various projects/extensions/code.)
Deleting threads/posts is available (to admins), and everyone else currently has a "hide" feature, which is equivalent to reverting but without being quite so opaque. There's room for improvement here, which will come with time and feedback and usage.
The performance does need to be improved, particularly for those of us with older machines. Examining that is constant, but attacking it vigorously is on the agenda.
I just half-skimmed, half-read the content at mw:Flow, and I found myself thinking that this is geeks seeking a new! improved! technical solution to something that 1) is at least partly a social problem (“New users on English Wikipedia have become less and less likely to participate in on-wiki discussions, in spite of a growing and mostly automated body of messages directed at them” -- sounds like capital-D Drama might drive some people away, and being increasingly nagged by automated stuff is just off-putting), and that 2) already has technical solutions for a number of the other issues they brought up, in the form of LiquidThreads (mooting the whole second paragraph of the Background section).
I do see in the Why not use LiquidThreads? section that they discuss some of the latter, but given Equinox's comments above, I'm unconvinced that we at EN WT have any need for Flow. This looks like the broader organization forcing something on all Wiki communities for the sake of ... I dunno, some ideal of consistency? The purported features of Flow that LiquidThreads does not offer don't look like anything we need, or would have much use for (globally unique identifiers, cross-wiki threads).
There are some other "features" of Flow that concern me. Flow will not directly support custom signatures.WTF? LiquidThreads does that just fine. Now we're going to be forced to use a different discussion mechanism on all talk pages, and we won't be able to use our sigs. The technical reasons they give all sound like “we're technically incompetent and it's too hard for us to figure out, so we're just going to throw out this one feature that all of our users have had for ages.” If they're too incompetent to figure out signatures, exactly how are we to trust that they can implement this entire system at all well?
Looking at the sample link Keφr provided, I am further horrified at this mess. Indentation stops after three levels, at which point, I completely lose any ability to tell which post is in reply to what. The mw:Flow page says that indentation relies on “arcane wikicode knowledge”. Granted, a user needs to know a little bit to use wikicode effectively. I posit that this is much more preferable over a patently broken and hard-to-use automated layout system. The justification for this visual crippling is that one quarter of WP viewership is on mobile devices. This reasoning is seriously flawed:
How much of that mobile viewership has any interest in Talk pages?
How much of that mobile viewership is using devices like iPads or Galaxys, which actually have pretty big screens?
How on earth is it acceptable, or even a good idea, to make design decisions for the PC based on what mobile phones are capable of? Microsoft spent billions on this boondoggle of an idea, and the early reviews of Windows 10 suggest that even this corporate behemoth has learned the error of its ways and is changing course (moving away from Metro, reinstating the Start menu, etc).
On other UI matters MW has imposed its will, despite a near revolt at de.wiki. I don't know what the final outcome was. As with many elites nowadays they probably believe that they have superior insight into the true needs of the people, which justifies ignoring everything that does not contribute to implementation of the plan. I'm fairly sure that we will get messages from MW staff tantamount to "You have to implement it in order to know what it is." DCDuringTALK21:57, 14 December 2014 (UTC)[reply]
@Eirikr Indent: The indentation limit is going to change - they've been postponing it for a long time, but everyone agrees that the current 3-indents limit is not good - it was meant to be an evolving experiment, and has remained static for too long. They're currently waiting for Design to provide a greater improvement than simply increasing the limit.
LQT: The LQT extension is no longer maintained and many of the highly active users (e.g. translatewiki) want to transition away, and there's a script for converting LQT to Flow (because for all LQT's problems, it is a logically structured system, at least). That part is fairly easy (comparitively speaking). It's how to deal with existing talkpages, that Gryllida was originally requesting comment on. Gryllida was not suggesting converting Wiktionary any time in the near future. Everyone agrees that Flow isn't nearly ready for that.
Signatures: Our username-attribution will need some way of being altered/adapted, to enable the editors who want an alternate name to display, e.g. the many editors who include a Greek/Latin name in addition to their local/primary script name.
However, the current system — of allowing anyone to A) give their name multiple different colors, in bold/superscript/comicsans/etc (which is bad for equality, and bad for accessibility), and B) to add numerous links (can often be confusing, or soapboxy), and C) to add templates and circumvent size-limits "but please don't", and D) to obfuscate our primary username (the one which appears in History/Logs/etc) thereby complicating everything — could benefit from a few changes. Quiddity (WMF) (talk) 02:57, 18 December 2014 (UTC)[reply]
Stranding off-topic a bit: I realise that LiquidThreads has a few quirks, but I think the amount of hate it gets from some users is quite disproportionate. Could those people illuminate me on what makes LQT so horrible to them? — Keφr14:33, 15 December 2014 (UTC)[reply]
Don't get me started. I have stopped watching the user pages of those who use LQT because of the annoying messages and the lack of inclusion in my regular watchlist. As a result I am effectively prevented from usefully communicating with users who use LQT. I assume it was done this way intentionally to force rapid adoption, in imitation of Facebook. DCDuringTALK15:29, 15 December 2014 (UTC)[reply]
The watchlist issues DCD mentioned;
It messes up patrolling (not that this affects many people...)
It’s hard to read the history of an entire discussion.
Hi, I've replied in a few places above. TL;DR: Flow is not in a final state by a long shot, and your feedback (throughout this thread) is appreciated. Gryllida was not suggesting converting Wiktionary any time in the near future. Everyone agrees that Flow isn't nearly ready for that. The dev team is concentrating on implementing the feature-set requests of the communities that are already actively/happily testing Flow, and they can only do so much at once. Personally, I'll be back to ask about and investigate more Wiktionary workflows (in all languages), in later months. Eventualism, and "slow and steady", are my constant mantras; They're (part of) the only reason any of this wonderful/aggravating/overwhelming/hopeful wikiverse work (imho, with apologies for using generalizations ;-) . Hope that (all) helps. Quiddity (WMF) (talk) 02:57, 18 December 2014 (UTC)[reply]
I for one believe that it is either impossible or very difficult to implement something as useful and flexible as the current system of talk pages, which are just wiki pages in a different namespace. I for one am not interested in providing feedback to Flow so that Flow can be improved. I just dread the day on which Flow is going to be forced down our throats the way Media Viewer was forced on German Wikipedia. --Dan Polansky (talk) 08:31, 20 December 2014 (UTC)[reply]
Hyphenation linked to a language-specific appendix[edit]
Similarly to the IPA key, can we link the Hyphenation label to a language-specific appendix (such as Appendix:Hungarian hyphenation) where the rules of hyphenation would be described? The {{hyphenation}} already has the lang parameter to make this feasible. If the appendix does not exist, then no linking would take effect. --Panda10 (talk) 20:56, 16 December 2014 (UTC)[reply]
I asked Jimbo to put in a word with Larry Page and Sergey Brin to see if we couldn't get a comprehensive list of words appearing in Google Books. Another editor suggested we look at "Google 1-grams", http://storage.googleapis.com/books/ngrams/books/datasetsv2.html :
"File format: Each of the files below is compressed tab-separated data. In Version 2 each line has the following format:
ngram TAB year TAB match_count TAB volume_count NEWLINE
As an example, here are the 3,000,000th and 3,000,001st lines from the a file of the English 1-grams (googlebooks-eng-all-1gram-20120701-a.gz):
circumvallate 1978 335 91
circumvallate 1979 261 91
The first line tells us that in 1978, the word "circumvallate" (which means "surround with a rampart or other fortification", in case you were wondering) occurred 335 times overall, in 91 distinct books of our sample."
Awesome. I notice some spurious things (e.g. "andthen", and "ation" which I assume is the suffix -ation widowed by a line break), but the list still seems quite useful. Question: if a book has, say, "Anna", is that in the 1-gram list as-is, or is everything downcased (to "anna")? - -sche(discuss)05:04, 18 December 2014 (UTC)[reply]
I am interested in getting a complete list of all words appearing in all Google Books. Can we get that from these lists compiled by Google? bd2412T17:53, 18 December 2014 (UTC)[reply]
Not quite. The terms in Category:en:Mammals refer to mammals as objects. But the words "one" or "seventh" don't refer to numbers as objects, or at least not in normal usage. If they did, they would all be nouns, like mammals are. —CodeCat01:50, 30 December 2014 (UTC)[reply]
These categories do not correspond at all to the categories of participles recognized in Polish grammar, which are:
adjectival participles:
active adjectival participles (imiesłów przymiotnikowy czynny), such as czytający
passive adjectival participles (imiesłów przymiotnikowy bierny), such as przeczytany
adverbial participles:
contemporary adverbial participles (imiesłów przysłówkowy współczesny), such as czytając
anterior adverbial participles (imiesłów przysłówkowy uprzedni), such as przeczytawszy
Currently, it seems that passive adjectival participles of perfective verbs are under "Polish past participles", active adjectival participles are under "Polish present active participles", and passive adjectival participles of imperfective verbs are under "Polish present passive participles". Anterior adverbial participles are nowhere to be found. This is clearly suboptimal and also misleading, since the entries under "Polish past participles" can also be used to form present tense sentences, such as Ten samochód jest już sprzedany which means This car has already been sold.
Is there any reason we present German composed forms? As far as I'm aware, the only "irregularity" in German composed form is whether a past participle takes "haben" or "sein", and that's already covered in both the heading line and the conjugation table. It seems at best sort of redundant, and at worst a little misleading (while there's nothing incorrect about the table at sein, for example, some of the composed forms aren't very idiomatic). On the other hand, German Wiktionary includes all this information, so it's entirely possible that I'm missing something. Smurrayinchester (talk) 14:48, 19 December 2014 (UTC)[reply]
I think this is very usual in conjugation tables (in all languages). Some conjugated forms are easy, some are less easy, but conjugation tables should be as complete as possible, this is useful to people wishing to use the verb and with little knowledge of conjugation rules. Lmaltier (talk) 17:59, 20 December 2014 (UTC)[reply]
I don't think it's necessary to show the full conjugation of all the auxiliary verbs. After all, the conjugation for those verbs can easily be looked up itself. For Slovene, I adopted the practice of showing only one form of the auxiliary. It keeps the tables much shorter while still giving an idea of the general formula. See kupovati for an example. For Latin, we don't list composed forms either, we show how to form them. Like on canto. —CodeCat18:22, 20 December 2014 (UTC)[reply]
With such a reasoning, you could as well remove all regular forms and keep conjugation tables of individual verbs only for irregular verbs. But, once again, providing complete tables is useful to some readers. Lmaltier (talk) 18:34, 22 December 2014 (UTC)[reply]
I am pleased to announce, as Wikimedian in Residence at the Royal Society of Chemistry, the donation of 100 "RSC Gold" accounts, for use by editors wishing to use RSC journal content to expand articles/ items on chemistry-related topics. Please visit en:Wikipedia:RSC Gold for details, to check your eligibility, and to request an account. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits13:34, 20 December 2014 (UTC)[reply]
The idea of an open and free dictionary using content that is behind such elitist closed doors doesn't sit well with me. —CodeCat14:20, 20 December 2014 (UTC)[reply]
There's probably not much useful for a dictionary in those journals anyway; I'm sure the words in those articles are found in plenty of more easily accessible places. Great news for Wikipedia, though! —Aɴɢʀ (talk) 14:28, 20 December 2014 (UTC)[reply]
And I don't understand what you mean: you state that the dictionary has 429314 words and that it has barely 10000 words (with a link to another dictionary!). What do you mean? Lmaltier (talk) 11:33, 23 December 2014 (UTC)[reply]
First of all, the orthography of written Kurdish is very complex, due to not having a single authoritative standard. I'm sure all of those spellings are in use. Second, you can't tell how many words a language has by looking at an online glosbe dictionary: those tend to be very sparse and incomplete- especially for a lesser-known language such as Kurdish. Third, even if you could, Wiktionaries shouldn't be limited to one language, so I'm sure they have entries for English, Arabic, Turkish, etc. There's no reason for them not to have as many entries as any other Wiktionary (we're approaching 4 million). Besides, each Wiktionary is independent, so there's not much point in complaining to us. Chuck Entz (talk) 13:36, 23 December 2014 (UTC)[reply]
Hi. I got blocked a couple of times for running a bot when pretending it wasn't a bot with the usernames User:Type56op8 and User:Type56op9. I'd like to continue with it, but without getting blocked again. The bot is really amazing, and makes past participle forms for Spanish verbs. Check out the recent contributions here and here and [here which were all created without a bot flag on the user, and tell me what you think. --SuperWonderbot (talk) 14:39, 23 December 2014 (UTC)[reply]
If you didn't even follow the rules before you got a bot flag, how do we know we can trust you to follow them after you do have one? —CodeCat19:20, 23 December 2014 (UTC)[reply]
Anyway, I very rarely follow the rules. You all know me, I do loads of great work for a while, then others clean up after me. Then later I clean up after others, and the whole site improves as a result. --SuperWonderbot (talk) 23:52, 23 December 2014 (UTC)[reply]
I suspected that, but I thought that his username would then be MGlovesfun. Welcome to the wild world of the Internet, I suppose. bd2412T16:09, 24 December 2014 (UTC)[reply]
User:Kephir appears to be in an edit war with two other users: User:CMBJ and User:Purplebackpack89. In the last 24 hours, he has altered signatures of CMBJ's on nine different pages (three of which are this, that, and the other thing). Purplebackpack89 found that objectionable, and undid each of his nine edits, on the grounds that user comments (including signatures) should not be refactored, the grounds that the signature was perfectly acceptable. Kephir undid Purplebackpack89's revisions without explanation, thereby starting an edit-war. Purplebackpack89 did not undo any of Kephir's edits, but he did leave a message on Kephir's talk page explaining why he thought those edits were in error. Kephir deleted that meessage. I am asking that Kephir be reverted by a fourth party, that he be told that his actions (including his continual refusal to dialogue with Purplebackpack89 on his talk page) are disruptive, and perhaps that he be blocked for a short time for continual disruption. Purplebackpack8915:38, 27 December 2014 (UTC)[reply]
I don't see User:CMBJ involved in any edit warring, so it's just you. And I think Kephir's actions are justified as signatures should link to a Wiktionary user and talk page. —CodeCat15:40, 27 December 2014 (UTC)[reply]
There's no rule saying they have to link anywhere, and there never should be. And even if there was, it's still inappropriate to refactor another user's signature, and then edit-war when another editor disagrees with your refactoring Purplebackpack8915:52, 27 December 2014 (UTC)[reply]
If they'd complained about it in the past, how come there's no mention of that at User talk:CMBJ? Also, I still cannot condone changing another person's good-faith comments for any reason. A signature is part of a user's comments. If Kephir had a problem with it (and, since Wiktionary:Signatures has yet to be enacted as policy, he doesn't have policy to back him up, just personal preference), why didn't he discuss it on the user's talk page? Why did he revert all of them before discussing it? Purplebackpack89 16:03, 27 December 2014 (UTC)
The complaint was in the Beer Parlour. And stop pretending that you’re doing this drama because of policies. You’re just trying to badmouth a user you don’t like. — Ungoliant(falai)16:08, 27 December 2014 (UTC)[reply]
Read the header. It's a draft. It hasn't been enacted as policy. It doesn't override the principle of not refactoring other people's comments. And actually engage with me on your talk page. If you'd done that, we wouldn't be here. Purplebackpack89 16:09, 27 December 2014 (UTC)
What principle? Where? Everything these two pages contain is quite well-established practice (well, maybe except the "no templates in signatures" rule, but even that has changed recently). If someone set up a vote to promote them to policy status, I can bet it would surely pass. That this has not yet happened only means that very few regulars are interested in such minutiae. Which is actually good: time spent on silly policies like signatures is time not spent building the dictionary. — Keφr16:31, 27 December 2014 (UTC)[reply]
I think it works both ways. There's no rule that signatures should link to your user page, there's also no rule against editing other people's signatures. I don't see how you can complain it's bad etiquette when the editing is happening to fix a bad etiquette issue in the first place. Renard Migrant (talk) 17:02, 27 December 2014 (UTC)[reply]
@Kephir: Your minutiae argument doesn't really hold water after you squandered away 18 edits fiddling with another user's signature. If you believe they should be policy, man up and start the vote. I will vote oppose to it; I think it's killing an ant with a bazooka gun in that it overly restricts users. Until it is enacted as policy, stop beating me over the had with the "well-established practice" argument. Something "established" by a few editors years and years ago doesn't carry the weight something discussed or voted on by 20 editors a few weeks ago does. And, as @Renard Migrant notes, there's a tad of hypocrisy here, in that you are ignoring the "well-established practice" of not refactoring other peoples' edits. Purplebackpack89 17:19, 27 December 2014 (UTC)
@Purplebackpack89: Your pings did not work. I happen to know why, but I am not going to tell you: I am actually quite happy with them not working. Suffice to say, you are making a fool of yourself again. — Keφr17:37, 27 December 2014 (UTC)[reply]
By the way, I would like to add that @Kephir has gone around replacing my signature with the unsigned template. I also find this highly inappropriate, and frankly disruptive. I have reverted him. Purplebackpack89 17:46, 27 December 2014 (UTC)
Re: "there's also no rule against editing other people's signatures": I have seen multiple editors state that editors should not edit other people's posts, not even for typo correction. I don't see how that does not apply to signatures. In general, signatures should be left alone, IMHO. --Dan Polansky (talk) 10:09, 28 December 2014 (UTC)[reply]
Our logo has been the focus of widespread complaint for a long time, with one person on WT:Feedback noting that it seems like somebody brings it up every week, and I know many editors here dislike it. It's visually unappealing and doesn't abide by our IPA standards on transcribing English r while simultaneously giving only a British pronunciation, and looks like a strange attempt to imitate the layout of a physical dictionary, which is everything we are not. Its only advantage, in my opinion, is that of consistency.
The other two logos shown at right are the tiles logo, which has the advantage of being the logo that the Wiktionaries all chose in a communal vote and therefore being the most widely adopted logo, and the book logo, which I (and I believe some other editors) find the most aesthetically and symbolically appealing, and which is also used by more Wiktionaries. If there are other logos that people like, or new ones that someone is willing to create, I would be happy to see them as well. Note that it is currently possible to change how you see the logo in your Preferences if you're logged in, and we will keep that no matter how the vote goes.
My two main questions are: preliminarily, what do people think about these options and having a vote on them? And secondly, would anyone be willing to draft the vote with me? I'm hoping that we can finally have a logo that we can be proud of rather than one that attracts regular complaint and criticism. —Μετάknowledgediscuss/deeds22:35, 27 December 2014 (UTC)[reply]
I would not mind a vote. Personally, I like the "tiles" logo. The "book" logo looks quite dull and non-indicative of what this project is about: pretty much any kind of knowledge can be put into a book (if you forget about the limitations of the medium). A book is practically meaningless as a symbol. — Keφr22:45, 27 December 2014 (UTC)[reply]
Actually, it had no consensus. But more importantly, that was more than four years ago, and it seems to me quite possible that the community will be able to agree this time. —Μετάknowledgediscuss/deeds23:00, 27 December 2014 (UTC)[reply]
As a logo, I dislike the book. It is not logo-like. I like the tiles. The biggest (or only) complaint I recall about the tiles was the Japanese kana that looks like a happy face. The specific symbols on the tiles are not immutable, they can be changed. Most wikis that went with the tiles did change one or more of them. Consider ko:위키낱말사전:대문 and tr:Ana_Sayfa. —Stephen(Talk)23:06, 27 December 2014 (UTC)[reply]
I like the tiles but I wish someone would re-draw them into something more modern looking. The colors and gradients don't look good. DTLHS (talk) 23:11, 27 December 2014 (UTC)[reply]
I still prefer the book logo. The tiles look too... cheap? Unprofessional? Playful? It also doesn't really evoke a dictionary as a repository of knowledge on words. Instead it seems to focus on language variety. The book is literally a dictionary (or is supposed to be) so it seems much more fitting. —CodeCat23:17, 27 December 2014 (UTC)[reply]
I agree that the tiles appear more evocative of a child's game (and they contain letters/symbols, not words, which is our main focus); the book seems generic. I would go for the tiles if the characters could be replaced with short words like be and 考虑 and عجب. bd2412T00:57, 28 December 2014 (UTC)[reply]
Another note: a user once commented that there was a page layout error with the current logo, because he didn't realise that the portions of previous and subsequent "entries" (shown as bits of grey text) were meant to be just that: incomplete portions. Equinox◑02:41, 28 December 2014 (UTC)[reply]
I'm not an artist, so I can't give you a picture, but I would like to suggest a computer screen with "Wiktionary" on it, surrounded by a book, a scroll, a clay tablet, and selected other representations of iconic things writing has appeared on throughout history and throughout the world (maybe a hand making sign language, too). Everything should be minimalist, and we don't need to show details of the writing (aside from the word "Wiktionary"). Chuck Entz (talk) 03:00, 28 December 2014 (UTC)[reply]
You know, if we went with Goatse, it would bring some much-needed attention to the site. However, it might be the wrong kind of attention. bd2412T16:34, 29 December 2014 (UTC)[reply]
The tile logo doesn't evoke our mission (lexicography) at all. The book does, although I'm not convinced that switching to it would be better than updating our current logo, either to use modern RP and GenAm pronunciations, or to drop the pronunciation and perhaps replace it with a terse etymology. I recognize the point made above that any sort of information can be put into a book, so I understand how some people might not think the book evoked lexicography, but I don't see how anyone thinks the book doesn't evoke lexicography but the tiles do. Of the previously-proposed logos Angr links to, only meta:File:Wiktionary firehazard07 v1.gif and meta:File:Wikt bookdictionary logo.svg clearly suggest lexicography to me. meta:File:Wiktionary Dynamic Dictionary Logo 2.svg is two people arguing about the meaning of a story by talking past each other about different highlighted paragraphs, and something seems off about meta:File:Wiktionary logo Stephane8888 01f.svg and meta:File:Wikty no text up.png. meta:File:Wikt jlc 10-4 plus 6a.svg would make a great logo for a WikiBacteria or WikiViruses spin-of of Wiki-Species and the puzzle piece logo would be good for a WikiPuzzles site, but neither suits a dictionary, IMO. - -sche(discuss)20:11, 29 December 2014 (UTC)[reply]
Actually, tiles evoke some word games, such as Jarnac, and thus evoke words. Its different scripts evoke the variety of languages. Thus, this logo evokes words in all languages, which is a perfect summary of our mission. Note that the Wikipedia logo also evokes a game, not an encyclopedia, and also evokes all languages. Thus, the tiles logo is very consistent with the spirit and the Wikipedia logo, and is visually more appealing (in my opinion, because it's subjective). Lmaltier (talk) 20:51, 31 December 2014 (UTC)[reply]
I'd say the puzzle pieces of the Wikipedia logo allude to "creating a complete picture". And the logo implies that by putting together the pieces, one is creating the world with all its knowledge. Wiktionary is not that different, but we'd want the puzzles to come together to form languages or words rather than encyclopedic knowledge of the world. So maybe a design with a book/dictionary made up of puzzle pieces? —CodeCat21:27, 31 December 2014 (UTC)[reply]
We're a dictionary, but not a book. I must say I don't understand the reluctance of some people to the tiles logo. After adopting it, even contributors opposing it get used to it, and this is not an issue any longer on fr.wikt. Lmaltier (talk) 22:19, 31 December 2014 (UTC)[reply]
I don't think being a dictionary is the reason to go for a book logo. Books are also tied to language and words, to literature. Of course, words are also spoken, which is why some of the proposed logos have people speaking instead. But using a book seems to fit better with our practice of requiring written attestations? —CodeCat14:45, 1 January 2015 (UTC)[reply]
A logo serves not only to symbolise what the project is about, but also to set it apart from other similar things. Many more things are connected to literature. Every Wikimedia project could use a book for its logo (maybe except Wikinews and some meta-projects). A book is so generic that it becomes meaningless. — Keφr15:29, 1 January 2015 (UTC)[reply]
I think we should have a logo vote, and that the winner should have at least (or more than) 50% of the votes (run-off voting if necessary). If one wants to play it really safe, one could even have a vote of confidence for the process itself: has the logo candidate selection been fair? Are the voting rules fair? Etc. If the current logo never has been voted for, I think we should definitely strive for a successful vote (which of course includes the possibility that the current logo, modified or not, wins). --Njardarlogar (talk) 12:11, 1 January 2015 (UTC)[reply]
Per Wiktionary:Guide_to_adding_and_removing_languages, I'd like to request that oui and khk be added to the list of languages. Currently "ug" is being used in place of "oui" in several etymologies (note that Old Uyghur is not an older form of Uyghur, but is in fact a different language with the same name), and "mn" is being used instead of "khk". —Firespeaker (talk) 07:54, 29 December 2014 (UTC)[reply]
Mongolian (mn) is a macrolanguage. Many examples give "Mongolian" examples, but are in fact Khalkha examples in the standard orthography of Mongolia. Many other varieties of Mongolian are not represented by this orthography (Chakhar, Ordos, etc.). If I were to consider a single variety "Mongolian", it would be written Classical Mongolian (still standard orthography for most varieties of Inner Mongolia, and recognised as an alternative in Mongolia), which is not the language of the forms being provided. —Firespeaker (talk) 04:19, 30 December 2014 (UTC)[reply]
I am rather puzzled by the name of this category, let alone its purpose, and would like to suppress it when it appears in entries which include the vernacular name, such as dvergbjerk. In this case there is no entry for Betula nana, only the Wikipedia link. How can I suppress it? Donnanz (talk) 13:34, 29 December 2014 (UTC)[reply]
I think {{vern}} is supposed to be used with the vernacular name, e.g. {{vern|dwarf birch}}. The taxonomic name is supposed to use {{taxlink}}, e.g. {{taxlink|Betula nana|species|noshow=1}}. (I have no idea what |noshow=1 does, but someone always comes along and adds it if I forget it, so I assume it needs to be there.) —Aɴɢʀ (talk) 13:48, 29 December 2014 (UTC)[reply]
Everything is a Angr says. I add the noshow=1 after I have looked at the entry and thanked the person who used {{taxlink}} (but, in this case, me). As we have an entry for dwarf birch, it doesn't need {{vern}} and would show up in a category of entries in which that template is redundant. DCDuringTALK15:25, 29 December 2014 (UTC)[reply]
The missing-taxonomic-name and missing-vernacular-name categories are tracked so that the most commonly "needed" ones are added relatively quickly, at least when I'm in the mood to do so. DCDuringTALK15:27, 29 December 2014 (UTC)[reply]
@Angr: As you already have my undying gratitude for so many things, sending further thanks would be coals to Newcastle. If you are uncertain about something, you could leave it out and I would look at it within a day, often less. I like to look at new English entries that use taxonomic names anyway, because some of them merit some additional external links and images, sometime including a map of the range of the taxon members to support requests for native-language translations. DCDuringTALK19:07, 29 December 2014 (UTC)[reply]
I would like it if users added English vernacular names. If, as a result, some pages are categorized as having redundant vernacular-name templates, I look at the new entries and add what I think is missing. Therefore I like it being a visible category, especially as there is not redlink due to the pedia link rendering it blue. OTOH, I would certainly defer to any consensus to the contrary. DCDuringTALK19:15, 29 December 2014 (UTC)[reply]
To me, visible categories are for all readers, including those who never edit, while hidden categories are for "behind the scenes" work that only editors do. —Aɴɢʀ (talk) 19:20, 29 December 2014 (UTC)[reply]
The category membership is in lieu of a redlink, which is an invitation to add an entry. I suppose we could hide the category and add an explicit invitation to add the missing vernacular name, something more conspicuous like what {{t-needed}} adds. DCDuringTALK20:16, 29 December 2014 (UTC)[reply]
Support in principle. My preference is simplified for lemmas but if the rest decides traditional, I won't object. (I will give my reasons for preferring simplified over traditional later.)
Support I support this proposal. I was worried about categorisation but I read above that it will be handled. For the conflict between simplified and traditionnal, is it possible to have a template on the non-lemma page which will parse the lemma page, extract the parts corresponding to the non-lemma word, convert it to the non-lemma script and display it? This way, the lemma and non-lemma page will display the same information. Meihouwang (talk) 15:00, 6 December 2014 (UTC)
. Some previous proposals are at m:Red, green, and blue#Proposed Wiktionary logo. —Aɴɢʀ (talk) 16:38, 28 December 2014 (UTC)
