Wiktionary

Wiktionary:Grease pit/2016/June

< Wiktionary:Grease pit

Insertable diacritics edit

I already posted this in May's Grease pit, but no one responded, so I'm saying it again here: Something's going on with the box of clickable characters governed by MediaWiki:Edittools. In Burmese and Devanagari, clicking any of the combining characters causes the character to appear twice. (For example, if I click on ा in Devanagari, what appears is ाा.) This doesn't seem to be happening for combining characters in the other scripts, though I haven't checked everything. Also, for Khmer, clicking any of the combining characters causes all of them to appear in the edit box.

I've also noticed a problem I was unaware of when I mentioned the above: the combining diacritics for Greek don't work anymore either: they're all bunched together instead of being separate, and clicking on them doesn't do anything. The combining diacritics for Cyrillic still work, though. —Aɴɢʀ (talk) 14:04, 1 June 2016 (UTC)[reply]

I fixed the Devanagari. Essentially the problem was that you nested some of the diacritics in two layers of class="charinsert Deva". I'll take a look at the others a bit later. --WikiTiki89 16:21, 1 June 2016 (UTC)[reply]
Thanks for your help! I think I fixed it for Burmese too (I was missing a </span> or two). The Greek and Khmer seem to be different issues. —Aɴɢʀ (talk) 16:25, 1 June 2016 (UTC)[reply]
I fixed Khmer (the problem was that there was no space between them). I cannot figure out what is wrong with Greek. I tried so many different things that I thought for sure would have worked, but they didn't. --WikiTiki89 20:48, 1 June 2016 (UTC)[reply]
Thanks for your help! It's weird that all of them used to work fine and then stopped even though the source text hadn't been edited. —Aɴɢʀ (talk) 22:07, 1 June 2016 (UTC)[reply]
  • Hmm, no changes to the Edittools page or any of my Javascript settings, yet suddenly Edittools isn't working: it renders correctly in the edit view, but now mousing over shows the text caret instead of the clickable cursor, and clicking doesn't do anything but move focus out of the edit textbox. Is someone mucking about with the EN WT server? ‑‑ Eiríkr Útlendi │Tala við mig 23:24, 9 June 2016 (UTC)[reply]

ISO code for Elfdalian edit

It now has a code: [1]. We should probably change our entries to reflect it. —CodeCat 22:15, 1 June 2016 (UTC)[reply]

Indeed we should. @-sche —Μετάknowledgediscuss/deeds 22:30, 1 June 2016 (UTC)[reply]
I agree. Previous discussion and an explanation of where we got the non-ISO code dlc from is at Template talk:dlc. Like the switch of Dhuwal from duj to dwu, described at WT:RFM#Dhuwal, it seems like a boring rote busywork task a bot could do. - -sche (discuss) 23:02, 1 June 2016 (UTC)[reply]
I copied the existing language data to "ovd", and marked "dlc" as deprecated via a mechanism I just added to Module:languages. You can see all uses of the code here. —CodeCat 12:28, 4 June 2016 (UTC)[reply]

head|es|noun edit

Hey. Can someone make me a page with all entries containing head|es|noun like in the link, please? --J19idf (talk) 11:33, 4 June 2017 (UTC)[reply]

how bout a search result --Dixtosa (talk) 11:38, 4 June 2016 (UTC)[reply]
Better search (yours also included noun forms). Redboywild (talk) 12:11, 4 June 2016 (UTC)[reply]

problem at 一 edit

The bottom half of the page 一 is filled with the error message Lua error: not enough memory ?? --87.63.114.210 11:00, 6 June 2016 (UTC)[reply]

Technical problems :( The solution has not been actively searched for. —suzukaze (t・c) 11:11, 6 June 2016 (UTC)[reply]
I have commented out the usage of {{zh-pron}} until it gets optimized. I am sure it gets the content of the entry and applies some regex on it. --Giorgi Eufshi (talk) 11:18, 6 June 2016 (UTC)[reply]
Of which entry? Wyang (talk) 11:20, 6 June 2016 (UTC)[reply]
The entry that uses it? No? whatever it made the whole Japanese section useless so I had to remove it. --Giorgi Eufshi (talk) 11:21, 6 June 2016 (UTC)[reply]
No it does not. Wyang (talk) 11:24, 6 June 2016 (UTC)[reply]
It does seem to be rather resource-heavy though, calling on all sorts of data modules. —suzukaze (t・c) 11:59, 6 June 2016 (UTC)[reply]

Unexplained attention category edit

Did I do something wrong here that is causing graciozzo to appear in Category:Ladino terms needing attention and Category:attention lacking explanation? —Aɴɢʀ (talk) 19:01, 8 June 2016 (UTC)[reply]

Nope. This was the problem. --WikiTiki89 19:10, 8 June 2016 (UTC)[reply]

TOC edit

How is the "___TOC___" and "___NOTOC___" here? Sobreira (talk) 11:55, 9 June 2016 (UTC)[reply]

Category for "Republic of the Congo" edit

Why isn't there any category for "Republic of the Congo"? ばかFumiko￥talk 01:24, 10 June 2016 (UTC)[reply]

I guess no one's made one yet. It's a wiki, {{sofixit}}. But I do find our country categories rather confusing. We have categories for most countries in Africa, but they aren't in Category:Countries of Africa; rather, they're in Category:Africa. Likewise for the other continents. It seems counterintuitive to me. —Aɴɢʀ (talk) 11:37, 10 June 2016 (UTC)[reply]
Countries of Africa is for terms that are names of countries of Africa. Terms related to the Republic of the Congo aren't a subset of that. —CodeCat 13:04, 10 June 2016 (UTC)[reply]
On a related note, there's been no distinct category for the dozens of French words that fr.Wikt says are specific to either the DRC or the ROC but not both, but the solution proposed in August 2015 could be implemented if anyone wanted to start adding more of those words. - -sche (discuss) 14:39, 10 June 2016 (UTC)[reply]

Template:der3 (etc.) edit

I would like to use this template with its self-balancing properties for Norwegian, but there's a problem with the letters æ, ø, and å which are sorted out of alphabetical order. These are the last three letters of the Norwegian and Danish alphabets (after z); for example "å" is automatically sorted under "a" which is totally unsatisfactory. Is there any way of amending the template to cater for this, or am I missing something? DonnanZ (talk) 10:36, 12 June 2016 (UTC)[reply]

The same problem occurs with Swedish, where the last four letters in the alphabet are z, å, ä, and ö. This problem doesn't occur in German, where words starting with ä, ö, or ü are included in dictionaries under a, o, and u respectively. Perhaps the answer is another template with the self-balancing facility, but without the self-sorting facility for certain languages. It would then be up to the editor to do the sorting into the correct alphabetical order for the language. DonnanZ (talk) 14:34, 12 June 2016 (UTC)[reply]

@Donnanz The module uses the sort key and entry name fields as defined in Module:languages/data2. Someone should be able to add the correct rules which will make {{der3}} sort as you expect. DTLHS (talk) 16:21, 12 June 2016 (UTC)[reply]
Thanks, but nothing has materialised yet. Another shortcoming with this template seems to be the inability to have more than one entry on the same line, e.g. different forms of the same word. DonnanZ (talk) 16:09, 18 June 2016 (UTC)[reply]
I would need a complete description of the sorting rules for Norwegian and Danish to add the proper sort keys. You can leave off the "lang" parameter and the terms won't be automatically linked, so you can put whatever you want on each line. DTLHS (talk) 16:14, 18 June 2016 (UTC)[reply]
The Danish and Norwegian alphabets are exactly the same, and are shown here in [2]. They are exactly the same as English up to Z, followed by Ææ, Øø, and Åå in that order. The Swedish alphabet is also mentioned in the article, where Z is followed by Åå, Ää, and Öö in that order. Is that what you require? DonnanZ (talk) 18:35, 18 June 2016 (UTC)[reply]
Just out of curiosity, have you checked to see |sort= parameter in {{der3}} has any effect? It looks like it's supposed to turn sorting on and off, depending on whether the value is 1 or 0 (though I'm not sure which is which). Chuck Entz (talk) 00:59, 24 June 2016 (UTC)[reply]

