Wiktionary:Grease pit/2011/April

This is an archive page that has been kept for historical purposes. The conversations on this page are no longer live.

April 2011

Move Romanian entries

I've started moving Romanian entries with cedillas to new names with commas according to community decision (Wiktionary:Votes/pl-2011-02/Romanian orthographic norms). I applied for the bot flag (Wiktionary:Votes/bt-2011-04/User:Flubot for bot status) and the tools I'm going to use are here. If there are any comments by anyone I'd be happy to listen to them. Regards, --flyax 14:57, 2 April 2011 (UTC)[reply]

Do you think you can add a note like this one to your redirect pages, so people know (a) they should not delete the redirect, (b) they should not use the redirect's target for Turkish (or whatever), and (c) they can replace the redirect page with a full Turkish (or whatever) entry?​—msh210 (talk) 04:42, 3 April 2011 (UTC)[reply]
I suppose that I could create a file and upload it with pagefromfile.py (massive creation of new articles). I have seen your similar edits, but strangely your text is not always visible. For example see [1].
Thank you also for your edits on the vote pages. You suggested that I announce my request on BP. Isn't this discussion enough? --flyax 07:17, 3 April 2011 (UTC)[reply]
It won't be visible in the page, but it will appear in the wikicode. It's the best one can hope for.
I think it's usual to announce votes in the BP.​—msh210 (talk) 07:26, 3 April 2011 (UTC)[reply]
Using pagefromfile to add text might not be a good idea after all. I can modify my script so that it appends this additional text right after moving. However I am not sure whether the vote that is going to start in a few days covers this action too or if I should ask for special permission. --flyax 15:07, 5 April 2011 (UTC)[reply]
Add it in to the vote (or to the script linked to from the vote) and I think you're fine. (If you add it to the vote or to the script linked to from the vote within a couple of days or so before the start of the vote, then IMO delay the vote by a couple of days or so so as to give people a chance to react.)​—msh210 (talk) 16:52, 5 April 2011 (UTC)[reply]
OK, the new version of the script works fine. See băşină and băşică. --flyax 17:48, 5 April 2011 (UTC)[reply]

Removing empty alphagram templates

I was considered setting MglovesfunBot to use the regex listed in User:Mglovesfun/vector.js to remove {{alphagram}} when it's followed by a wikilink on the same line, so that:

