Wiktionary:Grease pit/2015/May

(copied from User talk:Eirikr)

I got two issues with Japanese entries today

1. 十七 doesn't display an additional reading - "じゅうなな"
2. 稟告's kanji categories are not correctly generated. I made manual ones but they are empty - Category:Japanese terms spelled with 稟 read as ひん and Category:Japanese terms spelled with 稟 read as りん. Any help is appreciated. --Anatoli T. ^{(обсудить}/^вклад) 13:08, 2 May 2015 (UTC)

十七: Is this good? (it's truly awful how templates can be so sensitive to whitespace :'D) —umbreon126 01:29, 3 May 2015 (UTC)

稟告: The same code works on other pages (I tested 隣国) so perhaps it has to do with the page name? (Maybe the "Jinmeiyō" designation for 稟?) —umbreon126 01:34, 3 May 2015 (UTC)

Yep I think it has something to do with the "Jinmeiyō" part because 喋喋 and 蜜柑 act different too —umbreon126 01:38, 3 May 2015 (UTC)

Thank you for the fix on 十七! I have no idea about the other problem. --Anatoli T. ^{(обсудить}/^вклад) 02:18, 3 May 2015 (UTC)

It's because they're jinmeiyō, because the module doesn't make those readings subcategories for kanji not taught in secondary schools. Probably I should have mentioned that in the doc. If people want to change the behavior there are maybe three choices:

1. allow kanji manually as needed -- the code already does that for a some kanji. The exceptions are the string "厭昌之芽昌浩智晃淳敦聡晃旭亮"... at Module:ja-kanjitab. Copying and pasting kanji into that string will make the categories appear.
2. remove a few lines of code that do (1) and make readings subcategories for every kanji
3. (I'm 99% sure this is possible but haven't done it before) add the category link only when the category already exists, that is, fall back on the higher category in case of redlink --Haplogy (話) 07:42, 7 May 2015 (UTC)

I don't believe this is intended? At the moment it says 'literally transitive' which baffled me in the beginning as I interpreted 'literally' as a modifier for 'transitive' - literally transitive as opposed to.. what? So if anyone could put a comma after 'literally' in the template, that'll be great :0. Jamesjiao → ^{T ◊ C} 21:50, 5 May 2015 (UTC)

This could be an easy fix, but there are likely some entries that were written to rely on the lack of a comma. For those, inserting a comma would make things look off. So I'm not sure what could be done here? —CodeCat 22:32, 5 May 2015 (UTC)

