Wiktionary:Grease pit/2017/August

Alternatives for Template:reconstructed?[edit]

Is there any way that we could automatically show the message above all pages in the Reconstruction namespace? Then we wouldn't need to put {{reconstructed}} on all the pages manually anymore. —CodeCa t 10:05, 1 August 2017 (UTC)[reply]

(Previous discussion: Wiktionary:Grease pit/2016/March#Template:reconstructed.) — Eru·tuon 05:58, 3 August 2017 (UTC)[reply]

MediaWiki:Gadget-TranslationAdder.js nests Gujarati under Aramaic[edit]

diff. --Anatoli T. ^{(обсудить}/^вклад) 02:22, 4 August 2017 (UTC)[reply]

Quite bizarre. Neither the canonical name or the code would explain that. — Eru·tuon 03:27, 4 August 2017 (UTC)[reply]

And it's the 2nd it happened to me. Not sure I fixed it correctly the first time it happened. I thought it was replacing one language with another, not nesting. --Anatoli T. ^{(обсудить}/^вклад) 03:34, 4 August 2017 (UTC)[reply]

Ohh, actually... I bet it's trying to put it before "Hebrew" – which it shouldn't, because Hebrew is just a script name nested under Aramaic. — Eru·tuon 03:57, 4 August 2017 (UTC)[reply]

@Dixtosa: Can you put this on your list of things to fix? — Eru·tuon 19:54, 7 August 2017 (UTC)[reply]

I think this fixed the bug. --Dixtosa (talk) 15:45, 12 August 2017 (UTC)[reply]

Maintenance category for quotes with translit but not native-script text?[edit]

Currently entries such as jb, which have quotations with transliteration but not the original native-script text, don’t seem to be put in any maintenance category, and they’re not categorized under the category of entries with usexes either (e.g. Category:Egyptian terms with usage examples), making them very hard to find. Could we perhaps make {{quote}}/{{ux}} automatically add them to the ‘… needing native script’ maintenance categories (e.g. Category:Egyptian terms needing native script) or make a new maintenance category for them? — Vorziblix (talk · contribs) 02:31, 4 August 2017 (UTC)[reply]

I think the "terms needing native script" is (theoretically) reserved for links to terms that would have entries. I've made Module:usex add the category Egyptian usage examples lacking native script (and the equivalent for other languages). The name can be changed if others object. I'll wait before adding it to the category-handling modules.

I guess the main question is which word we want: "needing", "lacking", "missing", something else? "Needing", which is used in the corresponding "term" category, would imply that ideally we want the native script to be supplied, whereas "lacking" does not. Maybe it would be best to switch, unless there are languages for which getting the native script isn't very important... — Eru·tuon 03:24, 4 August 2017 (UTC)[reply]

All right, thanks! I’m indifferent to the naming issue myself, but I’ll wait a while longer to see if anyone else comments before creating the category. — Vorziblix (talk · contribs) 21:24, 4 August 2017 (UTC)[reply]

I think "needing native script" is just fine for this. I don't think we need to distinguish links versus usexes. —CodeCa t 21:27, 4 August 2017 (UTC)[reply]

@CodeCat: Yeah, but the category is "terms needing native script". I assume "terms" would be referring to links to entries, not to any old text. — Eru·tuon 21:32, 4 August 2017 (UTC)[reply]

True, maybe. Renaming the category is also a possibility. Is there a reason other than naming that favours splitting the two? —CodeCa t 21:33, 4 August 2017 (UTC)[reply]

Not really. But subcategories for types of template might be useful, in case for some reason a person particularly wants to improve usage examples or quotes and not other categories of text in that language. — Eru·tuon 21:38, 4 August 2017 (UTC)[reply]

Font for Jawi (Arabic-script Malay)?[edit]

The current font for Jawi (Arab) doesn't display the Jawi-specific letters well. For example, {{m|ms|تڠن|tr=tangan}} produces تڠن (tangan) with disjointed ڠ, unlike the desired form of تڠن. Is it possible for this to be fixed? (Mac, Chrome) Wyang (talk) 08:28, 4 August 2017 (UTC)[reply]

While you're at it. Please check the Uyghur fonts. They are too small on most systems. --Anatoli T. ^{(обсудить}/^вклад) 08:38, 4 August 2017 (UTC)[reply]

Yuck. I created a new script code ms-Arab for Malay in Arabic script, so more appropriate fonts can be selected for it in MediaWiki:Common.css. The typical Arab fonts probably don't have some of the extended characters. (Traditional Arabic, which I use, certainly doesn't.) — Eru·tuon 21:46, 4 August 2017 (UTC)[reply]

Woops. Could an admin add ms-Arab to the various lists of all Arabic script codes in MediaWiki:Common.css, so it doesn't display italicized? — Eru·tuon 21:48, 4 August 2017 (UTC)[reply]

Added. DTLHS (talk) 05:31, 6 August 2017 (UTC)[reply]

Why the heck is Arial Unicode MS so high in the .Arab font stack? There are better fonts out there. Investigating with BabelPad shows that Segoe UI, Tahoma, Microsoft Sans Serif are sans-serif fonts capable of displaying the text تڠن correctly. —suzukaze (t・c) 07:04, 6 August 2017 (UTC)[reply]

Does someone at MW test font appearance on mobile devices, especially for less common languages? How is font delivery handled if the user's mobile device doesn't already have the font? (I focus on mobile devices because I imagine that PCs have abundant resources and techniques to accomplish the result.) DCDuring (talk) 23:38, 6 August 2017 (UTC)[reply]
- MediaWiki has no input in Wiktionary's font choices. All the font-related CSS styles are locally hosted in MediaWiki:Common.css. Unfortunately, none of the script- or language-specific CSS styles apply in the mobile version. MediaWiki:Common.css contains all of them, and it is only loaded in the desktop version. MediaWiki:Mobile.css contains very little, none of it font-related. So, in the mobile version non-Latin-script mentions are italicized (example: أهلا وسهلا), many obscure scripts probably display as boxes, etc. — Eru·tuon 00:34, 7 August 2017 (UTC)[reply]
  The question arose in my mind because some anon using a mobile complained rudely about his phone being ruined by something or someone here. But the question of how fonts look on mobile devices is important. If we don't research it, we probably should rely on MW for that for mobile devices. DCDuring (talk) 04:32, 7 August 2017 (UTC)[reply]
  I don't understand what you mean. Doesn't a given font (say, Times New Roman) look roughly the same on a computer and on a tablet or phone?
  
  And as far as I know MediaWiki has nothing to do with font selection. There might be a default font for the site, but besides that and the font selections that we have added to our CSS pages, browsers are what select which fonts are used for which characters. And they in turn can only select fonts that the user actually has on their device (ignoring web fonts). Avestan, for instance, seems to be unrecognized by my browser; I have the right fonts, but they only show up if the Avestan text is explicitly marked as Avestan (class Avst) and if our Common.css is loaded. So, anyway... I'm not aware of anything that MediaWiki can do for us. — Eru·tuon 05:30, 7 August 2017 (UTC)[reply]

I do not support Arial Unicode MS. Although, it may be useful for basic users but it is created for ages, given free with Office, less glyphes and no any update. Its rendering is also awful. Other fonts like Arial, Microsoft Sans Serif, Segoe UI, Times New Roman are okay. --Octahedron80 (talk) 01:09, 20 August 2017 (UTC)[reply]

Automatic listing of languages that use a transliteration module[edit]

Transliteration module documentation pages will now automatically list all languages that use the module, as long as the module is listed either in the language's data file or in the data module Module:translit-redirect/data. The module will also have a category added for each language. Till now, categorization was inconsistent for modules used by more than one language.

