@Kutchkutch, Erutuon, -sche: What was the rationale for forking Module:Brah-translit to yield Module:sa-Brah-translit rather than adding a few lines at the end to convert the transliteration to IAST for the languages that use it? I thought the rationale for having Module:translit-redirect was that a page would only need to load one Brahmi transliteration module. As an example of a less elegant mechanism, Module:pi-translit (as of this morning not yet hooked into the transliteration system) invokes Module:Brah-translit and Module:si-translit and then converts their outputs to IAST. I was planning, once Module:pi-translit is hooked in, to incorporate conversion code in the Brahmi and Sinhalese modules to convert transliteration of Pali and Sanskrit to IAST. --RichardW57m (talk) 12:21, 2 June 2021 (UTC)
add a few lines at the end of Module:Brah-translit. If you know how to modify Module:Brah-translit so that it can replace Module:sa-Brah-translit at Module:translit-redirect/data without changing the current arrangement for Sanskrit (or causing errors with the languages that currently use Module:Brah-translit), then please go ahead with your planning (notifying @SodhakSH). Kutchkutch (talk) 09:54, 3 June 2021 (UTC)
|func_with_link= to allow the user to provide a function that does all the formatting of the 'example' column in the outputs. That seems a lot of heavy work compared to the seemingly light coding in Module:si-translit/testcases, which also handles two different transliteration standards for one script. My question now is whether I should integrate the enhancements back into Module:transliteration module testcases, or just convert the testcase module to work like the Sinhalese one. I don't want the new support module to hang around for long. --RichardW57 (talk) 22:02, 5 June 2021 (UTC)
@Benwing2, Daniel Carrero, DCDuring, Dixtosa, Erutuon, Rua, Vriullop: https://dixtosa.toolforge.org has stopped working with the error Connection failed: Unknown database 'enwiktionary_p'. Is there a way to fix this or a workaround? Kutchkutch (talk) 10:02, 3 June 2021 (UTC)
% if you want. — Eru·tuon 01:24, 5 June 2021 (UTC)
I see a template use that has an attribute who's meaning is not obvious to me from the name. How do I lookup the attributes that a particular template supports and what they mean? - Dough34 (talk) 14:21, 3 June 2021 (UTC)
|nocat= is a very common parameter used in a large number of templates. Setting |nocat=1 prevents the template from adding the term to the category that it otherwise would add the entry to. However, {{plural of}} doesn't actually categorize entries it's added to, so in that case, |nocat= isn't doing anything at all, which is presumably why the documentation for {{plural of}} doesn't mention it. The way to find the source code for a template is to click the Edit button. —Mahāgaja · talk 19:51, 3 June 2021 (UTC)
|nocat= parameter does not do anything, I requested it to not be added to plural forms automatically any more, which is yet to be done. J3133 (talk) 21:45, 4 June 2021 (UTC)Kindly change <center> to <div class="center"> and </center> to </div> to fix the obsolete tag --Minorax (talk) 10:31, 5 June 2021 (UTC)
Hello, happy Sunday from el.wikt. I see that words in your Cateogires link precisely to their language section. Is this done with a module, or some other trick? Thank you ‑‑Sarri.greek ♫ | 05:26, 6 June 2021 (UTC)
require "Module:utilities".catfix(language_object, optional_script_code) into category pages, and then run MediaWiki:Gadget-catfix.js to transform the category links. The gadget is installed here so that it is loaded efficiently by the server. The catfix HTML is inserted either by calling the module function in the module functions that generate category descriptions (for instance in many categories that are added by {{autocat}}) or by using {{catfix}} in a page. So it's a combination of a module and a JavaScript gadget. — Eru·tuon 06:16, 6 June 2021 (UTC)
Category:English irregular plurals is small considering Category:English nouns with irregular plurals has more than 14000 entries: it is not feasible for someone to categorize these manually. J3133 (talk) 19:43, 6 June 2021 (UTC)
Could
if args or args then
textHide = textHide .. "\n* ]"
if args then
textShow = textShow .. "\n* ]: " .. ipaFormat(args, true)
textHide = textHide .. "\n** ('']'') " .. ipaFormat(args)
end
if args then
textShow = textShow .. "\n* ]: " .. ipaFormat(args, true)
textHide = textHide .. "\n** ('']'') " .. ipaFormat(args)
end
end
be changed to
if args or args or args then
textHide = textHide .. "\n* ]"
if args then
textShow = textShow .. "\n* ]: " .. ipaFormat(args, true)
textHide = textHide .. "\n** ('']'') " .. ipaFormat(args)
end
if args then
textShow = textShow .. "\n* ]: " .. ipaFormat(args, true)
textHide = textHide .. "\n** ('']'') " .. ipaFormat(args)
end
if args then
textShow = textShow .. "\n* ]: " .. ipaFormat(args, true)
textHide = textHide .. "\n** ('']'') " .. ipaFormat(args)
end
end
to add the Arik dialect of Amdo Tibetan? --沈澄心✉ 12:53, 9 June 2021 (UTC)
(Sorry if this isn't the right area to bring this up in. I don't really bring this kind of matter up often, so I am not quite certain where it best belongs.)
I recently created entries for all bedlam breaks loose and all bedlam broke loose. Since all bedlam breaks loose is the base form, I put the citations under that form. However, the citations themselves are actually for all bedlam broke loose, not the base form.
Is it proper to put them under the base form, or is it preferred for them to be put under the inflected form? Tharthan (talk) 22:16, 9 June 2021 (UTC)
Have i clicked something wrong? At the moment I view module sources as wikitext. Does it happen to anybody else? ‑‑Sarri.greek ♫ | 08:01, 10 June 2021 (UTC)
Is there a font for the Kharosthi script that at least renders the text in a sensible way? According to the Wikipedia support page, the recommended font is Segoe UI Historic, but that seems to be specific to Windows 10.
On my system the word 𐨠𐨂𐨬 (thuva) (wiki template for the text: {{m|pgd|𐨠𐨂𐨬|sc=Khar}}) displays as if it were "thavu" in the page (the vowel "u" as a little circle thingy on the bottom attaches to the hook-shaped letter for "V", rather than to the cross-shaped letter for "Th"), but it shows up fine in the editing area.
Is there a recommend font/setting/combo solution, preferably without switching to Windows 10? --Frigoris (talk) 17:16, 11 June 2021 (UTC)
.Khar { font-family: 'Noto Sans Kharoshthi'; }. — Eru·tuon 18:24, 11 June 2021 (UTC)
Currently the transliteration module seems unable to deal with Kharosthi modifiers such as "bar above" (U+10A38) or "cauda" (U+10A39). The following texts generate zalgo text in transliteration:
It seems the Kharosthi combining modifiers are not transcribed and are just copied as-is into the Roman-alphabet transliteration, and gets combined to the text somehow. In the second case the "cauda" even combines to the closing parenthesis.
Unfortunately I don't know any Lua to improve the module. Could @AryamanA, Bhagadatta help? Thanks! --Frigoris (talk) 11:22, 14 June 2021 (UTC)
inc-ash also uses Kharoshti). I had to rollback my own edits and reinstate a previous version of the page. I probably should have asked someone for help (e.g. @Erutuon) but it didn't cross my mind then. -- 𝓑𝓱𝓪𝓰𝓪𝓭𝓪𝓽𝓽𝓪(𝓽𝓪𝓵𝓴) 13:26, 14 June 2021 (UTC)Now that we finally have automatic Pali transliteration available, I am now hitting problems because of the range of writing systems seen in the wild. Specifically, issues are arising because of the following features:
Consequently, the automatic transliteration (which would be correct for another writing system), correct transliteration (dependent on knowing the writing system) and Roman script equivalent may all be different. This is rare, but happens. --RichardW57m (talk) 13:02, 14 June 2021 (UTC)
I have been in the habit of using {{link}} and {{inflection of}} to simultaneously link to the word or stem both in the relevant non-Roman writing system and its equivalent in the IAST-based Roman script origin system. I have been using the transliteration output as the link. Now, if it were not for the issues above, setting the 'link_tr' property for Pali would give me exactly what I want. However, this would work incorrigibly badly when the correct transliteration and Roman script equivalent were different. Am I missing a bettwer way of simultaneously linking to non-Roman and Roman script forms of a word or stem? Would someone (e.g. @Benwing2) be open to providing manual control of the link_tr behaviour? --RichardW57m (talk) 13:02, 14 June 2021 (UTC)
Now, I can, and before transliteration, had been, getting the equivalent of manual control by passing the manual transliteration in as the result of {{link}}. However, this never matches the automatic transliteration, and, before I started implementing a work around, the category of pages with mismatching manual and automatic transliterations had reached the size of 360. I have been experimentally reducing these reports by using the as-yet undocumented template {{pi-nr-inflection of}}, which has some fairly dirty behaviour so that it can invoke {{inflection of}}. (Essentially, it has parameters |tr= to override transliteration and |eqv= to override the equivalent form in Roman script.) If I follow this approach, I will need a clutch of susbstitutes for other members of cat:Form-of templates and even {{link}}. --RichardW57m (talk) 13:02, 14 June 2021 (UTC)
I have now created that clutch of replacements:
{{pi-nr-inflection of}} for {{inflection of}}{{pi-link}} for {{link}}{{pi-mention}} for {{mention}}{{pi-alternative form of}} for {{alternative form of}}{{pi-alternative spelling of}} for {{alternative spelling of}}{{pi-combining form of}} for {{combining form of}}{{pi-form of}} for {{form of}}{{pi-misspelling of}} for {{misspelling of}}So far, I have documented the first four, except for the internal support template {{pi-ml}}. --RichardW57 (talk) 01:26, 11 July 2021 (UTC)
Template:R:Merriam-Webster Online produces the text "(Please provide a date or year)". I cannot see, though, any way to add the date or year to uses of the template. The documentation only mentions entry=, url=, and nodot=. There also appears to be a 3=, which I guess is for including quotations from the MWO entry. The documentation needs to be updated to describe how this template actually works currently. Perhaps someone wiser than me could also figure out what is causing that "Please provide date" warning. Cnilep (talk) 01:04, 15 June 2021 (UTC)
Hi, I've been wanting to add some new traditional pronunciations to this module as well as make (see here) what's currently nebulously called "Vulgar" into a default concrete alternative pronunciation called "2nd CE Campanian" while also possibly having a specialized reconstructed proto-Romance (ideally just phonemic), but I'm coding-disabled. I know how to make the current Vulgar be displayed by default, but I'm not sure how to split an existing pronunciation into two, one of which would have to be enabled with the option vul=1 and automatically in the Reconstructed namespace, and the other would be default like current Classical. With Ecclesiastical, I just want to double, triple etc. the current automatic Ecclestiastical output - ideally under a drop-down menu like Ancient Greek (λόγος) and with the general title "Traditional". Starting at line 963 the module generates phonemic and phonetic transcriptions, and the Traditional ones need to output both in a new line, just like all three currently existing ones do.
Additionally, I'd like to be able to add automatic variant outputs to one variety, as with the different syllabification at petra or different pronunciations of y at Syrus without having to manually specify it (alternative syllabification currently requires manual specification as pet;ra). The second case does probably need qualifiers such as "older, hellenizing" instead of just being given inside the same line, but I'm not sure how to implement this either way. Since I'm not likely to suddenly evolve an understanding of Lua, I have to ask for some pointers if not outright for someone to implement it for me. Can I steal the code from somewhere? Which parts of the module do I need to copy-paste and what do I want to keep track of? Mentioning @Benwing, Urszag, J3133, Erutuon, JohnC5 as having edited the module recently. I figured here is more visible than at the module's discussion page. Brutal Russian (talk) 15:03, 18 June 2021 (UTC)
I feel that a reference template to Franklin Edgerton's Buddhist Hybrid Sanskrit Dictionary would be valuable for Sanskrit entries and perhaps also for languages that borrows heavily from BHS, such as Chinese. The dictionary is available from U. Köln's Sanskrit Lexicon website, which also hosts the {{R:sa:MW}} dictionary, among others. Example PDF page output.
The BHS dictionary template would serve a purpose similar to that of the {{R:sa:MW}}, by showing the headword and linking to the PDF server by page number. I can see several parameters in the MW template useful for this, too, such as the ones for resolving page/column.
The problem is that I don't have the skills with wiki templates and their testing & maintenance, even if I presume there's a lot to re-use from the MW template. I appreciate your help! Thank you! --Frigoris (talk) 15:35, 19 June 2021 (UTC)
Carried over from ]:
We have reader complains that mobile pages are always expanded which make the pages hard to see. This becomes a serious problem on LongPages with a hundred entries. Especially that TOC does not appear in mobile view.
I have verified with mobile view that this is the case on WT. Section headings always appear expanded.
I also went to the other WikiMedia projects and their section headers are minimized (collapsed).
Anyone knows why the difference in behavior and how to fix it? Need to call in help from meta:?119.56.97.84 05:55, 30 March 2021 (UTC)
- I will go look for a meta developer to see if I can get some opinions. 119.56.103.124 16:58, 31 March 2021 (UTC)
- This is a global setting active on all Wiktionaries (but not on other Wikimedia projects). It was discussed in phab:T63447, and while I’m also embarrassed by this setting when I read Wiktionary on mobile (as I do a lot), I also understand the reasoning there. —Tacsipacsi (talk) 19:46, 1 April 2021 (UTC)
From ]:
I am bringing this up again for our attention. On mobile pages, language headers are overtly expanded which makes the pages very long to scroll through.
A 2014 change in phabricator was the cause of Wiktionary headers always being expanded. This is different from other Wikimedias which have collapsed headers, which makes it easy to go to header you want to. (shared by someone from the tech community).
I was not sure how much community agreement the change has.
One suggested solution is to set the headers to collapsed again.
A second proposal is to only collapse entries with more than, say, 5 language headers. Then, shorter pages with less than 5 headers will not be collapsed. This behavior is like the _TOC_ box which only appears when there are about 5 or more language headers in desktop view.
I wonder how many of us write on mobile, but increasing number of people use mobile view to visit Wiktionary. This means overly long pages which are difficult to read are driving away readers and potential contributors. So it is quite an important issue. 119.56.98.229 04:54, 4 April 2021 (UTC)
- I was thinking how many pages and how many visitors are affected by this issue. We can have a look at the most visited pages, have a look using mobile view and imagine how it will look like on a phone/tablet. There should be a link to most visited at Special:Statistics119.56.96.203 06:41, 8 April 2021 (UTC)
- Mobile page has been bad on WMF for a long time. Many current readers and editors still use desktop for full functionality, but it is a reality that more people are accessing the web through mobile. The subpar mobile experience has become such an impediment to wikiwork that complaints are filed with User_talk:Jimbo Wales.
119.56.97.153 19:00, 19 April 2021 (UTC)
- Agreed that the mobile user experience is pretty awful. Sometimes pages load on mobile with all the L2 headers collapsed (user talk pages), which is preferable; sometimes they don't (our forum pages, like WT:TEA), and the page can quickly become unusably long. I don't understand why the behavior is different; it comes across as shoddy programming. ‑‑ Eiríkr Útlendi │Tala við mig 18:46, 20 April 2021 (UTC)
- @EirikrSomeone from phabricator, which is WMF volunteer tech working group, complained that it is too much work on Wiktionary to open up the collasped headers when there are only a few headers on a non-talk page. So all the headers are now expanded by default to meet that guy's requirement.119.56.111.132 13:45, 20 June 2021 (UTC)
- meta:Tech/Archives/2021See April. — This unsigned comment was added by 119.56.111.132 (talk).
- Huh. So I was right -- it is shoddy programming. What's worse, it's intentional. :(
- @Anon, thanks for the link. ‑‑ Eiríkr Útlendi │Tala við mig 19:08, 21 June 2021 (UTC)
This is on one of the biggest and oldest projects on Wikimedia.
On mobile site, the header sections which are usually collapsed on other wikis, always appear expanded on this wiki.
Our readers are complaining about this issue. Sections can be very long and always-expanded sections are hard to read. Links to a section don't position correctly, because the link first goes to the section, then all sections expand after that which makes useless the positioning that happens just before.
Would like guidance on what is causing this, and what can be done to correct this behavior. 119.56.97.84 17:35, 31 March 2021 (UTC)
- Answer at wikt:Wiktionary:Grease pit/2021/March#Wiktionary:Information_desk/2021/March#Always_minimize_all_sections_(mobile_version) (I’d appreciated if you’ve given the link, though). —Tacsipacsi (talk) 19:46, 1 April 2021 (UTC)
- @Tacsipacsi So it was a change on Phabricator. Thank you very much for getting the decision for us. And also for visiting our forum (sorry that I did not think to bring it back).
- For us, would need a look on how many pages this seriously affects (as a percentage), to decide if something needs to be done. I do note that it affected your reading wikt.
- Mobile view has been more neglected even though more people are reading on mobile. It is sad when many editors still stay with desktop view because mobile view is still difficult to use. 119.56.100.135 07:05, 2 April 2021 (UTC)
- If there is community consensus to change an existing configuration setting for a Wikimedia website, then please see Requesting wiki configuration changes how to proceed (plus include a reference to phab:T63447). Thanks! --AKlapper (WMF) (talk) 12:17, 2 April 2021 (UTC)
From MobileFrontend user experience on Wiktionary is rough, T63447 on Phabricator:
Authored By
MZMcBride Feb 16 2014, 9:25 PM
Screenshot of https://en.m.wiktionary.orghttps://dictious.com/en/wildcard on an iPhone, 2014-02-16
The MobileFrontend + Wiktionary user experience is pretty rough. Screenshot of https://en.m.wiktionary.orghttps://dictious.com/en/wildcard on an iPhone attached. The page almost looks broken. There's only a single language for this entry yet it's collapsed. Owww.
Given that MobileFrontend is the default for mobile devices, I think this is fairly high priority.
I get that it's inconvenient to have an entry with only one section, and that section is collapsed.
However, that is only an inconvenience -- a mild annoyance.
When browsing to a large page, and all the sections are expanded, the page can be unusable.
Trading a mild annoyance for page unusability is a bad trade.
I don't have time to dig, and all the related Phabricator issues I can find at the moment appear to be closed:
Does anyone know where we could discuss this with the back-end maintainers? Or could we fix this somehow without them? ‑‑ Eiríkr Útlendi │Tala við mig 19:17, 21 June 2021 (UTC)
Is there any reason to keep Module:sa-Modi-translit, for Sanskrit, and Module:Modi-translit, for Old Marathi, separate? There don't seem to be any conflicts yet, and if any arise they can probably be handled by a simple language-sensitive tweak as with Brahmi. Pinging recorded editors - @SodhakSH, AryamanA, DerekWinters, Kutchkutch. Silence is consent. --RichardW57m (talk) 12:35, 22 June 2021 (UTC)
|ts= parameter.the edit history at https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=Talk:;&action=history shows edits up to 2014, but the talk page is unviewable now. it just returns "Bad title" and behaves as if viewing the main page. Sure we can use talk:semicolon but i wonder if this is a bug that can be easily fixed. thanks, —Soap— 15:19, 27 June 2021 (UTC)
There are also seem to be problems with viewing the definition page ... I made an edit just now but can't get to it from my contribs page. —Soap— 15:23, 27 June 2021 (UTC)
{{punctuation}}). The other URL works (e.g., https://en.wiktionary.orghttps://en.wiktionary.org/w/index.php?title=;). J3133 (talk) 15:44, 27 June 2021 (UTC)Do we have control of the basic sorting rules in categories? Where do the basic sorting rules come from? They don't look like ICU/CLDR/DUCET to me.
If we have control, we need to sort out the sorting of:
so that they sort near the corresponding 'Burmese' Burmese script characters. MON NGA does occur in Pali, even if it shouldn't. I think we should also accommodate
just in case. I've seen MEDIAL MA in a Sanskritic spelling; I don't know which the language was. I don't have the privilege to edit the definition of the sort keys. @Octahedron80 --RichardW57 (talk) 04:14, 2 July 2021 (UTC)
U+1028 MYANMAR LETTER MON E already sorts next to U+1027 MYANMAR LETTER E.