Someone could check a current database dump (I don't have time to download one at the moment) to see which pages use "literally" followed by another context label. If feasible, they could flip through all the pages with AWB to see which, if any, relied on the absence of a comma. Motherfucker, for instance, would benefit from a comma, as would abstract — it currently displays "literally figuratively"! - -sche (discuss) 05:31, 6 May 2015 (UTC)

"I literally walked to the bus stop." Renard Migrant (talk) 09:30, 6 May 2015 (UTC)

You didn't literally put that in a context label, though, did you? - -sche (discuss) 14:20, 6 May 2015 (UTC)

No it just made me smile. Renard Migrant (talk) 16:25, 6 May 2015 (UTC)

How the bloody hell do you create these? {{topic cat/documentation}} points to Module:category tree and Module:category tree/topic cat, but I can't find parameters for individual topical categories in either of these. So where are they? Renard Migrant (talk) 09:29, 6 May 2015 (UTC)

Shortcut: go to a category of the same type, click on the "edit" link at the end of the description, and you'll find yourself at the data sub-sub-sub module for that category, in edit mode. I usually copypaste one of the other sections into the appropriate place in the alphabetical order and replace all the content- that way I don't have to worry about getting the picky details of the syntax right. The only really tricky part is choosing the right category to start from, and the right parent. In this case, Category:Pedophilia is under Category:Sex, so I would start from Category:en:Pedophilia (defined in Module:category tree/topic cat/data/Sex) and make "sex" the primary parent (you only get two parents: the primary and the secondary).

That said, I wouldn't create the category at all, because it's redundant to Category:en:Philias. Better to just remove it from the entry and tag the category for deletion. Chuck Entz (talk) 13:14, 6 May 2015 (UTC)

Redundant? So Japanophilia is a paraphilia, then? Renard Migrant (talk) 13:19, 6 May 2015 (UTC)

Given that our sole definition of the countable sense of philia is "a psychological disorder characterized by an irrational favorable disposition towards something", I'd say Japanophilia isn't a philia at all, let alone a paraphilia. —Aɴɢʀ (talk) 13:41, 6 May 2015 (UTC)

Yes, this looks like it's turned into a mirror of Category:English words suffixed with -philia. Chuck Entz (talk) 13:52, 6 May 2015 (UTC)

By redundant, I mean that all of the entries in Category:en:Paraphilias are already in Category:en:Philias. I suppose there's some benefit to having it in the tree under Category:en:Sex, so you may be right to create it. Chuck Entz (talk) 13:52, 6 May 2015 (UTC)

There's no limit to how many parents you can have actually. But the first one is the primary parent, it's the one used in the breadcrumb list at the top. —CodeCat 13:20, 6 May 2015 (UTC)

(not strictly on topic) Category:en:Philias seems to have turned into Category:English words suffixed with -philia. Renard Migrant (talk) 16:22, 6 May 2015 (UTC)

It's too tough for me, I'll leave it to the experts. Renard Migrant (talk) 11:51, 9 May 2015 (UTC)

In holy, the Mari language code mhr (Eastern Mari) produced this error:

Mari: Lua error in Module:translations at line 40: The language code "mhr" is not valid.

I tried it again and got this:

Lua error in Module:languages/templates at line 28: The language code 'mhr' is not valid.: Lua error in Module:parameters at line 41: The parameter "<strong class" does not exist. —Stephen ^(Talk) 06:47, 7 May 2015 (UTC)

"mhr" is merged with "chm" (Mari). Eastern Mari is the most common and the standard variety of Mari, when referring to Mari, people usually mean Eastern or Meadow Mari. "mrj" is still the code for Western or Hill Mari. --Anatoli T. ^{(обсудить}/^вклад) 06:54, 7 May 2015 (UTC)

(edit conflict) The ISO/Ethnologue in effect gave Eastern Mari two codes, and we decided to use chm rather than mhr, so the solution for Eastern Mari (aka standard Mari) is to switch from writing "mhr" to writing "chm". See Wiktionary:Language treatment and the two discussions it links to, Wiktionary:Beer parlour/2013/September#Merging_Mari_and_Buryat_varieties and Wiktionary:Language treatment/Discussions#Merging_Buryat_dialects.3B_also.2C_merging_Mari_dialects. mrj should be working for Western Mari, and for me it is. Hmm... - -sche (discuss) 06:54, 7 May 2015 (UTC)

It would be great if someone could add automatic conversion, like with Serbo-Croations varieties - type "bs" - get "sh". --Anatoli T. ^{(обсудить}/^вклад) 07:34, 7 May 2015 (UTC)

Do you mean that the code is automatically changed on saving the page? I don't think that's possible at all. If you mean that the codes are simply synonyms, that is more feasible but only if all uses of that code are passed through Module:languages. So if there is a template that uses, for example, {{{lang}}} instead of {{#invoke:languages/templates|getByCode|{{{lang}}}|getCode}}, then things won't work right. Likewise, modules would need to always retrieve the code through the :getCode() method of languages, and never directly from the parameter. —CodeCat 21:06, 8 May 2015 (UTC)

@CodeCat I meant (currently) line 2,491 in User:Conrad.Irwin/editor.js starting "var clean = ...". It seems simple, I might add it later when it's the right side of midnight. --Anatoli T. ^{(обсудить}/^вклад) 15:04, 15 May 2015 (UTC)

For example, {{specieslite|Nosema|i=1}}, (diff).

It does nothing at all, it seems. —CodeCat 21:07, 8 May 2015 (UTC)

Hmm. Thank you. —BoBoMisiu (talk) 23:51, 8 May 2015 (UTC)

It would have the side-effect of causing Module:parameters to generate a module error if any of those templates were converted to use it, though. Chuck Entz (talk) 01:21, 9 May 2015 (UTC)

We should have the ability to selectively italicize the display in the project links. I come across this for taxonomic names for which entries have links to pedia, species, and commons. I mentioned the matter in Template talk:pedia, apparently not watched by anyone capable and desirous of making the changes required. DCDuring TALK 11:44, 9 May 2015 (UTC)

There is ''{{pedia}}''. Renard Migrant (talk) 11:50, 9 May 2015 (UTC)

The standard category "List of topics" should never have anything but English category names in it, and the names in the language-specific versions are all prefixed by the language code. For example, what's the point of even having a TOC for Category:ru:List of topics, when there are no Cyrillic-initialed category contents for the Cyrillic TOC to link to? Would it be possible to always use an English TOC in the language-specific lists of topics, and to strip the language-code prefix for that TOC?

As for the TOC for "All topics": it has the same issue, but the solution is different- only Category:All topics needs one. All the language-specific ones have fewer than the 200 members needed to go to multiple pages, so the TOC should be suppressed for those. Chuck Entz (talk) 21:33, 8 May 2015 (UTC)

This is really a wider problem for categories that contain other categories. Entry names are in the current language, but category names are in English regardless. What should be done for categories that contain both? It's possible for modules to tell whether a category contains entries, categories or both (via mw.site.stats.pagesInCategory), so the module could in theory be made to test for this and select the TOCs appropriately. But I have found that this causes some slowdown, especially because it presumably means this function has to retrieve a list of everything in the category and then count. There was originally code in Module:category tree to include a "large" TOC when the category contains more than a threshold number of pages, but this was removed some time ago because of that slowdown. —CodeCat 21:47, 8 May 2015 (UTC)

Yes, it's part of a broader problem, but the narrower problem doesn't have the implementation barriers of the broader one. Why not fix what we can fix, and maybe someday replace this fix with a better one when it becomes available? Chuck Entz (talk) 22:25, 8 May 2015 (UTC)

But how would the narrower problem be fixed? Are you suggesting a hack for "List of Topics" alone, that might well take more effort to implement than the full fix? —CodeCat 23:05, 8 May 2015 (UTC)

Here's another thought: category tree has the following line:

local isEmpty = mw.site.stats.pagesInCategory(mw.title.getCurrentTitle().text, "all") == 0

How much performance difference would there be if you took out the second parameter and saved the resulting table, then set isEmpty based on whether all the counts were zero? It seems to me like a lot of the expensive part of the function would be shared by the different counts, not duplicated. I'm sure running the function once- even with all the bells and whistles- would take less time than running it twice, as you did before. Chuck Entz (talk) 23:25, 8 May 2015 (UTC)

That's a good idea. Do you want to try it? —CodeCat 23:33, 8 May 2015 (UTC)

I think it would be worth trying, but I'm better at reading Lua than writing it, so I'd rather not do the code myself. Chuck Entz (talk) 23:45, 8 May 2015 (UTC)

If a flag were added that category tree subtemplates could set for subcategory-only categories, it would allow tracking of non-categories to such categories in the same way empty categories are tracked. There are probably other uses, as well. Chuck Entz (talk) 01:29, 9 May 2015 (UTC)

I think semicolons would improve the intelligibility of context labels in a small number of entries like Billett where it's necessary to note that a term has multiple levels of rareness or currency vs archaicity in multiple regions. I suggest modifying Template:label et al. to accepted ";" as a parameter similar to "or", in that it suppresses the usual comma and displays a semicolon instead (which, unlike "or", won't be separated from the previous label by a space). I would like to type {{lb|de|current in|_|Switzerland|Belgium|Luxembourg|;|archaic in|_|Austria|;|dated|_|elsewhere}} and get (current in Switzerland, Belgium, Luxembourg; archaic in Austria; dated elsewhere). Drawback: the semicolon might be overused (e.g. people might type "archaic|;|rare" where just "archaic|rare" would be sufficient). - -sche (discuss) 22:19, 8 May 2015 (UTC)

Template talk:User lang--Dixtosa (talk) 07:33, 10 May 2015 (UTC)

I've noticed that people just copy and paste. That is horrible and does not preserve the history. Why don't you just move it?--Dixtosa (talk) 16:41, 11 May 2015 (UTC)

I am working on adding Gaelic names of fauna. Some of the bees I am adding have long compound names like "seillean càrdair nan lurgann dearg", which is a "red-shanked carder bee" (Bombus ruderarius). I am not sure of the genitive in these cases, so I don't want to include a genitive clause, but I do know the plural. When I try to include the plural form of this creature's name (seilleanan càrdair nan lurgann dearg) in {{gd-noun}}, the plural will not display.

After some rudimentary testing, I have determined that if the genitive case is empty, {{gd-noun}} will not display the plural regardless of whether the genitive tag is included. E.g. "xyz" will not be displayed in either of these cases: {{gd-noun|g=m|gen=|pl=xyz}} or {{gd-noun|g=m|pl=xyz}}. When the genitive value is not NULL/NIL, the plural is always displayed. A few of the existing examples are: seillean càrdair cumanta, seillean càrdair nan lurgann dearg and seillean-mòr a' bhlàir-fhraoich.

Having looked briefly at the code, and not wanting to break any of the 5,443 existing Gaelic nouns, I bring this issue here rather than try to solve it on my own.

Can/would anyone help me? Thanks in advance. Kibi78704 (talk) 19:59, 11 May 2015 (UTC)

I will look into fixing it, but it will take a while as it's quite a jumble. —CodeCat 20:01, 11 May 2015 (UTC)

@Kibi78704 I've rearranged a lot of the code, hopefully it's all good now. —CodeCat 22:21, 12 May 2015 (UTC)

@CodeCat Thank you SO much! I have not had a chance to look at it yet, but I am grateful for the time you spent on it! Kibi78704 (talk) 23:07, 12 May 2015 (UTC)

The diacritics in Burmese font aren't all showing up over the correct letter for me, but some are instead turning up as individual characters above a dotted circle. Assuming that one of our Mymr fonts was not performing the character compositions correctly, I checked them all individually by removing one font at a time from Mediawiki:Common.css, and then clicking 'Hard purge' on အငြိမ့် (where the C-shaped diacritic on the last character is not on top of the last letter). I didn't succeed in removing the problem, so I'm really unsure of what to do now. @Angr, -sche, CodeCat. —Μετάknowledge^{discuss/deeds} 21:16, 12 May 2015 (UTC)

It displays right for me, so it's not a problem at Wiktionary's end. It sounds like your font might be having an issue with the ordering of the two diacritics ့ and ်. What do the following look like for you?

အငြိမ့် (့ before ်)

and

အငြိမ့် (် before ့)

I think that the first one is the canonically correct order, but I also think our software should automatically correct the order if it's entered wrong (which is why I had to use HTML entities above to show the difference). But maybe that's what's going wrong for you? At any rate, both of the above display correctly for me. —Aɴɢʀ (talk) 21:42, 12 May 2015 (UTC)

Both display fine for me as well, just as pagetitles do. We've had the issue before where we were specifying fonts that were faulty and then used by browsers, so I thought that would be it. The thing is, we should be able to display everything correctly regardless of user-end font specs. —Μετάknowledge^{discuss/deeds} 22:03, 12 May 2015 (UTC)

If they display fine for you, what isn't displaying right? Burmese fonts are always a little wonky. On Firefox, Burmese only displays correctly for me if it's inside a tag like {{l}}, {{lang}}, {{m}}, or {{t}}. If it's not inside a tag, I get boxes (including in the edit window and in page titles). In Chrome, on the other hand, Burmese displays right for me everywhere except browser tabs. And this is on the same computer with the same fonts installed. —Aɴɢʀ (talk) 22:07, 12 May 2015 (UTC)

Um, yeah. Replace r with ɹ inside IPA and rhymes if and only if the language statement is en. Any questions? I'll remind you (before someone asks), that ɹ rather than r is recommended by a vote. Renard Migrant (talk) 15:19, 14 May 2015 (UTC)

There is an error on भूगोल, and I did some tracing to find out why it happens. It seems to come down to this code in Module:wikimedia languages: mw.language.isKnownLanguageTag(code). When given "bh" as the code, this function returns false. But this is strange, because there is, in fact, a Bihari Wikipedia: //bh.wikipedia.org/ . So why is this function saying that the software doesn't recognise the code? —CodeCat 12:23, 15 May 2015 (UTC)

. They forgot to rename the wiki xD.--Dixtosa (talk) 14:37, 15 May 2015 (UTC)

But we're using "bh" as the code for Bihari in Wiktionary as well. Should that be changed? —CodeCat 14:53, 15 May 2015 (UTC)

Yup I guess as it not a single language. P.S. the default language is bho on bh.wiki. --Dixtosa (talk) 15:11, 15 May 2015 (UTC)

Why doesn't {{deftempboiler}} have an {{{id}}} to discriminate a particular {{senseid}} target in the same way {{l}} does? —BoBoMisiu (talk) 14:55, 16 May 2015 (UTC)

It's an old template, written before senseids were introduced. It should probably be converted to Lua at some point and brought up to date, along with other templates. —CodeCat 15:27, 16 May 2015 (UTC)

clockpunk headword: clockpunk (plural ) (code is {{en-noun|~}}). Also adds Category:English term requests. Not sure if {{en-noun}} is the culprit or it's Module:en-headword. Renard Migrant (talk) 17:20, 17 May 2015 (UTC)

Revert 'em all. DCDuring TALK 17:47, 17 May 2015 (UTC)

Fixed now. —CodeCat 17:49, 17 May 2015 (UTC)

Principal namespace isn't a sandbox.

Do we need some kind of test rig that behaves like principal namespace? Or should the basic practice of duplicating entire template and module trees under different names be insisted upon? DCDuring TALK 17:47, 17 May 2015 (UTC)

No, unit tests are enough. Creating thorough tests (like this) is tiresome but worthy. Note one can check if the change causes any errors using the "show preview" button without saving it first. --Dixtosa (talk) 18:14, 17 May 2015 (UTC)

For template/Lua editors: Please note the existence of both the "Preview page with this template" box on the edit screen, and Special:TemplateSandbox. --Yair rand (talk) 23:56, 17 May 2015 (UTC)

I'm aware of this and I did preview it, but this was a use case I apparently missed. —CodeCat 01:37, 18 May 2015 (UTC)

Oh well. As Mao('s translators) wrote: "You can't make an omelet without breaking some eggs." DCDuring TALK 02:29, 18 May 2015 (UTC)

In fairness sometimes you just screw up. The difference is, on a single page you can revert in second, with a template used thousands of times it takes a lot longer for the server to catch up. Though I'm surprised nobody spotted it before I did. Something like {{en-noun/test}} where you start with a verbatim copy of en-noun then modify it and try it on a page. In fact you can see that en-noun/test has previously existed and been deleted (as it should be when not in use). Renard Migrant (talk) 17:24, 22 May 2015 (UTC)

We have Category:Reduplications by language, but AFAICT we don't have any template that categorizes into it. Could someone please make a template {{reduplication}} to be used in etymology sections (not a definition-line form-of template, though, which is why it probably shouldn't be called {{reduplication of}}) that will categorize terms into the language's reduplication category? I could do it myself the old-fashioned way, but I suppose it really ought to invoke Module:category tree or something, and I don't know how to do that. —Aɴɢʀ (talk) 14:16, 18 May 2015 (UTC)

If you make it the old fashioned way, I can check it and fix things up if you like? —CodeCat 14:25, 18 May 2015 (UTC)

Will you fix this up too? You can see how it is going to be used here and how contributors were immensely delighted about the proposal here. --Dixtosa (talk) 17:23, 18 May 2015 (UTC)

I've done that now. —CodeCat 17:35, 18 May 2015 (UTC)

OK, old-fashioned template is at User:Angr/Template:reduplication. —Aɴɢʀ (talk) 21:18, 18 May 2015 (UTC)

Done. It appears that this template takes the exact same parameters as {{m}}, so there is a further optimisation I could apply. The template could invoke the module used by {{m}} directly rather than calling the template as an intermediate. —CodeCat 21:25, 18 May 2015 (UTC)

Yeah, the way you rewrote it. I had intended the syntax to be {{reduplication|jaw|lang=en}}, but your syntax is {{reduplication|en|jaw}} which is indeed just like {{m}}. I think my way is a little more intuitive; it has the same syntax as other etymology templates like {{clipping}}. In fact, I'd like it to take all the parameters that {{clipping}} does. And I'm also thinking about whether it should take a parameter specifying the type of reduplication: total reduplication (e.g. jaw-jaw), rhyming reduplication (e.g. jeepers creepers), alliterating reduplication (e.g. jibber-jabber), and so on. Maybe this is something to discuss at ES before taking the template live. —Aɴɢʀ (talk) 22:01, 18 May 2015 (UTC)

I think lang= is more cumbersome than using the first parameter. And I'm not a fan of making templates default to English either. There is also clearly a tendency towards making templates work this way; {{m}}, {{label}} and {{ux}} were all created as alternatives/replacements for {{term}}, {{context}} and {{usex}}, and {{topic cat}} was also converted to this format years ago. So I think all new templates should be created this way. —CodeCat 22:17, 18 May 2015 (UTC)

I suppose it's a matter of what we expect and what we expect other people to expect. I've gotten used to the syntax of {{m}}, {{lb}}, and {{ux}}, but in general I expect templates to take a lang= parameter and I'm always having to go back and correct my syntax when I use something like {{prefixsee}} or {{phrasebook}}, because I expect them to take lang= and they don't. Anyway, I don't suppose it's a huge deal, but I do think things like nocap=, nodot=, gloss= and so on would be a good idea, and I probably will bring up the other things at ES, but not today because it's my bedtime. —Aɴɢʀ (talk) 22:28, 18 May 2015 (UTC)

We could have both {{reduplication|lang=en}} and {{redup|en}} or something like that. As far as I can tell, we can still implement both with Module:links/templates, with the long one using compat=1. --WikiTiki89 22:34, 18 May 2015 (UTC)

Tabbed languages is not working right on this page, and the Citations tab and some gadgets are also missing. —CodeCat 17:14, 18 May 2015 (UTC)

Looks fine to me. —Aɴɢʀ (talk) 18:23, 18 May 2015 (UTC)

Our Wiki parser/checker revealed a systematic problem with Albanian entries done by User:Etimo. These have often "Alternative forms" as level5 header following a l2 header for the language itself (see e.g. Arbërore, Lekë, prehër and some hundred other entries - I have a list.) IMO, these "Alternative forms" should be level3 as can be seen in color. LinguistManiac (talk) 14:01, 19 May 2015 (UTC)

What LinguistManiac meant to say is that he would like a bot to fix the headings. --WikiTiki89 14:27, 19 May 2015 (UTC)

Yes, but actually to L3 - corrected the heading LinguistManiac (talk) 15:03, 19 May 2015 (UTC)

Would you consider adding subsection anchors in all the pages for Chinese characters? For example, then http://en.wiktionary.orghttps://dictious.com/en/%E5%85%88#Japanese would navigate directly to the Japanese section of that article. Same for Chinese, Korean, Vietnamese, etc.

Such a link sort-of works now, but it takes me to the bottom of the Japanese section, not the top.

thanks, -Mark Garrett

Hi! Wiktionary already has anchors (as you note), and these are supposed to take clickers to the top of the relevant language section. For me, that's just what they do. If they take you to the bottom of the language section instead, I suspect collapsing tables (which take up a certain amount of space when the page is loading, but then collapse and take up less space, causing the content below them to "rise") are to blame. We're aware of that bug, but we haven't found a good way of fixing it yet. - -sche (discuss) 20:14, 19 May 2015 (UTC)

Module:labels/data contains a label "singulare tantum" which displays "singular only", and a separate label "singular only" which displays "not used in the plural". They both categorize into pos_categories = {"singularia tantum"}. Is there some reason for having these as separate labels, or can the second one be combined into the first one? I noticed this when adding "no plural" as an alias of the first one. - -sche (discuss) 20:10, 19 May 2015 (UTC)

I have combined them. - -sche (discuss) 16:54, 22 May 2015 (UTC)

No (there is no good reason to have these as separate labels) and plurale tantum, plural only and pluralonly should be merged (if they are not currently merged). Renard Migrant (talk) 17:16, 22 May 2015 (UTC)

• {{C.|22}} yields "22th c." - should be "22nd c."
• {{C.|1}} yields "1th c." - should be "1st c."
• {{C.|0}} yields "0th c." - I'm not convinced there was such a century
• {{C.|-1}} yields "-1th c." - should be "1st c. BC" or some such
• {{C.|too}} yields "tooth c." - template should do some basic vetting

SemperBlotto (talk) 20:26, 20 May 2015 (UTC)

It's not a bug, but a missing feature. You're supposed to do {{C.|22|nd}}, etc. --WikiTiki89 20:33, 20 May 2015 (UTC)

Why I am getting the following message in my babel box:

"Lua error in Module:languages/templates at line 28: The language code 'en-us' is not valid."

Did somebody delete the language code for en-us? I don't believe there was a consensus to do so. The babel I'm running is en-us-N, FWIW. Purplebackpack89 23:56, 20 May 2015 (UTC)

There never was such a code. —CodeCat 00:19, 21 May 2015 (UTC)

Well, SOMEONE changed SOMETHING so that what worked before doesn't work now. This follows a pattern by SOMEONE imposing changes without without knowledge or concern about consequences and without bothering to ask. I wish that SOMEONE would stop for good. Further the response to Purplebackpack89 is so evasive as to be deceptive. How is one supposed to AGF while being played for a fool? DCDuring TALK 01:13, 21 May 2015 (UTC)

If the environment was less hostile and more cooperative, editors might be more willing to be open about the things they do. Your accusatory tone is not helping. —CodeCat 01:22, 21 May 2015 (UTC)

@CodeCat: If SOMEONE were more transparent in the activities engaged in, there would not be accusations. (Please note that it is an actual accusation, not merely the tone of one.) DCDuring TALK 08:21, 21 May 2015 (UTC)

First off, User:DCDuring, wha? You've completely hyperbolized what I asked in a manner that is ABF and generally unhelpful.

My best guess as to what happened is that there have been some recent changes to the babel template that require different templates exist, or else errors are generated. At one time, it may not have mattered that Template:en-us was a redlink, now it does. Not a coding expert, but would like there not to be error messages on my (and likely others') user pages. Purplebackpack89 04:15, 21 May 2015 (UTC)

BTW, User:DCDuring, the error in the template appears on your user page as well as mine, because you, like I, am in Category:User en-us-N. So you yourself have a least a little vested interest in getting this fixed. Purplebackpack89 04:33, 21 May 2015 (UTC)

@Purplebackpack89: Actually I had noticed it but had so despaired that such a thing would ever get fixed that I had chosen not to bring it up. But when a squeakier wheel brought it up, well .... DCDuring TALK 08:21, 21 May 2015 (UTC)

I suppose I should have been more politic, but someone has to bell the cat. DCDuring TALK 08:26, 21 May 2015 (UTC)

Related discussion: Wiktionary:Requests for deletion/Others#Template:User_en-us-N (which shows no consensus for deletion). - -sche (discuss) 01:51, 21 May 2015 (UTC)

no, this is the related discussion. I would not give up on this feature.--Dixtosa (talk) 06:44, 21 May 2015 (UTC)

Aha. If we implemented the third solution you mention on Template talk:User lang, rather than the second (which is the one I implemented), would that unbreak this? - -sche (discuss) 13:13, 21 May 2015 (UTC)

No. en-us does not exist in ISO 639.

A new function could be written specifically for this purpose maintaining a list of the additional language codes. Are en-uk and en-us the only additions? --Dixtosa (talk) 15:30, 21 May 2015 (UTC)

I know en-us isn't an ISO code, but the non-existence of a Wikipedia page wouldn't cause a module error the way the nonexistence of the code in Module:languages does, would it? - -sche (discuss) 17:25, 21 May 2015 (UTC)

I think it is completely unacceptable that non-existant language code causes Module:languages to throw an error and no content to display. What should happen is it should be taken as "und" and an error category and maybe message should be added to the content. --WikiTiki89 17:39, 21 May 2015 (UTC)

I agree with you, but apparently nobody who can do something about it cares what you think. DCDuring TALK 17:27, 22 May 2015 (UTC)

Pull-down tables have problems with skins Cologne Blue and Modern. Both with Internet Explorer 11 and with the latest Chrome, the label reading "Show" does not appear in the top-right corner. As an example, go to https://en.wiktionary.orghttps://dictious.com/en/vedere, and scroll down to "Conjugation". The problem goes away if I pick another skin/theme, or I log out (whereby Wiktionary will pick the default skin, I imagine). The console in both IE and Chrome displays Javascript error messages when either problematic theme is selected. Thanks. - User:Rgiuntoli 09:05, 21 May 2015 (UTC)

Incidentally, this is nothing new, it's been there for quite some time, and it's only now that at last I've had the opportunity to investigate this more in depth, and narrow the problem down to the abovementioned skins. - User:Rgiuntoli 09:09, 21 May 2015 (UTC)

and {{alternative term for}} which redirects to {{alternative name of}} all three seem to do the same thing and behave identically. --Dixtosa (talk) 22:19, 21 May 2015 (UTC)

I don't see what the problem is. They display different text. —Μετάknowledge^{discuss/deeds} 18:50, 22 May 2015 (UTC)

{{synonym of}} does not have a comprehensive documentation but I guess it is also

used to indicate exact synonymy between the headword and the linked-to target, when the two terms are not simply spelling or punctuation differences of each other, but instead include different words

--Dixtosa (talk) 19:15, 22 May 2015 (UTC)

It's the displayed text that matters. It would be weird to say "up for is an alternative name of or term for down for", mostly because these are not really names or terms. I guess "synonym of" is more general and can apply to pretty much anything, but sometimes it's good to be more specific and use "alternative term for" or "alternative name of" when these actually apply. Just like {{alternative spelling of}} is almost the same thing as but more specific than {{alternative form of}}. --WikiTiki89 19:26, 22 May 2015 (UTC)

What's the point of any of these in a definition line? They add words, but not value. Does someone find them useful for dump searches? DCDuring TALK 19:34, 22 May 2015 (UTC)

I think our human users find it useful. What does this have to do with dumps? --WikiTiki89 19:37, 22 May 2015 (UTC)

Useful for what? What information is conveyed that isn't conveyed by argument 1 and its link alone?

Also {{alternative name of}} is just a specialization of {{alternative term for}} for nouns.

The use for dumps is to find text that has been so marked by a human. Were these widely used they would have some value. If there were some project that used these for some distinction, that would be an argument for keeping them. DCDuring TALK 11:34, 27 May 2015 (UTC)

When you go to a grocery store to buy lemons, you might see a sign that says "Lemons - $X.XX/lb.". Are you going to complain that they should remove the word "Lemons" because people should already know those round yellow things are lemons? --WikiTiki89 14:17, 27 May 2015 (UTC)

I have moved it to {{blockquote}} because it was used for larger texts and the appearance was a proof of this. If I get no objections I ll replace all the uses of {{quote}} with blockquote and then move {{quote/new}} to {{quote}}--Dixtosa (talk) 15:57, 28 May 2015 (UTC)

User:kc_kennylau hasn't been around in several weeks, so I'll ask the community at large: can someone please fix Module:cy-mut so that mut3 is "H" followed by a lowercase letter when the input is a capital vowel letter? For example, at Amwythig, the h-prothesis is currently generated as hAmwythig, but it ought to be Hamwythig. Thanks! —Aɴɢʀ (talk) 17:06, 30 May 2015 (UTC)

@Angr Actually I'm still here. Fixed. --kc_kennylau (talk) 22:52, 30 May 2015 (UTC)

Thanks, Kenny! —Aɴɢʀ (talk) 14:12, 31 May 2015 (UTC)

Having compared the Basque and the English wiktionaries, it is clear that Basque is lacking in terms of vocabulary and templates on Wiktionary. The vocab can be added quite easily, but the templates might take a bit longer. There is already a noun-inflection template here, but a verb-inflection template would really help. I would suggest that two templates be made, one for synthetic verbs (which exists in the Basque version, for example the very detailed page on esan) and one for generating non-finite forms for periphrastic conjugation. Is there anyone who would object to this for whatever reason? — This unsigned comment was added by Skahmed23 (talk • contribs).

it seems like we do not have any conjugation templates yet, so go ahead copy them from euwikt. Something is better that nothing.--Dixtosa (talk) 18:04, 1 June 2015 (UTC)

Just rememember that we have a unique combination of templates and modules underlying most of our basic templates that won't match those of eu Wiktionary, so you should have someone knowledgeable in our setup take a look at them once you port them over. It may be that we already have modules that do a great deal of what the template code does, but in a different way. Chuck Entz (talk) 01:20, 2 June 2015 (UTC)

Just had a look at the Basque version and that has no verb template either. Instead the users have manually inputted a table with the necessary forms. So it seems as though I would be working from scratch. As a complete novice at wiktionary coding, should I attempt to make a template myself or let someone else do it in due course? Skahmed23 (talk) 17:44, 2 June 2015 (UTC)

@Skahmed23: I'd certainly be prepared to work with you to make them (I'm not a template master, but I'm definitely good enough for this). Could you give some links to the ad hoc tables so I can see where to start? —JohnC5 20:54, 2 June 2015 (UTC)

@JohnC5: Sure thing! How should I send them to you? Skahmed23 (talk) 20:58, 2 June 2015 (UTC)

How about we work in my User:JohnC5/Sandbox2? —JohnC5 21:02, 2 June 2015 (UTC)

When you are finished make sure you move your sandbox or copypaste the content or even better work in a more appropriate place as the discussion about design choices and the coding might be interesting for a future user.

Also, before doing your coding try to find Basque templates in other Wiktionaries. They might help. I have found this and this

Also try to find the closest paradigm here and imitate it. --DixtosaBOT (talk) 05:40, 3 June 2015 (UTC)

Oooh, the Japanese Wiktionary table is quite nice (transitive found here). @Skahmed23: what do you think? —JohnC5 06:30, 3 June 2015 (UTC)

@JohnC5: I think the Japanese one is good in that it offers some sort of idea of what to do, although the formatting is unclear, and the contents are of varying degrees of accuracy. The French verb table is also quite nice, but is pretty much exactly what I have already made a template for. Skahmed23 (talk) 11:52, 3 June 2015 (UTC)