@CodeCat Could you help me out here? Category:Danish lemmas is sorted correctly without needing a sort key in Module:languages/data2, but doing table.sort in Module:columns produces

I can convert the compare function to bytes in Module:User:DTLHS/test to get

{{:User:DTLHS/Template:test|b|a|c|d|e|z|æ|Ø|å|lang=da}}

which still isn't right. DTLHS (talk) 19:07, 18 June 2016 (UTC)[reply]

  • @DTLHS: I have tried with tid (Bokmål) and tid (Nynorsk) to start with, and it worked wonderfully. Thanks a lot! I hope this template will be useful for other editors too; e.g. for Danish, Swedish and maybe other languages (I don't know which). There may be a need for {{der2-u}} and {{der4-u}} if anyone asks, but this'll do for now. Thanks once again. DonnanZ (talk) 20:48, 23 June 2016 (UTC)[reply]

{{der}} with "-" as the target language edit

So apparently {{der}} is just {{etyl}} with the source and target parameters reversed. (Related discussion: Wiktionary:Beer parlour/2016/March#Use of "inh" vs "etyl")

This works: {{etyl|fr|en}} = {{der|en|fr}}

But this does not work: {{etyl|fr|-}} = {{der|-|fr}}

If I want to show just the language name without categorization, do I have to use {{etyl}}? I was hoping {{etyl}} could be superseded by {{der}} at some point, but {{der}} does not seem capable of doing it. --Daniel Carrero (talk) 04:15, 15 June 2016 (UTC)[reply]

If {{etyl|fr|-}} is followed by a French term, you can replace it with {{cog|fr|(term)}}, e.g. {{etyl|fr|-}} {{m|fr|chien}} can be replaced by {{cog|fr|chien}}. I'm not sure why {{etyl|fr|-}} would ever not be followed by a French term. —Aɴɢʀ (talk) 11:36, 15 June 2016 (UTC)[reply]
Because you could theoretically say: "A {{etyl|fr|-}} borrowing, but the exact source is unknown". Such wording is common in Iranian borrowings. --Vahag (talk) 19:14, 15 June 2016 (UTC)[reply]
In that case, you would want to put it into the "terms derived from French" category, so you wouldn't use "{{etyl|fr|-}}" but "{{etyl|fr|en}}" (or whatever). And if you really didn't want to categorize, you could dispense with the tag altogether and just write "A French borrowing". —Aɴɢʀ (talk) 19:20, 15 June 2016 (UTC)[reply]
I tested this now: it seems {{cog|fr}} returns the same result as {{etyl|fr|-}}. So you can use: "A {{cog|fr}} borrowing, but the exact source is unknown", which is enough to me. --Daniel Carrero (talk) 06:39, 16 June 2016 (UTC)[reply]
{{cog}} "is used to indicate cognacy with terms in other languages that are not ancestors of the given term". - -sche (discuss) 07:52, 16 June 2016 (UTC)[reply]
Thanks for pointing that out, I missed it.
Can we edit all entries to replace {{etyl|aaa|bbb}} by {{der|bbb|aaa}}?
Can we edit all entries to replace {{etyl|aaa|-}} by something and kill {{etyl}}?
As far as the current output goes, we could use {{cog|aaa}} since it returns a link to the Wikipedia article and does not categorize the entry. I don't suppose {{cog}} will ever categorize entries? Do we really need a template especially for "cognacy with terms in other languages that are not ancestors of the given term"? Isn't this just to avoid using {{cog}} when we should use {{inh}}? --Daniel Carrero (talk) 08:05, 16 June 2016 (UTC)[reply]
For the record, some entries also have "of {{etyl|de|en}} origin" ("of German origin"). --Daniel Carrero (talk) 09:03, 17 June 2016 (UTC)[reply]
Sure, but it's straightforward to change those to "of {{der|en|de}} origin}}". —Aɴɢʀ (talk) 09:19, 17 June 2016 (UTC)[reply]
What should the template do when the term is not provided, but is needed? {{m}} adds a request for the term if you don't provide it, {{der}} should also support this. —CodeCat 18:53, 18 June 2016 (UTC)[reply]

courir and the wrong past particple IPA edit

courir has the wrong pronunciation for the past participle, though it has the right spelling. Hillcrest98 (talk) 20:45, 15 June 2016 (UTC)[reply]

Also, ordonner has the pronunciation /ɔʁ.dɔ̃/ for ordonne instead of /ɔʁ.dɔn/. Redboywild (talk) 12:54, 17 June 2016 (UTC)[reply]
courir should be fixed. I'm not sure what the problem with ordonne is, it looks like it's happening in donner too. I suspect Module:fr-pron. KarikaSlayer (talk) 01:12, 20 June 2016 (UTC)[reply]
You're right, the problem is with Module:fr-pron. Just doing {{fr-IPA|donne}} gives the wrong result (IPA(key): /dɔn/). --WikiTiki89 15:34, 20 June 2016 (UTC)[reply]
The problem may be with this line: 
word = mw.ustring.gsub(word,'([mn][^aeiouàéèêâîôûäëïöü])e$','%1')
This deletes the silent e in mCe and nCe, but doesn't exclude mme, nne, mne.
Benwing2 (talk) 17:42, 20 June 2016 (UTC)[reply]
I added a new rule that looks like fixed it. KarikaSlayer (talk) 20:34, 20 June 2016 (UTC)[reply]
BTW this module needs a corresponding test module, like we have for Module:ru-pron (copy the machinery in Module:ru-pron/testcases to create Module:fr-pron/testcases). Benwing2 (talk) 17:46, 20 June 2016 (UTC)[reply]
There's a test page on {{fr-IPA}}. KarikaSlayer (talk) 20:34, 20 June 2016 (UTC)[reply]

Bengali Letter Template List edit

Would somebody help deal with Template:list:Bengali script letters/bn? --Lo Ximiendo (talk) 05:16, 16 June 2016 (UTC)[reply]

I don't know the letters, but I started the template. DTLHS (talk) 16:18, 18 June 2016 (UTC)[reply]

Unwanted blanks with substitution edit

If I do {{subst:gml-entry}}, every {{{|safesubst:}}}-clause (or maybe every if-clause) with an empty paramter in it gets turned into a blank space or blank line. Why is that and how can I fix it?Korn [kʰũːɘ̃n] (talk) 12:57, 18 June 2016 (UTC)[reply]

@Korn: I made some changes. Try it now. --WikiTiki89 15:23, 20 June 2016 (UTC)[reply]
Internal blank lines seem to get cut. This is the result. Korn [kʰũːɘ̃n] (talk) 16:26, 20 June 2016 (UTC)[reply]

3 small template fixes edit

  1. {{tr-verb}} should categorize into Category:Turkish lemmas.
  2. {{grc-IPA}} should categorize into Category:Ancient Greek terms with IPA pronunciation.
  3. {{hu-IPA}} needs to separate multiple pronunciations with pipes, not commas.

Can someone fix these please? Ultimateria (talk) 15:14, 18 June 2016 (UTC)[reply]

Done. DTLHS (talk) 16:11, 18 June 2016 (UTC)[reply]

Numismatics Context edit

Currently, adding the "numismatics" context to a word adds it to the appropriate daughter category of Category:Money. Shouldn't it instead automatically add the appropriate daughter category of Category:Coins, itself a subcategory of money? Would somebody well-versed in coding be so kind as to make that change? Purplebackpack89 17:35, 18 June 2016 (UTC)[reply]

  • @DTLHS @Daniel Carrero? Purplebackpack89 17:48, 18 June 2016 (UTC)[reply]
    • Words related to numismatics aren't coins, so it's not appropriate to subcategorise them there. —CodeCat 18:56, 18 June 2016 (UTC)[reply]
      • @CodeCat If it's not appropriate to categorize them as coins, it's even less appropriate to categorize them as money. Purplebackpack89 20:22, 18 June 2016 (UTC)[reply]
        • Money is a topical category, it contains terms and subcategories on the topic of money, not things that are money. Coins is a "set" category however, containing terms belonging in a particular set of things. The set of all coins in this case. —CodeCat 20:24, 18 June 2016 (UTC)[reply]
          • How are people supposed to tell the difference between topical categories and set categories? This is the first I've heard of such a distinction. —Aɴɢʀ (talk) 21:14, 18 June 2016 (UTC)[reply]
          • I can see how having the distinction between sets and topics is useful for structuring the category trees, but I don't think keeping them rigidly separate is always a good idea. Numismatics is indeed a topic, but it's a topic tied very closely to the set of things that are coins. There are a good number of these close connections between sets and topics that we need to be able be able to reflect: oink, pigtail, trotter, ham, bacon, lard, porcine, sty, pigpen, etc. aren't pigs, but they share them as a common theme. Having a separate topical category for pigs would increase category clutter in the entries and increase the risk of naming collisions between the two trees.
            Also, there are many cases where the density of terms is quite different between the two trees, so a topical category may not have enough members to merit subdivision, but each of those members is specific to a fully-populated subdivision of a set. In such cases, you either have very sparse topical categories or you lose information on which topics are connected to which sets. Chuck Entz (talk) 22:24, 18 June 2016 (UTC)[reply]
            • I don't agree with the assessment that coins is a different type of category than money; I think that's overthinking things. Almost all coins are money; coins is rightfully a subcategory of money. Not all money has to do with numismatics (paper money?). Therefore, it follows that an article tagged as numismatics should either a) generate the coin category, or b) generate no category at all. Also, @CodeCat, if your logic were followed to its logical conclusion, coins should not be a subcategory of money. (I disagree with doing this). Purplebackpack89 22:31, 18 June 2016 (UTC)[reply]
              • When we have, say Category:Colors, we don't want those to be diluted with all kinds of terms related to colours or colour theory or paint or anything like that. We'd want to keep it cleanly a category just for terms referring to colours. Just like we wouldn't want Category:Days of the week to have "weekday" or "weekend" or "long weekend" or any similar terms. —CodeCat 23:03, 18 June 2016 (UTC)[reply]
                • I'm not saying we should flood the set categories with topical terms- if there are enough to do that, a separate topical category is merited. It's just that most of the terms in Category:en:Money due to the label "numismatics" are, in fact, names for coins, and the number that aren't might not be enough to merit a separate numismatics category. Chuck Entz (talk) 23:37, 18 June 2016 (UTC)[reply]
                • That's essentially what I'm saying too. Purplebackpack89 00:14, 19 June 2016 (UTC)[reply]
                  • I certainly think that these terms belong in Category:Coins then. But perhaps they also belong in Category:Numismatics, if they have senses used primarily within that context? —CodeCat 00:16, 19 June 2016 (UTC)[reply]
                    • After looking through Category:en:Money, I think there are enough entries to merit creating Category:en:Numismatics, and that's without even touching w:Glossary of numismatics. One odd thing, though: numismatics can refer to not just coins, but also tokens, medals and paper currency, though by far the most usage treats it as just coins. I would favor the coin-only senses for the category, though a few of the senses tagged with the "numismatics" label seem to be based on the broader ones. Chuck Entz (talk) 01:14, 19 June 2016 (UTC)[reply]
                      • I started to create the category, but then I noticed that Category:Money and Category:Coins are currently both implemented as topical categories, and I'm not even sure we have a suitable place on the tree of sets to put a category for coins as a set, though I haven't looked through it, yet. Chuck Entz (talk) 01:27, 19 June 2016 (UTC)[reply]
                        • Sets are much harder to categorise as a tree than topics are, so you might as well just put it under the top-level category until someone has a better idea. —CodeCat 01:37, 19 June 2016 (UTC)[reply]
                          • Perhaps the solution to that is to allow sets to attach to nodes on the topical tree, and vice versa. If you still want to keep the trees separate, you could have some kind of placeholder nodes so you could navigate on either tree. Chuck Entz (talk) 02:02, 19 June 2016 (UTC)[reply]
                            • All categories are sets, and subcategorisation implies a subset. With topics, we have subtopics, and with sets, we have subsets. In principle, terms belonging to a particular set can also be relevant to a particular topic, so including a set as a subtopic just says "all terms belonging to this set are relevant to this topic". A good example would be Category:Planets of the Solar System as a subcategory of Category:Astronomy. The planets form a set, but they are also relevant to the topic of astronomy so the subcategorisation makes sense. But it doesn't work the other way around. A subcategory of a set forms a subset; all entries in a subcategory should be able to be placed in their parent (we may choose not to, but it it should be logically sensible). This principle applies across Wiktionary, not just with sets and topics. When you put Category:Numismatics as a subset of Category:Coins, this principle breaks down. "Coins" isn't a topic, but a set (by the nature of the name alone), but "Numismatics" is not a subset. At the same time, if you were to treat "Coins" as a topic somehow (anything related to coins?), then you run into the problem that the parent-child relationship is ambiguous. Is Coins a subdivision of Numismatics, or Numismatics a subdivision of Coins? Both topics are obviously related, but not in a way that makes subcategorisation sensible. Some other means is needed to link them. —CodeCat 20:54, 20 June 2016 (UTC)[reply]
          • (edit conflict) I just looked through the Category:All sets, and they've only been implemented for living things, celestial bodies, names, and a couple of other more minor sets. All of the categories we've been discussing except for Category:Pigs and Category:Days of the week (even those you gave as examples of sets) are currently implemented as topical categories. Making Category:Coins a set would require a massive reworking of our category trees that shouldn't be done without much broader discussions than this, so I propose that we make {{lb|xxx|Numismatics}} categorize to Category:Coins for now- we can always change it later, if we decide to. Chuck Entz (talk) 01:52, 19 June 2016 (UTC)[reply]
            • I agree with that. That was what I was trying to propose in the first place. Purplebackpack89 04:05, 19 June 2016 (UTC)[reply]
              • I disagree. Not all terms with the label "Numismatics" would necessarily belong in the "Coins" category. Such a label would be used to indicate that a term is used within the field of Numismatics, but nothing about the category "Coins" indicates this restricted usage or even anything about numismatics at all. Moreover, coins form a set, but not everything in the field of numismatics is a coin. However, coins are of relevance to the topic of numismatics, so Category:Coins ought to be a subcategory of Category:Numismatics, and the label should categorise only in the latter. If you want to place things in the Coins category, there should be a separate "coin" label (which may display "numismatics" in the entry), though I think that's a misuse of labels much the same way as the label "particle" is. Labels shouldn't be used to categorise members of a set, only to indicate usage within a field or topic. —CodeCat 21:02, 20 June 2016 (UTC)[reply]

