Hello, you have come here looking for the meaning of the word Wiktionary:Grease pit/2013/January. In DICTIOUS you will not only get to know all the dictionary meanings for the word Wiktionary:Grease pit/2013/January, but we will also tell you about its etymology, its characteristics and you will know how to say Wiktionary:Grease pit/2013/January in singular and plural. Everything you need to know about the word Wiktionary:Grease pit/2013/January you have here. The definition of the word Wiktionary:Grease pit/2013/January will help you to be more precise and correct when speaking or writing your texts. Knowing the definition ofWiktionary:Grease pit/2013/January, as well as those of other words, enriches your vocabulary and provides you with more and better linguistic resources.
The problem: Han script ({{Hani}}, {{Hans}}, and {{Hant}}) tends to look pretty bad in bold, at least in my opinion. Complex traditional characters get mangled and blurred, and even simple characters don't form as well (see the {{&lit}} at 小人#Mandarin for an example). The same is true of a few other scripts, like Burmese ({{Mymr}}). Can we set these to instead increase in size slightly in Mediawiki:common.css like {{Hebr}} curently does? —Μετάknowledgediscuss/deeds22:37, 3 January 2013 (UTC)
You might want to try it out on your own common.css and get all the numbers adjusted right, before making it global. --WikiTiki8905:34, 5 January 2013 (UTC)
The 125% part probably makes sense for any script where we want to use font-size as a substitute for font-weight; but the 144% parts are Hebrew-specific, since they're based on the fact that we already embiggen Hebrew text by 15% (since 115% × 125% = 143¾%). Since we only embiggen Han-script text by 10%, the analogous CSS would have 137% or 138% (since 110% × 125% = 137½%) instead of 144%. Do you see what I mean? —RuakhTALK16:52, 5 January 2013 (UTC)
What is the process for approving bot accounts? I just created WikitikiBot (talk • contribs), which I intend to use for some menial labor, and I want to get it approved. I'm still working on the bot's code and so have not yet tested it. --WikiTiki8904:26, 4 January 2013 (UTC)
Firstly — most of that page is irrelevant to Wikitiki89's specific question, but the question showed that he hadn't read it (and presumably wasn't aware of it), and I would not say that most of that page is irrelevant to him if he plans to run a bot. Secondly — your punchline was a bit mistaken. You said "usually ~50" test edits, but that pages specifies "10-50", with a stricter upper bound, namely "not more than 25", in some cases (possibly including this one: you don't know what Wikitiki89 is planning). So you weren't too far off, but still, why not send him straight to the horse's mouth? —RuakhTALK19:14, 4 January 2013 (UTC)
Sure. But re # of test edits: it's not policy, so historically the number has fluctuated, and we don't even enforce it (we tend to just block bots when they become annoying). WF is still botting through one of his non-bot accounts, or at least was when I last checked, and nobody has blocked him. —Μετάknowledgediscuss/deeds23:01, 4 January 2013 (UTC)
Check again. I was hoping it wouldn't come to that, since up until then he was on his best behavior using that account- but that was too much to ignore. Chuck Entz (talk) 05:26, 5 January 2013 (UTC)
"do a test run (under the bot account) on some 10-50 entries until you’re certain everything goes well". Hmm, seems to me you can't necessarily do both, it would be possible to do edits to 50 entries and not be certain that everything goes well. In which case, you'd need to violate one of the other. Also I notice it specifies a number of entries to be edited, not a number of edits. So in fact there is no limit to the number of test edits, as long as only 50 entries are affected. Mglovesfun (talk) 01:14, 13 January 2013 (UTC)
Doubly separable German verbs
There's a request for an inflection table at ], but I can't fulfill it because that is one of a handful of German verbs (others include ], ], and ]) that are so-called "doubly separable". They have separable prefixes that are themselves separable: when the prefixes are attached to the verb, everything is written together (der Fehler, den ich wiedergutmache), but when they're separate from the verb, then the parts of the prefix are separated too (ich mache den Fehler wieder gut). German Wiktionary has a template for this at de:Vorlage:Deutsch Verb schwach doppelt trennbar, but I'm wondering if there's some way we can modify {{de-conj-weak}} to accommodate these verbs. —Angr11:33, 5 January 2013 (UTC)
Yeah, but since {{de-conj-weak}} already accommodates verbs both with and without separable prefixes, I'd rather it was edited to accommodate verbs with doubly separable prefixes as well, if possible. That way we don't have a proliferation of templates, and we don't create a template that will be used on maybe only four entries. —Angr12:43, 5 January 2013 (UTC)
The language sections were out of order. Is this being adequately addressed by KassadBot or should we devote additional resources to language sorting? DTLHS (talk) 19:06, 6 January 2013 (UTC)
It's true that the language sections were out of order, but that's not really the reason for the problem that CodeCat described; I mean, the same problem would have occurred if the other language had been (say) Polish, which rightly precedes Serbo-Croatian. Rather, the problem is that Tabbed languages had no way of knowing what language Category:Kajkavian Serbo-Croatian belonged to, so it automatically added it to the same tab as the previous category, namely Category:Slovene conjunctions. Re-ordering the languages happened to fix the problem, yes, but only because it meant that there was no previous category (since Category:Slovene conjunctions now followedCategory:Kajkavian Serbo-Croatian), so Tabbed languages just stuck Category:Kajkavian Serbo-Croatian in the first tab. See also: ]. —RuakhTALK19:20, 6 January 2013 (UTC)
In miljard, there seems to be a problem with categories and tabbed languages: the Estonian and Swedish categories move upwards, into the Dutch section. It seems that some templates correctly catch the categories and others let them move upwards. For example {{head|et}} doesn't catch the Estonian categories, so they end up in the Dutch section. When I change {{head|et}} into {{head|et|noun}} the Estonian category correctly stays in the Estonian section, at least in the preview. --MaEr (talk) 14:26, 13 January 2013 (UTC)
Tagging (too) vulgar and/or offensive language: an idea from the Russian Wiktionarians
Hey there! This just came into my mind, that it would be a great addition for English Wiktionary (and probably for others as well). Check this out: ru:на хер. Just that funny symbolism with the &#§$ swearing is worth the implementation alone. I can't seem to remember that we here have such a template, but I may no longer be up-to-date. Anyways, your opinions please? :) -andy 77.7.116.4021:42, 11 January 2013 (UTC)
Support, but only limitedly effective in conjunction with Tabbed Languages, so I'm not sure how much of a difference it would make. I would oppose if it wasn't in the L2 section of the language in question. —Μετάknowledgediscuss/deeds00:30, 12 January 2013 (UTC)
With tabbed languages it’s even better. People reading the entry of a term in language X don’t need to be warned that it’s offensive in language Y. — Ungoliant(Falai)00:36, 12 January 2013 (UTC)
My point was simply that when the TOC is eliminated, the page is so much tighter that offensive material is immediately viewable. But people read downwards, so I guess it's fine. —Μετάknowledgediscuss/deeds01:43, 12 January 2013 (UTC)
I strongly oppose the idea of hiding "offensive" images; Wiktionary is NOT censored. How would you decide whether an image was offensive or not, anyway? On de.Wikt there was a dispute some time ago over whether a picture of two men kissing on their wedding day (as an illustration of homosexuality + gay marriage) was offensive or not. Is nudity as in ] and ] offensive or instructive? Is the Hakenkreuz in ] offensive or instructive? What about the dead pigeon in ]? - -sche(discuss)02:51, 12 January 2013 (UTC)
Since my previous comment was only about hiding images, I'll note that I also think tagging "potentially offensive" entries is a bad idea. As Equinox says, we already tag offensive words as {{offensive}}; a second, boxier "you might be offended by this!! teh horror, teh horror!!" tag would be unnecessary and imprecise: it would cast aspersions on this small tailless amphibian, for example, just to (IMO fail to) convey that the "French person" sense of ] is offensive. Or if the proposal is to tag offensive entries... we shouldn't have any of those; our entries should all be staid, even our entries on offensive words. Consider how staid our coverage of the terms ] and ] is. (And again consider polysemy: if you wanted to declare e.g. ] to be a potentially-offensive entry, because one sense of the word is vulgar, you'd be casting aspersions on "the Spanish language".) And as with images: how would you decide whether an entry was offensive or not, if you weren't tagging all and only {{offensive}}-tagged entries? Would you just tag anything Vahag or Dick Laurent wrote a usex for, lol? - -sche(discuss)05:11, 12 January 2013 (UTC)
I have a different interpretation of WT:NOT censored. I believe that it means that because the word fucktard exists, we should have an entry for it like any other word. I also believe that it does not preclude a warning tag on the page. The "frog" example et al are somewhat ridiculous, because community consensus for any term having non-vulgar senses should be necessary. Just recently, I was checking penis#Latin to see if we had the Old Latin sense meaning "tail" (we do). Naturally, while loading, I got an excellent view of the large photo in penis#English, which I did not particularly want to see at that moment. We get a lot of user requests that we censor, and although I wouldn't go as far as to remove the image, I would prefer if it auto-collapsed, and I think this would pacify a lot of our users as well. —Μετάknowledgediscuss/deeds06:02, 12 January 2013 (UTC)
I find cold weather makes mine auto-collapse. No seriously, I'm ok with the idea of images auto-collapsing, I don't like the idea of an 'offensive' banner. I'd find it patronizing, if I've looked up an offensive word, either I already know it's offensive but don't know the exact meaning, or if I have no idea what it means, I'm going to look it up whether it's offensive or not. As a more general point, I don't believe that being offended is harmful. Mglovesfun (talk) 11:37, 12 January 2013 (UTC)
Not everyone is exactly like you, Mglovesfun. Some people will see the warning and decide not to read the definition (either at all or just at that moment (until they finish eating, for example)). As for images, even if you don't mind seeing certain images in general, some images are inappropriate in certain contexts (for example, at work or other public places) and it will be useful if they are collapsed by default. On the other hand, there is absolutely nothing wrong with seeing a picture of an apple in a public place, so it does not make sense to make all images auto-collapse. --WikiTiki8917:26, 12 January 2013 (UTC)
Some cultures generally, and some people individually, are offended by all images, or by images of people, or only by images of people who are no longer alive, or... etc, etc. Censorship of some images is incompatible with NPOV: unless you hide all images (as Ruakh proposes), you're offending some people. - -sche(discuss)01:43, 13 January 2013 (UTC)
We are not here to cater for everyone's sensibilities. It's impossible to avoid POV entirely. For instance, this dictionary is primarily designed for those can read with their eyes rather than with e.g. their fingers (braille). We sort language entries alphabetically with English/Multilingual at the top; this is also a POV. I could go on. Hiding certain images by default is no more POV than the previous things; it's a matter of design and organisation. We don't say that the images are offensive or should be; we just recognise that a large number of people are not interested in looking at them.
It makes a lot of sense for a dictionary to have images where possible and relevant, just as it makes sense to focus on design and the experiences any user of the dictionary will have.
If we said that we would not have pictures at all at entries x, y, and z because they would offend some people, then that would be POV and censorship. Having the images for certain entries accessible with an extra click is not, it's a minor design issue. Njardarlogar (talk) 12:55, 13 January 2013 (UTC)
Re: "I don't believe that being offended is harmful": I'm not sure whether I agree. From context, I agree with your meaning — it is not harmful to be exposed to content that one considers offensive — but I disagree with your actual words. To offend someone is to harm them. —RuakhTALK18:07, 12 January 2013 (UTC)
I agree with Meta's interpretation of the not censored principle. Censoring the content would be deleting or removing it, or making it very hard to access. Having to click one extra time is not censorship.
The implication that it would be unusually hard to figure out what should be hidden at first sight ("censored") is absurd. It is in principle no different from agreeing on the critera for inclusion; one does not demand divine intervention for this task either, consensus will suffice.
I don't know if I agree with hiding offensive meanings, but if it were implemented, something like "This page contains potentially offensive definitions, click here to show them" sounds ideal to me. Then all potentially offensive defintions would appear/disappear at once. Same with images. Njardarlogar (talk) 18:48, 12 January 2013 (UTC)
re "The "frog" example et al are somewhat ridiculous": the whole idea of a "this entry might offend you!" template is ridiculous, IMO, but... re "community consensus for any term having non-vulgar senses should be necessary": ah, that's a new idea, and creates even more problems. If you do tag some entries (e.g. ] and/or ]), you lull people into a sense of security, that terms for vulgar things have warnings. If you then don't tag ], sense 3 of which refers to a very vulgar practice, those lulled people get quite a surprise and a chance to be offended at the entry and at your failure to warn them about it... whereas, if you do tag ], sense 1 of which is the only common term for one of the most widely-spoken languages in the world, you're likely to offend other people (by implying there's something wrong with Castilian). - -sche(discuss)02:09, 13 January 2013 (UTC)
Re: "our entries should all be staid, even our entries on offensive words": I agree, but not everyone does. Many editors believe that the definition for a foreign-language term should just be its English translation(s) plus a parenthetical gloss, and therefore that the definition for an offensive foreign-language term should be an offensive English term. Until such time as the community decides to explicitly reject that view — and I'm not holding my breath — we can't really operate on the assumption that our entries will be staid/inoffensive. —RuakhTALK18:07, 12 January 2013 (UTC)
I don't think the censorship should be happening at our end, though. Those who want censorship can install something that will flash and abort when a page has a dirty word. Likewise, those who need screen-readers, or extra-large text, should be doing it with their own software, not relying on us. We only provide a dictionary. Equinox◑18:11, 12 January 2013 (UTC)
Agreed, we need to avoid trying to be all things to all people (one of our worst vices in my opinion, like trying to be an encyclopedia or a book or quotations). If people want offensive language filtering out, that should not come from our server, but from their software. Would love to know what Ungoliant MMDCCLXIV, Wikitiki89 and Metaknowledge are thinking. Mglovesfun (talk) 01:10, 13 January 2013 (UTC)
Adding a box which tags something as offensive doesn’t censor anything, it merely adds more information. It’s not really necessary (because we already use parenthetical context tags to indicate offensiveness), but I’d find it quite useful. The accidental use of an offensive word in a language someone is learning can ruin their day... or month, or friendships, or career... and therefore an extra tag (which, BTW, should be used when the word’s main modern meaning is offensive; so that words like nigger, shitskin and faggot would have it, but not frog and Spanisch) would be an extra measure for helping prevent accidental misuse of an offensive word.
Auto-colapsing offensive images is more borderline, but I think it’s not really censorship either. Are we censoring German, because the declension tables of their adjectives are auto-colapsed, while the Old English ones aren’t? — Ungoliant(Falai)02:16, 13 January 2013 (UTC)
Print dictionaries don't print warning boxes like this, despite including "rude words". I don't see why we differ. Equinox◑02:33, 13 January 2013 (UTC)
They don’t have conjugation boxes either. Print dictionaries have a much harder time balancing usefulness and space limitations than we do. — Ungoliant(Falai)02:36, 13 January 2013 (UTC)
Well... the OED did not include such words as "fuck" until the 1970s. Clearly we need to be more pragmatic about lexicography than simply saying "they don't do it, why should we". —Μετάknowledgediscuss/deeds03:13, 13 January 2013 (UTC)
I only fall back on the "lemming argument" ("they don't do it") when people aren't listening to the others. Censoring ourselves because some theoretical person might be offended, when nobody has registered offence, is bizarre Orwellianism. Equinox◑21:02, 14 January 2013 (UTC)
Maybe we should add a big red button on the sidebar that says "Click here if you were offended by the content of this page."? --WikiTiki8921:11, 14 January 2013 (UTC)
Well I just meant that it would record the number of people who are offended by certain pages. It was a response to Equinox's claim that only "some theoretical person might be offended". --WikiTiki8921:52, 14 January 2013 (UTC)
But there would be way no way to know how many people were actually offended by it and how many people just thought it would be funny to click the big red button and pretend to be offended by some perfectly innocent word. —Angr21:57, 14 January 2013 (UTC)
I’m not claiming it should be done because people might be offended. I said that it should be created as an extra step to prevent misuse of a word. Preventing misuse of words is a valid goal for a dictionary. — Ungoliant(Falai)21:34, 14 January 2013 (UTC)
I think "obscene or offensive" should link to a Wiktionary page that gives more information about the practice. —CodeCat14:09, 15 January 2013 (UTC)
I think the colors seem a little out of place here. Unlike the ru.wikt, we don't use a lot of colorful templates. I think removing the pink background and making the red bold text black bold instead would fit better. --WikiTiki8916:47, 15 January 2013 (UTC)
BTW, one of the reasons I don't like the red text in the original version is that red text for me is heavily associated with redlinks. --WikiTiki8906:18, 17 January 2013 (UTC)
If the word "Attention!" is left out, then there needs to be a little more space between the bubble and the text, otherwise it looks a bit awkward to me. --WikiTiki8907:27, 17 January 2013 (UTC)
Here's another suggestion; "Attention" replaced with "Note" (which might also be redundant):
I still disapprove of having any such tag on an entry at all. I would much rather we write our own Content disclaimer rather than merely soft-redirecting to Wikipedia's, and let that contain the warning that some entries may seem obscene or offensive to some readers. —Angr18:00, 17 January 2013 (UTC)
We don't want to entirely prevent people who are offended by obscenities from browsing Wiktionary. We should allow them to browse the majority of pages that don't have obscenities without worrying about finding obscenities. --WikiTiki8922:41, 17 January 2013 (UTC)
People who are that offended by obscenities probably shouldn't be on the Internet in the first place. It's not our job to try to anticipate what words someone somewhere might be offended by and then put a completely useless tag on it warning them of its presence. It's not like we're putting up graphic photos of rape/murder/child molestation in progress. It's just silly to slap a big ol' template on every word like poo or Republican just because some people might get their delicate sensibilities hurt by them. I also don't think anyone who is offended by obscene words is going to be placated by a sign like one of these. —Angr23:14, 17 January 2013 (UTC)
Well obviously poo and Republican are not the kind of words that we would use this template on. And we are not trying to placate them, but warn them not to read the page (in the presence of their children or something like that). --WikiTiki8923:24, 17 January 2013 (UTC)
I recall that my high school library had an English dictionary with a small supplementary volume containing all of the slang and vulgar words. This was a great convenience for us In looking up the dirty words and discovering new ones. There was no need for a big red label; we had no trouble finding the little book when we needed to. I suppose the relevant category pages make it even more convenient in Wiktionary.
Anyone know which dictionary that would have been? —MichaelZ. 2013-03-13 20:49 z
I just added a citation to wiki#Lower Sorbian using {{quote-book}}, but I noticed that that template doesn't have a lang= parameter, and when I look at the HTML source of the page ], the Lower Sorbian isn't marked as being Lower Sorbian. Should I just use {{Latn|...|lang=dsb}} for the quotation, or what? —Angr15:45, 13 January 2013 (UTC)
In general, I think it's best to avoid {{quote-book}}; but especially when it gives you any trouble, it's not worth thinking about. When it's simple and straightforward and perfect, fine, it's O.K. to use it (but still better not to), but when it isn't, it's really best to just bypass it. (And likewise for all the other quotation templates.) —RuakhTALK16:16, 13 January 2013 (UTC)
OK, but even if I add the quote templatelessly, the same problem arises: how do I tell the HTML that this text is written in Lower Sorbian? Is {{Latn|...|lang=dsb}} the best way to do it? —Angr16:39, 13 January 2013 (UTC)
One of the reasons for {{lang}} is that we have templates that provide a link and automatically set the script/language, but none that set the script/language alone without a link. Basically, one has to know the script a language uses if one is to apply it correctly, which is a bit strange and inconsistent... —CodeCat20:12, 13 January 2013 (UTC)
The existence and use of a template gives the impression of standardization, the impression that the template should be used. For example, anyone who's spent any amount of time at Wiktionary, and sees a definition-line that starts with italicized parenthesized text, will immediately see that it should use {{context}}. And indeed, {{cite meta}} — which {{quote-book}} uses — actually marks up its HTML with hooks for CSS, which obviously only makes sense if we assume from the get-go that all quotations will eventually use quotation templates. But that will never be the case, because quotation formatting is complicated, and there are always special cases that no template could know how to handle. (For example: What if the author of the chapter is not the author of the book? What if the book is quoting someone?) The quotation templates do not actually help with formatting; their only benefit is if they helped with standardization, and they don't, so they've no benefit at all.
The quotation templates in general, and {{quote-book}} in particular, do not accord with Wiktionary:Quotations; and it's often not even clear what they're trying to do. For example, if {{quote-book/source}} gets an undocumented origdate= parameter, then it puts that in square brackets after the bold year. What can that possibly mean? If the quotation actually originates from the date specified in origdate=, then clearly origdate= is what should be in bold at the beginning of the metadata-line. (As it happens, {{quote-book}} actually doesn't relay origdate=, so this is just dead code — not exactly reassuring, BTW — but other similar quotation templates do the same thing in non-dead code, and it's impossible to keep track of the ins and outs of all of them.)
The quotation templates are not very well written, even for what they currently achieve. For example:
{{quote-book}} supports two disparate notations, one based on positional parameters and one based on named parameters. This is pretty expensive — similar problems in Wikipedia quotation templates have actually caused such performance issues that they're a big motivator in the creation of Scribunto — but more importantly, it means that individual invocations of {{quote-book}} are completely inconsistent and incompatible. Someone who's only used to using one notation will basically have to start fresh if they want to add information to a quotation that was formatted using the other notation.
The editor who created the quotation templates apparently didn't realize that indentation could be controlled rather simply, by using the HTML tags that : evaluates to (namely <dl> and <dd>); as a result, he originally created a very complicated indentation system based on exhaustively listing all possible indentations and passing them in as separate parameters . . . I've done my best to retrofit the simple HTML-based system into the templates, which addresses the worst of it, but it's very difficult to fix the rest of it without breaking existing template invocations. I believe it will require a bot run.
More generally, the templates are very complicated and very fragile. When someone points out an issue with one of them, it generally takes a few years before anyone works up the courage to try to fix it. And there are currently plenty of open issues that may (or may not) be fixed within the next few years.
If our quotation-templates weren't already a widely-used mess, we could maybe start fresh and introduce a less-bad system of quotation-templates, but as it is, it's a very large amount of work to make even small improvements without breaking things. —RuakhTALK18:36, 13 January 2013 (UTC)
This is very sad, because quotations are something which would benefit greatly from standardisation, and because I’ve been using it for a while, and because last night I started collecting citations of abafador in a text file, and now I will have to reformat all of them :-(. This might be a case for a “pseudo-RFDO”, which would result in the addition of a warning against use at {{quote-book/doc}} and a ban on further use if it passes. — Ungoliant(Falai)18:55, 13 January 2013 (UTC)
I don't think you need to find/fix/reformat existing cases of {{quote-book}}; if we ever build a consensus to do that, it shouldn't be too hard to automate it. (Famous last words, I know.) In the meantime, if you want to keep using it for the cases that it handles well, feel free; I just hate to think that people are contorting themselves to try to deal with the cases that it doesn't handle well. —RuakhTALK20:02, 13 January 2013 (UTC)
I'm surprised to hear your negativity about automation. It's relatively trivial (I've done it) to write a wikitext template parser to find and transform templates into dictionaries or other useful structures, regardless of the parameter order or other formatting considerations. I can parse the templates on pneumonoultramicroscopicsilicovolcanoconiosis and abduct identically with no custom considerations for each. I agree with your other points. DTLHS (talk) 18:59, 13 January 2013 (UTC)
The problem isn't that it's terribly hard to find and handle {{quote-book}}, when that's what you want to do; it's that you have to do that, even when that's not what you want. (For example, I was once asked to count the number of blocks of definitions on en.wikt, aside from ones that are just form-ofs. This task was made needlessly difficult by the fact that, if a single quotation-template spans multiple lines, then not every line within a block of definitions will begin with #; so even the concept of "block of definitions" takes significant effort to translate into code. I assume that tools like ninjawords have also had to deal with this in cases where it wasn't really relevant to their goals.) —RuakhTALK20:02, 13 January 2013 (UTC)
Hi there. I've started a new extension, NamespaceRelations, recently, which allows to define additional tabs (like Citations or Documentation). I've approached the community of Wikinews on the same question (they have an Opinions tab there). So for now I'd like to ask you - do you find this extension useful for Wiktionary and a better implementation of the feature than the current one (JS)? Wizardist (talk) 00:57, 14 January 2013 (UTC)
How does this relate to the other two patches linked to from ]? I mean, first of all, does have the same function? If so, then is this to be installed because you've given up hope on the other two's being installed, or why? And if that is the reason, then why do you think this is more likely to be installed?—msh210℠ (talk) 20:33, 14 January 2013 (UTC)
Those patches (one by Svip, one by myself) were superseded by this extension (read this why). The first patch was outdated, and both Svip's patch and mine were changing the core (MediaWiki itself). It was considered that such functionality is redundant for core. Moreover, my patch was really hackish, as described by Daniel Friesen. On the other hand, this extension does everything that Wiktionary needs (and even more): additional tab for a specific namespace, targeting to a certain namespace, optionally show the tab for Main Page (if attached to main namespace), option to define the query string for "red" tabs (this feature wasn't implemented in neither patch), tab sorting, and optional hide Talk tab feature. It's completely localazible by standard means of MediaWiki (including tooltips) and it doesn't create new requests to MediaWiki via API :) Wizardist (talk) 00:40, 15 January 2013 (UTC)
Ah, okay; thanks for the info. I'm all for this change (in theory. I haven't actually read the extension (and likely wouldn't understand it if I were to)).—msh210℠ (talk) 01:14, 15 January 2013 (UTC)
Oh, that's awesome that you reminded me about a tab in Template namespace (it just got out of my head). I'll work some magic to define custom targets (not just namespace). Thank you! Moving template documentation is not evil, but we have a cross-wiki practice to put it to the subpage. Wizardist (talk) 16:52, 15 January 2013 (UTC)
On my screen, the special characters toolbar at the bottom is literally right below the "Save page", "Show preview", and "Show changes" buttons...so close, in fact, that recently I managed to misclick and hit save page instead of the drop down for the special characters toolbar. Is there any way that there can be a separation inserted between these buttons and the special character toolbar, perhaps of about the same size as between the "Subject/headline" line when creating a new section or between the edit summary and the "minor edit"/"watch this page" check boxes? Ks0stm(T•C)19:33, 16 January 2013 (UTC)
Most of the special characters below the edit box are actually duplicated in the "Special characters" area above the edit field. You might want to use those instead. --Yair rand (talk) 22:37, 16 January 2013 (UTC)
Un-collapsed templates by default in template namespace
On Wikipedia, collapsible templates only collapse if there is more than one template of the same kind on the page. I think it would be useful if templates didn't collapse when viewed from within the Template namespace. This would make viewing/editing inflection tables a bit easier because they would be visible by default. Would it be possible to do this automatically (without having to edit all the templates)? —CodeCat04:35, 17 January 2013 (UTC)
Certainly would be possible. Adding mw.config.get("wgNamespaceNumber") == 10 || in front of the NavBars addOnloadHook would disable the collapsing/expanding bit entirely in the Template: namespace, and something a bit more complicated could just make it run, but just be expanded by default. I'm not sure it would be a good idea though. It might confuse people to have the display be different in the template space than in the main namespace. --Yair rand (talk) 04:46, 17 January 2013 (UTC)
I think it's an excellent idea, though I'm not sure about the mw.config.get("wgNamespaceNumber") == 10 approach (since then it also wouldn't collapse all the copies of the template in its documentation page, and so on). The approach that I've been using, e.g. at Template:he-prep-inflection, is approximately class="<noinclude>not </noinclude>NavFrame", so that the template-page shows all the same styling, just not collapsed (and not collapsible); but it could definitely be improved upon. —RuakhTALK05:22, 17 January 2013 (UTC)
I have no idea how the template collapsing works, so I'm not sure where the changes would be made or how to make them. Could you help Ruakh? —CodeCat15:32, 17 January 2013 (UTC)
Change template:prefix to take a null second parameter
I just learned that you can use {{suffix}} with a null first parameter. This is really handy when you have a suffix added to something that doesn't exist unsuffixed in the language: you have the whole etymology, then you put {{suffix|ic}} (or whatever) after it. This doesn't work with a null second parameter and {{prefix}}, though. Might someone who's good enough with templates to not mess up a heavily-used workhorse template be so nice as to "make it so"? Chuck Entz (talk) 15:14, 17 January 2013 (UTC)
As CodeCat implies, it works if you just completely leave out the second parameter. It will misbehave if you try to use a blank second parameter, as in {{prefix|pre||lang=en}}, because the category sort-key it uses is {{{sort|{{{2|{{SUBPAGENAME}}}}}}}}, which evaluates to the empty string if 2= is present-but-blank, and MediaWiki gets confused when you try to use the empty string as your sort-key. The simplest fix, if we care to fix it, is to change {{{2|{{SUBPAGENAME}}}}} to {{#if:{{{2|}}}|{{{2}}}|{{SUBPAGENAME}}}}. —RuakhTALK07:06, 18 January 2013 (UTC)
I think a better way would be to force a sort key if there is no second parameter, so that it's obvious that the template will sort wrong if it's not provided. Would that be ok? —CodeCat14:13, 18 January 2013 (UTC)
I'm not sure if these are known bugs or idiosyncracies of my own system, but most fonts that the docs claim to support (Kannada, Ge'ez, etc) which I could not view previously are still not displaying. At Category:Bengali nouns, I can see the Bengali entries, but the letter headings are still boxes. —Μετάknowledgediscuss/deeds05:10, 18 January 2013 (UTC)
Re: Category:Bengali nouns: The reason you can see the Bengali entries is that just under a year ago, Yair rand added some JavaScript that applies language-formatting to them (search MediaWiki:Common.js for Category page fixes). The reason the letter headings are still boxes for you is that no such JavaScript has been created for those. —RuakhTALK07:03, 18 January 2013 (UTC)
FWIW, as of today I can see Burmese (except at the top of Burmese entries and on my watchlist, where it's still boxes) on my computer at work, which I didn't used to be able to. So something is going right! —Angr12:38, 18 January 2013 (UTC)
Some script templates hadn't been filling in the lang attribute, so the fonts weren't being applied. I've fixed it for Kannada. Unfortunately, the only Ethiopic script languages that WebFonts recognizes by default are Amharic and Tigrinya, so it's not working for Ge'ez. We should probably change Common.css so that the fonts get applied depending on script templates instead of by lang attributes, so that languages that WebFonts isn't aware of still get fonts. --Yair rand (talk) 01:26, 21 January 2013 (UTC)
Hm, I'm not sure how that should be done. For category page headings, we probably don't want things like "א cont." entirely in the language's script. Maybe we could modify MediaWiki:Listingcontinuesabbrev to just nullify the effects of applied fonts over the "cont.", and then just change the JS to apply them over all H3s. (Or maybe we could just hide the headers entirely with CSS, like the Swedish Wiktionary does. I don't really get why we have them in the first place.) For page titles at the tops of pages, we might need to have a template using DISPLAYTITLE: in entries, but that would be rather annoying to have to do. For titles appearing in watchlists, recentchanges, etc, I think there might not be a possible solution at all. --Yair rand (talk) 07:04, 21 January 2013 (UTC)
Isn't the whole point that they could have chosen the best Hebrew font without worrying about whether people have it, rather than some oddly-shaped monospaced font that comes with everyone's computer anyway? --WikiTiki8923:20, 21 January 2013 (UTC)
The fonts for Hebrew available in WebFonts are Miriam CLM (אבגדהוזחטי) and Taamey Frank CLM (אבגדהוזחטי). Do you think we should use a different font? If you find a better free font, we could file a bug to change the WebFonts configuration on Wiktionary. (To quote the documenatation, "please note that we will add support only for freely licensed fonts, for example fonts licensed under GNU GPL, SIL OFL, etc".) I suspect that neither the font we were previously using nor the one being used now are available on everyone's computers. --Yair rand (talk) 01:38, 22 January 2013 (UTC)
I don't see what you mean, Angr. The typefaces used for printing Modern Hebrew and Yiddish are not much different from the font you linked to. I tried it out, and in my opinion the only problem with it is that it doesn't look very good in small sizes. --WikiTiki8921:41, 22 January 2013 (UTC)
It's more of a style thing. Amir was telling me once how fonts like Ezra SIL just look very "Biblical" to speakers of Modern Israeli Hebrew, and it strikes them as rather odd to see modern texts written in it. Sort of like Blackletter in English, though maybe not quite as extreme. —Angr22:21, 22 January 2013 (UTC)
FWIW, I don't think Ezra SIL looks "Biblical"; old-fashioned, sure (in the extreme thinness of the verticals, and in the elegant detailing of the serifs), but the kind of old-fashioned that strikes me as acceptable in a dictionary. And . . . it might be unavoidable. It's hard to find a font that handles all the nikúd (vowels and whatnot) correctly and readably, while still looking perfectly normal when rendering Modern Israeli swear words. (The problem that Wikitiki89 describes, however, seems like a bigger deal.) —RuakhTALK03:02, 23 January 2013 (UTC)
Well you're more used to reading the Hebrew alphabet than I am, so if you're happy with it, I'm happy with it. I wonder if someone could make an image comparing Ezra SIL with Taamey Frank CLM at a relatively small size (like 10, 12, and 14 point) so we can see the difference between them at that size. —Angr11:29, 23 January 2013 (UTC)
I can do that if you find me a link where I can download Taamey Frank CLM. Looking at its results in Google Image Search, I would say that in larger sizes Taamey Frank CLM looks slightly less awkward than Ezra SIL, but I can't say whether it will continue to look good small without being able to try it out. --WikiTiki8916:32, 23 January 2013 (UTC)
Taamey Frank CLM can apparently be downloaded here. Of the other fonts on that page (which I assume are all libre, though it doesn't seem to say so anywhere) I rather like Taamey David CLM. It's less old-fashioned than Taamey Frank. Ruakh, what do you think? —Angr17:11, 23 January 2013 (UTC)
-sche's comparison FWIW. Ezra SIL is at the top of each triplet, Taamey Frank CLM is in the middle and, for reference, Arial is the bottom row. The top triplet is at size 14, the next ones down are size 12, 10 and 8. Taamey Frank seems illegible to me at small sizes. Ezra seems to be inherently larger. - -sche(discuss)17:20, 23 January 2013 (UTC)
Wikitiki89's comparison Here's the comparison I did (the sizes are 14, 12, and 10). I still think Ezra SIL looks awkward at those sizes, but it does seem to be the most legible with vowel points. --WikiTiki8918:06, 23 January 2013 (UTC)
┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ I also agree, based on both images, that Ezra SIL is the most legible at small sizes. —Angr18:49, 23 January 2013 (UTC)
As do I. Taamey David is meh IMO, and having a prayer written in it looks weird and distinctively un-prayerbookish. Does this count as consensus for Ezra SIL? —Μετάknowledgediscuss/deeds18:59, 23 January 2013 (UTC)
Re: "I'd like to hear what Ruakh thinks": Sorry, I've got nothing. All I see are tradeoffs, no clear winners. —RuakhTALK07:12, 24 January 2013 (UTC)
Well, Ruakh called Ezra SIL "acceptable" and said that it "might be unavoidable". Not a glowing recommendation, but maybe he'll be more partisan for a certain font after seeing the image samples. Yes, I know that the text doesn't matter, but font preference is somewhat a gut reaction thing anyway (I mean, as long as the fonts in question display stuff accurately, which a bunch of these can't even do). And my opinion of it being fairly "meh" stands independent of that judgement. —Μετάknowledgediscuss/deeds19:42, 23 January 2013 (UTC)
@Angr, Here is an example of typesetting in Modern Hebrew books. To me it looks much more like what you call "old-fashioned" fonts than like the David fonts. --WikiTiki8920:37, 23 January 2013 (UTC)
You think? It doesn't have what Ruakh called "extreme thinness of the verticals" or "elegant detailing of the serifs". It looks more formal than David, but not as formal as Ezra. Maybe there needs to be a font called Chronicles (since that's what comes between Kings and Ezra in the Old Testament!). —Angr20:47, 23 January 2013 (UTC)
I agree with Ruakh above that there are only tradeoffs, no clear winners here, but I consider Ezra SIL the least bad of the options we've seen so far. Is anyone opposed to it? —Angr16:51, 24 January 2013 (UTC)
I've been seeing bogus sub-stub entries lately with (Mobile edit) at the end of the edit summary (there doesn't seem to be a pattern in the IPs creating them). Is there some new mobile app with entry-creation capability that's making it easier to create junk entries? Chuck Entz (talk) 02:08, 19 January 2013 (UTC)
I haven't seen a single non-vandalistic edit from a mobile source. Can we set a filter to give users a warning that they must click through before they can save a mobile edit? That might slow them down a bit. —Μετάknowledgediscuss/deeds06:16, 21 January 2013 (UTC)
How about issuing warnings as a temporary measure? I mean, the way things are going, I suspect a large minority of edits will be mobile in a coupla years.—msh210℠ (talk) 06:50, 21 January 2013 (UTC)
It's now the end of the month, and we have been getting several of these every day. Without exception, every single one has been rubbish. SemperBlotto (talk) 16:44, 31 January 2013 (UTC)
Not really related, but there are a lot more spambots lately, and some of them seem to be "standard" ones that put together bits of gibberish from different Web sources. Equinox◑16:50, 31 January 2013 (UTC)
You have to sign up for the Beta to get access to edit capability. I made an edit for emerald using the interface, but from my laptop. It took the edits but added "carriage returns" that I didn't think I'd added (now cleaned up). DCDuringTALK17:11, 31 January 2013 (UTC)
I'm sure there are other possibilities too. Some of these may be fixable. Mobile devices are likely to become even more popular over time. Can't we let this run its course for a while? We can ask for it to be disabled if things don't get better. DCDuringTALK
I want to add a {{{alt}}} parameter to template:soplink. I tried one method, but it didn't work. (I've reverted.) One method that will work is to put {{{alt|the linked-to page}}} as the display text, but the linked-to page is a rather lengthy, complicated thing, and I'd rather avoid repeating it if possible. Is there another way?—msh210℠ (talk) 06:55, 20 January 2013 (UTC)
Table width
Is there a way to specify (with CSS) that a collapsible table (like {{sl-decl-noun-table}}) should normally have a certain fixed width, but allow it to be narrower if it would not fit on the user's screen otherwise? —CodeCat13:57, 21 January 2013 (UTC)
Bug in translation table rendering
There is a bug that causes the Armenian translation to appear in the heading of each translation table, for example in this screenshot taken from the page water:
It’s a feature called Targeted translations. You can disable it here (under the Gadgets tab). Or you can deselect Armenian as a targeted language (just open any translation table with an Armenian translation and click “Select targeted languages”). — Ungoliant(Falai)20:23, 21 January 2013 (UTC)
Sorry, should have tested it more. It works when I'm logged out and without tabbed languages. With tabbed languages it just defaults to the English section. 70.162.4.24221:44, 22 January 2013 (UTC)
Does anyone here know what the resource costs of the various special maintenance pages, both those run twice a week and those not run at all?
Four special pages have not been run at all since 2009, Special:DeadEndPages, Special:AncientPages, Special:FewestRevisions, and Special:WantedPages. Of those, Wanted Pages seems the most useful. It is fairly clear that the technical folks at MediaWiki do not want to run Wanted Pages for large wikis at all, even annually, apparently for resource reasons. A possibility is that we could give up some of the special pages which are not particularly useful to us (a BP matter, IMO) in exchange for getting some runs of those that have not been run for three years. If the resource cost of the what we give up does not approach the cost of what we would ask for, then this approach would not work. DCDuringTALK15:16, 23 January 2013 (UTC)
I don't think the resource cost is really all that high. If you consider that these pages only get updated once a month, why is it such a problem if the server load goes up once a month? Surely Wiktionary has much bigger loads to deal with than that? —CodeCat15:32, 23 January 2013 (UTC)
I haven't looked at the relevant code, but I understand that these are implemented as SQL queries, so it's not at all surprising that they'd be too resource-intensive to run. The database is the hardest-to-cheapen part of a system like en.wikt. The dumps are presumably only possible because their WHERE-clauses are so simple, and so closely tied to primary keys, that the database can generate the query output without ever even needing to assemble a list of records. —RuakhTALK06:11, 24 January 2013 (UTC)
The first three of these seem fairly useless - I wouldn't mind them going. The fourth is very useful and should be recreated. But I can't help noticing that some of the entries still haven't been dealt with after more than three years (I've just dealt with "abetir") SemperBlotto (talk) 15:34, 23 January 2013 (UTC)
It may be that we really need to do special dump runs instead, that focus on mainspace pages wanted by other mainspace entries, excluding, for example, mainspace items wanted only on user pages and old discussion pages. There is a lot of cruft on these pages and probably would be on fresh runs. It would be nice it MW could do a more selective run for us routinely rather than requiring dump processing. DCDuringTALK15:54, 23 January 2013 (UTC)
Whatever our assessment of the resource costs of special wanted pages is, MW does not want to run it as part of the maintenance runs that they seem to do every 4 days or so. They had not been running it for any project. They seem to be planning on doing it for "smaller" wikis only. DCDuringTALK16:02, 23 January 2013 (UTC)
How useful would it be to run our own version of WantedPages, just counting "easy" links- no templates, just explicit wikilinks? DTLHS (talk) 06:28, 24 January 2013 (UTC)
I'm not sure that explicit-wikilinks are that much easier than all-wikilinks; the latter are readily available, after all, from the pagelinks.sql.gz dump ("Wiki page-to-page link records"). —RuakhTALK07:10, 24 January 2013 (UTC)
I would really like it if the "wants" were limited to pages in principal namespace wanted only from other pages in principal namespace. Also, it would be useful to identify the language of the wanted term, which would be possible for many that are in {{term}} or {{l}}. Presumably most of those not so enclosed, but in Latin script using no diacritical marks are English. In any event it would be up to someone working the presumed-English list to get them to the right list. DCDuringTALK00:47, 25 January 2013 (UTC)
re: namespaces: The pagelinks.sql.gz dump apparently does not unambiguously distinguish the main namespace from others- it uses 0 as the "default" namespace, which catches most pages but also includes things like User: and Wiktionary: pages for some reason. In addition any namespace prefixes are stripped from the page identifiers so there's no way to filter them. If someone knows how to get around this I'd love to hear it.
Better explanation: there are 3 pieces of information for each link: the linking page ID, namespace of page being linked to, and title of the page being linked to. There is no information about the namespace of the linking page. DTLHS (talk) 01:20, 25 January 2013 (UTC)
I could do something similar with {{term}} and {{l}}, identifying language sections, but that would have to be a separate process, from the main dump file. DTLHS (talk) 00:59, 25 January 2013 (UTC)
Is it just a single simple list with those three items? So one would would have to look up each link page by its ID to find out what namespace it was in or create a list of page IDs that were in principal namespace and only process them? DCDuringTALK01:44, 25 January 2013 (UTC)
My 2 pence: DTLHS's list is somewhat helpful, but includes a massive amount of junk as well, stuff like Queequeg and CFI. Without being able to only get mainspace links, I think our manually generated request pages are superior. Maybe an updated User:Visviva/Elsewhere is the best way to get this kind of data. —Μετάknowledgediscuss/deeds07:17, 25 January 2013 (UTC)
If we can't get better discrimination, we might as well not have the run.
Are the page IDs at least persistent? If a given page ID belongs to a principal namespace entry today, is it very highly likely to belong to the same one the next time there is a dump (and highly likely next year)?
Page-IDs are absolutely persistent, yes. Even if a page is deleted, its page-ID will never be reassigned to a different page. The only way that a page-ID will change namespaces is if someone uses Special:MovePage and changes its namespace. (In practice, that does happen sometimes — sandbox JavaScript moved from User: to MediaWiki:, proposed policies moved from User: to Wiktionary:, completed transwikis moved from Transwiki: to namespace zero, non-CFI-meeting entries moved to Talk: or Citations: or Appendix:, etc. — but the vast, vast majority of pages have always resided in the same namespace.) —RuakhTALK15:26, 25 January 2013 (UTC)
Well, that would be a start. I guess it is still somewhat resource intensive to extract only those of the vast number of redlinks that had link IDs that were included in the list of more than a million principal namespace pages. As the IDs are persistent, there would be lasting benefit from excluding pages that were only "form of" entries (in all languages), only updating the exclusion list at long intervals, ie, annually.
Also, I could not find the top 10 items (each with more than a thousand hits) on more than a few pages using search. Why do they show up with so many hits? DCDuringTALK15:42, 25 January 2013 (UTC)
For some reason I thought the page IDs were arbitrary. Now updated with only links from the main namespace. DTLHS (talk) 03:24, 26 January 2013 (UTC)
Excellent! It is most helpful. I can see that a few have already turned blue. At some point we are going to have to get beyond the first 5000 because there will some that just won't get done. There is some clogging with upper-case spellings which we don't have, some in under-represented languages, etc. DCDuringTALK04:54, 26 January 2013 (UTC)
At User:DCDuring/SpecialPagesRelativeCost is something from an e-mail about the relative time taken on servers for WP's special runs. As one might expect, the runs that hove most and least in the titles take a long time to run. Also "Wanted Pages", which is really "Most Wanted Pages". I doubt that we need these as frequently as they are run (~every four days). DCDuringTALK17:36, 30 January 2013 (UTC)
A little thing for those who care about it...
If you are one of the people who care about whether text is marked in the correct language (HTML-wise), you can add this to your common.css file:
*:not(:lang(en))
{
background: #FFF0F8;
}
This will give all text on the page that is not marked as English a slight pinkish background so you can spot it. More importantly you can spot when it's missing. I hope it's useful! :) —CodeCat21:56, 24 January 2013 (UTC)
I've noticed while creating/editing Chinese (CJKV) character pages that Hakka gets little love. I'd like to make a template for it similar to Template:yue-hanzi with attributes for associated romanization methods such as Phak-fa-su and Guangdong phonetic (as used by Hakka with tones 1-8 and no given "4" tone); in other words, like (Cantonese) yue-hanzi's "jyut=" (jyutping) and "y=" (Yale) attributes. Just to give some facts, Hakka Chinese hasn't undergone the same sort of standardization processes that the more widely spoken Mandarin and Cantonese have. In spite of this, Hakka has over 31 million speakers and ranks 39th in most-spoken languages worldwide; it has a notable linguistic diaspora outside of mainland China and Taiwan. Anyway, I just thought such a template would be useful and would like to create it myself but I thought I'd bring it up here first. Bumm13 (talk) 22:28, 24 January 2013 (UTC)
I don't think you really need to discuss creating a new set of templates for a language that had none before. If you know how to do it I think you should go for it. :) —CodeCat22:31, 24 January 2013 (UTC)
This was created some time ago, but it hasn't really been used much. It is much faster and more efficient than {{l|en}} though, and I kind of like the idea of tailor-made linking templates for languages. If we did the same for translations, it would allow us to make templates that check for the presence of a gender or transliteration, for example. Concerning this template in particular though, is there support for rolling it out more widely? A bot could easily replace most occurrences of {{l|en}} that have no additional parameters. —CodeCat01:15, 25 January 2013 (UTC)
I also support the idea of tailor-make linking templates, for all languages. If we use it in pages like a they will load faster. — Ungoliant(Falai)01:26, 25 January 2013 (UTC)
I don't think there would be a problem in keeping {{l}} available for its additional parameters. We could use {{l/en}} when we can, and fall back to {{l}} when we need to. Alternatively we could get rid of it entirely and use some other solution, like writing it out manually. —CodeCat01:57, 25 January 2013 (UTC)
If it helps... it has advantages both for performance (less complexity means faster templates, which is important for such a frequently used one) and for usage (since different languages have different needs regarding links, overridden headwords, transliterations and so on). —CodeCat17:29, 25 January 2013 (UTC)
Marking transliterations as foreign languages
Yesterday I changed {{t}}, {{term}} and other templates so that they added a HTML lang= attribute to the transliterations of words. I believed that this would be better because transliterations are not actually English, they are still in the foreign language even if they are not represented in the normal script. But this caused a few problems with gadgets so Ruakh asked me if I could ask here whether others think it's a good idea... —CodeCat15:21, 25 January 2013 (UTC)
Transliterations aren't really any language, but they are much less English than they are the language they are transliterating. So I support the change. --WikiTiki8916:22, 25 January 2013 (UTC)
They aren't strictly a what you'd call "normal" representation of a language, but they still represent that language and not the English language. I don't think anyone would doubt that Pinyin or Romaji are still Mandarin and Japanese? —CodeCat16:50, 25 January 2013 (UTC)
I would think that in those templates the default should be that they are not English. Based on much of our recent experience with such templates, I'd bet that it would not be worthwhile to complicate the templates to try to allow for them to be deemed English based on whether they had an English L2 section. I suppose we could allow a user to explicitly include a link to an English L2 section for tr=, but we should not do any testing for existence. DCDuringTALK17:07, 25 January 2013 (UTC)
Do they have to be specified as any language? I would think they only need a script and that the script is always Latin on this wiki. DCDuringTALK17:10, 25 January 2013 (UTC)
There is no real "not English" language, though. All that is possible, aside from explicitly specifying the language, is to specify "no language"... that is, <span lang="">. There would still need to be some kind of specification, because all content on Wiktionary is considered English unless overridden. This overriding is what our templates (script templates in particular) already do, but this was so far neglected for transliterations. —CodeCat17:15, 25 January 2013 (UTC)
It seems as though transliterations should be marked as lang='he' (for example), more specifically as lang='he-Latn' (if I recall the syntax correctly), but (1) what "problems with gadgets" does that cause, and, probably more importantly, (2) what do i18n (non-enwikt) folks say about this? Surely what language to mark a transliteration as has been discussed before, and there may even be a standard.—msh210℠ (talk) 17:19, 25 January 2013 (UTC)
What I could find was that "he-Latn" may be acceptable, at least. Whether it is common or standard, I don't know. —CodeCat17:22, 25 January 2013 (UTC)
Come to think of it, he-Latn is ambiguous at best. Specifically, the Hebrew word כָּשֵׁר is reasonably transliterated into English as kasher but into French as cacherre (I think. Even if that's not quite right, my point remains): specifying a transliteration as Latin-script is insufficient for screen-readers and whoever else cares. Is there a way to specify it's into English?—msh210℠ (talk) 17:39, 25 January 2013 (UTC)
But it's not into English. As far as I know many languages have standard transcription systems, which may be based in English (like Romaji is) or on some other convention (like that of many Slavic languages). On the other hand, if screen readers are the issue... technically they shouldn't need transliterations at all because they should be able to read the native script. —CodeCat18:20, 25 January 2013 (UTC)
Screen-reader users want to read, and edit, the same text that the rest of us do. Transliterations are used for several reasons, and conveying the spoken word is a secondary one. For example, whether you are sighted or not, you may be unfamiliar with the Cyrillic alphabet but learn from the transliteration that the Russian word его is spelled ego, even though it is pronounced like yevo (oops, some of our editors don’t understand the purpose of transliteration – insert your own better example). Anyway, I doubt that a screen reader will ever exist that can read out every language in en.Wiktionary. —MichaelZ. 2013-01-28 16:51 z
I've been gone a while and just really got back into things somewhat today, but I did note that romaji transliterations of JA entries look a bit funny -- the font is maybe 10% or so smaller than it used to be. I also saw on the hólǫ́ entry for Navajo that words entered into running text in the sample sentences, but using the {{l}} template, all wind up looking funny.
It looks ok to me, and what I changed only affects transliteration, everything else is the same. Maybe it's your computer? —CodeCat00:27, 26 January 2013 (UTC)
Odd. I'm running Firefox 18.0 on updated Win 7. Screenshot showing the differences in size between text using the {{l}} template and regular text:
It looks like there may be some special fonts configured for Navajo text, since Navajo uses {{nv-Latn}} as its script, and only the links are considered to be Navajo but not the rest of the text. I've wrapped the text in {{lang|nv}} now (which exists for this purpose specifically), has that changed anything? —CodeCat00:57, 26 January 2013 (UTC)
Hmm, nope, nothing's changed from what I can see. I've got my browser configured to use the DejaVu fonts for "other" languages -- perhaps that's what's happening? In Firefox, Tools > Options > Fonts & Colors > Advanced > Fonts for: Other Languages. I'm out of time for now, but I'll have a look later tonight or maybe over the weekend. -- Eiríkr Útlendi │ Tala við mig01:03, 26 January 2013 (UTC)
Firstly — I didn't actually say anything about Gadgets; my example (which Eirikr has independently mentioned) was that Firefox displays Japanese-tagged text differently, even if it's tagged as Japanese-with-Latin-script. But I wouldn't at all be surprised if the change did break a Gadget or two; it broke User:Ruakh/Tbot.js, which is fine (it's in development/testing anyway) but possibly suggestive. Secondly — the Navajo issue is unrelated; the issue with that is just that we specify certain fonts for Navajo, and on many systems, the fonts used for Navajo look (are) smaller than the fonts used for the surrounding text. (We used to magnify Navajo so it would actually look bigger, but we no longer do that.) —RuakhTALK04:06, 26 January 2013 (UTC)
Official language subtags live in the IANA language subtag registry. It has several variant subtags specifically for romanizations. (For more detail, search on that page for “romanization.”) This also confirms authoritatively that a transliterateion should be tagged as the original language.
ALA-LC Romanization, 1997 edition: -alalc97
Hepburn romanization: ja-Latn-hepburn
Hepburn romanization, Library of Congress method: ja-Latn-alalc97 preferred over deprecated ja-Latn-heploc
Choosing a language tag says that cmn-Latn-pinyin and zh-Latn-TW-pinyin, for example, are also perfectly legal.
But there are many more transliteration schemes than the official subtags registry allows for. There are at least three valid methods for expressing these:
There are two officially registered extensions, the singleton t and u subtags, and a private-use x subtag:
t – transformed content, which tags content transformed from a different source, and seems to allow for some freestyle tagging. E.g., uk-Latn-t-uk-Cyrl for Ukrainian-Latin transliterated from Ukrainian-Cyrillic. The m0 field separator can be followed by a standard and version, e.g., uk-Latn-t-uk-Cyrl-m0-ungegn-1997 for Ukrainian romanized according to the UN Group of Experts on Geographical Names standard, 1997 version.
x – which allows us to use our own custom tagging. With the menu of available options above, I hope we don’t have to resort to reinventing these wheels.
By the way, “Setting the attribute to the empty string indicates that the primary language is unknown,” so lang="" would override and negate the default lang="en" in en.wiktionary’s HTML. Also “If the resulting value is not a recognized language tag, then it must be treated as an unknown language having the given language tag, distinct from all other languages.” Undefined language is tagged lang="und".
For both the t and u extensions, the Unicode CLDR registers subtags representing “transforms” (transliteration methods). The latest registry (version 22.1, 2012-10-24) has the following codes:
alaloc – American Library Association – Library of Congress
bgn – US Board on Geographic Names
buckwalt – Buckwalter Arabic transliteration system
din – Deutsches Institut für Normung
gost – Euro-Asian Council for Standardization, Metrology and Certification
iso – International Organization for Standardization
mcst – Korean Ministry of Culture, Sports and Tourism
satts – Standard Arabic Technical Transliteration System (SATTS)
ungegn – United Nations Group of Experts on Geographical Names
I am a Telugu wiktionarian. I need some help for the senior etymologists. In Telugu wiktionary, we have about 80,000 word definitions. Many of them are derived from different languages. Can someone make the Etymology template work in Telugu wiktionary. It will be very helpful for us. Thanking you.Rajasekhar1961 (talk) 06:06, 26 January 2013 (UTC)
If it is too difficult, please make it work initially for the Indian languages and English. Later on may be we can expand to other languages.Rajasekhar1961 (talk) 10:25, 26 January 2013 (UTC)
It depends on how the language infrastructure works there. For example, here the language codes are also templates which return the name of the language ( {{te}} → Telugu). — Ungoliant(Falai)20:01, 26 January 2013 (UTC)
The Telugu wording in the Category should be "ఇంగ్లీషు నుండి పుట్టిన తెలుగు పదాలు". Can you now keep this in the etyl template, so that I can start working with "Telugu words derived from English".Rajasekhar1961 (talk) 05:08, 29 January 2013 (UTC)
Are you talking about te:మూస:etyl? If so, I put the category in there, but I don’t know if it will work. It’s too complex for me and I don’t understand how it works. —Stephen(Talk)06:17, 29 January 2013 (UTC)
It is giving: "Telugu నుండి పుట్టిన ఇంగ్లీషు". In Telugu language, the arrangement of words is different; In English, if we write "Telugu words derived from English", In Telugu we write "ఇంగ్లీషు నుండి పుట్టిన తెలుగు పదాలు"; exactly the opposite way. I think we can modify the sequence of words in the template.Rajasekhar1961 (talk) 08:38, 30 January 2013 (UTC)
Yes sir. Now it is exactly what it should be. "ఇంగ్లీషు నుండి పుట్టిన తెలుగు పదాలు". Thank you very much. Your untiring effort has given the result. I am now trying with Sanskrit words derived from Telugu. It should come out as "సంస్కృతము నుండి పుట్టిన తెలుగు పదాలు". See the page te:క్షేత్రము.Rajasekhar1961 (talk) 12:12, 31 January 2013 (UTC)
It is now working fine. I have interconnected this Category to the Telugu terms derived from Sanskrit. But when I have added the term template, it is showing some error. The error is probably in the te:మూస:sa. Can you please correct it.Rajasekhar1961 (talk) 07:44, 1 February 2013 (UTC)
I hope that it works for all languages. There may be some problems with the language templates (such as te:మూస:kn), but those can be fixed when they are discovered. If te:మూస:etyl does not work for other languages, then I do not know how to fix it. —Stephen(Talk)23:29, 1 February 2013 (UTC)
Thank you. I have started using Telugu terms derived from Sanskrit. When I use other languages, we will be in touch. Thank you very much sir.Rajasekhar1961 (talk) 07:18, 2 February 2013 (UTC)
Okay, so WebFonts kick in for Burmese, which is great because it's an alphabet most people don't have local support for. But the WebFont for Burmese isn't applying only for things written in the Burmese alphabet. It's also applying to transliterations: {{term|ဗမာ|tr=băma|lang=my}} is appearing as ဗမာ(ba.ma) with the transliteration in this ugly font that has no proper italics instead of in a nice font intended for the Latin alphabet. Worse yet, it's applying to IPA transcriptions of Burmese: {{IPA||lang=my}} appears as IPA(key): with the Burmese WebFont overriding the IPA formatting. Is there any way to fix that? —Angr14:50, 26 January 2013 (UTC)
It seems that the extension is treating all Burmese-language text as though it needs that font, even though it shouldn't apply it to IPA transcriptions (which use lang="my-fonipa") or transliterations (which use lang="my-Latn"). I'm not sure if it can be fixed in an acceptable way, except by tagging those things as having no language, rather than being in Burmese. —CodeCat16:14, 26 January 2013 (UTC)
It's not WebFonts that's doing that, it's your own CSS (User:Angr/vector.css). The span selector applies to all Myanmar-tagged text, even if it's tagged as Myanmar-in-Latin-script. (You seem to have attempted to comment out that line by using <!-- … -->, but that's not a CSS notation. (It's an SGML/XML/HTML/XHTML notation, and MediaWiki has borrowed it as a wikitext notation, but user CSS doesn't go through the wikitext parser.) To comment something out in CSS, you can write /* … */.) Even so, this problem of yours may be an argument against the recent change to {{term}} (etc.) to have it language-tag transliterations: language-specific CSS is a good thing — maybe even a necessary thing, actually, due to Han unification — and if this makes that harder, then that's bad. (But I don't know whether this makes that harder. It breaks the approach you were using, but there may be another/better approach.) —RuakhTALK19:50, 26 January 2013 (UTC)
Changing <!-- ... --> to /* ... */ seems to have fixed it. Thanks for your help! As for the broader issue, it's over my head anyway and I'll leave it to other people to figure out. —Angr20:08, 26 January 2013 (UTC)
I just noticed that my own customized edittools are no longer available in the dropdown when editing a page. This happened some time in the last hour or two. I didn't change anything on my side. Anyone know what's going on? -- Eiríkr Útlendi │ Tala við mig19:15, 28 January 2013 (UTC)
Q about lang codes to use in etym sections for ancient forms of Chinese
I've run into a bit of a puzzler. When working on etym sections that reference ancient forms of Chinese, I'm stuck with how best to link through to terms. For the {{etyl}} template, sometimes it isn't sufficiently clear when a term was borrowed from Chinese, in which case we should probably use {{etyl|zhx}}. If it is clear when the term was borrowed, we should probably use {{etyl|och}} or {{etyl|ltc}} as appropriate.
However, when linking to the Chinese term itself, what lang code should we use? Using {{term|lang=cmn|...}} strikes me as inappropriate, as doing so implies that the ancient word came out of modern Mandarin, which isn't correct. So which of the following should we do instead?
When we don't know when the term was borrowed:
Use {{term|lang=zhx|...}} for terms where the time of borrowing is unknown. (Note: not currently possible, as zhx is the code for the entire Sinitic language family. We no longer have any lang code for Chinese in general that could be used for indeterminate varieties of Chinese. We could cludge this by using {{term|lang=etyl:zhx|...}}, but that's exceedingly hacky and very likely to break things.)
Use {{term|sc=Hani|...}} for terms where the time of borrowing is unknown. This omits any lang code at all. I'm not sure what technical problems this might entail.
When we do know when the term was borrowed:
Use {{term|lang=och|...}} or {{term|lang=ltc|...}} as appropriate. We don't have very many Chinese character pages that actually include Old or Middle Chinese entries, but this at least points to the correct page, and editors savvy about Old or Middle Chinese can fill in the missing entries over time.
In any given entry, there are two possibilities: either (1) not only do you not know exactly what language the term was borrowed from, you also don't know exactly what form it took in the source language, or (2) thanks to the magic of Sinitic logograms, you do know the exact form (or rather, the exact written form), despite not knowing the exact language. In case #1, this is a non-issue, because you can't just write "from Sinitic foo" if foo is just the Mandarin form and not necessarily the source form (instead, you need to write something like "from Sinitic; compare Mandarin foo", in which case obviously foo would be tagged and linked as Mandarin); and in case #2, I think this is still a non-issue, because if the form exists in Mandarin, there's no harm in tagging and linking it as Mandarin. You write that "Using {{term|lang=cmn|...}} implies that the ancient word came out of modern Mandarin", but I don't think it does imply that. But if it really bothers you, you can use the same approach for case #2 as is necessary anyway for sense #1. —RuakhTALK06:49, 30 January 2013 (UTC)
Well, there are circumstances where I would prefer to have use {{term}} with a missing/blank language code; but in the circumstances that I think you're asking about, you understand correctly that my preference is to use the correct language code (usually cmn). —RuakhTALK03:09, 31 January 2013 (UTC)
Done ~ Röbin Liönheart (talk) 07:46, 18 January 2013 (UTC)
