Wiktionary:Grease pit/2019/August

New language appendix edit

I just created Appendix:Choctaw pronunciation, but the IPA(key) link on Choctaw entries (like hattak) doesn't link to it. I see in the IPA module it's supposed to check. How can this be updated? Kmack (talk) 22:25, 5 August 2019 (UTC)[reply]

It needs to be added to Module:IPA/data. DTLHS (talk) 22:28, 5 August 2019 (UTC)[reply]
Heck yeah! You rock! Kmack (talk) 22:32, 5 August 2019 (UTC)[reply]

Bot Request- Fix 2-Line Dates in Quote Templates edit

Over the past few weeks I've been seeing intermittent module errors rejecting date parameters in quote templates as invalid time stamps. These are all in a format consisting of a month and numeric day followed by a 4-digit year on the next line:

|date=August 7
2019

instead of

|date=August 7, 2019

These are all apparently the result of a poorly-executed bot run that fixed another problem years ago. I'm not sure how many are left, nor why they've been turning up a handful at a time instead of all at once. It seems, though, like finding and fixing them would be very easy for a bot. Would anyone be willing to take care of this? Thanks! Chuck Entz (talk) 04:18, 7 August 2019 (UTC)[reply]

All of them: fair crack of the whip, festy, blogish, Vectisian, tighty whities, tidy whities, spk, predrinks, bizarrer, finickity, kangaroo piss, m8, bullocks, veggo, cariad DTLHS (talk) 04:45, 7 August 2019 (UTC)[reply]
Thanks! I think I got all of them. It's nice to know that the tip of the iceberg I was stressing about was just a few ice cubes... Chuck Entz (talk) 05:13, 7 August 2019 (UTC)[reply]

Creating an entry de:verschönern edit

Why are my attempts to create verschönern flagged as harmful? I copied my lay-out into the sandbox; what´s wrong with it?--Akletos (talk) 11:36, 7 August 2019 (UTC)[reply]

Specifying the target RFD thread in "RFD" template edit

Presently there is a thread at Wiktionary:Requests_for_deletion/English titled "Tardis-like and spelling variations". Is there any way to link correctly to this from the RFD banner at Tardis-like? By default, it only links to a thread titled "Tardis-like", which does not exist. Mihia (talk) 17:22, 10 August 2019 (UTC)[reply]

@Mihia: There seems to be a |fragment= parameter, so you can do {{rfd|en|fragment=Tardis-like and spelling variations}}. I will note this in the documentation for {{rfd}}. — Eru·tuon 17:28, 10 August 2019 (UTC)[reply]
@Erutuon: Aha! Great, that works just fine. Thanks for your quick response. Mihia (talk) 17:34, 10 August 2019 (UTC)[reply]

Can someone please add the option for "mf" for |1= like the one in {{ca-adj}} for epicene adjectives? Ultimateria (talk) 18:48, 11 August 2019 (UTC)[reply]

@Ultimateria: It looks like {{oc-adj}} already responds to that option by displaying "m or f". But it isn't as intelligent as {{ca-adj}}; for instance, it doesn't display "masculine and feminine plural cadas", and if I remove |f=cada in cada, it displays feminine singular *cadaa and feminine plural *cadaas. {{ca-adj}} is handled by Module:ca-headword, which could be used as a starting point for a Module:oc-headword. It would be too much trouble to try to make {{oc-adj}} smarter without a module.. — Eru·tuon 22:56, 11 August 2019 (UTC)[reply]

By the way, does "epicene adjectives" make sense? I have only found Category:Catalan epicene adjectives named that way. An epicene is a masculine or feminine noun used for both males and females. Adjectives are variable or invariable in gender, it is just inflection not an implicit gender. --Vriullop (talk) 06:56, 13 August 2019 (UTC)[reply]

It doesn't make sense. This is just syncretism between the masculine and feminine forms. —Rua (mew) 17:06, 21 August 2019 (UTC)[reply]

Manual transliterations inside the Derived terms and Related terms templates edit

@Rua, if we do this, we lose the macrons over the u's in the transliteration. Is there any way to manually specify transliterations inside {{der3}} and {{rel3}} and their friends? —Mahāgaja · talk 20:18, 13 August 2019 (UTC)[reply]

In this particular case, we could decide to put macrons over the Gothic letters too. But I have no solution for the general case. I just find putting a whole linking template in place of a term very ugly, and Victor argued on the BP that nesting templates inside templates is often a bad idea. —Rua (mew) 21:27, 13 August 2019 (UTC)[reply]
Would it be possible to implement something along the lines of |tr2=mikildūþs, |tr6=mikilþūhts and so on? That doesn't work at the moment, but would it be possible and/or desirable? It would be good for languages like Persian without automatic transliteration too. —Mahāgaja · talk 10:07, 14 August 2019 (UTC)[reply]
That seems annoying since sometimes these tables can have hundreds of entries- there's no easy way to tell what the indexes are. DTLHS (talk) 18:51, 14 August 2019 (UTC)[reply]
@Rua In this case you should not remove the manual transliterations, because they supply more info. Benwing2 (talk) 22:23, 18 August 2019 (UTC)[reply]
Then I propose putting macrons on the Gothic, so that we don't have to mess with transliterations. —Rua (mew) 10:27, 19 August 2019 (UTC)[reply]