Editor.js edit

Adding of glosses (trans-top) can only by using the latin script. Why does he not work with Cyrillic? -- DenisWasRight (talk) 23:29, 22 June 2016 (UTC)[reply]

It was designed for English Wiktionary, where glosses are generally in English. I'm sure making it script-agnostic would have added to the complexity. Chuck Entz (talk) 01:27, 23 June 2016 (UTC)[reply]
But If I want to use it for another dictionary with cyrillic script, where do I need to change that? -- DenisWasRight (talk) 09:50, 23 June 2016 (UTC)[reply]
Does nobody know that? -- DenisWasRight (talk) 11:45, 26 June 2016 (UTC)[reply]

{{ko-syllable-hangul}}, {{ko-defn-hangul}} and {{ko-IPA}} in monosyllabic Korean entries edit

@Wyang, TAKASUGI_Shinji, KoreanQuoter See 적 (jeok).

Should Korean syllables have this template? Will {{ko-IPA}} override it?

Also, I think {{ko-defn-hangul}} could also be made redundant if some model could decompose hangeul into jamo symbols automatically and display them in monosyllabic Korean entries. --Anatoli T. (обсудить/вклад) 08:10, 19 June 2016 (UTC)[reply]

I removed the romanisation support in this template and made it automatically generate the romanisation, like all the other Korean headword templates. Korean needs a Lua overhaul like what has been done for Japanese. Wyang (talk) 08:16, 19 June 2016 (UTC)[reply]
I agree with Wyang on this one. And I also agree with Anatoly's comment on {{ko-defn-hangul}}. But for monosyllabic entries, I really don't know. But I know that Korean leetspeak (on the internet) would be problematic since a lot of them are monosyllabic or lack vowels, but only consonants. --KoreanQuoter (talk) 12:40, 19 June 2016 (UTC)[reply]
ㅎㅇ, I don’t think we will ever use auto-romanization for Internet slangs made of jamos. Isn’t it simply impossible? — TAKASUGI Shinji (talk) 02:00, 21 June 2016 (UTC)[reply]
@Wyang, TAKASUGI_Shinji, KoreanQuoter Thanks for the answers. I think I didn't make myself very clear.
{{ko-syllable-hangul}} is often used on its own, without other templates. Now it only shows one romanisation - the Revised Romanisation. So we have a bit of information loss. See 견 (gyeon). It lacks {{ko-IPA}}, so you can't see other romanisations. Is it a big loss? Perhaps instances of {{ko-syllable-hangul}} should be replaced with {{ko-IPA}} with a correct heading?
{{ko-defn-hangul}} decompiles hangeul into jamo, which can be done automatically. No need to romanise jamo. --Anatoli T. (обсудить/вклад) 03:33, 21 June 2016 (UTC)[reply]
{{ko-IPA}} probably cannot be added in an automated fashion as it requires length information too. (As a note, this template was copied to the Korean Wiktionary and added automatically to all articles - so it looks like the length was disregarded in the process, e.g. ko:멀다.) Personally I don't really find that much value in having alternative romanisations for single syllables, but I'm fine with temporarily restoring the support for alternative romanisations as well. Wyang (talk) 03:46, 21 June 2016 (UTC)[reply]
I don't find much value in having alternative romanisations for single syllables either. --Anatoli T. (обсудить/вклад) 04:23, 21 June 2016 (UTC)[reply]
One example of Korean leetspeek would be ㅇㅇ. But it is often pronounced 이응이응 and simply 응 It doesn't look well-organized to me. --KoreanQuoter (talk) 12:06, 26 June 2016 (UTC)[reply]