Also, for curiosity's sake, modules are categorized by how many languages use them. The record seems to be held by Module:Ital-translit, which is used by 12 languages.

The system isn't perfect: some languages have a dedicated module for one of their scripts, but also redirect to another module. There's no way for Module:languages/byTranslitModule to detect those, as far as I know. — Eru·tuon 05:19, 6 August 2017 (UTC)[reply]

Headword templates that should be converted to use Template:head[edit]

{{sco-proper noun}}, {{scn-adj}}, {{sw-inf}}, {{rom-adj}}, {{mt-possessive pronoun}}, {{lv-adj}}, {{kj-noun}}, {{id-proper noun}}, {{hil-verb}}. Some of them have very complicated logic if you're looking for a challenge. DTLHS (talk) 00:34, 7 August 2017 (UTC)[reply]

Template:eo-head issue[edit]

On damoj, the entry is ending up in Category:head tracking/unrecognized pos because it has "plurale tantum" as part of speech category. This isn't a part of speech category, so it should be changed to "noun". —CodeCa t 12:21, 7 August 2017 (UTC)[reply]

Fixed. —Aɴɢʀ (talk) 14:27, 7 August 2017 (UTC)[reply]

I wouldn't call that a fix. Also, there's many more Esperanto entries in that category with the same issue. —CodeCa t 16:24, 7 August 2017 (UTC)[reply]

@CodeCat, Mx. Granger: Well, it looks to me like MOD:eo-headword needs to be fixed. It shouldn't be hard for {{eo-noun}} to be able to figure this out without arguments. —Μετάknowledge^{discuss/deeds} 21:28, 7 August 2017 (UTC)[reply]

It could be done that way, or "plurale tantum" could be specified using the label template and not through the headword template. — Eru·tuon 21:35, 7 August 2017 (UTC)[reply]

I've reverted Angr's edits, which resulted in displaying incorrect inflection information. I don't have an opinion on what the template syntax should be, but the entry should display something like "accusative damojn", not "accusative singular damoj, plural damoj, accusative plural damoj". —Granger (talk · contribs) 23:24, 7 August 2017 (UTC)[reply]

Template:mul-semaphore letter, Template:mul-morse letter and Template:mul-morse number issue[edit]

As above. The template is specifying an invalid lemma category. —CodeCa t 12:31, 7 August 2017 (UTC)[reply]

Applying Vietnamese sortkeys[edit]