Module errors on proto-language category pages edit

@Erutuon and anyone else in the know: it appears that all category pages for proto-languages (e.g. CAT:Proto-Indo-European language, CAT:Proto-Celtic language) are currently throwing a module error: "Lua error in Module:family_tree/nested_data at line 23: language code table not recognized". Someone please fix this! Thanks. —Mahāgaja · talk 18:45, 14 August 2019 (UTC)[reply]

My mistake – it's not just the proto-language categories, it's all the language categories. —Mahāgaja · talk 19:08, 14 August 2019 (UTC)[reply]
Seems to be fixed now. —Mahāgaja · talk 20:41, 14 August 2019 (UTC)[reply]
The error was triggered because the parent value in this edit by Victar in Module:etymology languages/data was a table. That's been fixed, but I've made it so that Module:category tree/langcatboiler will simply not display a family tree if there's an error, and made Module:data consistency check check that parent values are strings. — Eru·tuon 22:42, 14 August 2019 (UTC)[reply]
Sorry about that. I accidentally had an array in the parent parameter for Old Azari. Module:data consistency check broke instead of displaying an error, so it took some trial and error to find the problem. --{{victar|talk}} 22:46, 14 August 2019 (UTC)[reply]
That was very bad, but has been fixed. This indicates that Module:data consistency check needs looking at to see if it's smart enough not to crash in response to other similar errors. — Eru·tuon 23:01, 14 August 2019 (UTC)[reply]
Thanks for finding and fixing it. It does seem like the module's response was out of all proportion to the triviality of the mistake. —Mahāgaja · talk 10:28, 15 August 2019 (UTC)[reply]

Turkish pluralia tantum and Module:tr-nouns edit

Turkish plurals end in -lar or -ler, and so do, consequently, the lemma forms of Turkish pluralia tantum. The declension module for Turkish nouns, Module:tr-nouns, adds another -lar or -ler to the lemma in the plural column, also for pluralia tantum. The result is that the declension of abanozgiller goes like abanozgillerler, abanozgillerleri, ..., instead of abanozgiller, abanozgilleri, .... I thought I could fix this by defining a local plsuffix which is normally set to -lar/-ler depending on the vowel harmony, but is set to void for a plurale tantum. However, that did not work; I got a Lua error: bad argument #1 to 'match' (string expected, got nil) at page abanozgiller. For now I have reverted my changes. The only matches I see in the code are with a variable stem that I did not touch. Can someone figure out what I did wrong? This is my first foray into tinkering with a module.  --Lambiam 21:55, 16 August 2019 (UTC)[reply]

@Lambiam: Your code almost worked; that particular error was caused ultimately by data.forms["nom|p"] = plsuffix where plsuffix was a string "" (a table was expected: data.forms["nom|p"] = {plsuffix}). The code below (data.lemma = (data.forms["nom|" .. (data.n or "s")])[1]) was indexing the string (equivalent to the code ""[1]), ang getting nil rather than a string as it expected. And local plsuffix = {stem .. "l" .. vowel.low .. "r"} would have triggered an error in non-plurale-tantum entries; a string was expected (local plsuffix = stem .. "l" .. vowel.low .. "r") so that it could be concatenated with the endings. Anyway, I got it to work with minimal changes to your code. — Eru·tuon 22:27, 16 August 2019 (UTC)[reply]

Incorrect error deleting templates edit

Every time I try to delete a template, I get an error about unclosed <includeonly> or similar tags. This has been going on for several weeks now. I recently hit it trying to delete {{la-noun form}}, which was a redirect with no doc page, and definitely didn't have an unclosed tag. This means some abuse filter is wrongly triggering. Benwing2 (talk) 22:22, 18 August 2019 (UTC)[reply]

sco-smi (Middle Scots) edit