Misleading watchlist message edit

When adding/removing a watchlist page, the message states that the associated discussion page will also be watched. This does not make sense when the page in question is already a discussion page, e.g. "Talk:starter and its discussion page have been added to (removed from) your watchlist". Equinox ◑ 23:06, 19 June 2016 (UTC)[reply]

#invoke edit

What should be the #invoke code for the autoTransliterate of bulgarian words. I used the {{#invoke:bg-translit|tr|{{{1|}}}}}, but didn't work that way. -- DenisWasRight (talk) 10:34, 20 June 2016 (UTC)[reply]

mw:Extension:Scribunto/Lua_reference_manual#Accessing_parameters_from_wikitextGiorgi Eufshi (talk) 11:11, 20 June 2016 (UTC)[reply]
You can't do that directly. Try {{xlit|bg|...}}. --WikiTiki89 15:26, 20 June 2016 (UTC)[reply]
Thanks, it helped a lot. I wish there was a chance for the IPA pronunciation. Many of the bulgarian words hasn't any. -- DenisWasRight (talk) 16:50, 20 June 2016 (UTC)[reply]

Inaccessible Redirect edit

I can't get to the redirect page of the diacritic of آ. I seek to repurpose the aforementioned redirect page so it can be added to Category:Arabic script characters. --Lo Ximiendo (talk) 06:17, 22 June 2016 (UTC)[reply]

Have you tried Special:WhatLinksHere/آ? Even if you can't click on the character itself, there's an edit link next to it. Chuck Entz (talk) 06:38, 22 June 2016 (UTC)[reply]
Vielen Dank! --Lo Ximiendo (talk) 06:44, 22 June 2016 (UTC)[reply]

Module:es-conj/data/-ar/errar/testcases - why are these tests failing? edit

As far as I can tell the output for the rows "érrate, yérrate", "érrese, yérrese", "érrense, yérrense" is identical to the expected output- why are these cases failing? DTLHS (talk) 05:41, 23 June 2016 (UTC)[reply]

Template:nb-noun-mu, Template:nn-noun-mu edit