@Fumiko Take, Wyang: The Vietnamese sortkey module has been created, but there are lots of pages with categories added using wikilinks. If they have any diacritics, they will not be correctly sorted. @DTLHS has said that he has a bot script that can convert all these categories to templates, which would apply the correct sortkeys. Would the Vietnamese editors (I don't know who they are, besides @Fumiko Take) be in favor of that? — Eru·tuon 20:01, 7 August 2017 (UTC)[reply]

Yes, absolutely. Wyang (talk) 21:22, 7 August 2017 (UTC)[reply]

It's done. DTLHS (talk) 04:11, 11 August 2017 (UTC)[reply]

I've made Module:vi-sortkey use Module:zh-sortkey (which should perhaps have been titled Module:Hani-sortkey) when it receives Han characters, because that seems to be the way Vietnamese Han characters and its subcategories are already sorted, for the most part. — Eru·tuon 04:43, 11 August 2017 (UTC)[reply]

Interwiki RecentChanges[edit]

Some days ago, the interwiki links disappeared from the Special:RecentChanges page on (as far as I can see) all languages of Wiktionary, Wikipedia and other projects. What's up? A bug? --LA2 (talk) 20:49, 7 August 2017 (UTC)[reply]

I have not heard anything about this. Also no longer on the Special:Watchlist. Maybe WikiMedia removed the link-hub page (or whatever they call that page, the wikidata site-links). I don't think there is any need for interwikis from Special:RecentChanges or Special:Watchlist, so maybe they simply removed the site-links page. —Stephen ^(Talk) 18:34, 8 August 2017 (UTC)[reply]

I noticed that it's also gone from Wikipedia (I don't often look at their recent changes so I don't know if it was removed at the same time). DTLHS (talk) 18:37, 8 August 2017 (UTC)[reply]

See phab:T172461. --Vriullop (talk) 10:51, 24 August 2017 (UTC)[reply]

As a workaround, an admin can move interwiki links from MediaWiki:Recentchangestext to MediaWiki:Recentchanges-summary. It works on ca:Special:RecentChanges. --Vriullop (talk) 19:31, 25 August 2017 (UTC)[reply]

Done, and it looks like the interwiki links have returned. - TheDaveRoss 19:36, 25 August 2017 (UTC)[reply]

Now, suddenly, they are back on Swedish, Russian, and Ukrainian Wiktionary too. I don't know how that happened, but I'm quite sure they weren't there yesterday. --LA2 (talk) 01:08, 8 September 2017 (UTC)[reply]

xx[edit]

Almost every day some version of xxx gets added. Can we automatically prevent the addition of terms containing two or more adjacent x characters? SemperBlotto (talk) 05:04, 8 August 2017 (UTC)[reply]

The xx's seem to be from random mobile users in countries that don't use the Latin script- mostly Arabic or Persian, with a few Thai. I suspect that most of it is some kind of misapplied phone-OS navigation commands, but the evidence is inconclusive. It's all in the past year or so, so perhaps there's some kind of new dictionary app that's dumping users here with telling them they're editing a dictionary.

There's already a filter to prevent adding small amounts of text with nothing but x's, but it doesn't seem to catch this. I've now added a separate filter for article creations. Please tweak or fix. Chuck Entz (talk) 13:51, 8 August 2017 (UTC)[reply]

It's people in India etc. trying to find porn. The titles often indicate this, "xx video", "xx sex" etc. Equinox ◑ 17:33, 8 August 2017 (UTC)[reply]

Dutch male/female gender[edit]

I think this is the right place. I just edited ex#Dutch and added {{nl-noun|mf|exen|exje}} just like the Catalan entry above it. But unlike the Catalan entry, it now says (question mark) "gender incomplete". It isn't! I entered "mf" (male/female) which is correct! See http://woordenlijst.org/#/?q=ex for evidence. This is not the same as neutral gender. An example of neutral gender is http://woordenlijst.org/#/?q=project. Template:nl-noun seems to have no option to have mf gender. W3ird N3rd (talk) 18:55, 9 August 2017 (UTC)[reply]

Fixed. You don't have to flip out when you don't know how to do something. --Wiki Tiki 89 18:58, 9 August 2017 (UTC)[reply]

Thanks. I'm not really flipping out, but I suppose it can come across like that. If I'm flipping out at all, it's not towards any person here but just towards the templates which nicely convert mf to "m, f" for Catalan but won't do the same thing for Dutch. W3ird N3rd (talk) 19:11, 9 August 2017 (UTC)[reply]

"mf" is a specific exception in the Catalan templates. It's not supported by templates generally. —CodeCa t 19:03, 9 August 2017 (UTC)[reply]

I think the nl-noun template (and any others for languages where mf is possible) should have the mf option added, or the option should be removed from the Catalan template if it's not standard so you don't get unexpected results like I did. W3ird N3rd (talk) 19:11, 9 August 2017 (UTC)[reply]

Isn't c how such things are usually marked? —Aɴɢʀ (talk) 20:10, 9 August 2017 (UTC)[reply]

c means that the gender is masculine or feminine, but the creator of the entry doesn't know which because they speak a two-gender variety of Dutch. —CodeCa t 20:13, 9 August 2017 (UTC)[reply]

Yeah, common gender refers to a merger of masculine and feminine genders, not to nouns that can be either masculine or feminine. --Wiki Tiki 89 20:37, 9 August 2017 (UTC)[reply]

There isn't any requirement that template parameters have to be standardized. But it might be easier to add |1=mf as an option for {{nl-noun}} than to remove it from the Catalan template, depending on how much mf option is used. — Eru·tuon 21:47, 9 August 2017 (UTC)[reply]

{{es-noun}} accepts the parameter too. —Granger (talk · contribs) 21:51, 9 August 2017 (UTC)[reply]

I'd rather remove it from Catalan. —CodeCa t 22:19, 9 August 2017 (UTC)[reply]

It seems {{pt-noun}}, {{it-noun}}, and {{fr-noun}} accept it too. That makes at least five templates we'd be removing it from, maybe more. Moreover, the syntax "mf" is more intuitive than "m|g2=f", in my opinion. I think we should keep the option for the templates that have it and consider adding it to {{nl-noun}}. —Granger (talk · contribs) 22:39, 9 August 2017 (UTC)[reply]

They're all Romance languages. Compare that to the many languages whose templates do not allow it. And the most important of all, {{head}}. I can only support this kind of "standardisation" if it can be applied to {{head}} as well. Otherwise the consistency argument is moot. —CodeCa t 22:57, 9 August 2017 (UTC)[reply]

"There isn't any requirement that template parameters have to be standardized."

There's no requirement for me to eat pizza either, but it sure would be nice. Since {{nl-noun|m|g2=f|g3=n|g4=p|-en|exje}} is also supported, is there a technical reason not to support any combination like {{nl-noun|pmnf|-en|exje}}? I know this example is nonsense, but so is the variant with g2g3g4, this is just easier for multiple genders. Unless of course combinations other than mf simply don't exist in any language, in that case it's more sensible to just support mf. W3ird N3rd (talk) 22:46, 9 August 2017 (UTC)[reply]

I've checked a few. (not all) Besides {{pt-noun}}, {{it-noun}}, {{es-noun}}, and {{fr-noun}} this is also supported by {{lv-noun}}, {{ast-noun}}, {{vec-noun}}, {{cy-noun}}, {{gl-noun}} and {{frm-noun}}.

These require g= for any gender but do support mf: {{yi-noun}}, {{ur-noun}}, {{bg-noun}}

These do not support mf but for I don't know if mf would be valid for these languages anyway: {{la-noun}}, {{lt-noun}}, {{wa-noun}}, {{sv-noun}}, {{sh-noun}}, {{gd-noun}}, {{rom-noun}}, {{ar-noun}}, {{osx-noun}}, {{mt-noun}}, {{lb-noun}}, {{ga-noun}}, {{el-noun}}, {{got-noun}}, {{fur-noun}}, {{fo-noun}}, {{ovd-noun}}, {{cs-noun}}, {{br-noun}}, {{be-noun}}, {{sq-noun}}, {{mk-noun}}

W3ird N3rd (talk) 23:42, 9 August 2017 (UTC)[reply]

Template:case-gov[edit]

I have created a new template to categorize prepositions based on which case they govern, as a way to help clean up the "(+ accusative)" stuff lying around. Anti-Gamz Dust (There's Hillcrest!) 02:58, 10 August 2017 (UTC)[reply]

We already have {{+preo}} for this purpose. —CodeCa t 09:43, 10 August 2017 (UTC)[reply]

"Module is unfinished"? Anti-Gamz Dust (There's Hillcrest!) 09:56, 10 August 2017 (UTC)[reply]

Template:ga-noun creating spurious "whatlinkshere"s (but only three?)[edit]

Check out Special:WhatLinksHere/~a and Special:WhatLinksHere/~e. There are hundreds of pages there, all of which use {{ga-noun}} and the parameter |~a or |~e. However, if you look at the actual pages, they don't have links to ~a and ~e, because the template knows to convert them to [[{{PAGENAME}}a]] and [[{{PAGENAME}}e]]. So why are the "whatlinkshere"s being created? And how can we stop them from being created? To make the phenomenon even weirder, {{ga-noun}} uses other similar shortcuts like |~í, but those aren't creating spurious "whatlinkshere"; Special:WhatLinksHere/~í is empty, even though that parameter is also used on hundreds of pages. What gives? —Aɴɢʀ (talk) 14:23, 10 August 2017 (UTC)[reply]

Special:WhatLinksHere/~ is also populated by a large number of pages using {{ga-noun}} but without actual links to [[~]]. —Aɴɢʀ (talk) 14:55, 10 August 2017 (UTC)[reply]

@Angr: I think it is the line {{#ifexist:{{{2|{{{3|{{PAGENAME}}}}}}}}||[[Category:Missing Irish noun forms]]}}. If the input to {{ga-noun}} is {{ga-noun|m|g2=f|~a|~aí}}, this would mean that the code checks to see if [[~a]] exists (and, it doesn't). —suzukaze (t・c) 06:23, 17 August 2017 (UTC)[reply]

@Suzukaze-c: I could see that that would populate CAT:Missing Irish noun forms even when the noun forms aren't missing, but it's still weird that it would create imaginary links to [[~a]]. Anyway, I'm not a fan of Category:Missing Irish noun forms anyway (it seems really useless to keep track of that, especially when it only looks at the headword line and not at the inflection table), and the person who created it has been blocked indefinitely, so I'm tempted to just remove that bit of code. —Aɴɢʀ (talk) 08:28, 17 August 2017 (UTC)[reply]

I have removed the code. —suzukaze (t・c) 08:40, 17 August 2017 (UTC)[reply]

@Angr #ifexist counts as a link. The same with its Lua equivalent. —CodeCa t 11:14, 17 August 2017 (UTC)[reply]

What are the advantages to the Reconstruction namespace?[edit]

(Apart from letting us adhere to the letter of the rule "only attested terms in mainspace"). A user on da.wikt may be interested in adding reconstructions (which we currently do not have there), but was unsure how to do so. If we all use special namespaces, we can use sitelinks, but da.wikt and eo.wikt (and probably many other versions) do not even currently have appendices. If we all use mainspace (and the same transcription standards), we can let Cognate do all the work. If neither of those, we need to go back to interwikilinks (which is not currently being maintained, see e.g. Reconstruction:Proto-Indo-European/deywós/es:*deywós).
So, what are the advantages?__Gamren (talk) 14:40, 10 August 2017 (UTC)[reply]

We find it useful to have reconstructions in a dedicated namespace; the solution at es.wikt, for example, marks reconstructions with the asterisk in namespace and thus confuses them with something like *band (yes, that is a word in English). For us, linking between Wiktionaries is a somewhat secondary concern, and also one that will probably be solved fairly soon for all namespaces, I think. —Μετάknowledge^{discuss/deeds} 17:28, 11 August 2017 (UTC)[reply]

The original reasoning for not putting reconstructions in the main namespace was that they are not attested and therefore do not pass CFI. --Wiki Tiki 89 17:34, 11 August 2017 (UTC)[reply]

The asterisk * is not really a part of the reconstructed word, so it is an improvement to omit it in the article title. If we put Reconstruction:Proto-Indo-European/deywós at *deywós, it could be taken to indicate that the asterisk was part of the orthography, as it is in English words beginning with an asterisk. — Eru·tuon 21:00, 11 August 2017 (UTC)[reply]

Some questions about adding audio recording of words pronunciation[edit]

Hi, I'm from the Hebrew Wiktionary team. I also took part in writing a site for easy recording of mass of words from a lists: https://lingualibre.fr/ (only French UI at the moment).

I wanted to know whether there is already an extension or a bot for uploading audios of words pronunciation to wiktionaries ? I think that an extension where users can record words and add it directly from the wikitionary page just like with editing, could be really cool.

Also, there is this site of words pronunciation forvo , I wanted to know if it is allowed to write a bot that import audio from there to wikicommon?

Thanks — This unsigned comment was added by Shavtay (talk • contribs) at 12:43, 11 August 2017 (UTC).[reply]

@Shavtay: Try User:Yair rand/AddAudio.js. --Yair rand (talk) 19:16, 14 August 2017 (UTC)[reply]

@Shavtay About Forvo, its CC license is not compatible with Commons. Many files from Forvo have been deleted, like these. — justin(r)leung _{{ (t...) | c=› }} 16:23, 7 September 2017 (UTC)[reply]

Editor2 and TabbedLanguages2[edit]

What are these? Who uses them? Should they be included in legacyscripts gadget? It says it was added temporarily. @Yair rand, what are the development stages of these two scripts? Dixtosa (talk) 17:21, 11 August 2017 (UTC)[reply]

@Dixtosa: TabbedLanguages2 works, editor2 may or may not still work. Both are also available as gadgets. We actually had a vote pass back in 2012 to turn on TabbedLanguages for all users, and that was going to happen as soon as someone could write a bot to make sure that categories were placed in the right sections, so that readers wouldn't have relevant categories hidden in other sections. That never ended up happening, afaik. The (intended to be) temporary script added in Common.js (later moved to legacyscripts) allow adding simple enable/disable buttons so that users could easily test the scripts in the intermediary period. I don't know if anyone still has it enabled only through the legacyscripts mechanism, but I suppose we could change it to just enable the gadgets for any remaining users using it that way, and then remove the bit from legacyscripts. --Yair rand (talk) 18:30, 14 August 2017 (UTC)[reply]

@Yair rand, so which tabbedlanguage is newer the one in your userspace or in the MW namespace? Also TL2 uses langrev templates which we decided to delete and I am set to replace all the remaining uses from active user scripts. So should I touch it too? And what do we do about editor2?BTW, TL2 does not work for me when I enable it from the page you linked. I use Chrome 60 and there are no js errors. BTW2, editor is a terrible name Conrad called TranslationAdder editor and in the code there is a class called Editor. Dixtosa (talk) 20:09, 22 August 2017 (UTC)[reply]

Collapsible table initially displaying “Collapse” when it is collapsed[edit]

For example, the homophone table inside {{zh-pron}} on 勢力 is displaying “Collapse” when it should be “Expand”. The table makes use of the collapsible element wikitable mw-collapsible mw-collapsed and the code is housed at the bottom of Module:cmn-pron. Is there a way to fix this? Wyang (talk) 22:29, 11 August 2017 (UTC)[reply]

It seems the collapsible table of {{zh-pron}} is interfering with this subtable. Perhaps id="..." could fix this. Wyang (talk) 22:52, 11 August 2017 (UTC)[reply]

Language-specific alphabetisation[edit]

I was about to add the information for how to sort Hausa entries when I realised that I still don't know how to solve a long-running problem. I want the letter ɓ to alphabetise after b but before c; this could be achieved by telling the module to sort ɓ as bz, but I also want it to be in a separate section in the categories, since it is considered a separate letter in Hausa. Is this currently possible? If not, could we submit a Phabricator request to make it possible? It would be useful for a great many languages. @Erutuon —Μετάknowledge^{discuss/deeds} 05:28, 12 August 2017 (UTC)[reply]

It is possible with new sortkey functionality (Module:vi-sortkey for example). The main annoyance is you have to make sure all categories are routed through the sortkey module, so categories must be templatised in {{C}}, etc. DTLHS (talk) 05:43, 12 August 2017 (UTC)[reply]

@DTLHS: When I look at, say, CAT:Vietnamese verbs, words starting with đ are still under D, despite that being a separate letter. I'm saying that I want there to be a Đ section after the D section, if that makes sense. —Μετάknowledge^{discuss/deeds} 05:49, 12 August 2017 (UTC)[reply]

Sorry I misunderstood. I think that this is not currently supported except as a configuration setting for the entire wiki (see [1]) DTLHS (talk) 06:04, 12 August 2017 (UTC)[reply]

Extremely hacky dumb solution: you could create a new alphabet that you would sort under (let a = 0, b = 1, ɓ = 2, c = 3, etc), then everything would be in the correct order but the collation headings would be meaningless. DTLHS (talk) 06:51, 12 August 2017 (UTC)[reply]

I think that would be worse. Do you think you could file a Phabricator request for category-specific collation? Even if it's not likely to happen any time soon, it would be good to let them know that we could really use it. —Μετάknowledge^{discuss/deeds} 06:53, 12 August 2017 (UTC)[reply]

I second that. It would be a wonderful feature. Having a way to treat digraphs and trigraphs as single letters and to give them their own sections would also be nice – for instance, for Hungarian. That would probably be more difficult than changing the order of the single letters, though. — Eru·tuon 07:20, 12 August 2017 (UTC)[reply]

@DTLHS: Make it even more hackier by making fake entries that will be converted to headers using JavaScript. 👍 —suzukaze (t・c) 07:14, 12 August 2017 (UTC)[reply]

Maybe we should poke the devs some more. They were supposed to have custom collations done ages ago. —CodeCa t 10:22, 12 August 2017 (UTC)[reply]

I'm thinking the idea related to digraphs could work. In the sortkey, we would convert each digraph or trigraph (or tetragraph, pentegraph) to an arbitrary character that doesn't appear in entry names. Then the new extension would correctly order the sortkeys using a language-specific collation order, and it would generate the headings by converting the arbitrary characters back into the digraphs and trigraphs that they represent.

For instance, dzsessz (“jazz”) could have the sortkey ₁e₂₂, in which ₁ represents the trigraph dzs and ₂ represents the digraph sz. (I'm not sure if this is the way a Hungarian dictionary would handle the double consonant ssz. Maybe the sortkey should use s₂ instead.) ₁ would be ranked after e in the extension, while ₂ would be ranked after s. And instead of placing the entry dzsessz under the heading ₁, it would convert that symbol back to DZS and use that as the heading instead.

This would require that the collation extension be coordinated with whatever Lua module generates the sortkeys (currently, for most languages, Module:languages combined with the sortkey data from the language's data table). That is, whatever generates Hungarian sortkeys would have a list of correspondences between the digraphs or trigraphs and the arbitrary characters chosen to represent them in sortkeys, and the collation extension would have, in its data for the language code hu, an identical list to convert back from the sortkey characters to the digraphs or trigraphs. — Eru·tuon 18:10, 12 August 2017 (UTC)[reply]

@Erutuon: That would be every more amazing. But as I keep saying, I need someone else (like you) who can explain this well to file a Phabricator request... —Μετάknowledge^{discuss/deeds} 18:50, 12 August 2017 (UTC)[reply]

The proper solution is to have custom collation for each category. That way, we don't need to bother with sort keys anymore. —CodeCa t 19:23, 12 August 2017 (UTC)[reply]

We would still need sortkeys, unless the custom collation can somehow create the same effect as the complex sortkeys that we use for Coptic and Vietnamese (see Module:cop-sortkey and Module:vi-sortkey). — Eru·tuon 20:17, 12 August 2017 (UTC)[reply]

Also I think it would be preferable in at least some cases to handle digraphs, trigraphs, etc. through sortkeys, rather than having the collation extension automatically consider all possible instances of the correct group of letters as a letter: I suspect that there are languages in which a sequence of letters is sometimes a digraph and sometimes not.

For instance, Serbo-Croatian nadžíveti and pódzēmlje might have instances of d + ž and d + z rather than the digraphs dž and dz, as the d is at the end of a prefix. I could be wrong about this specific instance. But if there are any examples like this, they would have to be handled by manual sortkeys. — Eru·tuon 00:07, 13 August 2017 (UTC)[reply]

@Metaknowledge: At the moment, I'd rather not file a Phabricator request. I haven't done it before and this would be a fairly difficult proposal to explain. I also have the impression that MediaWiki people are difficult to deal with, especially when you are a programming newbie (as I am). I might experiment with making a Lua module that uses this method of sorting, however. — Eru·tuon 01:05, 2 October 2017 (UTC)[reply]

@Erutuon: I know less than you and I've done it. Recently I filed a task that was poorly thought out in retrospect, but the devs treated me and my task nicely anyway. I think you should try it. —suzukaze (t・c) 04:42, 2 October 2017 (UTC)[reply]

Unrelated, but why is CAT:Nigerien Hausa throwing an error? I added Niger to MOD:labels/data/regional. —Μετάknowledge^{discuss/deeds} 05:19, 13 August 2017 (UTC)[reply]
Oh, and despite adding the diacritics to be stripped, ā̀ still doesn't link to a. No clue why. @Erutuon —Μετάknowledge^{discuss/deeds} 06:26, 13 August 2017 (UTC)[reply]
1, there is no category boiler template for regional categories, 2, ā̀ is a combined character, so you need to add GRAVE to the entry name field. DTLHS (talk) 06:38, 13 August 2017 (UTC)[reply]
@DTLHS: Thank you! It's weird that we don't have boilerplate for even something like CAT:Regional Hausa. —Μετάknowledge^{discuss/deeds} 17:03, 13 August 2017 (UTC)[reply]
@Metaknowledge: I can look into making a module to power a category boilerplate template for subvarieties of languages at some point. It's going to be a little complicated, though, uniting Module:etymology languages with Module:labels/data/subvarieties and Module:labels/data/regional. — Eru·tuon 18:46, 13 August 2017 (UTC)[reply]

Some help developing my Mongolian headword module[edit]

Here it is: Module:User:Crom_daba/mn-headword. I'm testing it on User:Crom_daba/Sandbox, but for some reason the noun won't display the given head parameter while the verb seems to work fine. Their implementation looks the same to me, what am I not seeing?

"heads" not "head" on line 75. DTLHS (talk) 20:45, 12 August 2017 (UTC)[reply]

Gotta love how a fresh pair of eyes can save hours of debugging. Crom daba (talk) 20:50, 12 August 2017 (UTC)[reply]

Bug in "+Add new rhyme" feature[edit]

The "+Add new rhyme" feature sorts the words using a case-sensitive (Linux-style) sort, so that when, say, adding "dismember" as a rhyme for "November", "dismember" will be listed after "November" instead of before. The sort needs to disregard case. — Paul G (talk) 15:54, 13 August 2017 (UTC)[reply]

Sorting is disregarded on save anyways. It never respected sorting. --Dixtosa (talk) 16:42, 13 August 2017 (UTC)[reply]

Fixed it anyways. Dixtosa (talk) 16:49, 13 August 2017 (UTC)[reply]

Transliterating inflections[edit]

Could we allow for a way to have inflections transliterated by Module:headword if so requested? I'm making a Mongolian headword module, and I think it would be nice if I could display the transliteration of Uighur script, compare the current state with my module. Crom daba (talk) 18:59, 13 August 2017 (UTC)[reply]

Can't you do this with the f1tr, f2tr... parameters, or am I misunderstanding? DTLHS (talk) 19:04, 13 August 2017 (UTC)[reply]

Arabic already does this, so the support for it exists in Module:headword. I'm not sure what's needed to get the transliterations to appear. —CodeCa t 19:10, 13 August 2017 (UTC)[reply]

Here's how this support looks (line 281) tr = part.translit or ((not (parts.enable_auto_translit or data.lang:getCode() == "ar")) and "-" or nil) Crom daba (talk) 23:15, 13 August 2017 (UTC)[reply]

I'll update the documentation. Crom daba (talk) 23:17, 13 August 2017 (UTC)[reply]

@Erutuon That specific exception for Arabic should probably go, so it can use the generic code. —CodeCa t 19:05, 14 August 2017 (UTC)[reply]

@CodeCat: Done. Also, @Crom daba, I made it so that you can enable transliteration for all inflections by placing enable_auto_translit = true in the data.inflections table. That's more convenient than having to add enable_auto_translit = true to every inflected form in the table. — Eru·tuon 19:44, 14 August 2017 (UTC)[reply]

It would be preferred to only have one way to do it. Are there any modules that use the "old" code? —CodeCa t 19:48, 14 August 2017 (UTC)[reply]

From a wikitext search, it looks like Module:yi-headword is the only non-sandbox module to use it. The question is if all inflected forms are supposed to have transliterations or not. — Eru·tuon 19:52, 14 August 2017 (UTC)[reply]

In the case of Module:mn-headword, only alternative script should be transliterated. Crom daba (talk) 20:08, 14 August 2017 (UTC)[reply]

In that case, I guess both ways of turning on transliteration should exist. — Eru·tuon 20:45, 14 August 2017 (UTC)[reply]

Watchlist options[edit]

I'm using Firefox browser with the Vector skin. For the past week or so, I have had trouble with the Watchlist options (appears at the top of the Special/Watchlist page. In the options, you can select your watchlist according to various lengths of time, such as 1 day, 3 days, 7 days, and so on:

Watchlist options

Legend:

Below are the last 250 changes in the last 72 hours, as of 14 August 2017, 11:20

The problem that I'm having is that, no matter which number of days I select, 1, 3, 7, or 30, I still get the same "last 250 changes in the last" list. It's the weirdest thing. —Stephen ^(Talk) 11:28, 14 August 2017 (UTC)[reply]

That is a technical limitation. Watchlist and recent changes have always had this limitation. Giorgi Eufshi (talk) 11:57, 14 August 2017 (UTC)[reply]

Something has changed. Not sure what it is, but for years I have been able to change my default watchlist of 24 hours to 3 days, and I would always see a list of triple length, with such headers as 14 August 2017 (partial day), 13 August 2017 (full day), 12 August 2017 (full day), 11 August 2017 (partial day). No longer. Now all I get is about 14 hours, regardless of how many days I tick. At this moment, even if I select the last 30 days, all I get are the 13 hours corresponding to 14 August, plus one hour of 13 August, beginning with скорее, 23:26 (13 August 2017). No matter how hard I try, I cannot see the full list for 13 August 2017, 12 August 2017, or 11 August 2017. —Stephen ^(Talk) 13:35, 14 August 2017 (UTC)[reply]

Okay, I have figured out the problem. It seems that something (it wasn't me) has changed a quantity in my Preferences. I looked in Preferences > Watchlist, and there is a box called Maximum number of changes to show in watchlist. It was set at 250, which is the number that I have been seeing for the past week regardless of the number of days I selected. I reset it to 1000, and now I'm seeing what I have been accustomed to see. —Stephen ^(Talk) 13:44, 14 August 2017 (UTC)[reply]

Edit filter to block edits that add interwikis[edit]

diff. Can we get an edit filter to stop edits such as these? The filter should actually stop the edit, not merely warn. —CodeCa t 21:19, 14 August 2017 (UTC)[reply]

Category:Plurals with a red link for singular[edit]

Would it make sense to split this category into multiple ones - one for each language? SemperBlotto (talk) 13:40, 15 August 2017 (UTC)[reply]

Yes, it would make it easier to find entries in the language(s) one is interested in. Each one should go in that languages "entry maintenance" category too. —Aɴɢʀ (talk) 14:32, 15 August 2017 (UTC)[reply]

Wanted: Gadget to speed linkification[edit]

As I add taxonomic names, I try to linkify any existing entry (actually L2 section) that uses the taxon, but does not link to it. It would be a help to be able to do that, say, from the entry page or from an entry creation page, without have to type the entry name and to obtain a list only containing the taxon not already linked. It would be nice if not only bare links, but also taxa enclosed in templates such as {{taxlink}}, {{m}}, {{l}} were excluded.

It would seem likely that it be possible. Obviously, it would be a resource hog for terms of wide use, like letters, many short words, and function words. Perhaps short terms in Latin and similar scripts at least could be excluded. Would it still be a resource hog? DCDuring (talk) 21:01, 15 August 2017 (UTC)[reply]

Number of modules invoked and Lua memory errors[edit]

Part of the reason for so much Lua memory usage is the number of modules that are required or have their data loaded in another Lua module, because there is additional memory used by the require() or mw.loadData functions beyond the size of the module itself.

I don't know how much memory each one requires. I thought it might be a half megabyte based on a test I did once, but that could be wrong. If anyone more digitally astute can find a way to get a more precise figure, that would be nice.

The memory used to transclude each module might explain why pages like air, which invokes 69 transliteration modules, mostly in the Translations sections, use so much memory. (Air is currently at 47.95 MB, and it went over the limit until recently, when I switched many of the Latin translations to the non-Lua template {{t-simple}}.)

Some of this memory could be freed up, then, by merging some of the transliteration modules, so that fewer modules have to be transcluded. There are some candidates that I noticed when I was going through the transliteration modules reformatting and simplifying the code. First, there are quite a few non-Slavic Cyrillic-script transliteration modules, probably for languages spoken in the former Soviet Union, that have similar code for handling iotated vowels. These could be merged to a single module with a bunch of tables for language-specific replacements. Second, there are a number of modules for languages using Canadian syllabics that are really small; they should be combined with the main module. Third, any modules that simply replace each letter with its Latin equivalent (Module:Phnx-translit, Module:Cher-translit) could be easily handled by a single module.

Merging the modules would make it somewhat harder to find the module for a particular language: instead of typing the language code and -translit, people will have to navigate to the correct module using the Modules by language categories. That's already the case for certain modules that are titled with script rather than language codes (for instance, Module:Armn-translit), so it's not a problem in my opinion.

This proposal wouldn't finally solve the memory problem, but would at least defer the final reckoning. — Eru·tuon 22:13, 15 August 2017 (UTC)[reply]

Tabbedlanguages miscategorising at ؟[edit]

@Dixtosa On this entry, Category:Arabic block and Category:Arabic script characters are placed under the Arabic tab, but these are actually added by the Translingual section and belong there. —CodeCa t 19:34, 16 August 2017 (UTC)[reply]

Bot request: remove the |style= parameter from `{{ja-kanji}}`[edit]

It is a deprecated parameter (that was theoretically never necessary in the first place, with clever enough code...). —suzukaze (t・c) 06:15, 17 August 2017 (UTC)[reply]

I think |rs= can also be removed, since Module:ja now invokes Module:zh-sortkey to get the radical and stroke number, if it wasn't added to the template. — Eru·tuon 06:45, 17 August 2017 (UTC)[reply]

Theoretically, yes. Technically, Japanese requires a new module (maybe even all of the 漢字文化圏 languages...) due to Han unification combining codepoints for characters whose local variants may have varying numbers of strokes. —suzukaze (t・c) 07:12, 17 August 2017 (UTC)[reply]

Removed style= from entries. DTLHS (talk) 19:48, 17 August 2017 (UTC)[reply]

"Declension", "Personal forms" or what - a question to grammar wizards[edit]

In Finnish there's a class of adverbs that require a possessive suffix which reflects the person of the subject of the sentence. For example, hyvillään (“pleased”):

Olen hyvilläni.	I'm pleased.
Olet hyvilläsi.	You are pleased.
Hän on hyvillään.	He/she is pleased.
Olemme hyvillämme.	We are pleased.
Olette hyvillänne.	You are pleased.
He ovat hyvillään.	They are pleased.

A comprehensive list of this type of adverbs can be found here: Special:WhatLinksHere/Template:fi-decl-pred-adv.

On each of these pages there's a table showing these forms. The header for the table is currently "Declension". I wonder if that is the correct term, or should the header be something else, like "Personal forms". --Hekaheka (talk) 07:42, 18 August 2017 (UTC)[reply]

"Inflection". It works for everything. —CodeCa t 10:04, 18 August 2017 (UTC)[reply]

I agree. I don't use "Inflection" much, but I do use it for the inflected prepositions of the Celtic languages (e.g. wrth#Inflection). —Aɴɢʀ (talk) 12:45, 18 August 2017 (UTC)[reply]

I use "Inflection" for all situations. There's no need to differentiate when they are the same thing. The division between declension and conjugation is Eurocentric anyway. —CodeCa t 12:19, 19 August 2017 (UTC)[reply]

Or Indo-Euro-centric? The distinction works for Indo-Aryan languages at least. —Aryaman ^{(मुझसे बात करो)} 20:14, 19 August 2017 (UTC)[reply]

Current font size for the title of `Hani`-script entries[edit]

is IMO a bit too big (to the extent that it becomes a little frightening); e.g. 獼猴桃. Wyang (talk) 12:04, 19 August 2017 (UTC)[reply]

.firstHeading .Hani { font-size: inherit; }. —suzukaze (t・c) 23:44, 19 August 2017 (UTC)[reply]

Quotations dropdown has changed appearance[edit]

The quotations dropdown [quotations ▼] has changed somehow, with less horizontal space between it and the preceding line of text. Why is that? Equinox ◑ 13:29, 19 August 2017 (UTC)[reply]

I have moved toggling functionality from the gadget legacy scripts to the main Common.js and changed them a little bit too. But I do not know why the appearance changed. Anyways, I tried to style it as it was before. Is it better?--Dixtosa (talk) 14:24, 19 August 2017 (UTC)[reply]

The only difference I see is it is slightly larger. DTLHS (talk) 21:27, 19 August 2017 (UTC)[reply]

Can we convert the display of Module:nyms to a similar dropdown appearance too ([synonyms ▼] or something)? Wyang (talk) 00:45, 20 August 2017 (UTC)[reply]

That seems impossible since presumably each different line is its own template invocation (one for synonyms, antonyms, ...). DTLHS (talk) 01:05, 20 August 2017 (UTC)[reply]

Perhaps feasible by assigning class to each of the templates and using Javascript to convert it to a dropdown? Wyang (talk) 01:14, 20 August 2017 (UTC)[reply]

┌────────────────────────────────────────────────────────────────────────────────────────────────────┘ This may be related – I've noticed that the "quotations" link is not working properly. Even though I have "Show quotations" activated and the link suggests that quotations are being shown, they do not in fact appear. I have to click the link twice – once to hide quotations, and again to show them – to make them appear. However, the choice is not remembered when I move on to another entry. — Cheers, JackLee ^–talk– 12:45, 20 August 2017 (UTC)[reply]

@Jacklee, what browser are you using?Dixtosa (talk) 12:51, 20 August 2017 (UTC)[reply]

I'm having the issue with both Mozilla Firefox and Safari on my mobile device. — Cheers, JackLee ^–talk– 13:18, 20 August 2017 (UTC)[reply]

No one else is experiencing this? — Cheers, JackLee ^–talk– 00:41, 22 August 2017 (UTC)[reply]

@Jacklee @Dixtosa, I am (Chrome). It's extremely annoying. Ƿidsiþ 09:43, 2 September 2017 (UTC)[reply]

@Jacklee, Widsith I have simulated iphone on my desktop Chrome and I do not see any problem :(. Are you using mobile version of the site (prefixed with m. by any chance? Dixtosa (talk) 12:23, 2 September 2017 (UTC)[reply]

No, I'm using the desktop version of the site. I'm still experiencing the problem with the latest version of Mozilla Firefox on Windows 10, and with Safari on iOS. — Cheers, JackLee ^–talk– 12:54, 2 September 2017 (UTC)[reply]

The problem seems to have gone away. — Cheers, JackLee ^–talk– 21:58, 6 September 2017 (UTC)[reply]

Module:Quotations and Wikidata[edit]

Would it be possible for MOD:Quotations to automatically get data from Wikidata if the language's data page does not have metadata for a specific work or author? —Aryaman ^{(मुझसे बात करो)} 20:13, 19 August 2017 (UTC)[reply]

Glitch in Translation tool?[edit]

Well, something weird just happened. This has never happened to me before, so I'm wondering if this is a temporary glitch or something that's happened only to me? --Robbie SWE (talk) 18:54, 20 August 2017 (UTC)[reply]

@Robbie SWE It was my mistake. It is now fixed. Sorry.--Dixtosa (talk) 19:40, 20 August 2017 (UTC)[reply]

@Dixtosa no worries, just thought my computer/account was on the fritz. --Robbie SWE (talk) 19:42, 20 August 2017 (UTC)[reply]

Misplacement of furigana[edit]

I found that the third example sentence in the page ある has misplaced furiganas, which I am not sure how to correct:

私(わたし)の学校(がっこう)は花園(はなぞの)があります。

Watashi no gakkō wa hanazono ga arimasu.

My school has a flower garden.

Solution:

私(わたし)の学校(がっこう)は花園(はなぞの)があります。

Watashi no gakkō wa hanazono ga arimasu.

My school has a flower garden.

This seems to be a systematic error. It goes like this:

When a part of the sentence is of the sequence kanji-kana-kanji, and the first kana of the second kanji is identical to the standalone kana, the standalone kana is erroneously shown as part of the first kanji's furigana, and the first kana of the second kanji is displayed as the standalone kana.

So, as the example has it,

...gakkou ha hanazono...

is mistakenly reanalyzed as

...gakkouha ha nazono...

even though the source code is correct. I cannot access the visual editor for some reason, so that is all I have. If I change the second ha to something like ga, the sequence of furiganas is correct. And since the algorithm seems to ignore spaces to first match for the kanas, changing the standalone ha to something else like sa does not correct the mistaken reanalysis.

I hope I have made myself clear.

Could this be fixed soon?

Rethliopuks (talk) 05:35, 21 August 2017 (UTC)[reply]

I hit on a solution by accident (which might be mentioned in Module:ja; search for "leak"): adding spaces around the particle は in the first parameter – {{ja-r|私の学校は花園があります。|...}}. I don't understand how it works, but I think the ruby is correct now. — Eru·tuon 06:02, 21 August 2017 (UTC)[reply]

Oh, I guess it signals to Module:ja that the は surrounded by spaces in the first parameter is the same as the は surrounded by spaces in the second parameter. Duh. — Eru·tuon 06:16, 21 August 2017 (UTC)[reply]

@Erutuon: The solution is documented at Template:ja-r/documentation. (There should really be one centralized place where the ruby function is documented...) —suzukaze (t・c) 06:36, 21 August 2017 (UTC)[reply]

@Suzukaze-c: Ahh, I had read that before, but didn't connect it to this. It's related but slightly different. In the case above, replacing the spaces with percents gives a module error. So the use of spaces should be mentioned in a documentation page somewhere. Whether it would be used in {{ja-r}} or just in {{ja-usex}}, I don't know for sure. — Eru·tuon 07:30, 21 August 2017 (UTC)[reply]

One thing I've always wondered, is why {{ja-r}} and {{ja-usex}} were not designed as having Kanji directly and adjacently annotated by kana. All the % markup is rather cryptic and unsightly. For example, 般若波羅蜜多 can have

観(かん)自(じ)在(ざい) 菩(ぼ)薩(さつ) 行(ぎょう) 深(じん) 般(はん)若(にゃ) 波(は)羅(ら)蜜(みっ)多(た) 時(じ) 照(しょう) 見(けん) 五(ご)蘊(うん) 皆(かい) 空(くう) 度(ど) 一(いっ)切(さい) 苦(く)厄(やく)

(or something similar), rather than the current

観%自%在 %[[菩%薩]] %行 %深'''%般%若 %波%羅%蜜%多''' %時 %照 %見 %[[五%蘊]] %皆 %空 %度 %一%切%苦%厄…|^かん%じ%ざい %^ぼ%さつ %ぎょう %じん '''%はん%にゃ %は%ら%みっ%た''' %じ %しょう %けん %ご%うん %かい %くう %ど %いっ%さい %く %やく…

In addition the module should be made more intelligent as well by knowing that Kanjis cannot start with certain morae (nasal or sokuon), so that something like いっせ or はんし can be correctly interpreted automatically, without resorting to %. Wyang (talk) 08:07, 21 August 2017 (UTC)[reply]

Personally I like the way kanji and kana are separate; the text remains fairly legible (to the degree that pure kana text is legible). The problem with % is that it was an afterthought, and the problem with the module is that it is not clever enough. Maybe it could be modified to support both styles of markup. —suzukaze (t・c) 08:16, 21 August 2017 (UTC)[reply]

I agree the module needs improvement. Even where the alignment of the ruby is more or less correct, it isn't quite perfect: for instance, compare {{ja-r|兄弟|きょうだい}} → 兄弟(きょうだい) (kyōdai) with {{ja-r|兄%弟|きょう%だい}} → 兄(きょう)弟(だい) (kyōdai). In the second case, the kanji 弟 are centered below the three or two kana that indicate their pronunciation, while in the first the two kana are centered below all five kana. (This is more obvious in the HTML.) I think in this case the module should try to figure out which kana belong with which individual kanji, rather than centering each group of kanji below the sequence of kana that correspond to them.

Moraic and syllabic analysis of the kana could play a part. For instance, in the current example, perhaps the module could calculate that the sequence きょうだい (kyōdai) consisted of four morae (きょ、う、だ、い). And secondly (as already mentioned), if っ and ん are involved, the module should consider them and the previous mora to constitute a syllable, which then cannot be divided between kanji. Perhaps then these morae or syllables could be divided up equally between kanji. In the example above, it would give the right result. In other cases, it might not, in which case percents would be required. But it would be good for the module to try to figure out which kana belong to which kanji, instead of doing what it does now. — Eru·tuon 19:56, 21 August 2017 (UTC)[reply]

I created a function that does the syllabic and moraic division: Module:User:Erutuon/ja. — Eru·tuon 20:39, 21 August 2017 (UTC)[reply]

Bugs in translation adder[edit]

@Dixtosa: Here is a screenshot showing two separate bugs in the translation adder:

The second translation added displays on a new line in the preview (although it is saved correctly when the translations are saved).
There are extra blank lines in place of the hidden gender checkboxes that take up unnecessary space.

--Wiki Tiki 89 15:28, 23 August 2017 (UTC)[reply]

The second feature request is fulfilled. Dixtosa (talk) 18:00, 23 August 2017 (UTC)[reply]

Thanks! Hopefully the first one is easier to fix. --Wiki Tiki 89 19:04, 23 August 2017 (UTC)[reply]

Special:Tags accountability[edit]

A bunch of these are still not properly documented. How can I get from that page to the actual code/regex/etc. that causes the given tag to be triggered? For example, I want to document what NewNum does. Where do I find the code? Equinox ◑ 22:55, 25 August 2017 (UTC)[reply]

I have found one abuse filter that adds this tag. Dixtosa (talk) 08:38, 26 August 2017 (UTC)[reply]

Global preferences – do you want local overrides?[edit]

Hey everyone, m:Community Tech are working on global preferences, to make it possible to set preferences for all Wikimedia wikis instead of for each one individually (which you’ll still be able to do – global preferences will be optional). You can read more at m:Community Tech/Global preferences.

The developers are now investigating how important it is to override global preferences locally, which would mean you set a preference for almost all wikis but still have different settings on one or a few wikis. Maybe because you’re more active on one wiki, maybe because you edit in different ways there. If you want to be able to set exceptions to global preferences it is important that you tell the developers this now. Tell them what, how you’d use it and why it is important on this talk page.

This is only necessary if you want global preferences and exceptions to them. If you only edit one wiki, or are happy having the same preferences everywhere, you can ignore this.

The reason they’re asking is it’s technically complicated to build. /Johan (WMF) (talk) 15:38, 28 August 2017 (UTC)[reply]

I have never yet needed local overrides (in about a decade). I actually find it mildly annoying each time I go to a new wiki and get the alert flag (red thing at top-right) for messages on other wikis, because I haven't yet set "only show local messages" in my global settings at the new wiki. Equinox ◑ 15:40, 28 August 2017 (UTC)[reply]

@Johan (WMF): Thanks for asking! If global preferences are implemented, I would certainly use them, and I would certainly want local overrides. The preferences I use on Wiktionary and Wikipedia are slightly different, and I wouldn't want differences like that to prevent me from benefiting from global preferences. --Wiki Tiki 89 15:45, 28 August 2017 (UTC)[reply]

Wikitiki89: Happy to hear they'll be helpful. If possible, please try to shortly explain why you'd want local overrides on this talk page on Meta, that'd be very helpful (true for everyone else, too). (: /Johan (WMF) (talk) 16:51, 28 August 2017 (UTC)[reply]

I have only edited on four projects (WP, enwikt, species, and commons), but probably more than 98% on enwikt. One the others, I only do occasional corrections or minimal additions. I'm happy to dispense entirely with global preferences and set my preferences one project at a time. Alternatively, I could live with global preferences with no overrides. I would like developers to provide me with a lexicographer's workbench instead. DCDuring (talk) 16:37, 28 August 2017 (UTC)[reply]

Pronunciation evaluation gadget for Wiktionary: GSoC 2017[edit]

Every dictionary need to provide phonetic representation of a word along with its written form. With advanced speech recognition tools now available, it's also possible to evaluate and correct user's pronunciation. I have shown it in a live demo hosted here. I request the admins to grant me permission to create a Gadget which will evaluate the pronunciation of a user within Wiktionary. Here's how the gadget will look like.

.

I want to create a page: https://en.wiktionary.org/wiki/MediaWiki:Gadget-pronunce.js This page will contain the contents of https://en.wiktionary.org/wiki/User:Brijsri/common.js.

Finally, I would like to publish it as a gadget. Thanks for the help.

This is interesting to me. I am less interested with the idea of 'correcting' pronunciation than in evaluating pronunciation and producing valid IPA representation. That is, allow contributors to add regional/dialectic variant pronunciations via a gadget. e.g. Parisian vs. Québecois, Delhi vs. London, etc. - Amgine/^t·e 15:17, 30 August 2017 (UTC)[reply]

Thanks for the suggestions. I will incrementally implement these requirements. Kindly create this page (https://en.wiktionary.org/wiki/MediaWiki:Gadget-pronunce.js) so that I can proceed with the development. Thanks! — This unsigned comment was added by Brijsri (talk • contribs).

You need to be an admin to edit MediaWiki namespace. As for your script it won't become a gadget until it is well tested. Last time I included your script it did not produce what was expected of it I think in Chrome. I make a screenshot if you wish. Giorgi Eufshi (talk) 06:29, 5 September 2017 (UTC)[reply]

`{{R:IEC2}}` not working[edit]

See càncer. Ultimateria (talk) 16:55, 30 August 2017 (UTC)[reply]

It looks like a temporary problem with the external website, or has it relocated to a different URL or even shut down? — SGconlaw (talk) 17:06, 30 August 2017 (UTC)[reply]

The front page leads to the dictionary just fine. Ultimateria (talk) 19:46, 30 August 2017 (UTC)[reply]

Fixed. DTLHS (talk) 19:56, 30 August 2017 (UTC)[reply]

Linking to transliteration[edit]

At lahar, {{bor|en|jv|ꦭꦲꦂ|tr=lahar|notext=1}} knows to attempt to link the transliteration lahar to lahar#Javanese, since Javanese can also be written in Latin script, but it's not smart enough to realise that it is on the very page it is trying to link to. As a result, the translit gets bolded as lahar. This should be fixed so that the link is not direct in this case. —Μετάknowledge^{discuss/deeds} 00:27, 31 August 2017 (UTC)[reply]

Category:French nouns with missing forms[edit]

All the entries in this category seem to have no missing forms. However (deprecated template usage) yodleur, which does, is not in the category. Any ideas? SemperBlotto (talk) 10:46, 31 August 2017 (UTC)[reply]

p.s. "Category:French adjectives with missing forms" and "Category:French nouns with missing plurals" seem to be suffering from the same problem.

It seems like the category is just being updated very slowly- I was able to get yodleur to show up with a null edit. DTLHS (talk) 16:06, 31 August 2017 (UTC)[reply]

It was my mistake: fixed. I seem to sometimes have a problem with getting basic logic right: I had made the "missing forms" categories track forms that have entries. — Eru·tuon 19:40, 31 August 2017 (UTC)[reply]

Detection of invalid IPA not working?[edit]

Someone just added IPA to bekerkard, but there's some HTML in there. How come this isn't being marked as invalid IPA? I'm not aware of any particular significance to an IPA superscript schwa. —Rua (mew) 18:30, 31 August 2017 (UTC)[reply]

Actually the superscript schwa is used in IPA, but the ᵊ character is what is meant to be used for that. But here, it's really the <, >, and / that should be detected as invalid (unless they are in fact used for something). I don't know if the superscript schwa is correct here or not. --Wiki Tiki 89 19:09, 31 August 2017 (UTC)[reply]

(edit conflict) Because HTML tags are removed before the module checks for incorrect characters. The characters in HTML tags aren't really invalid IPA characters; they make up the formatting that is applied to the characters. And the category gets messy and useless if HTML is tracked in it. However, if you want to track superscript tags, or schwa encircled in superscript tags, that can certainly be done. — Eru·tuon 19:21, 31 August 2017 (UTC)[reply]

@Erutuon: Why do we allow HTML tags in IPA? --Wiki Tiki 89 19:35, 31 August 2017 (UTC)[reply]

@Wikitiki89: I don't know. But they are there, and tracking them as invalid characters makes no sense. — Eru·tuon 19:36, 31 August 2017 (UTC)[reply]

Paired HTML tags in IPA are now tracked with the category IPA pronunciations with paired HTML tags. — Eru·tuon 19:47, 31 August 2017 (UTC)[reply]

So far it seems they are only used for tone marking in reconstructed Middle Chinese. Since those transcriptions are automatically generated, I think we should create a way for them to bypass the check for invalid characters (or perhaps not treat those transcriptions as IPA at all, since they really aren't if they are using non-IPA tone marking), and then ban HTML tags from IPA. --Wiki Tiki 89 20:05, 31 August 2017 (UTC)[reply]