I want to add scripts I learn but two {{User Mymr-1}}
and {{User Khmr-1}}
don't get added:
Using {{Babel|Cyrl|Latn|Hira-4|Kana-4|Arab-4|Hang-4|Hani-3|Jpan-3|IPA-3|Grek-2|Deva-2|Thai-2|!||Bopo-1|Hebr-1|Khmr=1|Mymr=1|align=left|footer=Scripts I can contribute in|header=Scripts}}
--Anatoli T. (обсудить/вклад) 06:57, 2 May 2018 (UTC)
Please, could all the words become clickable (black colour)? And blue only if a specific #, or a particular page (Appendices etc) or external. Especially at UsageExamples... and definitions. Would be great. sarri.greek (talk) 10:55, 2 May 2018 (UTC)
What's the technical reason why incategory:"en:Nautical" doesn't work? — This unsigned comment was added by 208.71.184.41 (talk) at 22:22, 3 May 2018.
Wikitext syntax highlighting, also known as CodeMirror, has been moved out of Beta Features and is available in the 2017 Wikitext Editor on all wikis. Syntax highlighting helps you see problems in your wikitext before previewing or publishing text. Please try out the tool if you did not do so while it was being developed, and feedback is welcome. - Keegan (WMF) (talk)
18:55, 4 May 2018 (UTC)
Hello. I create this module on Azerbaijani Wiktionary. But I want write info.cat_name with lower case. How I can do that? For example change from English terms derived from Turkic languages to English terms derived from turkic languages. Please help me. --Drabdullayev17 (talk) 20:29, 4 May 2018 (UTC)
info.cat_name
has been set to either source:getCanonicalName()
or source:getCategoryName()
, where source
is a language object from Module:languages or a language family object from Module:families. So you will have to edit Module:languages or Module:families, or their data modules such as Module:languages/data2 and Module:families/data, to change "Turkic" to "turkic"."turkic"
, not "Turkic"
) because Azerbaijani doesn't capitalize language names. (But Azərbaycan
, the name of the country, as the name for az
, and it is capitalized.) Then you can capitalize the first letter of the category name (english terms derived from turkic languages
→ English terms derived from turkic languages
) with code like the following: category_name = mw.getContentLanguage():ucfirst(category_name)
. — Eru·tuon 23:08, 4 May 2018 (UTC)
"Turkic"
to "turkic"
in az:Module:families/data, but you will have to change the rest of the language family names. This may cause problems in places where language family names need to be capitalized. — Eru·tuon 20:54, 5 May 2018 (UTC)
Özbək dilində Ərəb mənşəli sözlər
→ Özbək dilində ərəb mənşəli sözlər
) --Drabdullayev17 (talk) 21:20, 5 May 2018 (UTC)
"Ərəb"
to "ərəb"
. I believe the module is az:Module:languages/data2. — Eru·tuon 21:24, 5 May 2018 (UTC)
az
, Azərbaycan) and some are not (ar
, ərəb). Is this correct? — Eru·tuon 22:02, 5 May 2018 (UTC)
I have a proposal, can WMF add "wikitionary.org" as an alias domain name for "wiktionary.org" ? It is currently being typosquatted, but it used to 404. The typosquatting could cause potential readers to gain unwanted malware. -- 65.94.42.219 03:53, 5 May 2018 (UTC)
There's probably no way around it but inserting brackets breaks the display of Arabic connected letters, compare: عَنِّي (ʕannī) (connected) with عَنِّي (ʕanniy) (disconnected), even without diacritics: عني. --Anatoli T. (обсудить/вклад) 03:52, 8 May 2018 (UTC)
Inspired by Wiktionary:Tea_room/2018/May#doleful, a feature request: similar to how {{en-noun}}
accepts a (short sequence of) parameter(s) that makes it display "usually uncountable, plural ", it would be useful if {{en-adj}}
accepted some parameter(s) to display something like "comparative usually more doleful, sometimes dolefuler, superlative usually most doleful, sometimes dolefulest". Alternatively, allowing individual forms to be qualified, as in {{en-verb}}
, could be useful. - -sche (discuss) 16:08, 9 May 2018 (UTC)
|gloss=
parameters to the template. — SGconlaw (talk) 12:20, 20 May 2018 (UTC)I have been working to reduce the number of entries with misnested tags or incorrect formatting (here) from upwards of 500 down to less than 50. There are some pretty interesting abuses of wikitext in the remaining pages, and it would be great if we could get the list down to zero. To identify where on the page the invalid wikitext is present, click the "edit" link on the lint errors page (this is not a normal edit link), then scroll through the edit box to find the highlighted text.
When this wiki is switched over to RemexHtml, the new wikitext presentation engine, the display of these pages may change. This could happen quite soon, so it is in the interests of this project to clean this up.
The errors in namespaces other than "main" are probably not worth worrying about. This, that and the other (talk) 11:57, 11 May 2018 (UTC)
I suggest Template:slim-wp, based on {{wp}}
, which would be a handy shortcut. DonnanZ (talk) 13:18, 16 May 2018 (UTC)
{{swp}}
, but I've added your suggestion. --Per utramque cavernam 13:20, 16 May 2018 (UTC){{swp}}
works fine. DonnanZ (talk) 14:47, 16 May 2018 (UTC)
Why is it that I slap
{{citations}}
on Citations:aporically and it's fine, but doing so on Citations:paint the mice gives an error message? Also, why don't we get a bot to put
{{citations}}
on all Citations pages without it. Should we care about such a minor thing? I certainly don't. --Genecioso (talk) 10:23, 20 May 2018 (UTC)
{{citation}}
as {{citations}}
is just a redirect to the former. — SGconlaw (talk) 11:28, 20 May 2018 (UTC)
{{citations}}
makes more sense as the main template. Also, that template has become way overbuilt over time. We don't use a bot to place the template on all citations pages because the template is supposed to include a language parameter. - TheDaveRoss 12:06, 20 May 2018 (UTC)
But to respond to Genecioso's original question, I have no idea why the template behaves that way. Pinging @Daniel Carrero, Erutuon who have edited the template and probably know more about how it works. — SGconlaw (talk) 12:19, 20 May 2018 (UTC)
{{sa-IPA}}
is producing unusual HTMLIt appears that sa-IPA is producing HTML with abnormal nesting, unless the "Raw HTML output" of Special:ExpandTemplates is wrong. The <div>
s are very unusual. One of them seems to be opened before an <ul>
and closed inside a <li>
???
Firefox is also rendering the result as <li>
s without enclosing <ul>
s, which looks very weird. —Suzukaze-c◇◇ 05:22, 21 May 2018 (UTC)
{{quote-book}}
When I put just a year in the date parameter, it generates May 21 as the day. See aguacatero. Ultimateria (talk) 15:06, 21 May 2018 (UTC)
In using the dictionary extensively the browser history is a little lacking for tracking progress, so to speak. I have often desired a graph with semantic features, a mind map of sorts, with chronology or not. Before I eventually attempt to write my own, I thought it best to ask for existing solutions along that line, or other input. 89.204.137.210 21:05, 21 May 2018 (UTC)
The consensus here is to migrate {{ga-decl-adj-1}}
, {{ga-decl-adj-1a}}
, and {{ga-decl-adj-2}}
to {{ga-decl-adj}}
. This is going to be pretty complicated, but please do the following:
1. For {{ga-decl-adj-1}}
:
|1=
into |1=
and |2=
according to the guidelines given at {{ga-decl-adj}}
(note that bh, ch, dh, etc. do NOT lenite)|2=
(minus the new |1=
) to |gsm=
|slender=
for the most part (see below)|gsf=
(once again, minus the new |1=
) to |gsf=
and set the new |gsf=~e
if the old |gsf=
is missing|pl=
(minus the new |1=
) to |pl=
and set the new |pl=
equal to "~e" if the old |pl=
is missing and |slender=
is there and "~a" if it isn't|comp=
to |irrcomp=
|nocomp=
to |comp=-
2. For {{ga-decl-adj-1a}}
:
|1=
into |1=
and |2=
as outlined above|2=
and pass it to |3=
unless |2=ia
; then do the following:
|2=
|gsf=
|pl=~a
|nocomp=
to |comp=-
|sp=
3. For {{ga-decl-adj-2}}
:
|1=
into |1=
and |2=
as outlined above|2=
and |3=
into |3=
|2=
(if any) and move it to |3=
|nocomp=
to |comp=-
I know this is really complicated, but we would greatly appreciate if someone could do this for us. Esszet (talk) 17:35, 22 May 2018 (UTC)
|1=
and omitted from the other parameters. Adjectives starting with anything else should have |1=
empty. So it should be {{ga-decl-adj|d|ual|gsm=uail|gsf=~e|pl=~a}}
, {{ga-decl-adj|g|ar|gsm=air|gsf=~e|pl=~a}}
, {{ga-decl-adj|sá|il|gsf=~e|pl=~e}}
, and so on. Otherwise, it all looks good at first glance. Thanks for doing this!! —Mahāgaja (formerly Angr) · talk 13:22, 23 May 2018 (UTC)
{{ga-decl-adj|B|údaíoch|gsf=údaíche|pl=~a}}
instead of {{ga-decl-adj||Búdaíoch|gsf=Búdaíche|pl=~a}}
. (For the s-clusters only the S itself will be capitalized.) Otherwise I'm not finding any errors. Is it possible for the bot to throw up an error in case it finds one of the old template on a nonlemma ("adjective form" or "mutated adjective") page? They should only be on lemma forms, and on your sample I only see lemma forms, but it's remotely possible someone put one on an inflected or mutated form by mistake. —Mahāgaja (formerly Angr) · talk 13:59, 23 May 2018 (UTC)
{{ga-decl-adj-2|fearú|i|l}}
→ {{ga-decl-adj|f|ear|úil}}
{{ga-decl-adj-2|difriú|i|l}}
→ {{ga-decl-adj|d|ifri|úil}}
{{ga-decl-adj-2|fearamh|ai|l}}
→ {{ga-decl-adj|f|ear|amhail}}
{{ga-decl-adj-2|có|i|r}}
→ {{ga-decl-adj|c|ó|ir}}
{{ga-decl-adj-2|deac|ai|r}}
→ {{ga-decl-adj|d|eac|air}}
{{ga-decl-adj-2|gaisceamh|ai|l}}
→ {{ga-decl-adj|g|aisce|amhail}}
{{ga-decl-adj-1a|2=iach}}
can't be converted to {{ga-decl-adj|3=iach}}
, so leispiach should have {{ga-decl-adj||leispiach|gsf=leispiaiche|pl=~a}}
(N.B. -iaiche, not *-iache). —Mahāgaja (formerly Angr) · talk 15:24, 23 May 2018 (UTC)|sp=
, I'd prefer it if the bot didn't touch templates with |sp=old
. Those shouldn't be migrated yet. (At some point we're hoping to get a module to do all this work instead of the complexity of {{ga-decl-adj}}
, but neither Esszet nor I know how to write a module.) —Mahāgaja (formerly Angr) · talk 15:28, 23 May 2018 (UTC)
{{ga-decl-adj-1a|leisp|ia}}
, which appears to follow Esszet's 2.2. In such cases the new form should be {{ga-decl-adj||ROOTiach|gsf=ROOTiache|pl=~a}}
? Should I skip only cases where "sp=old" or any instance which has "sp" at all? - TheDaveRoss 15:35, 23 May 2018 (UTC)
{{ga-decl-adj}}
doesn't recognize the parameter |3=iach
at all. The form should be {{ga-decl-adj||ROOTiach|gsf=ROOTiaiche|pl=~a}}
(don't forget the extra i before the ch!). Please skip only cases where "sp=old"; cases with "sp=new" or "sp=both" can be processed and the "sp=" part ignored. —Mahāgaja (formerly Angr) · talk 15:45, 23 May 2018 (UTC)
|gsf=
, not “iach” to |3=
. I didn’t say anything about |3=
there at all. Esszet (talk) 16:05, 23 May 2018 (UTC)@Wikitiki89. At the moment, נ־ש־א is in CAT:E, but there's nothing on the page itself that explains why. That's because the template {{HE root see}}
is passing {{#invoke:he-utilities|plain_root|{{#if:{{{1|<noinclude>x</noinclude>}}}|{{{1<noinclude>|כתב</noinclude>}}}|{{SUBPAGENAME}}}}}}}} to {{derivsee}}
, which in turn passes it to the parser function #categorytree
. Parser functions, generally, are designed to fail gracefully and invisibly if given bad input, so all the big fat screaming red lua-error displays are swallowed silently and nothing is displayed.
This is very bad interface design because contributors using {{HE root see}}
have to know about templates and about parser-function behavior to find out why there's a blank space where the template display should be- if they even notice. I had to copypaste the invocation syntax with the parameter substituted in into the edit window and preview it to see the error display (the module didn't like the middle letter in the root).
Even people who know Lua and the rudiments of template coding might have problems figuring this out. Fortunately, I've run into this kind of thing before, so I knew to look through the templates listed until I found one that fed a parameter into a parser function.
We need to develop some way to make sure this doesn't happen. Ideally, all input for parser functions should be checked, and errors displayed rather than passing the input to the parser function. Sure, it adds to the complexity of the code, and it requires extra memory and often extra expensive-function calls, but we need to make it easier for our contributors to do things right.
Perhaps we need to make sure that all modules used in such ways have a validity-check function and/or something like the err function at Module:languages, or maybe we need to include intermediate code in the template that checks the parser-function inputs for error messages and decides whether to display the text as errors or feed it to the parser functions.
As an aside, it would also be nice to include better error handling in the translation adder so it doesn't add masses of error text to the entry when someone uses a bad language code.
Thanks! Chuck Entz (talk) 00:08, 26 May 2018 (UTC)
{{zh-pron}}
is pushed down by Wikipedia link and imagesAdding "overflow: hidden" to div.zhpron fixes this, but I don't know if it's the appropriate solution. — This unsigned comment was added by 2001:da8:204:1088:a0f9:7563:cf87:8edb (talk).
The behavior of various templates including {{compound}}
and {{m}}
has changed some time in the past few weeks, such that formatting in tr
strings has become problematic.
In the past, the tr
values were output surrounded in <i>
tags, such that {{m|||tr=}}
would produce the equivalent of #|]] (<i></i>)
. In cases where additional transliterations were required, one could add a closing </i>
tag after the first transliteration and a <i>
tag before the second one. This worked fine for years, such as at 藍: {{m|ja|青|tr=ao</i>, formerly <i>awo||]}}
reliably produced 青 (ao, formerly awo, “blue”) -- where the ", formerly" is contrastively not in italics, while "ao" and "awo" are both italicized.
(NB: Alternative approaches, such as using the pos
parameter for such additional information, do not work -- the pos
values are always placed after the tr
values and after the term gloss.)
However, with the recent changes, the above tag-based approach fails: inspecting the markup shows that the closing tag is stripped, resulting in too many opening <i>
and unwanted italicization of the rest of the paragraph. Attempting to use ''
wikitext instead of <i>
fails: the rendered markup shows that the first ''
, which is expected to turn off italics, is instead an opening italics <i>
, while the second ''
closes it as </i>
, which ultimately does nothing in an already-italics context. Experimentation shows that certain inline closing tags (</i>
, </b>
, </u>
) are stripped, no matter how many were added, but some (such as </span>
) are kept -- suggesting that the underlying module is doing some kind of selective cleanup.
For the {{compound}}
template, one related change appears to be this one by Benwing to Module:compound in late April. However, that itself was in response to changes in other modules, and I have not been able to find any similar changes to {{m}}
or Module:links.
This change in behavior is a problematic deviation from past norms, and it is causing a bit of a mess on various JA entries that were formatted in accordance with the past behavior. I'd greatly appreciate it if someone could 1) explain where the change occurred, 2) explain the reasoning behind this selective stripping of markup from tr
strings, and 3) either back out these changes to tr
behavior, or explain how to again achieve output like 青 (ao, formerly awo, “blue”).
TIA, ‑‑ Eiríkr Útlendi │Tala við mig 16:17, 29 May 2018 (UTC)
{{compound}}
to not strip things quite so aggressively?tr
argument string for wikicode and handle it accordingly?tr
string is output in <span class="mention-tr tr">
tags, which render in italics according to our CSS. The current behavior takes a tr
input string like ''this'' sample
and outputs it as <span class="mention-tr tr">like <i>this</i> sample</span>
. However, since the context of the string (as enacted by the <span>
style) is already italics, the <i>
tags don't do what we'd expect -- the anticipated behavior for the ''this''
would be non-italics. More ideally, the tr
output when using ''italic wikicode''
would be something more like <span class="mention-tr tr">like </span>this<span class="mention-tr tr"> sample</span>
.{{affix}}
or similar templates. I did notice a change a month or two ago where the translation stopped being in italics in certain places (maybe in headwords?), but I figured that was an intentional change, and it may be unrelated to the problem you're seeing. There have been a lot of code changes by User:Erutuon affecting these modules, and some by User:JohnC5; it's possible they may have changed this behavior, but I'm not sure. You're right that the code is quite complex. Benwing2 (talk) 14:19, 1 June 2018 (UTC)<i>
tag when Module:script utilities is tagging transliteration with the "term" markup. The term markup is used by {{m}}
for instance, as well as many etymology templates such as {{der}}
. I did this because transliteration parameters sometimes include kana, which shouldn't be italicized. There is a note to this effect in Module:script utilities/data.class="tr mention-tr"
and with lang="language code
-Latn"
, and the non-transliteration text should not be. But it is clear that the non-transliteration stuff is sometimes needed. I don't know what the solution should be. More parameters, some markup to indicate which part of the transliteration parameter is actually transliteration and should be tagged, separate templates for whatever languages need this annotation in the transliteration parameter? — Eru·tuon 22:27, 1 June 2018 (UTC)Can someone do that? Because, as here, people (including me when I'm not thinking about it) recurringly use it as the POS parameter, because because it's much shorter to type and it works in e.g. {{m|en|valid|pos=adj}} and is used in naming many headword-line templates. - -sche (discuss) 07:57, 30 May 2018 (UTC)
{{head}}
.) - -sche (discuss) 08:04, 30 May 2018 (UTC)
I've just noticed the {{suffix}}
template has a useful feature that {{affix}}
doesn't have. I want to split CAT:French words suffixed with -ment in CAT:French adverbs suffixed with -ment + CAT:French nouns suffixed with -ment. At abondamment, writing {{suffix|abondant|-ment|lang=fr|pos=adverbs}}
produces automatic categorisation to the right subcat, while {{af|fr|abondant|-ment|pos2=adverbs}}
doesn't. Would it be possible to give that behaviour to {{affix}}
as well? --Per utramque cavernam 20:39, 30 May 2018 (UTC)