These are potentially useful templates, and I would use them, but:

  • Neither template adds to the uncountable nouns categories automatically.
  • The Nynorsk template creates a lemma, but the Bokmål one doesn't.

The same could be true with {{nb-noun-cu}}, {{nb-noun-nu}}, {{nn-noun-fu}}, and {{nn-noun-nu}}, but I haven't checked those yet. DonnanZ (talk) 12:13, 24 June 2016 (UTC)[reply]

{{nn-noun-mu|bla}} just expands to {{nn-noun-unc|m|root=bla}}. So it seems rather redundant. —CodeCat 13:48, 24 June 2016 (UTC)[reply]
Um, what does that mean? DonnanZ (talk) 14:07, 24 June 2016 (UTC)[reply]
Obviously not. Is it needed? Most uncountable nouns have a definite singular, there's only a few that don't. DonnanZ (talk) 19:03, 25 June 2016 (UTC)[reply]
Well, as I pointed out, {{nn-noun-mu}} is implemented in terms of {{nn-noun-unc}}, so if there is an uncountable template for Nynorsk, why not for Bokmål? —CodeCat 19:28, 25 June 2016 (UTC)[reply]
Ah, is that what you meant. DonnanZ (talk) 19:54, 25 June 2016 (UTC)[reply]

I am currently working on the Bokmål uncountable templates. There may be redundancy, but the templates should work "normally" once I am done. --Njardarlogar (talk) 19:02, 25 June 2016 (UTC)[reply]

Okay, I think the two points have been addressed now. The template names themselves may still need som addressing. Possibly, there should just be one template for all nouns, or one for regular nouns (e.g. {{nn-noun-reg|mu}}) and one for irregular ones. Not sure what's best; but there's no haste, either way. --Njardarlogar (talk) 19:23, 25 June 2016 (UTC)[reply]
@Njardarlogar: Thanks for popping in and sorting things out. So you created lemmas as well, and Nynorsk should be OK too? Irregular uncountable nouns: I can think of kristendom. DonnanZ (talk) 19:54, 25 June 2016 (UTC)[reply]
Those things should be fixed now, yes. Uncountable nouns with more than one definite singular form could e.g. be handled with the templates for irregular nouns with something like a | unc = yes parameter (neither of those templates has been implemented in Scribunto/Lua, which they probably should be). --Njardarlogar (talk) 20:50, 25 June 2016 (UTC)[reply]
Working marvellously so far, cheers. DonnanZ (talk) 21:06, 25 June 2016 (UTC)[reply]
I've now implemented the |unc= parameter for both the Nynorsk and Bokmål templates for irregular nouns. I've also created {{nb-noun-comireg}}. --Njardarlogar (talk) 09:12, 26 June 2016 (UTC)[reply]
I will have to see how that works. And thanks a lot for the comireg template. DonnanZ (talk) 09:19, 26 June 2016 (UTC)[reply]

{{nb-verb-comireg}} is now also in place. --Njardarlogar (talk) 15:04, 26 June 2016 (UTC)[reply]

Why are there so many Norwegian headword templates anyway? Why can't there just be one, like for English and most other languages? I think too much is being put into the headword line, there should be inflection tables like we have for Swedish. —CodeCat 15:43, 26 June 2016 (UTC)[reply]
Don't forget that English and some other languages are much simpler when it somes to inflections for nouns. Yes, inflection tables are used in Danish and Swedish for nouns, and genitive forms are being included as well, which doesn't happen in Norwegian, thank goodness, although they do occur of course - all you have to do is remove the "s" at the end when looking it up. The Danish system that is used for nouns is quite messy and needs revision; it is one reason why I hardly bother contributing to Danish. I prefer the "at a glance" approach which is used in Norwegian, without having to click on a hidden table. Much better. DonnanZ (talk) 16:07, 26 June 2016 (UTC)[reply]

Translations sections won't expand edit

Is anyone else finding that the Translations tables won't expand? We've recently started having edit window problems on Wikisource, and I wonder if there is a problem here as well from the last update. --EncycloPetey (talk) 02:27, 25 June 2016 (UTC)[reply]

Yes it has been a problem for several months, without anyone being able to diagnose the cause. DTLHS (talk) 02:29, 25 June 2016 (UTC)[reply]

Term requests using der, inh, cog, bor edit

I'm thinking whether it's possible to kill all instances of {{etyl}} (either by itself or used with {{m}}) and use only {{der}}, {{inh}}, {{cog}}, {{bor}} in all entries.

See this: {{der|en|grc|tr=kardiakós}} = {{der|en|grc|tr=kardiakós}}

This works as a term request. The romanization of the Ancient Greek is known, not the term written in Greek letters.

But {{der|en|grc}} is not a term request. ({{der|en|grc}} = {{der|en|grc}})

Is there any way to make a term request like this without using {{m}}? If not, can we add this function: use "?" as the parameter 1 to make a term request: {{der|en|grc|?}} = {{etyl|grc|en}} {{m|grc}}

--Daniel Carrero (talk) 05:47, 25 June 2016 (UTC)[reply]

We can make it work that way, it's basically a matter of how we want {{der}} to behave in comparison with {{m}}. Personally, I think they should behave the same: with no term given, they should generate a request. That way there's less surprises and that makes them easier to learn for beginners. That leaves the question of how to indicate to {{der}} that no term request is wanted. —CodeCat 13:54, 25 June 2016 (UTC)[reply]
Maybe this:
{{der|en|grc}} = {{etyl|grc|en}} {{m|grc}} (request)
{{der|en|grc|-}} = {{etyl|grc|en}} (no request)
What do you think? --Daniel Carrero (talk) 13:59, 25 June 2016 (UTC)[reply]
That seems ok, as long as we're sure that those templates should never have to link to -. Additionally, when the language is a family, no term should be required, requested or even accepted. —CodeCat 14:03, 25 June 2016 (UTC)[reply]
To be fair, one could edit the entry -- or the entries of some emoticons like :-) and add "from -" in the etymology, but they would use {{m|mul|-}} anyway unless we have some reason to specify the language (Translingual).
Even if there are any rare exceptions that I didn't think of where one would want to see "from Translingual -", I think the benefit of having {{der|en|grc|-}} to disable requests outweighs them.
Plus, maybe {{der|en|mul|[[-]]}} with a bracketed link would be the best way to link specifically to the entry -, since we can already use bracketed links in the 1st parameter.
It seems that the underlying modules already recognize when the language is a family and generate a module error if one tries to add a term or a transliteration. I'm totally OK with it if the templates only generate term requests for languages. --Daniel Carrero (talk) 14:35, 25 June 2016 (UTC)[reply]
@CodeCat: Done and updated the documentation of the templates. --Daniel Carrero (talk) 07:15, 27 June 2016 (UTC)[reply]
See CAT:E. This is causing a module error with certain undefined "from" languages such as Iberian and Pre-Greek. These seem to be cases where there's no possibility of a term in the language, so the module can't find the information necessary to formulate a request. As long as you're trying to replace {{etyl}} with {{der}}, you have to allow for cases where there can't be a term. Chuck Entz (talk) 03:28, 28 June 2016 (UTC)[reply]
@Chuck Entz: Fixed. --Daniel Carrero (talk) 06:01, 28 June 2016 (UTC)[reply]
Here is my argument against. Cases where the term is intentionally omitted are supposedly permanent, while cases where the term is requested are supposedly temporary (until someone supplies the term). Permanent markup should not be uglier than temporary markup. --WikiTiki89 18:00, 28 June 2016 (UTC)[reply]
@Wikitiki89: Here is my counterargument. I believe that in {{der}} and others, usually you'll want to type the term or generate a term request, so cases where the term is intentionally omitted are special and rarer. (there are some exceptions: like, when the target is a family as in "from a Romance language", there can't be a term so it won't generate the [Term?] ever) We need some way to distinguish the usual case from the special, rarer case. Being 2 characters longer by the addition of "|-" is the best thing we have—we are already used to using the "-" in some places with supposedly permanent markup, like {{en-noun|-}}, {{en-adj|-}} and {{etyl|en|-}} (though I repeat that I intend to kill Template:etyl completely at some point if it's ok), not to mention that it needs the concious choice of the editor to override the term request. For these reasons, in my opinion it befits the cases where the term is intentionally omitted. --Daniel Carrero (talk) 03:22, 29 June 2016 (UTC)[reply]
Theoretically, all term requests will eventually be fulfilled and there will be zero of them, while the cases where the term is omitted will remain and thus be more common than term requests. But even in practice, I don't know the actual statistics at the moment, but I'm not convinced that term requests are more common than intentionally omitting a term. --WikiTiki89 20:19, 29 June 2016 (UTC)[reply]

