It looks like the Mediawiki people or somebody else has mucked around with the search so that instead of helpful preload options for a new entry when an non-existent entry is entered in the Search box, a barebones search page comes up instead. — Carolina wrendiscussió04:12, 2 July 2009 (UTC)[reply]
Not only that, but this means that the "near"-spelling search that used to happen automatically now requires a user to initiate a seacond search to actually get the search to occur! That's silly. Instead of getting a list of the closest matches, it returns only a single "did you mean"? That may be fine for an encyclopedia, but it's counterproductive and harmful to a multilingual dictionary. --EncycloPetey15:27, 4 July 2009 (UTC)[reply]
I've restored the preload options - we can probably modify hippietrails previous and next page script to show alphabetically close words on failed search, though it won't help with misspellings. Conrad.Irwin19:53, 4 July 2009 (UTC)[reply]
Maybe, but diacriticals don't alphabetize correctly unless you force them to with fancy code. That is, "ábellarde" would come not after "abellarde", but after "zyzyxy", unless a code resequenced the listing. (examples are wholly invented) --EncycloPetey20:14, 4 July 2009 (UTC)[reply]
Is this fixed? I couldn't get the preload options to appear today. I'd particularly like to get this fixed on ga:wikt as it cuts down on manual correction which is pretty much down to me. If someone could give me a clue (like are we being sent to a new MW page and what is it?) I could make a start on it. Thanks. ☸ Moilleadóir☎04:45, 6 July 2009 (UTC)[reply]
No, the software no-longer passes the failed search as a parameter to the message, so you can only create lots of entries at $1, I reverted my change. Conrad.Irwin07:33, 6 July 2009 (UTC)[reply]
On a related note, it seems that additional legal warnings have been added to the edit window. I now have to scroll down each time I need to insert certain special characters, then scroll back up to see the edit window. Specifically, I now get:
By saving, you agree to irrevocably release your contribution under the Creative Commons Attribution/Share-Alike License 3.0 and the GFDL. You agree to be credited by re-users, at minimum, through a hyperlink or URL to the page you are contributing to. See the Terms of Use for details.
If you do not want your writing to be edited and redistributed at will, then do not submit it here. If you did not write this yourself, it must be available under terms consistent with the Terms of Use, and you agree to follow any relevant licensing requirements.
Now, I can undersatnd alerting anons or new contributors, but for the frequent editors, it is extremely irritating to have all this text pop up in every single edit window, thereby necessitating scrolling just to edit Latin entries. Is there any way to customize this portion of the edit window to collapse it / hide it, so that it doesn't interfere with editing? --EncycloPetey16:41, 4 July 2009 (UTC)[reply]
Where are Conrad and Robert? They sometimes can figure out how get more reasonable results. Can't Javascript be used to allow more control over this aspect of screen appearance. Hippietrail has been active lately on preference-related matters. DCDuringTALK16:46, 4 July 2009 (UTC)[reply]
It would seem to make sense to combine the two boring paragraphs into one that more people will hopefully read. (it particularly irks me how they expand "Creative Commons Attribution/Share-Alike License 3.0" but leave "GFDL" condensed) Conrad.Irwin19:53, 4 July 2009 (UTC)[reply]
By saving you irrevocably give anyone the right to distribute and modify your work under the terms of the CC-SA license and the GFDL as described in the Terms of Use. Do not submit copyrighted work here, it will be deleted unless it is available under a suitable free license.
Those who wish the pref to follow their account rather than their computer can add #editpage-copywarn{display:none!important} to their monobook.css. (Untested, but should work.)—msh210℠15:24, 6 July 2009 (UTC)[reply]
This change ocurred because I edited the three main templates responsible for dealing with singular simple present indicative forms in various languages: {{first-person singular of}}, {{second-person singular of}} and {{third-person singular of}}. Initially, this was done to prevent the existence of a excessive number of highly-detailed categories in German language (such as Category:Spanish informal second-person imperfect indicative forms). --Daniel.17:20, 4 July 2009 (UTC)[reply]
Hmm. I don’t think that this is appropriate for English verbs. The third-person singular simple present indicative form is the only verb form regularly marked differently from the rest of the English verb forms (excepting the archaic -(e)st forms with thou). The way that these verb forms are now categorised lumps together (deprecated template usage)I abide, ((deprecated template usage)thou abidest,) (deprecated template usage)you [sg.] abide, and (deprecated template usage)he/she/it abides in the first category, whilst listing together (deprecated template usage)he/she/it abides with (deprecated template usage)they abide in the second category; this essentially means that virtually all English verbs should be members of both categories. (Granted, our naming of the former category was never watertight — it elliptically allowed subjunctives and past forms, in theory.) Even if we are to let it be assumed that these abbreviated category names only allow third-person singular simple present indicative forms, we should not have redundant, duplicate categories for these forms. †﴾(u):Raifʻhār(t):Doremítzwr﴿18:25, 4 July 2009 (UTC)[reply]
I see. I still think that the categorization system in question (i.e., separating various characteristics of verbs into different categories, such as Dutch verb singular forms) is appropriate for many languages, so I'd like to keep my edits in the three templates above. I agree that this is not appropriate for English, though. Then, I also propose these watertight categories for the few possible English conjugated verb forms:
English verb forms
English verb irregular forms
English irregular past participles
English verb simple past forms
English verb archaic second-person singular present indicative forms
English verb third-person singular present indicative forms
English verb archaic third-person singular present indicative forms
Sounds good. May I suggest that you also include English verb irregular simple past forms (e.g.swam in the irregular conjugation of swim) and English verb archaic second-person singular simple past forms (strong-conjugation verbs (and some weak-conjugation monosyllabic verbs) suffix -est in the second-person singular simple past; e.g.tookest, thoughtest, madest, walkedest, &c.). Except for modals and other irregulars, that’s all of them, I think. †﴾(u):Raifʻhār(t):Doremítzwr﴿20:34, 5 July 2009 (UTC)[reply]
As this is a significant category renaming, I suggest posting in the BP to be sure there is general support for restructuring the names. There may be a problem in some language categories with renaming in this way. The restructured names do look a little odd to me, since some of the descriptive terms follow the primary noun, but some of them preceded the noun. This has the potential to make for inconsistent category naming. --EncycloPetey04:55, 6 July 2009 (UTC)[reply]
I'm trying to work out why this isn't categorising correctly. The syntax looks okay to me {{suffix|disc|like}}, surely like is a suffix, it's not a combining form, is it? Mglovesfun (talk) 21:14, 5 July 2009 (UTC)[reply]
It looks as though User:Opiaterein had done a test edit on the template that broke its categorization function. I've alerted him. --EncycloPetey04:59, 6 July 2009 (UTC)[reply]
For several days, at least, I have not had the use of special characters in the search box. The edittools pull-down appears, but no special characters appears after the selection. I thought I had made the right selections at [[:WT:PREFS}}. If I am making a mistake in using "my preferences" or WT:PREFS, it is one I persist in making. Today I deleted my wiktionary cookies and started again without improving anything. Can the problem reside at another level? DCDuringTALK21:23, 6 July 2009 (UTC)[reply]
It depends on when the job queue gets to it. If things are not busy, it happens quickly; if they are, it takes a while. At the moment there are a lot of cache invalidates, and the P2 partition (en.wikt, 14 wps, common and meta) is constantly lagged 10-30 sec). It may take some time. Robert Ullmann02:24, 12 July 2009 (UTC)[reply]
The edit was done something like 10-12 hours ago, and only about 200 out of over 1000 articles have disappeared from the category, most are still there. So whatever 'some time' means, it seems to be an awfully long time. I guess I'll just have to wait. --CodeCat09:09, 12 July 2009 (UTC)[reply]
CodeCat, please do null edits to the affected pages (i. e. adding a space somewhere). This causes the pages to disappear from the erroneous categories. -- Prince Kassad13:53, 12 July 2009 (UTC)[reply]
A "null edit" can be just that; don't change anything, just edit/save. It won't show in the history (as there is no change), but it will force the page cache invalidate, and re-parsing. And note the job queue is seriously behind; the server lag on partition 2 (which has the en.wikt among other things) is "lagged" seriously. It was slowing down Interwicket seriously, I improved its timer handling this morning. (It should back off enough, but not really far. ;-) Robert Ullmann14:14, 12 July 2009 (UTC)[reply]
I know that would work, but we're talking over 1000 pages here, so that's not exactly doable. And besides, isn't that kind of repetitive task what we have software for, in the first place? :p --CodeCat14:51, 12 July 2009 (UTC)[reply]
All of a sudden the {trans-*} collapsing boxes aren't working (they are stuck open with no show/hide link). I'm on MS Vista with IE8, FF3.5 and Chrome.
Ah, so it happened because I switched to the Vector theme (from monobook). Changed it back and everything works fine again. Is there something people who use non-monobook themes have to do to enable this (and possible other js things)? --Bequw → ¢ • τ17:52, 12 July 2009 (UTC)[reply]
There is a problem with shaddas when writing in arabic script. A shadda and a diacritic one after another always get inverted. Like this: شَدَّة. Here I typed a shadda then a fatha which should have given this: شَدَّة. It works when using unicode codes. Any idea what is happening ? It is is bothersome because it makes the wiki-code harder to read, and also it is impossible to enter words with shaddas using the translation edit tools. Beru720:05, 12 July 2009 (UTC)[reply]
This is the Nikkud bug, the result of normalization (I think that is the word they used). The Foundation "normalized" input so that even if people enter certain kinds of text in different orders, it will always be saved in the same order, so that searches will be more dependable. It creates problems with right-to-left scripts like Arabic. I reported it several years ago and it was never fixed, so apparently it won’t be. You cannot type two Arabic diacritics in a row or they will be improperly inverted. The work-around is to type it this way: shadda+fatha = � 651;� 64E; • shadda+kasra = � 651;� 650; • shadda+dhamma = � 651;� 64F; (without spaces): لستنَّ إنـِّى الطـُّولى —Stephen21:45, 12 July 2009 (UTC)[reply]
From what I understand, it's not so much a bug in MediaWiki as in Unic�de itself. It's arguably a bug that MediaWiki is enforcing a buggy standard, but until Arabic countries have the kind of political clout that would get the Unic�de C�ns�rtium to violate its policy on incompatible changes, I don't think we can expect improvement. (It also affects Hebrew, but is only problematic in some really, really rare cases — like, a few times in the Bible, and never anywhere else.) BTW, I think Beru7 was already aware of your approach (it's what (s)he means by "using unicode codes"). Also BTW, to produce an ampersand, type &. So, shadda+fatha = َّ • shadda+kasra = ِّ • shadda+dhamma = ُّ. —RuakhTALK22:44, 12 July 2009 (UTC)[reply]
I don’t know the fine details but it used to work fine from 2002 through 2004. Then in 2005, Wikimedia flipped a switch somewhere, enabling "normalization". That’s when the Nikkud bug made its appearance. I made two reports at bugzilla, and reports were also filed by some Hebrew editors, but nothing was ever done about it. —Stephen11:38, 13 July 2009 (UTC)[reply]
Yes I was aware of how to display things correctly and even modified {{ar-dia}} to get the right result more easily. So thanks to your pointer Stephen I have found and read much more about the subject. From what I understand it is not really a bug in unicode. The unicode normalization standard C indeed dictates that the order is fatha + shadda and not shadda + fatha. However the real problem is that windows displays fatha + shadda differently than shadda + fatha. It shouldn't and from what I gather Service Pack 3 fixed the bug for hebrew nikkud but, unfortunately, not for arabic diacritics. So for now we have to use the codes, which makes life harder for editors and also breaks search. It is too bad because it would be really easy to fix, but it would mean deviating just a little bit from the unicode normalization standard and that is not acceptable to the foundation apparently. Now, what I am wondering is, couldn't we fix this ourselves with a little javascript that would replace fatha+shadda with shadda+fatha right before page display ? Beru712:10, 13 July 2009 (UTC)[reply]
The problem did (or would have, it makes sense) appear when normalization was turned on. But the actual bug is not in Unicode, it is in the rendering. It is like this:
Unicode provides for "decomposed" characters, base character + modifier + modifier ...
Thr order of modifiers is in most cases not significant, e.g. L + M1 + M2 should be the same (look the same when rendered) as L + M2 + M1
where there is a difference in rendering, the modifiers are given the same "combining class" to indicate that they interact
otherwise, they get different combining classes
normalization sorts them on combining class, using a stable sort, so modifiers in the same class are not re-ordered, but those that are in different classes are
this means equivalent strings will compare equal when normalized
Got that? (:-) Now onto Arabic:
A given letter + shadda + fatha should render the same way as letter + fatha + shadda. (As defined by the standard.) The problem is an interaction between two things:
the font rendering in the browsers etc do not treat the two orders the same, in spite of the standards requirement that they do, and
the combining class assignments for the Arabic modifiers were given unfortunate combining classes: shadda is 33, and fatha is 30, so the sort is the reverse of the expected linguistic order
Ah, so I guess Arabic is bit different from Hebrew. In Hebrew, the order does matter in some cases. (Full explanation: there are a few places in the Masoretic Text, such as Lamentations 1:8, where a single consonant has two vowels underneath it. Those two vowels need to be in the right order, but Unicode specifies that the order doesn't matter, and (for example) normalizes the correct יְרוּשָׁלִַם(y'rushaláim, “Jerusalem”) into the incorrect יְרוּשָׁלִַם(y'rushalíam). This is a bug in Unicode.) Even aside from that, the combining classes are weird for Hebrew (e.g. the vowels sort before the dagesh, even though the dagesh is actually part of the consonant), but most browsers nowadays seem to handle it O.K. —RuakhTALK13:16, 13 July 2009 (UTC)[reply]
The correct solution for Hebrew (e.g. your example) is to insert U+034F (Combining grapheme joiner, CGJ) in the sequence, which prevents reordering. So for example the points patah + hiriq can be written patah + CGJ + hiriq and they won't be reordered into hiriq + patah. Robert Ullmann13:42, 13 July 2009 (UTC)[reply]
You say "solution", I say "workaround", but that does seem to work: יְרוּשָׁלַ͏ִם. Thanks! (Though for some reason it confuses Firefox into thinking the text is really tall, heh.) Hey, I wonder if we can get MediaWiki to handle this for us automatically? —RuakhTALK14:16, 13 July 2009 (UTC)[reply]
It is the Unicode defined standard way to force modifiers into a specific order other than combining class where/when strictly required, and specifically in this case. So it isn't a "workaround", but rather the recommended standard method for these cases in Hebrew. MW is doing normalization properly ... (:-) Robert Ullmann23:40, 13 July 2009 (UTC)[reply]
Yes normalization is properly done, and the unicode standard isn't broken, but Windows XP still doesn't display correctly some arabic diacritics in normalized texts (I tested with Firefox on Ubuntu today and it works well). Since most users actually use Windows, something should be done about it. Right now we are polluting our pages with things like this ُّ to work around this problem. I have proposed above a small javascript function that would simply swap some characters on page load so that everything is correctly displayed. I would like to know if such a solution is acceptable or not. Beru723:49, 13 July 2009 (UTC)[reply]
The concept of your solution is definitely good, but I worry that replacing the innerHTML of the entire body might be problematic (e.g., likely to conflict with another script running at the same time; also, likely to take a long time on large pages on slow or low-memory computers, since it involves fully serializing and then fully deserializing the page). I wonder if it would be better, or worse, to go through the page and specifically target spans of classes Arab, ku-Arab, etc.? (Thanks to Mzajac (talk • contribs), our script templates are very consistent in using this sort of class, so aside from classed text, the only things we'd need to touch are the page's title and its H1 header.) Maybe I'm just worrying too much, though. —RuakhTALK03:53, 14 July 2009 (UTC)[reply]
For what it's worth, replacing .innerHTML of the body can break event handlers that have been attached to the document dynamically (i.e. our [show] buttons), so should not be done. Iterating over all nodes with a specific class will be much easier when we get jQuery installed (which is I believe in the pipeline for MediaWiki). Conrad.Irwin07:11, 14 July 2009 (UTC)[reply]
You are right the collapsible boxes weren't working anymore ! I modified my function (User:Beru7/monobook.js) so it only replaces text within <span class="Arab"> tags. Tell me if it needs more work - or if I should just drop it for now ! Thanks. Beru714:50, 14 July 2009 (UTC)[reply]
The js sounds like a good thing. It should operate on elements with class "Arab" or "xx-Arab" (e.g. "fa-Arab"); using "*Arab" to match the class name is probably just about right.
FYI: FireFox 3.5 has known issues with editing Arabic and also Hebrew Niqqud, where characters get detached; is apparently very annoying. This is fixed in 3.5.1. (I recommend 3.5+, it is noticebly faster.) Robert Ullmann05:04, 18 July 2009 (UTC)[reply]
I was wondering if anyone knows of a Ubiquity script which can be used to access Wiktionary directly from firefox using the popular 'Ubiquity' add-on? Found nothing with a google search. Andipi21:24, 12 July 2009 (UTC)[reply]
Now getting message "Could not find translation table for 'it:scitico'. Please improve glosses" when trying to use Assisted Translation system (browser = Google Chrome (don't ask!)). SemperBlotto21:41, 12 July 2009 (UTC)[reply]
Can I customize preload templates to my needs? I liked it when they were broken; the search page looked neat and clean. I want to disable those or at least create and see only ones I choose. --Vahagn Petrosyan23:07, 12 July 2009 (UTC)[reply]
Edit that page, select all the text, copy, edit this page, paste it here, save, delete it from there, and save. Make sure when you paste it here you indicate where it came from, so as to allow someone to determine the citation (who said what) as required AFAICT by the GFDL. (IANAL.)—msh210℠15:59, 14 July 2009 (UTC)[reply]
That is an improper name. Templates prefixed with "see-" should be for the Seneca language. I would expect a template named see-conj to display the inflection line of a Seneca conjunction. Why do we need a template for this? --EncycloPetey20:28, 15 July 2009 (UTC)[reply]
Well how would you link to the conjugation of mettre? My initital instinct was
====Conjugation===
* see {{term|mettre|lang=fr}}
I was more or less anticipating that someone would correct me on this, so I tried to preempt it by suggesting a template myself, even though it can be replaced by simple text. Mglovesfun (talk) 20:34, 15 July 2009 (UTC)[reply]
Clear enough, yes, but it different people will end up doing different things. I'm not particularly for it as I think it can be done by hand, I just thought other people might be for it. Mglovesfun (talk) 14:27, 16 July 2009 (UTC)[reply]
I'm not sure a template would be very useful for this. We might want to templanate it eventually, but I think we'd first want to try out a few different pages, and see what kinds of flexibility the template would need to have. Translations are split by sense, so we have a bunch of adjacent fancily formatted translation boxes, which {{trans-see}} fits in with; but conjugations are rarely like that (and when they are, as with (deprecated template usage)fleurir or (deprecated template usage)ressortir, we need clarifying text anyway). Though I see that we're actually missing one of the conjugations of (deprecated template usage)fleurir! —RuakhTALK01:34, 16 July 2009 (UTC)[reply]
How come on the French Wiktionary, every time you edit a new page you have to re-select the sub-section you want, but on here it uses the last page you chose. What parameter does this? Mglovesfun (talk) 22:29, 17 July 2009 (UTC)[reply]
In Mediawiki:Monobook.js, you'll find it sets a cookie ("edittoolscharsubset") when you choose one. (in "chooseCharSubset") So it persists. Should be easy to copy. Robert Ullmann05:11, 18 July 2009 (UTC)[reply]
Is there something to add to my monobook.js (or elsewhere) to make it follow the user rather than the browser?—msh210℠21:00, 19 July 2009 (UTC)[reply]
Yes, but no very smooth way, since you probably wouldn't want to remove the ability to set it to something different on a given computer. (For example, if you switched it to "Arabic" to edit a certain page, you probably wouldn't want it to switch back the instant you hit the "Show preview" button.) The best/simplest approach I can think of is something like this:
in the case of "Hebrew". (That checks if the edittoolscharsubset cookie exists and is nonzero — 0 being the index of "Templates", which is set by default — and if not, it sets it to 22, which is the index of Hebrew.) The main problem is, every time the index of Hebrew changed, you'd have to edit Special:Mypage/monobook.js to match. And the "Templates" value would never stick. (Really, I think it's kind of a mistake that we set the cookie to 0 by default — we should leave it blank by default, and just treat blank the same as 0 — but I suppose it doesn't matter much for most purposes.)
That said, I use a completely different approach, which you might want to try; User:Ruakh/monobook.js has a bit of code that basically copies the "Misc.", "Hebrew", "Latin/Roman", "IPA", and "enPR" sections up into non-collapsed <p>s. (The relevant code is the findEdittoolsSection function, and the addOnloadHook block underneath it. It should be obvious how to customize it for whichever sections you want to copy up.)
{{weather}} is an example of a topical context template. It provides the visible context label (weather) and adds the entry to Category:Weather. The lang=zh-tw parameter specifies that it is the category for Chinese language entries Category:zh-tw:Weather, presumably of the "tw" variety. If one were to add enough {{context}} tags with the same content, say "operations", eventually a category and the associated specific context template {{operations}} would be magically created. I'm not sure what it takes for the category magic to occur in each language as entries are labeled with the various lang= parameters. DCDuringTALK18:46, 20 July 2009 (UTC)[reply]
Technically: (gaak! ;-) I thought I'd seen some terrible things, but that one is one of the worst. It uses templates that try to do what the (poorly designed, hence not installed) string functions extension does, in turn using a bug in the padleft parser function, with layers and layers of iteration. If we want to, we'll do it a far better and simpler way!
Desirability: I'm pretty sure people will not want this. And note that when an entry has multiple languages it may not be in the group where italics might be appropriate for the title for all languages, unlike in the 'pedia with one topic. (for example Erica) Robert Ullmann10:59, 22 July 2009 (UTC)[reply]
Italicization is language-specific, so it shouldn't be applied to page titles. It probably shouldn't be anyway.
It might be applied to headwords, but in some cases it may be sense-specific. It would be more valuable to apply a label or usage note explaining why a word is italicized: unnaturalized borrowing, scientific name, title of a major work, etc. —MichaelZ. 2009-07-22 13:11 z
I agree with RU and MZ: it's language-specific, sometimes sense-specific, so should not be used on the h1.—msh210℠17:10, 22 July 2009 (UTC)[reply]
I agree with the other editors, except for RU's "technically" paragraph. On Wikipedia, it's terrible — incredibly so — because they have tons of ugly, expensive code to check for parenthetical disambiguation labels not to italicize (e.g. at [[w:Hydra (genus)]]); but we don't use such labels, so if we wanted something like this template, we could jettison all that code. But I must say, their ugly, expensive code is kind of brilliant. They should be perversely proud of it. —RuakhTALK17:36, 22 July 2009 (UTC)[reply]
Also have a look to the following page title: fr:Mme. I agree with above comments: if you want to add Mme for a different language (with a normal typography), it has to be removed anyway. Lmaltier18:04, 22 July 2009 (UTC)[reply]
Whilst this is a very good idea for inflexion lines’ headwords (i.e., the lines immediately below POS headers), it isn’t for page titles because of the issue of inconsistent italicisation translingually; however, if say, a species name, is italicised in every language in which it appears, then perhaps, in such cases, italicising their page titles would be OK, though such a thing is of questionable desirability. †﴾(u):Raifʻhār(t):Doremítzwr﴿18:13, 22 July 2009 (UTC)[reply]
Yes. But it cannot be made systematic. Better be consistent, and keep to principles. But, of course, it's very important to use a correct typography inside the page. Lmaltier18:39, 22 July 2009 (UTC)[reply]
Would it be possible to add an ital= parameter to our various inflexion templates to allow for this italicisation of inflexion lines’ headwords? †﴾(u):Raifʻhār(t):Doremítzwr﴿20:32, 25 July 2009 (UTC)[reply]
It might be simpler to just have a specially dedicated inflection line template for all the genera and species. Since they will all be translingual proper nouns, a single template would work for all of them. --EncycloPetey20:58, 25 July 2009 (UTC)[reply]
But such italicisation is appropriate not only to the cant of botanical Latin — in English, for example, many “foreignisms” are marked out by italics in edited prose (e.g., helluo librorum) — they would also warrant the ital= parameter. †﴾(u):Raifʻhār(t):Doremítzwr﴿03:36, 26 July 2009 (UTC)[reply]
Note that man scientific names correspond to common names, although we seem to put them in separate entries, just because the capitalization varies, or to confuse the reader, or something. Examples: geranium and Geranium, aster and Aster, orca and Orcinus orca, E. coli, etc. —MichaelZ. 2009-07-26 16:48 z
What kind of user are we helping by taking a lexical approach to typographic variation in entry titles for search or display? Of course we have no facts, but I don't think that the overwhelming majority users expect typography to be matter of concern in the search and display process. We probably provide adequate service to those who are concerned about typography when we give them information on typographic practice in various contexts. The variation in typographic practice only imperfectly maps to inflection line or even sense line. Although there may be cases where there are good reasons to place typographic information at the inflection line or the sense line, it seems more like appendix material than lexical entry material. Where links to such appendices might be placed is an interesting design question. DCDuringTALK17:15, 26 July 2009 (UTC)[reply]
The COD and some other dictionaries indicate unnaturalized foreign terms using italicization of the headword. This is very sensible: it's a lexical quality, indicated in the dictionary the same way it is indicated in normal writing. The information is descriptive, being based on Oxford's citations database. It gets the information across using zero extra characters, symbols or labels; it is self-explanatory to anyone who cares about it, and doesn't bother anyone who doesn't. It also serves a practical function for the reader, conveying this bit of writing advice for the entire surveyed corpus without forcing her to find a style manual.
But capitalization and italicization are attributes of a word or sense, not always differentiators of meaning, typically secondary, optional, or only in nuance. They should be indicated for the reader as usage, but we shouldn't use them to remove these non-spelling variations of words to separate web pages. This places a burden on the reader to actually figure out what is the significant difference between liberal and Liberal, or aboriginal and Aboriginal, for example, to guess whether we've actually addressed these differences adequately, or even realize that there is another entry important to their query. —MichaelZ. 2009-07-26 18:16 z
Sorry, I didn’t quite follow here; your first paragraph seems to argue in favour of such inflexion-line italicisation, whereas your second seems to argue the opposite — which is it? †﴾(u):Raifʻhār(t):Doremítzwr﴿22:28, 27 July 2009 (UTC)[reply]
I was noticing this very problem at beta#Noun where there is confusion relating to Beta. I don't think most users think to look at other capitalizations, especially after the {{also}} content goes off the screen. A user looking for the Brave New World "Betas" would not find them at "beta". There is not much reason for giving users this problem in English.
OTOH, I may just be confused about the specificity of what we attest to and how it relates to what we present to users. We often seem so punctilious as to have completely forgotten about "imbecilic" users, even when they strongly resemble ourselves, perhaps some time ago. DCDuringTALK21:21, 26 July 2009 (UTC)[reply]
We have case, so we naturally started using it (gosh forbid we should get hammers). Nobody stopped to think that in a print dictionary, the other version is always right there, while in a web page it can't be seen at the same time! This is a bad situation for the readers, but unfortunately it's mainly editors who are making the dictionary.
A solution is to never split up an etymology or part-of-speech subheading between separate entries due to capitalization. Do we have a chance in hell of agreeing on something like that? —MichaelZ. 2009-07-27 03:21 z
Well, you've got my vote on that. I'd like to make sure that I get all the implications, but it seems like the right direction. I fear that it is likely that someone will feel that some potential ox of theirs might get gored. DCDuringTALK03:36, 27 July 2009 (UTC)[reply]
For terms not Translingual, I thought this is a simple problem in logic under WT:CFI. By convention the use of italics to mark a passage in running text marks it as not English and defines where the non-English passage begins and ends. We are not supposed to be accepting such passages as evidence of use in English. If a phrase of originally non-English text is "borrowed" whole into English and appears without italics, we could and often do include it as an English entry. It could also appear as a whole in its original language, in which case it also does not appear in italics.
If Translingual terms are italicized, but the corresponding English term is not we have created extra entries, to no useful purpose that I can see.
If we were to recognize italics in headers, would we then have to allow for attestation both with and without italics?
How does this help users?
How many extra nanoseconds of delay for every search?
Headword italicization seems not-very-useful, in that most people wouldn't notice it, or if they did, wouldn't know how to interpret it. (In a print dictionary, you see a bunch of headwords at once, so you notice if one is italicized while the rest are not. On Wiktionary, for all you know it's our custom to italicize headwords.) I mean, we should do it, but it's not a complete solution. (But as for the suggestion to merge Uppercase and lowercase entries, I heartily support.) —RuakhTALK02:58, 28 July 2009 (UTC)[reply]
You're right about italicization. I tried to figure that out quite a long time ago, but the results were unsatisfying. It would be nice, but I can't think of any way to accomplish it that's not too much effort for the gain.
I'm glad to see that unifying alternate capitalizations might have support. I'll propose it in a bit. —MichaelZ. 2009-08-07 05:24 z
Hello. U ppl r normally gd at manipulatin the dump. Is it possible 2generate a list of all French Wikt entries sans conjugatn? 'd B gd, coz I'm always findin these entries + addin conj 2 entries. Maybe 2 put at User:Rising Sun/Sans conj? Ta --Rising Sun18:35, 22 July 2009 (UTC)[reply]
To aid the anglophones around here, I'll translate: "Hello. You people are normally good at manipulating the dump. Is it possible to generate a list of all French-Wiktionary entries sans conjugation? It would be good, because I'm always finding such entries and adding conjugation to [them]. Maybe [you could be convinced] to put such a list at User:Rising Sun/Sans conj? Ta."—msh210℠22:20, 22 July 2009 (UTC)[reply]
Sorry I am cancelling this request because.I could formulate the link I wanted.Mahitgar05:39, 24 July 2009 (UTC) I have requested a help at Wiktionary talk:Random page simmiller request seems to have been made early this month by another wiktionarian too.Thanks and Regards.[reply]
The usual reference is the SIL/ISO website, where one can search both the codes and language names. They define xcl as "Classical Armenian", but we chose the name Old Armenian to be in conformance with the Wiktionary naming scheme used for other ancient languages (such as Old English, Old Church Slavonic etc.). --Ivan Štambuk17:23, 24 July 2009 (UTC)[reply]
You mean the Dutch common gender? We use c for "common", m for "masculine", f for "feminine", n for "neuter". Note, however, that "common" is not the same as "masculine and feminine". A common gender noun is neither specifically maculine nor feminine. So, while Dutch has a common gender, it also has some masculine and some feminine nouns. Spanish has nouns that may serve as either masculine or feminine, but these are not common gender nouns, because they may take masculine or feminine adjectives or complements. Spanish has no common gender. --EncycloPetey13:06, 28 July 2009 (UTC)[reply]
According to Wiktionary:About Dutch, Dutch doesn't have a common gender as far as we're concerned. From a linguist's standpoint, it's valid to talk about the common gender in some forms of Dutch, but that's not the approach Dutch dictionaries take, including the Dutch Wiktionary. I think any proposal to use c for Dutch should be discussed at Wiktionary:Beer parlour and/or Wiktionary talk:About Dutch — or if there's already been such a proposal, and people supported it, then it needs to be documented at Wiktionary:About Dutch. —RuakhTALK20:11, 28 July 2009 (UTC)[reply]
Just tick "common gender" - or is that not what you want? (It will only appear when a language that requires it is specified, so type "nl" into the box, and then you can get it). Conrad.Irwin19:29, 28 July 2009 (UTC)[reply]
CSS' built-in :lang selector is not now supported by MSIE. Am I correct in supposing that if and when it is supported by whatever browsers then comprise most of the market (or whatever supermajority we're comfortable with), we'll be able to get rid of (most of) our script templates (including Xyzy)?—msh210℠17:28, 27 July 2009 (UTC)[reply]
I doubt it, given that it's actually per-script that we want to change font, and there is no one-to-one mapping between the two. Conrad.Irwin10:37, 1 August 2009 (UTC)[reply]
I'd say yes and no—we should eventually use lang selectors as the primary method of formatting languages and scripts, but it is currently some script templates which insert lang attributes. Certainly the language attribute is where this information lives in a web page.[1] But don't hold your breath until MSIE 6 and 7 are gone—we'll need a supplementary class name to support that shit for a long time.
Our whole optional brackets framework for labels is a broken mess, and I fail to see the reason for a non-standard "face" mechanism, so some significant changes are still needed. —MichaelZ. 2009-08-01 15:43 z
The main problem was there was a space " " after {{trans-mid}}, which caused it not to find it (I will fix this, it is a bug), the other problem was that you missed out the parameter to {{trans-top|gloss of definition}} - which is not optional. Conrad.Irwin20:45, 29 July 2009 (UTC)[reply]
See Atelaes' fix. The issue was that, because the "i)w=ta" contains an equals sign, it thought you were giving it the named parameter {{{i)w}}} (like {{{lang}}} in other templates). Conrad.Irwin20:00, 29 July 2009 (UTC)[reply]