How can I go about getting the language code sco-smi working ? It appears to be an etymology-only language code that works when referenced from Modern Scots (e.g. {{inh|sco|sco-smi|term}}, but not from a Middle Scots entry {{inh|sco-smi|sco-osc|term}}. Do we not count Middle Scots as a language ? Leasnam (talk) 21:34, 19 August 2019 (UTC)[reply]

I think we have discussed this before somewhere. DTLHS (talk) 21:36, 19 August 2019 (UTC)[reply]
At the moment, the "destination language" parameter in etymology templates (the first parameter in {{inh}}) only accepts the language codes that can have their own headers – regular languages as opposed to etymology languages. Middle Scots, as an etymology language, can't be used there. There wouldn't be much of a point in using etymology language codes there, given the way things are currently set up. At the moment there aren't categories for "x terms derived from y", and similar, where x is an etymology language (for instance, "Middle Scots terms derived from Old Scots"); x has to be a regular language. Only the "source language" name (the second parameter in {{inh}}) is displayed in the template output. — Eru·tuon 22:26, 19 August 2019 (UTC)[reply]
@Erutuon, whatever be the strait, since a Middle Scots entry has been created, we needs must find a solution for this. —Lbdñk (talk) 11:08, 20 August 2019 (UTC)[reply]
If a solution cannot be found, there is still always the alternate option of moving the entry to Scots. Leasnam (talk) 14:28, 20 August 2019 (UTC)[reply]
@Leasnam: Didna get... d'you mean merging the two entries into one? There is already a Scots entry, and I do not think we should forgo the Middle Scots entry, as Middle Scots is very much an independent language on its own. —Lbdñk (talk) 14:52, 20 August 2019 (UTC)[reply]
We could merge, or keep both and turn one into an Alternative form entry, labelling the senses specific to Middle Scots at the Scots page. That however is not what I am suggesting, as I wouldn't be opposed to seeing Middle Scots as a language...I'm just making sure we don't back ourselves into a sticky situation Leasnam (talk) 15:02, 20 August 2019 (UTC)[reply]
How different are Middle Scots and (modern?) Scots? If the two were consistently separated, how many entries would be duplicated? If this were done, which of the two headers would entries for Old Scots words (if there are any) be under? — Eru·tuon 15:46, 20 August 2019 (UTC)[reply]
I am not certain. It seems like splitting hairs to me. My concern would be insufficient support if we added Old/Early and Middle Scots. We barely keep up with the Scots entries as is. Leasnam (talk) 16:30, 20 August 2019 (UTC)[reply]
(edit conflict) Keeping Middle Scots words under the Scots header (Category:Middle Scots is empty, but there might be some matches in the search results for : insource:"Middle Scots", particularly those with "Middle Scots" in {{lb}}) solves that problem. — Eru·tuon 16:54, 20 August 2019 (UTC)[reply]
It is important to mark that Early Scots is but a northern Middle English dialect (having descended from the Northumbrian dialect of Old English), so we would never need Early Scots entries, and as such we do give many alternative dialectal variants in the Middle English entries. However, Middle Scots had both diverged markedly from Early Scots, and is quite different from Modern Scots (which has been heavily influenced by Modern English) in orthography etc., so we cannot do without Middle Scots. —Lbdñk (talk) 16:53, 20 August 2019 (UTC)[reply]
If Middle Scots orthography is significantly different (I'm clearly pretty ignorant about Scots), maybe many entries would not be duplicated. Middle Scots (sco-smi) can be promoted to a regular language, but this isn't the right place discuss it; WT:BP or WT:RFM is more appropriate. I've posted at Wiktionary:Beer parlour/2019/August § Promoting Middle Scots (sco-smi) to a full-fledged language. — Eru·tuon 17:02, 20 August 2019 (UTC)[reply]
Very good points, all. Thanks @Erutuon ! Leasnam (talk) 20:33, 20 August 2019 (UTC)[reply]
It's not a completely Middle Scots entry – the header says Middle Scots, but the language code in the headword template ({{sco-noun}}) says Scots. — Eru·tuon 15:44, 20 August 2019 (UTC)[reply]
Yes, that is because we don't have a working Middle Scots code to use (the whole point of this discussion :) Leasnam (talk) 16:29, 20 August 2019 (UTC)[reply]

Scots noun template: unknown plural edit

It would be good if sco-noun worked with an unknown plural, like {{en-noun|?}}. This is useful when you don't know whether a word is uncountable or countable (or, I suppose, when you know it's countable but aren't sure of the plural, but that's not too likely with Scots). Equinox 02:07, 20 August 2019 (UTC)[reply]

WT:RFVN cat + Thai script edit

The "Tagged RFVs" category ({{request category page list}}) near the top of WT:RFVN is using Thai script (e.g. "Requests for verification in Afrikaans entries (1 น)"). Can't figure out why; the template is fine in its other transclusions, and the category itself is good too. Julia 16:18, 21 August 2019 (UTC)[reply]

@Julia: I'm seeing English abbreviations: "Requests for verification in Afrikaans entries (0 c, 1 e)". — Eru·tuon 16:21, 21 August 2019 (UTC)[reply]
@Erutuon: It fixed itself for me right after I posted, so I guess that's solved. Julia 16:25, 21 August 2019 (UTC)[reply]
Strange. This is controlled by "Internationalisation" in the "User profile" section of "Preferences"; it's as if it temporarily switched to Thai. — Eru·tuon 16:32, 21 August 2019 (UTC)[reply]

Regex help needed edit

Please see Special:AbuseFilter/32. My new section about "given-names vandal". It's supposed to block edits like this one. [1] I don't think it's right, though I find the abuse filter testing tools hard to use so maybe I just wasn't searching recent edits properly. Please check and fix if you can. This vandal has persisted for many years and is clearly sick in the head. Equinox 18:21, 22 August 2019 (UTC)[reply]

Small bot-jobs edit

Here is a small bot task that would be nice if someone could run a bot to do.

1.1 Replacing ===Enclitic=== and ===Proclitic=== with ===Pronoun=== in all members of the following categories: https://en.wiktionary.org/wiki/Category:Kambera_enclitics and https://en.wiktionary.org/wiki/Category:Kambera_proclitics
1.2 Replacing {{head|xbr|enclitic}} and {{head|xbr|proclitic}} with {{head|xbr|pronoun}}.
1.3 Adding the category tag Category:Kambera pronominal clitics to all pages
2.1 Replacing ===Enclitic=== with ===Pronoun=== in all members of the following category https://en.wiktionary.org/wiki/Category:Lamboya_enclitics
2.2 Replacing {{head|lmy|enclitic}} with {{head|lmy|pronoun}}.
2.3 Adding the category tag Category:Lamboya pronominal clitics to all pages

Thanks in advance! Allahverdi Verdizade (talk) 05:56, 23 August 2019 (UTC)[reply]

@Allahverdi Verdizade: I did the second job with JavaScript Wiki Browser. — Eru·tuon 14:35, 25 August 2019 (UTC)[reply]
@Erutuon: thanks a billion! Allahverdi Verdizade (talk) 16:17, 25 August 2019 (UTC)[reply]
@Allahverdi Verdizade Are these all done? Can you strike out the ones that are done? Thanks! Benwing2 (talk) 21:56, 22 September 2019 (UTC)[reply]

Template:audio/styles.css edit

Hello. I created local wiki on my PC via xampp. When I want create Template:audio/styles.css some problem occur. I only added wfLoadExtension( 'TemplateStyles' ); code to LocalSettings.php. I also can't change content for that page from css to sanitized css. I think I need some additional configuration for TemplateStyles extension on LocalSettings.php. --Azpolyglot85 (talk) 09:29, 23 August 2019 (UTC)[reply]

@Azpolyglot85: I think hardly any of us Wiktionary editors have any experience with the PHP backend for Wiktionary, because the Wikimedia folks handle it. You might try posting about this on Extension talk:TemplateStyles on MediaWiki wiki. — Eru·tuon 16:11, 23 August 2019 (UTC)[reply]

interwiki to Beer edit

From Wiktionary:Beer parlour I go to the greek room from left-hand menu, as stated at wikidata. But when I am at the greek room and click the English from ITS menu, I get lettuce. Is it vandalism? or did the Beer parlour turn vegetarian? sarri.greek (talk) 16:22, 25 August 2019 (UTC)[reply]

Improvement for Module:nyms edit

Usage of the templates {{synonyms}}, {{antonyms}} below each definition line is much preferred over the older format using ====Synonyms==== or ====Antonyms===== which require separate headers.

I would like to suggest the following improvements to Module:nyms as it still lacks some functionality:

  1. Italics for transliteration of terms into Latin script. The current output is not italicized.
    e.g. {{syn|ja|確実|tr=kakujitsu}}Synonym: 確実 (kakujitsu)
  2. A |gloss= parameter to specify the meaning of {{antonyms}}, {{hyponyms}}, {{hypernyms}}, etc.
    e.g. # [[big]]
      #: {{ant|ja|小さい|tr=chiisai|gloss=small}}
  3. |alt=, |alt2= parameter and |altsc= parameter for languages such as Serbo-Croatian or Malay which use multiple writing systems in different scripts.
    eg. # [[seldom]]
     #: {{ant|ms|altsc=ms-Arab|selalu|alt1=سلالو|sentiasa|alt2=سنتياس|gloss=always}}

I hope User:Rua (creator of the module) or somebody else would be able to look into this matter. KevinUp (talk) 21:35, 25 August 2019 (UTC)[reply]

Numbered alt parameters are already used for link text (and that shouldn't be changed because it's a widespread convention), so the form in another script would need a different parameter name. It might be fine to use numbered altsc parameters, because at least in most cases script can be automatically detected, certainly in the example you gave: {{ant|ms|selalu|altsc1=سلالو|sentiasa|altsc2=سنتياس}}. This would only allow one alternative script. — Eru·tuon 22:57, 25 August 2019 (UTC)[reply]
I don't think alternative forms should be listed under synonyms. Otherwise it would become ridiculous in some cases. The synonyms should link to the main lemma only, which should list alternative forms. Likewise, glosses are unnecessary, because they are synonyms and antonyms, and moreover they clutter up the display. It's supposed to be a simple list that fits on one line, otherwise we might as well use a section for it. —Rua (mew) 08:35, 26 August 2019 (UTC)[reply]
Regarding #1, according to User:Surjection, "it uses require("Module:links").full_link which should use italic, so this would probably need more changes in the language data, like some kind of flag whether to italicize transliterations" (quoted verbatim).
Regarding #2, the |gloss= parameter can be used in non-English entries such as 偶然#Japanese because in some cases, word X and word Y are considered antonyms, but the meanings of X and Y can be broken down to more specific meanings in English.
Regarding #3, I am requesting this mainly for Malay entries, because the main form is in Latin script (compare merdeka and مرديک). I noticed some irregularities in this edit, where the synonyms header was eliminated. I think the suggestion by Erutuon to use altsc1=, altsc2= is a good one.
By the way, these improvements are for non-English entries, so please consider them. KevinUp (talk) 10:22, 26 August 2019 (UTC)[reply]
Italics are for mentions within running English text. These are not mentions, since they occur alone in a list, just like in the old Synonyms section. So they should not be italic. I maintain that glosses should not be added to -nyms, because that's not what the list is for. Glosses would make the list extremely long and hard to read, when all we're trying to do is list -nyms, not their meanings. For meanings, we have the actual entries. The same applies to alternative forms. We should not be in the habit of trying to duplicate part of the function of entries inside lists on other entries. Such lists should not define the term, give its inflection, pronunciation, alternative forms etc. Their purpose is to link to the entries, not replace them. —Rua (mew) 10:48, 26 August 2019 (UTC)[reply]

standardChars edit

Will standardChars in Module:languages recognize combining diacritics as part of the preceding character? Or will it treat the diacritic as its own character?

I'd like to add standardChars for Mecayapan Nahuatl so that a̱e̱i̱o̱ are recognized as standard characters and other diacritic combinations are not, but I suspect that it will treat the diacritic as a character on its own, and thus allow it anywhere.

Likewise, is it possible to get standardChars to recognize a digraph as a standard character, so that the same letters outside of the character are recognized as nonstandard? Mecayapan Nahuatl use the digraph "tz" but does not normally use "z" on its own. --Lvovmauro (talk) 09:19, 26 August 2019 (UTC)[reply]

Currently, standardChars can only match a set of Unicode code points and of ranges of code points, not of sequences of code points. So it can check for the code point COMBINING MACRON BELOW but not that this code point only appears after a, e, i, or o; similarly it cannot check that z only appears after t.
But what do you want to achieve with this? At the moment, the only way standardChars is used is to populate categories like Category:English terms by their individual characters. With your proposed additions, any Mecayapan Nahuatl entries whose title contains a z not in the tz digraph would be added to Category:Mecayapan Nahuatl terms spelled with z and any whose title contains COMBINING MACRON BELOW not after a, e, i, or o would be added to Category:Mecayapan Nahuatl terms spelled with ̱. I could be wrong, but it sounds to me like a situation where you'd want to find Mecayapan Nahuatl words that are using z and COMBINING MACRON BELOW incorrectly and mark them for cleanup, which can be done in Module:script utilities. — Eru·tuon 17:01, 26 August 2019 (UTC)[reply]

New reference template for Swedish edit

Hi, today I created Template:R:tre linking to svenska.se as a replacement for Template:R:SAOL which links to an older verbatim copy of SAOL only, Template:R:SO and Template:R:SAOB online.

Template:R:tre links to all three of the dictionaries of Svenska Akademin and gives a nice overview. I believe it is better to have one good template for the new website than these 3 old templates that link to resources that might disappear anytime now that Svenska Akademin has created and is pushing svenska.se.

I suggest that we use a robot to switch from the old templates to the new template as all words found in SAOL, SO and SAOB are present in svenska.se. It is a much better website and I see no reasons to hold back. WDYT?--So9q (talk) 15:44, 26 August 2019 (UTC)[reply]

@So9q: Good thought, although it would be hard to pinpoint from which of the three sources the info has been gathered, and I find that quite problematic.Jonteemil (talk) 16:41, 26 August 2019 (UTC)[reply]
@So9q: I agree with @Jonteemil that it is quite problematic to leave it ambiguous which is the source, and I think it would be better to indicate that and to have a separate reference to each dictionary if more than one of them is referenced. This could still be achieved with a single template, however, e.g. {{R:svenska.se|[saol/so/saob]|akademi}} could give a reference to a different dictionary based on the parameter and change the link accordingly. Their URL scheme is quite simple: https://svenska.se/saob/?sok=akademi, where the middle part can be changed to saol or so. A bot can then convert the existing references to SAOB to the new template without losing any information. – Krun (talk) 11:00, 27 August 2019 (UTC)[reply]
I agree with you both and like your solution, Krun. :) I will change the template to reflect your suggestion and report back here when I'm done.--So9q (talk) 06:00, 28 August 2019 (UTC)[reply]
Done, example use. It accepts one parameter currently, and works with the form @Krun wrote above. Are we ready to ask for a robot to make the change?--So9q (talk) 13:43, 28 August 2019 (UTC)[reply]
I just fixed it so it doesn't display a module error on the template page. Please verify that I didn't break anything. Chuck Entz (talk) 13:57, 28 August 2019 (UTC)[reply]
It works fine. Thanks :)--So9q (talk) 16:22, 28 August 2019 (UTC)[reply]
Looks good. – Krun (talk) 09:08, 29 August 2019 (UTC)[reply]
I will proceed with advertising a bot job to make the change.--So9q (talk) 11:49, 29 August 2019 (UTC)[reply]