Double translations edit

By which I mean something like this. Could someone detect them and remove the duplicates? I can help with removal if it's not on such a scale as to require a bot. —Μετάknowledgediscuss/deeds 20:45, 25 June 2016 (UTC)[reply]

@Metaknowledge User:DTLHS/cleanup/repeated translation languages DTLHS (talk) 22:00, 25 June 2016 (UTC)[reply]

iPad bug re Arabic characters edit

Discussion moved from Template talk:etyl#iPad_bug.

On my iPad, the mobile version of e.g. יעני (https://en.m.wiktionary.org/wiki/יעני) displays the Arabic origin correctly, i.e. يَعْنِي , whereas the desktop version (https://en.wiktionary.org/wiki/יעני) displays the isolated forms of the letters: يَ عْ نِ ي – who could fix this? Dan Pelleg (talk) 21:54, 26 June 2016 (UTC)[reply]

(To clarify after this discussion was moved here): the bug is in Template:etyl. Dan Pelleg (talk) 06:06, 27 June 2016 (UTC)[reply]
I don't know what exactly happened. Please provide some screenshot? I guess that the problem is about the iPad's font itself that does not support some formation. If it's true, nobody can fix this other than Apple.--Octahedron80 (talk) 06:10, 27 June 2016 (UTC)[reply]
(To clarify why I moved the discussion here:) The bug is not in Template:etyl, which does not display any Arabic text. - -sche (discuss) 06:28, 27 June 2016 (UTC)[reply]
I have this issue with my iPhone as well. It seems that simply that the Iranian Sans font does not render properly on iOS anymore (although it used to render perfectly fine a few months ago). Iranian Sans is the default Arabic font in MediaWiki:Common.css and is supplied as a web font (i.e. is downloaded as a resource from our servers and used even if it is not installed on the client device). However, in the mobile view, that part of the CSS does not make it in. --WikiTiki89 18:09, 27 June 2016 (UTC)[reply]
Sorry – just realised the problem is not with Template:etyl but with Template:m. And no – the mobile view works, it's the desktop view that doesn't. Does the template force different fonts for mobile and desktop views respectively? And if so, why should it force a font at all? And what kind of Arabic font wouldn't support letters' connected forms? Makes no sense to me. Should this discussion be moved to Template talk:mention? Here's the screenshot, I hope it helps. Dan Pelleg (talk) 23:07, 27 June 2016 (UTC)[reply]

 

I have the same problem with formatted (templatised) Arabic and Urdu on my iPhone. iPhone supports Arabic well, as you know, it's the templates' font, which doesn't work. Persian appears normal. --Anatoli T. (обсудить/вклад) 23:16, 27 June 2016 (UTC)[reply]
To clarify, the reason the desktop view does not render properly on iOS, is because it is using the Iranian Sans font and the Iranian Sans font does not render properly on iOS anymore. The actual mobile view works fine because the part of the CSS that specifies the Iranian Sans font is missing from the mobile view. Thus, the problem is with iOS's rendering of the Iranian Sans font, not with any of our templates. --WikiTiki89 16:41, 28 June 2016 (UTC)[reply]
Could the part of the CSS that specifies the Iranian Sans font be removed also from the desktop view specifications of the mention template? Dan Pelleg (talk) 23:06, 28 June 2016 (UTC)[reply]
The mention template has nothing to do with anything. The problem is anywhere where there is properly tagged Arabic script text. We can remove Iranian Sans from the CSS, but that would affect desktop users as well and it is a really good Arabic font and more importantly is available as a web font (which means that users who don't have any Arabic fonts on their computer can still use this font). --WikiTiki89 20:16, 29 June 2016 (UTC)[reply]
Ok the culprit is actually 'Arial Unicode MS', not 'Iranian Sans' – I checked on my iPad. Could Arial Unicode MS be removed from the font-family list for Arabic? (The iPad ignores the entire font list except for Arial Unicode MS, which has the letters render isolated even if it's last on the list.) Dan Pelleg (talk) 05:38, 30 June 2016 (UTC)[reply]

Cleaning up {{given name}} edit

The |diminutive= parameter inserts a raw link instead of a language link using {{m}} or whatever. If someone feels like fixing it that would be great. Benwing2 (talk) 06:31, 27 June 2016 (UTC)[reply]

Done. DTLHS (talk) 23:21, 27 June 2016 (UTC)[reply]
Thanks! Benwing2 (talk) 05:25, 28 June 2016 (UTC)[reply]

borrowing, borrowed, loan, loanword → bor edit

Suggestions:

  1. Replacing {{borrowing}}, {{borrowed}}, {{loan}}, {{loanword}} by {{bor}} in all entries.
  2. Using the format {{bor|fr|es|whatever}} in all entries, as opposed to {{bor|es|whatever|lang=fr}}. (that is, removing "lang=" from the template in all entries)

Rationale:

  • Looks nicer in comparison with {{der}}, {{inh}}, {{cog}}.

--Daniel Carrero (talk) 08:18, 27 June 2016 (UTC)[reply]

This is fine with me. Benwing2 (talk) 00:47, 29 June 2016 (UTC)[reply]
I have no objections. —CodeCat 00:48, 29 June 2016 (UTC)[reply]

[Term?] edit

I have a question about how using template coding like {{der}}, {{bor}}, and {{inh}} without a particular parent word within the bracket now generates [Term?]. Does the actual word itself matter (as in will it eventually be sorted into a category that shows that word being derived from the parent word?) I ask because sometimes I use these templates without it, such as when it comes from a set of words in an expression (of which only the last may be the desired lemma link, like with (mensis) maius), or a non-lemma or unattested term that doesn't warrant its own entry, or when it's certainly derived from a parent language word but we don't have an entry or attested term for it. I'm guessing the aforementioned example should be done like "From Latin (mensis) maius."? It doesn't look good now that [Term?] shows up in all these entries. Ugh, I don't want to go back and edit all of those... Oh well. Word dewd544 (talk) 01:46, 28 June 2016 (UTC)[reply]

That would be due to the recent edits to Module:etymology by @Daniel Carrero. DTLHS (talk) 01:49, 28 June 2016 (UTC)[reply]
Since "mensis maius" is intended as one single term, not two separate terms, they should be included together in one linking template. —CodeCat 01:51, 28 June 2016 (UTC)[reply]
I did the change that introduced [Term?] in {{der}}, {{bor}}, etc., per #Term requests using der, inh, cog, bor. Before that, I would usually add {{m|la}}, {{m|it}}, etc. (the template {{m}} without the word) to make term requests, when I found a derivation without the exact term. I find it a bit annoying that in many language sections of pizza, for example, some languages say "From Italian" instead of "From Italian pizza". --Daniel Carrero (talk) 01:53, 28 June 2016 (UTC)[reply]
But in most cases the term is right next to the template, so you have [Term?] followed by the term. I think this should be undone. DTLHS (talk) 01:56, 28 June 2016 (UTC)[reply]
I have a suggestion: Maybe a bot could replace all instances of {{der|xx|yy}} {{m|yy|term}} by {{der|xx|yy|term}}. (and the same with: {{bor}} and {{inh}})--Daniel Carrero (talk) 01:57, 28 June 2016 (UTC)[reply]
I hope you mean only in etymologies, because {{m}} has other uses. DCDuring TALK 02:29, 28 June 2016 (UTC)[reply]
No. You need to change the entries before you introduce this change. I won't run a bot before this is reverted. DTLHS (talk) 05:55, 28 June 2016 (UTC)[reply]
I oppose the new changes to these templates. [Term?] should not be displayed unless at least one part of the term or an empty parameter is provided. For example, {{inh|it|la}} should not display [Term?], but {{inh|it|la|}} and {{inh|it|la|t=foo}} should. --WikiTiki89 16:45, 28 June 2016 (UTC)[reply]
I disagree. These templates should behave the same as {{m}} with respect to requests. Why would they not? —CodeCat 17:15, 28 June 2016 (UTC)[reply]
So that you could do things like {{inh|it|la}} and then use a different template to display the term itself if it makes sense to do so. For example, I've found myself doing things like {{bor|en|he}} {{m/he|מסורת|dwv=מָסֹרֶת}} as at masoret. Another example is like at davanti: from the {{der|it|la}} locution {{m|la|[[dē]] [[ab]] [[ante]]}}. --WikiTiki89 17:27, 28 June 2016 (UTC)[reply]
You can still do that, you just need to provide an extra -. Not a big deal. It matters more that these templates work the same as {{m}} so that users don't run into unexpected surprises. Reducing the mental workload of learning our templates is important. —CodeCat 17:45, 28 June 2016 (UTC)[reply]
Ok, it's good that we have that as an option, so I'm not as opposed to it, although I still would prefer it the way it was. More importantly, you broke all the places that were already doing this and haven't fixed them. I recommend that we do a poll on whether we like this change, and if we do, then you need to go and fix all the places that didn't have a third argument before you made this change, if we don't then you need to undo it. --WikiTiki89 17:49, 28 June 2016 (UTC)[reply]
Yeah, I just now figured that out on my own (regarding the use of - to avoid [Term?] coming up). I suppose that's a fair compromise. There's still a lot of entries that need to be changed now, though. Actually, is there a way that these term requests could automatically generate a category, so it's known which ones need editing? Word dewd544 (talk) 18:23, 28 June 2016 (UTC)[reply]
I agree that these instances should have been fixed beforehand. It seems, though, that you missed the proposal and discussion that led to this change, as you weren't aware of the - option. Maybe you should go to the discussion above and read it? —CodeCat 17:51, 28 June 2016 (UTC)[reply]
Yes, I missed it. I just commented there. I still think we should do a poll in the WT:BP. --WikiTiki89 18:01, 28 June 2016 (UTC)[reply]
@Word dewd544: See Category:English term requests. --Daniel Carrero (talk) 22:48, 28 June 2016 (UTC)[reply]
@Wikitiki89: Do you want to create the poll? If you want to, ok with me. Bear in mind, some people are already using "-" to disable [Term?]. (or is it just @Word dewd544 for now?) If we just revert Module:etymology, the instances of "-" will become links to the entry -. (Linking to - was discussed in the previous discussion.) For the record, some people are fixing [Term?] in entries where needed: diff 1, diff 2, etc. I edited some of the entries in CAT:English term requests. (347 to go) Many of CAT:Ancient Greek term requests were requests I added willingly with a transliteration or translation, like in the entry empyreuma. --Daniel Carrero (talk) 00:09, 29 June 2016 (UTC)[reply]
The problem is that these templates are replacements for both {{etyl}} and {{m}}. The difference between these templates and {{m}} is that {{m}} is a single-purpose template that's only used for displaying and linking to terms. If the term is missing from {{m}}, it's quite logical to assume that one should be provided. {{etyl}}, on the other hand, is a single-purpose template that's only used for displaying names of and adding categories for languages. It has no provision for terms at all, so it's not logical to assume that the lack of a term in its replacement means that one should be provided.
There's simply no way to avoid increasing the cognitive load when converting to these templates: their dual purpose makes them inherently ambiguous when the term is missing. I think we should allow for this and only generate term requests when there are term-related parameters such as glosses and transliterations. Yes, that's different from the way {{m}} behaves, but {{m}} doesn't categorize, either, so it wouldn't really be the same, anyway (even with {{cog}}, we have to decide to use it rather than {{der}}, {{inh}}, etc.- which is an extra choice). Chuck Entz (talk) 03:03, 30 June 2016 (UTC)[reply]
The language parameters of these templates are already swapped compared to {{etyl}}, and {{der}} does not allow the first parameter (etyl's second) to be -. So the two are already clearly different in how their parameters work. They are very similar to {{m}}, however: {{cog}} takes exactly the same parameters as {{m}}, and {{der}} is the same as {{m}} except one extra positional parameter for the current language. When they are this similar, a small difference like this is jarring and confusing to users. Also consider that the difference with {{etyl}} is irrelevant, as they're intended to replace that template entirely, so they will not exist beside {{etyl}} in the long term and so the confusion is only in the short term, for users still used to {{etyl}}. {{m}} will continue to be used, however. —CodeCat 20:14, 2 July 2016 (UTC)[reply]

@Word dewd544 said above: "sometimes I use these templates without it, such as when it comes from a set of words in an expression (of which only the last may be the desired lemma link, like with (mensis) maius), or a non-lemma or unattested term that doesn't warrant its own entry, or when it's certainly derived from a parent language word but we don't have an entry or attested term for it."

I believe we would do it like this:

  • if it's a non-lemma:
    • {{der|en|la|foo|foos}} (to display "foos" and link to "foo")
  • unattested term that doesn't warrant its own entry:
    • {{der|en|la||foo}} or {{der|en|la||*foo}} (the 1st parameter is empty and so a link is not generated; you may want to use an asterisk)

--Daniel Carrero (talk) 23:05, 28 June 2016 (UTC)[reply]

@Wikitiki89 A little late, but I feel strongly, in regards to your suggestion above concerning empty parameters triggering [Term?], that there should never be a difference between an empty and a missing parameter. Benwing2 (talk) 00:46, 29 June 2016 (UTC)[reply]

I support this: there should never be a difference between an empty and a missing parameter. --Daniel Carrero (talk) 02:42, 29 June 2016 (UTC)[reply]
@Benwing2: I agree that it generally preferable to have an empty argument behave the same way as an omitted argument, but I don't think that there can't be exceptions to that rule. I think this is one case where such an exception makes sense. --WikiTiki89 20:21, 29 June 2016 (UTC)[reply]

Recent changes category edit

Why is recent changes categorized in Category:Undetermined language links? I didn't know it was even possible to categorize special pages. DTLHS (talk) 04:45, 28 June 2016 (UTC)[reply]

It was because WT:WE had a Undetermined link in the active list (livadus). I created the entry and removed the link. I don't know how to fix it so that RecentChanges stops being categorized like that. See Template:l. I populated Category:Undetermined language links in the first place, but it shouldn't categorize RecentChanges. --Daniel Carrero (talk) 05:01, 28 June 2016 (UTC)[reply]

Scots adverbs and nouns don't get added to cat:Scots lemmas? edit

Noticed this just now; for some reason {{sco-adv}} etc. do not add the lemmata to [[Category:Scottish lemmas]]. Case in point: groof, on one's groof. — Kleio (t · c) 00:34, 29 June 2016 (UTC)[reply]

Fixed. --Daniel Carrero (talk) 00:37, 29 June 2016 (UTC)[reply]
Gratias tibi ago. I fixed it for t:sco-noun as well based on how you did it. — Kleio (t · c) 00:45, 29 June 2016 (UTC)[reply]
These templates use quite horrible and outdated code, so if someone would like to bring them up to modern standards (using {{head}}) that would be great. —CodeCat 00:50, 29 June 2016 (UTC)[reply]
Scots in general seems a bit messy on Wiktionary, based on my very limited experience. For example, older stages of the language, like Middle Scots, have to be lumped in with regular Scots and an obsolete disclaimer as it stands right now. — Kleio (t · c) 00:55, 29 June 2016 (UTC)[reply]
I've altered {{sco-adj}}, {{sco-adv}}, and {{sco-noun}} to use {{head}}. I think I've done it correctly, but the behavior of these templates is fairly odd and there was no documentation. Could someone look these over? —JohnC5 04:46, 29 June 2016 (UTC)[reply]
Would be worth it to move Middle Scots terms like quhilk (with clearly obsolete orthography) to a new code gem-msc or something similar? KarikaSlayer (talk) 20:04, 2 July 2016 (UTC)[reply]

Entries for comparative forms of ölig (German) edit

Hi, could anyone with a script to generate pages take a look at ölig, especially the comparative forms? I just fixed the comparative forms to be öliger- instead of ölig-, and the öliger- pages don't exist yet. Wyverald (talk) 09:45, 29 June 2016 (UTC)[reply]

grc test tracking 1 edit

What is CAT:grc test tracking 1? It appears in a lot of Ancient Greek entries, e.g. φρήν. Benwing2 (talk) 20:19, 29 June 2016 (UTC)[reply]

Preload a page with output of a module? edit

Is it possible, when creating a new page, to preload the edit window with wikitext that has been output by a module? We have the preloadtext= URL parameter (though it seems undocumented by MediaWiki?) which WT:ACCEL currently uses, but that text is static and therefore needs to be provided by the JavaScript creating the URL. I had hoped that it would be possible to leave the actual entry generation to a module, rather than being built into JS (User:Conrad.Irwin/creationrules.js) where nobody but administrators can edit it. However, it seems that this would only be possible if the JS called the module itself through template expansion, which would be very slow for page loading I think. Does anyone have a better idea? —CodeCat 19:39, 30 June 2016 (UTC)[reply]

I don't have a better idea, yours is the best I could come up with. But where do you plan to use this? --WikiTiki89 19:44, 30 June 2016 (UTC)[reply]
Like I said, to take the entry generation part out of JS and into Wikispace so that it can be edited more easily and keep the URLs short. —CodeCat 20:36, 30 June 2016 (UTC)[reply]
I got that, but where? Like to replace the current WT:ACCEL system? --WikiTiki89 20:40, 30 June 2016 (UTC)[reply]
Maybe, depending on how much is possible. Ideally, a replacement system could even insert the content into an existing page, which is possible with a module: it can get the wikitext of a page and modify it, then present the modified content in the edit window. But it doesn't seem likely. —CodeCat 20:46, 30 June 2016 (UTC)[reply]
I just wanted to know what your intent was in asking this question. Also, I'm pretty sure JS can fetch the page text as well, and I'm not sure modules would be any faster at doing any of this. --WikiTiki89 20:50, 30 June 2016 (UTC)[reply]
It's not about it being faster, but about having it as a module rather than JS. Then people can edit it freely. It would also make it much easier to run a form creation bot, as it would just be able to call the module. —CodeCat 20:54, 30 June 2016 (UTC)[reply]
Oh, ok. --WikiTiki89 20:55, 30 June 2016 (UTC)[reply]
[3], it looks like you can pass in templates with arbitrary parameters (haven't tried it). DTLHS (talk) 19:47, 30 June 2016 (UTC)[reply]
But the template/module itself doesn't get substed before loading the page. What I'd like is for the module to be called, then the edit window filled in with whatever the module puts out. —CodeCat 20:36, 30 June 2016 (UTC)[reply]
I don't use JavaScript much (at all), but can you send a GET request for a corresponding template to your module like this: https://en.wiktionary.org/w/api.php?action=expandtemplates&text={{TEMPLATE-NAME}}&prop=wikitext, then copy the relevant part of the response to your URL? Edit: Did I suggest exactly what you said in your initial note? Apologies if I (probably) did. I don't think it would be slow except in cases where Lua is an inappropriate solution, for example, a form creation robot creating pages that require Lua to keep reloading data per-page which the robot could more easily cache locally for the whole run. I have found mere template expansion of simple computation-only modules to take hundreds of milliseconds. Edited again: If the main cost is indeed in module and dependency loading, as is the case in my expensive modules, would some kind of batch-call template that takes advantage of per-page loading semantics amortise the cost? I am not sure if to cache multiple pre-formed edit window URLs would be feasible or sensible in a browser environment. I know so little about JS I would probably delete this note if I did not fear you may have already read it. Isomorphyc (talk) 14:52, 1 July 2016 (UTC)[reply]
Retrieved from "https://en.wiktionary.org/w/index.php?title=Wiktionary:Grease_pit/2016/June&oldid=65118002"