==Anagrams===
* {{alphagram|acdo}} [[coda#Italian|coda]]

becomes

===Anagrams===
* [[coda#Italian|coda]]

(example taken from cado)

Any objections? Bare in mind that {{alphagram}} is blank unless it contains a wikilink (using {{isValidPageName}}). Mglovesfun (talk) 12:16, 3 April 2011 (UTC)[reply]

I've found a way to do it for multi-line alphagrams too. Alphagram by its very nature doesn't do anything wrong, as it's empty? It was an experiment by Conrad.Irwin (talkcontribs) which was abandoned as editors kept editing it wrongly, so it was blanked to discourage that. I've consulted Conrad on his talk page and he's not against removing it. Mglovesfun (talk) 13:06, 4 April 2011 (UTC)[reply]

I've created this template as a complement to {{proto}} to link to unattested terms in non-proto languages such as Vulgar Latin or West Germanic. Would have prefer a title 'unattested' or 'reconstructed', but they were both taken. Mglovesfun (talk) 10:21, 5 April 2011 (UTC)[reply]

Wouldn't it be easier to add a parameter to {{termx}}? —CodeCat 10:45, 5 April 2011 (UTC)[reply]
Honest answer is I don't know. Feel free to do it and I'll try it. Mglovesfun (talk) 10:50, 5 April 2011 (UTC)[reply]

Search of principal namespace content disabled?

I was formerly able to search the content of entries. Now I seem only to be able to search the headwords. Is this permanent? Can it be changed? How? Is the current state of crippled search desirable? DCDuring TALK 20:17, 5 April 2011 (UTC)[reply]

I'm betting that Lucene's search indices need to be rebuilt. We should contact a dev. (But, I'm not sure how we're supposed to do that. Bugzilla?) —RuakhTALK 22:19, 5 April 2011 (UTC)[reply]
It seems to be functioning now. DCDuring TALK 03:52, 7 April 2011 (UTC)[reply]

Interface changes

Why do I get the silly little arrow icons next to definitions? Are they installed by default for all users? Why? Can they be rendered selectable but not available by default? Does anyone have any actual evidence that they are useful for unregistered users or non-contributors? Was this ever discussed in GP or BP? DCDuring TALK 04:09, 7 April 2011 (UTC)[reply]

See WT:BP#Tabbed Languages, Definition side boxes, and Sense IDs. There's a button to disable it there, as well as at WT:EDIT. Alternatively, you could use the gadget to disable it. --Yair rand 04:11, 7 April 2011 (UTC)[reply]
I'd still like to know what gives you the justification or right to impose this on unregistered users or even inattentive registered ones. What's the evidence that this is a good thing for them? This isn't a playground, nor is it just for us. DCDuring TALK 05:12, 7 April 2011 (UTC)[reply]
FYI, in Opera, the arrows/triangles sometimes did not line up with the numbers (sometimes if there a word had multiple senses, particularly if one took up multiple lines, a triangle was between not beside the numbers), and sometimes there formed mirages of the numbers, doubles above the numbers. It looked good in Firefox. - -sche (discuss) 18:26, 7 April 2011 (UTC)[reply]
Re Opera: Prince Kassad pointed that out in the BP. I fixed it about an hour ago. --Yair rand 18:29, 7 April 2011 (UTC)[reply]
Great!   - -sche (discuss) 18:55, 7 April 2011 (UTC)[reply]

Võro noun template

I edited a Võro noun entry and I noticed that the link to the template {{vro-noun}} doesn't exist. May I make that template? If so, how do I do that? Is there a way to make it plural friendly? - Lo Ximiendo 00:25, 8 April 2011 (UTC)[reply]

I don't know much about that language, but you could try copying {{et-noun}} and see what needs changing. —CodeCat 01:55, 8 April 2011 (UTC)[reply]

When I first created the template and tested it on the Võro word liin (town), I went through a trial and error approach, until I thought about follwing an example from an Indonesian template. Thanks, anyway. - Lo Ximiendo 04:14, 10 April 2011 (UTC)[reply]

Homophones

There's been a request at WT:TODO to remove all the homophones headers and put them under ===Pronunciation===. Anyone disagree? I'd quite like to remove homophones from User:AutoFormat/Headers. Mglovesfun (talk) 10:55, 9 April 2011 (UTC)[reply]

OK, but what about the categories, could we add something like fr:Catégorie:Homographes non homophones en français? JackPotte 15:34, 9 April 2011 (UTC)[reply]
Yes Category:English heteronyms. That's a separate issue. Mglovesfun (talk) 16:28, 9 April 2011 (UTC)[reply]
Also, is the Hyphenation header used? Mglovesfun (talk) 12:36, 24 April 2011 (UTC)[reply]

Browser freezes on Slovenia

My firefox-4 on Mac, freezes on Slovenia and Chrome also fails to load the page. Does anybody know what's wrong?--Leo Laursen – (talk · contribs) 18:42, 11 April 2011 (UTC)[reply]

        • I had that problem several years ago (about seven years ago, I think) using an iMac to try to load the page fire. Apparently it was one or more of the UTF-8 codes used by one of the non-Roman languages that my Mac was interpreting as a command (like EOP) instead of a letter. It’s hard to imagine that this could still be happening with your modern software, but that’s what it sounds like to me. I fixed it by switching to a Windows machine. —Stephen (Talk) 21:47, 11 April 2011 (UTC)[reply]

WikitanvirBot for inter-wiki linking

Hi, I've opened a vote page for approval of my bot, WikitanvirBot. This bot runs in all Wikipedia, and already have done a satisfactory job in inter-wiki purpose. I would love to provide this services on English Wiktionary too. I hope you will consider. Thanks in advance! Wikitanvir 16:00, 13 April 2011 (UTC)[reply]

If you agree here, I would like to run some test edits, so you can verify. Wikitanvir 16:05, 13 April 2011 (UTC)[reply]
I am done with test. I think 12 test edits are enough to judge this bot. Also don't want to clutter the recent changes now, so I stopped the bot. Looking to hearing from you. Wikitanvir 16:57, 13 April 2011 (UTC)[reply]
Can we see the source code, and some test edits where it adds links, please?​—msh210 (talk) 17:11, 13 April 2011 (UTC)[reply]
Of course, we can. It uses standard script interwiki.py and uses Pywikipediabot framework. Unfortunately, in that time bot only founds inter-wiki to remove. I can run another test phase, but I am afraid, it will be more than 20 test edits this time. If you don't have problem with that, please let me know. I will run. As it is a global bot, it is already running in global bot Wiktionaries. Wikitanvir 17:33, 13 April 2011 (UTC)[reply]
You can see some link adding on its zhwikt contributions. Wikitanvir 17:44, 13 April 2011 (UTC)[reply]
Yes, the only mainspace wikt edits seem to be at zh, et, and bn, of which the first two look fine, but the last (which are older) does not inspire much confidence.​—msh210 (talk) 18:08, 13 April 2011 (UTC)[reply]
Can you please tell me why? I think the bot did not make any wrong. Wikitanvir 02:05, 14 April 2011 (UTC)[reply]
The only three mainspace interwiki edits I see there are [2], [3], and [4], in all of which the bot added interwikis that don't comport with enwikt's interwiki linking practices.​—msh210 (talk) 06:46, 14 April 2011 (UTC)[reply]
Aha, I think I got your point now. Those inter-wiki links were in months ago. In that time my bot was not running in regular basis. That was an manual operation which forced me to select a group of inter-wikis (that because of duplicate inter-wikis). I selected, and the bot removed and added some inapplicable inter-wiki in some pages. That was it. But now, I run this bot completely automatically. It is running with -auto enabled, so it will skip any pages if there is duplicate inter-wikis. No need to worry about now I think. You can see my present activities. I hope they are okay (many of them are on et and zh wikit). You said zh and et wiki looks fine, and the cause is they have the recent ones. :) Wikitanvir 17:10, 14 April 2011 (UTC)[reply]

Slovak entries/templates

I've been tackling the uncategorized Slovak entries in the last three days. There many like kyselina (permanent link) which have long, vertical 'list style' inflection lines. {{sk-noun}} is very basic; calling on {{infl}} this way makes it necessarily so, it seems to me to be much better to have a more traditional noun template. But what should go in the template? Headword and gender definitely, but a plural? A genitive? Not sure. For much inflected languages we normally pass these into a declension table. We have {{sk-decl-noun}} which displays 12 forms. --Mglovesfun (talk) 11:39, 14 April 2011 (UTC)[reply]

Oh and there's {{sk-dub}} which ought to be (but, AFAICT isn't) redundant to declension templates. Simply, I don't think we have the declension tables yet. --Mglovesfun (talk) 11:41, 14 April 2011 (UTC)[reply]
I have something of a solution, {{sk-noun/new}} allows more than {{sk-noun}}, and links to a declension appendix when one exists using decl=foo, so for špenát:
==Slovak==

===Noun===
{{sk-noun|m}}

# [[spinach]]

====Declension====
pattern {{sk-dub}}

Becomes:

==Slovak==

===Noun===
{{sk-noun|m|decl=dub}}

# [[spinach]]

Any everything else goes in the declension template. See also Category:Slovak templates, which seem to be all {{sk-dub}} style ones. Mglovesfun (talk) 14:05, 14 April 2011 (UTC)[reply]

Recent changes bug

I have absolutely no idea why, but when I click on the recent changes button on the left, it then auto-redirects to Appendix:Unsupported titles. Mglovesfun (talk) 14:14, 14 April 2011 (UTC)[reply]

The recent changes button on the left is working properly for me, pointing to Special:RecentChanges like always. --Daniel. 18:51, 14 April 2011 (UTC)[reply]
It works properly for me also, in Firefox and Opera. Does it still not work for you? - -sche (discuss) 01:36, 16 April 2011 (UTC)[reply]
It was only for about two minutes, it got fixed, false alarm. Mglovesfun (talk) 11:39, 16 April 2011 (UTC)[reply]

Sorting key for Greek words

Greek words are sorted badly, specially those beginning with an accented letter. I think it would be good to remove sorting elements from templates and add DEFAUTSORT to entries. For example, remove {{{sort|{{PAGENAME}}}}} from the line {{#if:{{NAMESPACE}}||[[Category:Greek nouns|{{{sort|{{PAGENAME}}}}}]]}} in Template:el-noun. What do you think about it? --flyax 12:35, 15 April 2011 (UTC)[reply]

Just to explain a bit, what the wikisyntax above means is if there's no namespace (WT:NAMESPACE) categorize in Greek nouns, with a default sort key of the page name. There's another way of doing it, that I've always assumed to be just a longer-winded version of the same thing: {{#if:{{{sort|}}}|[[Category:Greek nouns|{{{sort}}}]]|[[Category:Greek nouns]]}}}. In this case, it only uses sort when sort is specified inside the template. Using this system default sort should work. Mglovesfun (talk) 12:58, 15 April 2011 (UTC)[reply]
Keep the namespace check of course. Mglovesfun (talk) 12:58, 15 April 2011 (UTC)[reply]
Of course it's better having two options for the sort key (sort= in the template or DEFAULTSORT). The latter would be preferable for entries belonging to multiple categories. --flyax 13:15, 15 April 2011 (UTC)[reply]

Sorting script

I am going to run this python script to add the "sort=" parameter to Greek nouns' inflexion line. Is it OK ? --flyax 23:31, 22 April 2011 (UTC)[reply]

IMO yes, just fix things if they go wrong. Mglovesfun (talk) 12:07, 23 April 2011 (UTC)[reply]

It would be good to be consistent over capitalizing the first letter or not; I'd consider adding {{lcfirst:}} or {{ucfirst:}} (that is, lowercase first or uppercase first) to be consistent. But which one, if either? Mglovesfun (talk) 13:26, 16 April 2011 (UTC)[reply]

Typically lower, but, of course, sometimes the first word of the gloss in is a capitalized word. Therefore, I don't suggest doing this. (Anyway, I'm not sure it would work. I seem to recall that ucfirst on {{{1}}} capitalizes the {{{1}}} (which, of course, does nothing) before the latter is evaluated, and likewise for lcfirst, m.m.)​—msh210 (talk) 20:00, 21 April 2011 (UTC)[reply]
lcfirst certainly would not work. ucfirst might cause WT:EDIT to break (and I've already broken it once this year). Mglovesfun (talk) 12:02, 23 April 2011 (UTC)[reply]
Re: "I seem to recall that ucfirst on {{{1}}} capitalizes the {{{1}}}": What you're probably thinking of is {{ucfirst:[[foo]]}}, which capitalizes the first square bracket (so has no effect). {{ucfirst:{{{foo}}}}} works fine: the parameter is substituted long before ucfirst is applied. —RuakhTALK 21:34, 27 April 2011 (UTC)[reply]

Overzealous "[quotations ▼]"

Sign-language entries include a "Production" section that serves a similar purpose to the "Pronunciation" section in spoken-language entries. Phonetically, each sign consists of a sequence of postures (a segment of the sign where the hands are in a particular shape, location, and orientation). Usually, a transition from one posture to the next contains no phonetic details (i.e. the hand(s) move directly from one posture to the next), but sometimes a transition has phonetic elements (e.g. the hands move at a deliberately fast or slow speed or along a particular path). To describe those phonetic details, the production sections of sign language entries include a narrative formatted as a numbered list of postures. Pronunciation sections of spoken-langauge entries show phonetic realizations (pronunciations) in an unnumbered list, so production sections of sign-language entries show phonetic realizations (productions) in an unnumbered list. For example, here is a pronunciation section from the spoken-language entry (deprecated template usage) snow:

* {{a|UK}} {{IPA|/snəʊ/}}, {{SAMPA|/sn@U/}}
* {{a|US}} {{enPR|snō}}, {{IPA|/snoʊ/}}, {{SAMPA|/sn@U/}}
* {{audio|en-us-snow.ogg|Audio (US)}}
* {{audio|En-uk-snow.ogg|Audio (UK)}}
* {{rhymes|əʊ}}

Similarly, here is a production section from the sign-language entry (deprecated template usage) 5@SideForeheadhigh-PalmDown-5@SideForeheadhigh-PalmDown SlowWiggle-SlowWiggle 5@SideTrunkhigh-PalmDown-5@SideTrunkhigh-PalmDown:

===Production===
* {{ase-prod intro | hands=two}}
*# {{ase-prod posture | 5 | SideForeheadhigh | PalmDown | 5 | SideForeheadhigh | PalmDown }}
*#* Move both hands down slowly while wiggling the fingers. 
*# {{ase-prod posture | 5 | SideTrunkhigh | PalmDown | 5 | SideTrunkhigh | PalmDown }}
* Be sure to move the hands down slowly to differentiate this sign from {{term|Claw5@SideForeheadhigh-PalmDown-Claw5@SideForeheadhigh-PalmDown Claw5@SideChinhigh-PalmDown-Claw5@SideChinhigh-PalmDown Claw5@SideChesthigh-PalmDown-Claw5@SideChesthigh-PalmDown||rain}}.

That used to display fairly well (ignoring verbosity). Now, though, in the entry, it displays a collapsed "[quotations ▼]" box around the movement phone.

Should I stop using *#* to describe the movement phones in production narratives or is there some other way to disable the "[quotations ▼]" feature in production sections? —Rod (A. Smith) 19:22, 22 April 2011 (UTC) [reply]

I think I answered my own question in the entry for (deprecated template usage) 4@NearTipFinger-PalmBackFingerDown-4@SideTrunkhigh-PalmBackFingerUp RoundVert 4@SideTrunkhigh-PalmBackFingerUp-4@SideTrunkhigh-PalmBackFingerUp. The narrative reads perfectly well with the move in its own numbered list item. No need to suppress the quotations feature. —Rod (A. Smith) 01:57, 23 April 2011 (UTC)[reply]

all pages created by one user

Is there a way I can get a list of all pages created by one user? --Porelmundo 11:51, 23 April 2011 (UTC)[reply]

I've wanted to ask this before, because of certain problematic users we've had in the past. Mglovesfun (talk) 11:59, 23 April 2011 (UTC)[reply]
Go to Special:Newpages and then type the user's name. For example, see the pages created by me here: http://en.wiktionary.org/w/index.php?title=Special%3ANewPages&namespace=0&username=Flyax. --flyax 14:07, 23 April 2011 (UTC)[reply]
OK, thanks, but this only shows recently-created pages. It doesn't show κιλό, for example, which was also created by Flyax, but in the year 2007. Is there anything that goes further back in time? --Porelmundo 15:51, 23 April 2011 (UTC)[reply]
New pages are marked by a N in "My contributions" page, now. I see my contributions of 2007 and there is no N before the new pages of that year. So, maybe it's not at all easy to get older created pages, unless you examine the synopses. --flyax 18:05, 23 April 2011 (UTC)[reply]
There is a relevant bug reported here: https://bugzilla.wikimedia.org/show_bug.cgi?id=28701 --flyax 18:46, 25 April 2011 (UTC)[reply]
I think I've got a solution to that problem. For those interested, the scripts are in User:Flyax/New pages by a user. --flyax 15:46, 25 April 2011 (UTC)[reply]
Would be useful for historically 'poor' (or if you like neutral terminology, 'unorthodox') users. Drago, Verbo/Fastifex abd KYPark come to mind. --Mglovesfun (talk) 16:32, 5 May 2011 (UTC)[reply]

Form of templates

Approximately 6 months ago AugPi changed (history) the {{plural of}} template to no longer have an automatic capital letter or automatically add a final full stop (final period). The fact that nobody has disputed this in six months tells me it's quite widely accepted. {{conjugation of}} doesn't use use these either. I'd like more or less all of our form of template to look like this; of course in certain cases an initial capital letter is vital, say {{form of|Late Latin spelling of|...|lang=la}}. Thoughts? Mglovesfun (talk) 12:08, 24 April 2011 (UTC)[reply]

I agree (although {{conjugation of}} DOES seem to have a trailing stop). Entries would then look better if the stop after the entry number was omitted. Looking at my paper dictionaries (COED, Collins, Webster's) all seem to have entries like 1 definition the first 2 second definition 3 etc - although the COED does put in trailing full stops between entries and at the end. With just Caps and Stops in intermediate sentence breaks. —Saltmarshtalk-συζήτηση 04:59, 26 April 2011 (UTC)[reply]
What I'm proposing is to not use {{ucfirst:}} or {{{nodot|}}} for form of or conjugation of (as noted, conjugation of doesn't use ucfirst anyway. --Mglovesfun (talk) 18:39, 29 April 2011 (UTC)[reply]
Have just done it for {{conjugation of}}, will wait for a reaction before doing the same for {{form of}}. Mglovesfun (talk) 12:53, 30 April 2011 (UTC)[reply]
This is certainly a good idea for the dot. Even if we want to end most sentences with a period, why not just put a period after the {{template}}? Capitalization I'm not sure how to handle best (why not {{Conjugation of}}?) but anyways I'm certainly not set on the way it's done now. DAVilla 19:44, 3 May 2011 (UTC)[reply]
This doesn't seem like a technical discussion so much as a significant UI change. Why wasn't it mentioned at the Beer parlour? —RuakhTALK 13:48, 5 May 2011 (UTC)[reply]
Right. Also, even if the default formatting is to change, which I certainly don't mind, the current entries should not. Thus, if {{eye dialect of}} is going to have {{#if:{{{nocap|}}}|[[eye dialect]]|[[eye dialect|Eye dialect]]}} removed from it (as Mg just did), then both (a) it should have {{#if:{{{cap|}}}|[[eye dialect|Eye dialect]]|[[eye dialect]]}} added to it and (b) all the entries that use it without nocap should have cap=1 added to them. And the same, m.m., for dots.​—msh210 (talk) 15:58, 5 May 2011 (UTC)[reply]
To put it better: If this is a GP-suitable discussion, then it's only about the default action of the template, and not about the way entries look. In that case, I have no objection to changes, which is why I didn't voice any until now (when Mg started making changes to the templates that actually effected changes in the entries). If OTOH this discussion is about changes to the templates that actually change the way entries look then (a) I didn't understand that, which is why I didn't protest hitherto and (b) it belongs in the BP.​—msh210 (talk) 16:02, 5 May 2011 (UTC)[reply]
Perhaps reversing the nocap function to cap as msh210 puts it above is a good idea. I like it. --Mglovesfun (talk) 16:30, 5 May 2011 (UTC)[reply]

Template:deftempboiler

You might be a bit surprised by this, but I think this is a good idea. Our form of templates seem to use four different syntaxes. They are:

  1. Writing the text out in full, not calling on any templates, apart from {{Xyzy}}
  2. Calling on {{form of}}
  3. Calling on {{deftempboiler}}
  4. Rarely, calling on {{inflection of}}, see {{vocative dual of}} (totally unused and no incoming links)

I like the idea of {{deftempboiler}} as it allows us to standardize all of these templates. Problem is, I just can't understand the code. FWIW, I would like us to use this template more, and pass the bolding to the script template. The reason is that some script templates deliberately don't support bolding, as in some cases, bolding is undesirable. Mglovesfun (talk) 12:10, 9 May 2011 (UTC)[reply]

Context templates that add two categories

Does anyone know how I can make a context template that adds a page to two categores instead of one? For example, if a term were used only in the northern and western region, would it be possible to make this add it to a category for the northern and to one for the western dialect, but display it as 'Northwest'? —CodeCat 10:27, 27 April 2011 (UTC)[reply]

Two ways of doing it (maybe three); either by adding regcat2 to {{context}}, or in the sort of hackish way I've done it at {{northwest}} (diff). Mglovesfun (talk) 11:14, 27 April 2011 (UTC)[reply]

Xyzy, again

Did our discussion on {{Xyzy}} get anywhere? It has failed RFDO and quite some time ago. --Mglovesfun (talk) 16:30, 27 April 2011 (UTC)[reply]

If it has failed RFDO, it should be deleted. -- Prince Kassad 16:34, 27 April 2011 (UTC)[reply]
Well yes, my question is how do we replace it so that it isn't used? --Mglovesfun (talk) 16:55, 27 April 2011 (UTC)[reply]
We return to previous practice, i. e. explicitely requiring the script to be defined every time. That's how it should have been from the beginning, anyway. -- Prince Kassad 17:08, 27 April 2011 (UTC)[reply]
Like so?​—msh210 (talk) 17:29, 27 April 2011 (UTC)[reply]
Hmm. Shouldn't it default to something sensible (perhaps not Latin like before, but {{None}}? -- Prince Kassad 17:35, 27 April 2011 (UTC) disregard me, cleared up on IRC[reply]
That diff actually doesn't work if someone uses sc=|, which, while fine AFAICT for the template in question ({{wikipedia}}), is not good in general. (After all, a definition-line template might call, e.g., {{term|{{{1}}}|sc={{{sc|}}}}}, which evaluates to {{term|foo|sc=}} when no script is specified.) A way around this is to always use {{#if:{{{sc|}}}|. An AFAICT better way around it is to use {{{sc|None}}}: better because it requires less coding on the part of future template authors.​—msh210 (talk) 17:49, 27 April 2011 (UTC)[reply]

see also User talk:Prince Kassad#Template:None -- Prince Kassad 21:07, 27 April 2011 (UTC)[reply]

Sorry about that; wasn't trying to duplicate this discussion. Mglovesfun (talk) 10:57, 28 April 2011 (UTC)[reply]

The recent change to {{term}} to deprecate {{Xyzy}} has resulted in mentioned terms' not being italicized (or, at least, not unless sc= is specified). This is not in accord with our practice until now, which has italicized mentioned terms by default, and runs counter the result of a vote. Note that most Latin-script uses of this template do not use sc=. This is not tenable.​—msh210 (talk) 18:56, 28 April 2011 (UTC)[reply]

I think we should reinstate {{Xyzy}} until we actually know how to replace it. —CodeCat 19:17, 28 April 2011 (UTC)[reply]
I agree 100%. —RuakhTALK 19:29, 28 April 2011 (UTC)[reply]
Done, for {{term}}. (Other templates have also been deXyzyfied.)​—msh210 (-
CodeCat's statement might be generalized to "No template that is used in common and desirable ways should be be removed without evidence that what it does is actually understood as well as how to replace it." I don't know what voting system adjustment would help, but the principle would at least structure discussion and should influence those who would wreak change upon long-standing templates that have not been objects of widespread and well-aired complaint. DCDuring TALK 19:48, 28 April 2011 (UTC) talk) 19:40, 28 April 2011 (UTC)[reply]
Also expressible as "Be CAUTIOUS in breaking the entire wiki for no reason." —RuakhTALK 23:42, 28 April 2011 (UTC)[reply]
Well we could use {{Latn}} but like I said, this would end up italicizing foreign-script terms which don't have the script specified. I'm not sure that we want that. -- Prince Kassad 00:38, 29 April 2011 (UTC)[reply]
FWIW I still like the idea of {{en/sc}} containing Latn and something like {{#ifexist:Template:{{{lang}}}/sc|{{{lang}}}/sc|Latn. I think using Latn as a default is a good idea as an intermediate solution but not more than that. --Mglovesfun (talk) 10:36, 29 April 2011 (UTC)[reply]
I don't think adding ifexist to replace Xyzy is a very good idea... —CodeCat 12:36, 29 April 2011 (UTC)[reply]
it wouldn't work anyway. ifexist can only be called 500 times and last time I checked, water has triple that amount of translations. -- Prince Kassad 13:08, 30 April 2011 (UTC)[reply]
But we can ensure every language with a code template has a /sc template. No ifexist necessary.​—msh210 (talk) 04:13, 1 May 2011 (UTC)[reply]

I have been omitting sc=Armn in thousands of instances of {{term}} and {{l}} because of Xyzy. Now one of you, Xyzy-killers, has to go back and fix them. --Vahag 13:19, 30 April 2011 (UTC)[reply]

Shouldn't be too hard by bot, believe it or not. I tried it using MglovesfunBot and infl, the worst that happened was sc=Cyrl appeared twice, which AFAICT, the second sc=Cyrl simply does nothing. Mglovesfun (talk) 13:28, 30 April 2011 (UTC)[reply]

So, is {{t}} OK to remove Xyzy from now? -- Prince Kassad 13:46, 30 April 2011 (UTC)[reply]

No. Good Heavens. Please read the discussion you're commenting in. —RuakhTALK 17:38, 30 April 2011 (UTC)[reply]
This is exactly why the template shouldn't have existed in the first place. — [ R·I·C ] Laurent17:48, 30 April 2011 (UTC)[reply]
Yeah it's more or less a self-defeating template. You should have every script for every language in it, but you can't because it would render Wiktionary totally unusuable. So, it ended up including a handful of languages, excluding a few thousands others. Mglovesfun (talk) 18:18, 30 April 2011 (UTC)[reply]
I really like it when people pretty much say what's in my head but without seventeen uses of the word fuck or some form thereof ♥ — [ R·I·C ] Laurent21:36, 30 April 2011 (UTC)[reply]

First and foremost, I took a short break because I felt I immersed myself too much into this project. I let it run for a while, but as I see, this project will not run without me (if you noticed, I did a few IP edits for urgent stuff). Therefore, I'm writing here to help this progress (even though I should be doing something else).

In any case, one proposal that was made was using a new set of templates that map languages to scripts. An earlier proposal (Wiktionary:Grease_pit_archive/2010/December#Replacing_.7B.7BXyzy.7D.7D.2C_.7B.7Blangscript.7D.7D_and_others) used {{sc:en}}, I don't like this because it creates confusion with the 639-1 code {{sc}}, so it should rather be {{en/sc}} or {{en/script}}. It should be reasonably easy to create a full set of templates by bot and get it to work this way (even I could do it if needed). Do note, however, that this will not work with templates that require only the script but not the language (there are a few like this, mainly {{unicode scripts}}), those will continue to need to have their script specified manually (or we need some other solution). -- Prince Kassad 09:44, 4 May 2011 (UTC)[reply]

Turns out that {{sc:en}} won't even transclude properly, since sc: is an interwiki prefix... --Yair rand 16:14, 16 May 2011 (UTC)[reply]

Since there doesn't seem to be any kind of consensus on how to proceed, I have created a vote. Please take a look and comment if you can! —CodeCat 11:43, 17 May 2011 (UTC)[reply]

Script templates

Just so you know, I've undone by modification to {{Hans}}, {{Hant}} and {{Hani}} as apparently bolding CJKV script makes it harder to read. --Mglovesfun (talk) 12:10, 28 April 2011 (UTC)[reply]

Yes. It is a very bad idea to bold Han ideographs. -- Prince Kassad 12:41, 28 April 2011 (UTC)[reply]
AFAICT the only script templates that should support italics are Latn and {{Latinx}}. For bolding, I don't know. Some seem to support it well and others less well. {{Cyrl}}, {{Grek}}, {{Armn}} and {{Arab}} (including regional Arabic templates) all seem to support it well. --Mglovesfun (talk) 14:54, 28 April 2011 (UTC)[reply]
I think all scripts should "support" "bolding", for some value of "support" and "bolding": in scripts where an increased font-weight is hard to read, we should increase the font size instead. The problem is that we have many ways to introduce bolding using CSS classes, which makes it hard to create language- or script-specific overrides for all of them. I think that if we want a given kind of text to be bold by default, then we should use <b> with a CSS class that allows individual users to disable that, rather than <span> with a CSS class that MediaWiki:Common.css emboldens. And, similarly for italics. It's then not hard to negate all italics for a given script (by defining CSS for i.Hebr and i .Hebr and heck, even .Hebr i) and to translate all bolding to embiggening for a given script (by defining CSS for b.Hebr and b .Hebr and .Hebr b); and this scales well even when we use .lang-he and .lang-yi instead of .Hebr, allowing {{Xyzy}} to be deprecated properly. (Which has the benefit that we can more easily treat .lang-he differently from .lang-yi, for example. They're both Hebr, but only the former really needs to disable italics and to translate embolding to embiggening, since only the former uses vowels.) —RuakhTALK 15:16, 28 April 2011 (UTC)[reply]
I agree with Ruakh's main point. But a nitpick: Yiddish uses vowels also, but they're not the marks around and in the letters that Hebrew uses as vowels. And, slightly less nitpicky: Yiddish also uses marks around some letters, alephs and yods in particular.​—msh210 (talk) 16:32, 28 April 2011 (UTC)[reply]
You're right, of course; but by "vowels" I guess I meant "problematic vowels" . . . in vocalized Hebrew text, bold italics make me have to zoom in 200% and squint if I want to tell tseirei from patakh and segol from kamats. Yiddish doesn't have that problem SFAICT, because it doesn't have segol and tseirei. (Of course, you Yiddish editors might actually want to use the same no-italics, bold-means-big approach as we do for Hebrew, and that would be fine. I just don't think y'all should be slaves to Hebrew in this regard.) —RuakhTALK 17:55, 28 April 2011 (UTC)[reply]
I don't know if all script should support some value of bolding. I just don't know enough about scripts to say that. Apart from Latn, Grek and Cyrl I can't read them all at. Mglovesfun (talk) 13:29, 30 April 2011 (UTC)[reply]