Conjugation template help edit

I would like to rewrite {{oc-conj-ar}} to allow for verbs ending in -car, -gar, and -jar without a separate template like {{gl-conj-car}} (which is poorly named because it serves other verb endings). Isn't there a way to have spelling changes for these endings controlled by a |2= parameter in the conjugation template, e.g. {{oc-conj-ar|tanc|tanqu}} for tancar, while allowing regular verbs like cansar to still be {{oc-conj-ar|cans}} and infer that the |2= parameter is the same as |1= if |2= isn't explicit? Ultimateria (talk) 06:02, 28 August 2019 (UTC)[reply]

@Ultimateria: Use {{{2|{{{1}}}}}} for the second root. It defaults to |1= if |2= doesn't exist. --Vriullop (talk) 13:02, 28 August 2019 (UTC)[reply]
That's just what I needed, thank you! Ultimateria (talk) 15:44, 28 August 2019 (UTC)[reply]
Would {{{4|{{{3|{{{2|{{{1}}}}}}}}}}}} be terribly inefficient? There are two overlapping spelling changes that I'd like to incorporate into the template if possible. Ultimateria (talk) 16:48, 28 August 2019 (UTC)[reply]
It's fine. It's Lua memory rather than complex template syntax that causes problems for us. — Eru·tuon 16:51, 28 August 2019 (UTC)[reply]
Super pretty. Reminds me of when I had to write pure SQL to pick the postcode out of a string like '10 High Street|Blahtown|County|X1 1AA' and it ended up looking like SUBSTRING(CHARINDEX(SUBSTRING(CHARINDEX(SUBSTRING(CHARINDEX(SUBSTRING(CHARINDEX(... Equinox 03:36, 30 August 2019 (UTC)[reply]

Suggestion: Make it easier to add translations where there is none like sv:wikipedia edit

Hi, I really like the JS-script on sv:wiktionary that look like this Lägg till översättningar... -> Add translations... and enables the reader to easily begin adding translations using the translation-js-ui on articles with no translations yet. See e.g. sv:r%C3%A4kneh%C3%A4fte.

I suggest we add that here too. Any reactions?--So9q (talk) 16:20, 28 August 2019 (UTC)[reply]

List of articles with nb-translation but no da-translation edit

Hi, I would like to have a list of articles with nb-translations but lacking da-translations. These languages are very similar and with such a list I would work my way through and add danish translations.

I have knowledge of parsing with PEG and Guile from before but I thought to ask here before I dive into a dumpfile in case anyone already have a tool or easy solution to the problem. --So9q (talk) 19:14, 28 August 2019 (UTC)[reply]

You can start here: Category:Norwegian Bokmål lemmas and Category:Norwegian Nynorsk lemmas. DonnanZ (talk) 19:35, 28 August 2019 (UTC)[reply]
Here is a list of titles that contain at least one nb translation but no da translation (in {{t}} or {{t+}}). They are not necessarily translations of the same sense, or even in the same Translations section. (I generated it from files of template instances from the latest dump with no context besides the page name.) — Eru·tuon 00:05, 29 August 2019 (UTC)[reply]
Big thanks @Erutuon, this was exactly what I wanted :)--So9q (talk) 11:55, 29 August 2019 (UTC)[reply]
You are not going to find SoP terms in that list which qualify for entries in Norwegian or Danish but are scorned in English. E.g. festningsby (= fortified town) just done. DonnanZ (talk) 12:03, 29 August 2019 (UTC)[reply]
Great! I copied the list to User:So9q/nb translations with no da because I'm going to use the sandbox page for something else eventually. — Eru·tuon 16:05, 29 August 2019 (UTC)[reply]
@Erutuon, can you please share the script or program you used to create this list?--So9q (talk) 08:20, 31 August 2019 (UTC)[reply]
@So9q: Well, it's a somewhat complicated process, involving Rust and C and Lua 5.3. I generated the list with a Lua script using bindings to a CBOR-parsing library written in C, from CBOR files containing all instances of various templates (including {{t}} and {{t+}}) generated by a Rust program from the latest pages-articles.xml file from the dump. But I haven't optimized the process to make it easy to set up.
The Rust program is essential; without it, it's painfully slow to search through template instances. But the data format and the scripting language could be changed; I could have the program output JSON or rewrite the script in Python, which is easier to install and get libraries for. — Eru·tuon 20:04, 31 August 2019 (UTC)[reply]
Hi again, could you create a similar list for sv (with da or nb or no translations)? What about a list for sv, nb, no, da where the article is a noun and the gender is missing from the translation? :p You are free to go ahead and put the lists in my userspace if you succed.--So9q (talk) 16:30, 5 September 2019 (UTC)[reply]
Okay, see User:So9q/da nb no without sv; the other request requires more work. I haven't done anything that requires checking which header a template is under. — Eru·tuon 17:45, 5 September 2019 (UTC)[reply]
Thanks! Maybe in pseudocode we could do something like
until(==regex(*)==) {
if(
and((translation-entry)
or((lang=x)(lang=y)(lang=z)) {
do check-gender}
Doable? It does not have to distinguish between the individual translations. You are welcome to post the code snippet here or on a suitable page for me to see. :)--So9q (talk) 05:05, 6 September 2019 (UTC)[reply]
Probably it could be done with regex or Lua patterns somehow, but I made a Rust program to parse the dump and run a Lua function, which it gives the templates in a section and the headers over them: function(templates, headers, title) return whether_to_continue end. So then I had a Lua function check that the list of headers contains "English" and "Noun" and "Translations" and then look through the translation templates and print any matching templates with their titles. I posted the titles at User:So9q/translations without gender. — Eru·tuon 04:02, 7 September 2019 (UTC)[reply]
Wow that was fast! I really appreciate this. Thanks. Actually I don't know Norwegian well enough to add genders, could you split this list into one for each language, so I can ask a native to look through it?--So9q (talk) 07:43, 7 September 2019 (UTC)[reply]
Done. I put the separated lists on subpages. — Eru·tuon 08:46, 7 September 2019 (UTC)[reply]

how to upload a tabbed list? edit

I'm sure the how-to is around here somewhere, but I'm not seeing it. I've been asked to help with Khoekhoegowab ("Nama") for a curriculum project in Namibia. To start with, we have a short (thousand entry) dictionary reformated as a spreadsheet. I don't think AWB will handle this directly -- at least at my level of knowledge, it would take multiple passes for the formatting, IPA, inflections and categories (e.g. sort the list by part of speech, then customize AWB to run the nouns, verbs, etc. separately, plus an additional run to convert the non-tonic orthography and tone category into IPA), and even then I'd have to copy-paste the definitions manually. How could I automate this if, say, col A is the lemma, B the English definition?

Thanks, kwami (talk) 02:51, 29 August 2019 (UTC)[reply]

The simplest way is to have col C with a formula that assembles the contents of col A and col B into the correct format for an entry (including Char() functions for the newline characters), then to copy col C into col D as values only. That means each cell would have the contents of one entry. If you need it in a text file, it should be pretty simple to select the cells in col D that have the data, copy, then paste into the text file. There are probably more efficient and elegant ways, but this can be done quickly without any special software if you know how to do formulas with text in Excel. Chuck Entz (talk) 03:19, 29 August 2019 (UTC)[reply]

Thanks, @Chuck Entz: I'm fine with Excel formulas, but I seem to be missing something very very basic here. How do I get any of the data into Wiktionary? My approach would be to paste the list of lemmas into the article list in AWB, then code it to append lines to each (newly created) article that give it its structure, with the header and IPA based on %%title%%. I'd then do another run to convert %%title%% to the form I want for the declination templates to generate the proper forms, etc. I'd have to do separate runs for each part of speech. But, apart from me pasting the lemmas in the article list, none of that is actually taking data from the DB. I have no idea at all how to approach that. kwami (talk) 08:22, 29 August 2019 (UTC)[reply]

I never tried to do anything as fancy as creating new entries from a file with AWB (or JWB). I wouldn't have thought it possible. It sounds more like a bot task. — Eru·tuon 03:31, 30 August 2019 (UTC)[reply]

Yeah, I don't know if it's possible with AWB either. Is it possible for an editor to mimic how a bot would do this, except of course for manually saving each edit? For AWB, all I can think of is pasting in a chunk of the DB, then deleting all lines that don't start with the page title. But that would be awfully clunky, even if I could get it to work. I was hoping there would be some other approach to use a DB to control the edit. kwami (talk) 05:48, 30 August 2019 (UTC)[reply]

@Kwamikagami: Well, if you have experience with Python, perhaps you could use Pywikibot to make a non-bot script. I made scripts (for semi-automatically correcting bad characters in link templates for languages that use Cyrillic and Arabic) that I decided didn't require a bot account because they show me the changes and prompt me to manually save the edit by typing into the command line. My interpretation of the bot policy was that it's okay to use a script if you have to check and approve each edit. So far nobody has objected. It helps that my edits haven't had problems (or I've corrected them). — Eru·tuon 06:44, 30 August 2019 (UTC)[reply]

Thanks. Yes, that's my understanding as well. I never learned Python, but that's something to look into. There might be something in the script library. kwami (talk) 07:06, 30 August 2019 (UTC)[reply]

Ah, yes. It looks like pagefromfile.py will work. Thanks for the tip! I'm not sure when the project will get going, but I think now I should be able to manage it. kwami (talk) 07:18, 30 August 2019 (UTC)[reply]

3 small bot jobs edit

  1. Replace {{R:SAOL with {{R:svenska.se|saol
  2. Replace {{R:SO with {{R:svenska.se|so
  3. Replace "{{R:SAOB online" with {{R:svenska.se|saob

Thanks in advance!--So9q (talk) 11:54, 29 August 2019 (UTC)[reply]

@So9q Should all be done. I took the liberty of removing the 2nd param from the various templates as I converted them; this param is no longer used. Benwing2 (talk) 08:45, 22 September 2019 (UTC)[reply]
@benwing2: I don't understand. Could you give an example of what you removed? Passing a second param in svenska.se is needed sometimes.--So9q (talk) 07:34, 28 September 2019 (UTC)[reply]

Template:head doesn't add Category:(lang) lemmas when "personal pronoun" is the part of speech edit

When I put "personal pronoun" as the part of speech using Template:head, it doesn't add Category:(lang) lemmas to the page as usual. How could I fix it? --YukaSylvie (talk) 04:15, 31 August 2019 (UTC)[reply]

Use "pronoun" instead. We don't use "personal pronoun" as the primary part of speech. The template does allow secondary parts of speech, so you can put |cat2=personal pronouns in there, too. Chuck Entz (talk) 04:43, 31 August 2019 (UTC)[reply]

There are several thousand audio files here that can be imported. I know the naming convention for files isn't 100% consistent, but it's at least the username and language are. Does anyone with a bot volunteer to do this? Ultimateria (talk) 04:29, 31 August 2019 (UTC)[reply]

Making TranslationAdder.js work on mobile browsers edit

Hi, I want to hear if there is a need/support for adding this feature? I for one would like to see the mobile interface improved and this is one of several changes that I have in mind. WDYT?--So9q (talk) 18:39, 31 August 2019 (UTC)[reply]

I now got it to work if anyone is interested in trying it out add this to your common.js:
//needed additionally on mobile view
 importScript( 'MediaWiki:Gadget-StorageUtils.js' );
 importScript( 'MediaWiki:Gadget-LegacyScriptsNewNode.js' ); //this is legacy and should be substituted for jQuery or ECMA5
 importScript( 'MediaWiki:Gadget-DefSideBoxes.js' );
 importScript( 'MediaWiki:Gadget-Editor.js' );
 //needed on desktop view
 importScript( 'MediaWiki:Gadget-TranslationAdder-Data.js' );
 importScript( 'MediaWiki:Gadget-LanguageUtils.js' );
 importScript( 'MediaWiki:Gadget-TranslationAdder.js' );
--So9q (talk) 20:17, 31 August 2019 (UTC)[reply]
I switched to the monobook skin in my preferences and found that to work better than the default on mobile.--So9q (talk) 13:05, 1 September 2019 (UTC)[reply]
One thing that needs to be considered carefully: how do we prevent mobile users from accidentally adding translations via hitting random characters?
We've had a flood of accidental edits in the past few years from new mobile IP users in areas where many can't read English. We've had to set up abuse filters to deal with creation of nonsense entries by these mobile users due to accidental use of our new-entry creators or accidental clicking of redlinks after failed searches.
It's real hard getting translations patrolled as it is, due to the lack of patrollers who know many of the languages. I don't want to have translations that consist of search terms or other random nonsense to add to the workload. Chuck Entz (talk) 20:57, 31 August 2019 (UTC)[reply]
Interesting. I was not aware that this was/is a problem at all. I think we should make it easy for good people to edit how they want, and keep the defaults so that we do not get loads of crap edits.--So9q (talk) 13:05, 1 September 2019 (UTC)[reply]

Solved: Show hidden translations by default edit

Hi, does anyone here know what to add to my common.js to make the translations be shown by default? I tried adding this to my common.css but to no avail:

#NavContent .translations {
	display:block}

I presume it did not work because it is overwritten by some JS onload. So I tried running this in the console:

function unhide() {
	var elems = document.getElementsByClassName('NavContent');
	for (var i=0;i<elems.length;i+=1){
	  elems[i].style.display = 'block';
	}
}
document.onload = unhide();

It works if I run unhide() from the console but not on page load. Any ideas?--So9q (talk) 21:27, 31 August 2019 (UTC)[reply]

@So9q: There's a "Visibility" menu on the sidebar. On a page with translations, you can click "Show translations" and the translations will always be expanded. — Eru·tuon 21:32, 31 August 2019 (UTC)[reply]
Fantastic! Thanks for helping me solve this also.--So9q (talk) 04:11, 1 September 2019 (UTC)[reply]