MediaWiki talk:Edittools

Definition from Wiktionary, the free dictionary
Jump to navigation Jump to search

Re-organizing the "Misc." section[edit]

Over time, the "Misc." section has become somewhat of a messy bag of mess:

· {{}} # <> “” ‘’ „“ ‚‘ ~ | ° ¿ ¡ º ª «» ‹› ⟨⟩ ® © § ˢᵗ ⁿᵈ ʳᵈ ᵗʰ

To some extent this is because some symbols have been added that maybe aren't so useful (do we need the ordinal superscripts for anything?), but it might help to divide it into subsections, something like this:

Wiki markup: {{}} # <> ~ | ··· Quotation marks: “” ‘’ „“ ‚‘ «» ‹› ⟨⟩ ··· Other punctuation: · ¿ ¡ Mathematical symbols: ° Other symbols: º ª ® © § ˢᵗ ⁿᵈ ʳᵈ ᵗʰ

What do y'all think?

RuakhTALK 16:23, 10 September 2010 (UTC)[reply]

Seems good. I count that ˢᵗ is used on 7 pages, ⁿᵈ on 43, ʳᵈ on 3, and ᵗʰ on 42. Since several of these aren't used often, maybe we could also reorganize. We could have a sub/super-scripts group with the individual characters. We could bring in those from the "Indo-European" section (most of the rest are in "Latin/Roman" and could add the couple missing). --Bequw τ 00:56, 11 September 2010 (UTC)[reply]
That would work.
Re: "I count that ˢᵗ is used on 7 pages, ⁿᵈ on 43, ʳᵈ on 3, and ᵗʰ on 42": More to the point, I believe that all uses are by a single editor, who should perhaps start using User talk:Conrad.Irwin/edittools.js
RuakhTALK 01:15, 11 September 2010 (UTC)[reply]
Put in both changes. --Bequw τ 04:53, 11 September 2010 (UTC)[reply]
Thanks! —RuakhTALK 11:30, 11 September 2010 (UTC)[reply]
What about the other superscript and subscript forms listed here? Are they worth adding? — Raifʻhār Doremítzwr ~ (U · T · C) ~ 15:18, 12 September 2010 (UTC)[reply]
Do we have use in Russian transliteration anywhere? Every time I want one, I have to go to another entry and copypaste. Mglovesfun (talk) 16:03, 28 February 2011 (UTC)[reply]
It's among the long list of quotation marks. -- Prince Kassad 16:15, 28 February 2011 (UTC)[reply]

IPA [g̊][edit]

In the IPA section, we had [g̊], which is loop-tail g, rather than open-tail IPA ɡ. I've corrected it to [ɡ̊]. (If for some reason the non-IPA g was intended, revert...) - -sche (discuss) 03:23, 29 August 2012 (UTC)[reply]

st and ᵈ ⁿ ʳ ˢ ᵗ[edit]

I propose that be removed. Should it ever be used, outside of and the few visually similar entries which link thither? My understanding is that it should not, that st should be used. I also propose that ᵈ ⁿ ʳ ˢ ᵗ be removed unless they have legitimate uses which are more common than, say, Runic (which is also legitimate but was removed by Liliana as not common enough to merit inclusion). ʰ ʷ are used in writing PIE, I know... I think the others were primarily misused by a single editor to represent superscripts in e.g. 2ⁿᵈ (which should have been 2nd). - -sche (discuss) 21:17, 5 September 2012 (UTC)[reply]

Re: : I agree, remove it. Re: superscript letters: I say remove them all, including ʰ ʷ, from the "Miscellaneous" section. ʰ ʷ are already in the "IPA" section, and can be added somewhere else for PIE if desired, but their current location is inappropriate. (There are quite a few things in the "Miscellaneous" section that aren't needed, IMHO.) —RuakhTALK 21:28, 5 September 2012 (UTC)[reply]
, if anyone is interested, are used in writing PIE (see brown, apple). - -sche (discuss) 10:33, 7 September 2012 (UTC)[reply]

trimming duplicated characters[edit]

  1. In the Hebrew section, there is Translit.: á é í ó ú. All of these characters are already present in the Latin/Roman section. We don't duplicate them or macron letters like ē in the Greek section, though they are also used for transliteration of Greek. Should they be removed from the Hebrew section to reduce the size of this page, or should they be added to the Greek section for ease of input without flipping between menu-items, or is the current inconsistency OK?
  2. How much would it reduce the page size to tack enPR on to the end of IPA rather than having it separate?
  3. How much of the Vietnamese section is already in the Latin/Roman and Double Diacritic sections? So much that merging the last little bit is appropriate, or too little to make merging sensible? - -sche (discuss) 21:28, 5 September 2012 (UTC)[reply]
I don't think some duplication is bad. From a systematic point of view, we should not duplicate anything and group it all neatly by script type and such. But that's less optimal from a usability point of view because people will have to constantly switch between the tabs even for a single language. So a compromise may improve things for the editors even if it's not as 'neat'. Languages that have significant amounts of characters that are otherwise spread across several tabs may warrant a tab of their own. In particular I think a tab for reconstructed languages would be very welcome. —CodeCat 21:37, 5 September 2012 (UTC)[reply]
Re item 1, I added (or requested the addition of) á et al. to the Hebrew section. I used it frequently when I used the Hebrew section, and I was one of few Hebrew editors. (Now I use User:Conrad.Irwin/edittools.js instead.) IMO if you want to remove it, check with the Hebrew editors instead of only discussing it here. (Same for Vietnamese and item 3, and Greek and item 1, IMO.)​—msh210 (talk) 06:32, 6 September 2012 (UTC)[reply]

and [edit]

These should be removed. They are used in fewer than fifteen entries. (An argument against removal is: they're hard to find when they are needed. But so are the Runic letters...) - -sche (discuss) 10:39, 7 September 2012 (UTC)[reply]

Agree. Mglovesfun (talk) 10:49, 7 September 2012 (UTC)[reply]

Characters with combining diacritic + combined diacritic?[edit]

For writing PIE, we need to be able to write vowels containing both a macron and an acute accent. In the case of ḗ and ṓ, those combinations are already present in Unicode, but the combinations ā́ ī́ ū́ are not. PIE also sometimes needs to write syllabic resonants with an accent: ŕ̥ ĺ̥ ḿ̥ ń̥. Those too are not part of Unicode. Is it ok to add such combinations, even if they are not 'characters' in the Unicode sense? —CodeCat 11:12, 7 September 2012 (UTC)[reply]

Yes. Maro 15:08, 7 September 2012 (UTC)[reply]
Yes, those characters should be included. Let's create a dedicated PIE reconstructed languages section for such characters (per your earlier comment, so it can also include other things). Are l̥ m̥ n̥ r̥ (currently in Latin/Roman) used for anything but PIE? If not, they can be moved. (currently in Misc.) should also be moved, and ʰ ʷ could be duplicated (if ʷ is common enough in IPA transcriptions to be kept in the IPA section rather than outright moved). Also consider moving ₁ ₂ ₃ from Misc. - -sche (discuss) 18:21, 7 September 2012 (UTC)[reply]

Size by section.[edit]

Since there seems to be interest in removing unnecessary characters and sections, I thought the discussion might benefit from some statistics on which sections are largest, in terms of total number of bytes.

So you have a basis of comparison for the below values: the HTML page for adding a new section to [[MediaWiki talk:Edittools]] (i.e., contains 24,488 bytes that are not part of the edit-tools, and 27,954 bytes that are part of the edit-tools. So the edit-tools are somewhat over half the downloaded content.

sectionsize (bytes)
Sign languages2884
Japanese Kana977

This doesn't necessarily tell us which sections will be easiest to cut things from, but it might help us decide where to start looking.

Notice that some sections contain many more bytes than you might expect from the number of symbols in the section. For example, in the "Miscellaneous" section, HTML snippets like <span title="multiplication sign"><span class="charinsert">×</span></span> are obviously much "bigger", in terms of bandwidth, than a single character in the "African" section. This means that, in cutting down the size of edit-tools, we should also consider why we're cutting them down. Are we cutting them down because it's unreasonable to include so much in the download every time anyone opens an edit-page on a mobile device? Or are we cutting them down because they become unusable and unwieldy when there are too many characters in each section? These two motivations will not give identical results. (I think they're both good reasons, and I think we should consider both factors, but it's not clear to me which is a higher priority, or by how much.)

RuakhTALK 18:42, 7 September 2012 (UTC)[reply]

It seems a bit pointless to include two span tags, so that is one thing we can cut down on. The download size hasn't been a big problem for me, nor has the size of the sections as such. I find it more annoying when I have to keep switching between sections for a single task. A page for reconstructed languages might help, but we could also consider that many people tend to work on related languages, so we could group them together (one page for all Slavic languages). An even better solution would be to make them customisable, so that everyone could make their own subsets and subcategories that work best for them. —CodeCat 19:12, 7 September 2012 (UTC)[reply]
Re: "The download size hasn't been a big problem for me": For me, either, but EP has mentioned that it's an issue on school computers with slow connections, and I'm sure it's more of an issue for people who edit on their cell-phones. The problem might be exacerbated by the fact that the JavaScript doesn't run until after the page is fully loaded, so the edit-tools mess with the physical size of the page and presumably cause things to jump around during downloading.
Re: "I find it more annoying when I have to keep switching between sections for a single task": Me, too. I have custom JavaScript that just copies the four sections I use most (Miscellaneous, Hebrew, Latin/Roman, and IPA) out above the original edit-tools, so I can have five sections open at once.) I definitely think customization is the way to go.
RuakhTALK 19:41, 7 September 2012 (UTC)[reply]


...appears as a redlink above the edit window when I edit MediaWiki:Edittools. Specifically, I see:

Warning: You are editing a page which is used to provide interface text for the software. Changes to this page will affect the appearance of the user interface for other users. For translations, please consider using, the MediaWiki localisation project.
This following documentation is included from the file intended for those translating this message into other languages.
Template:optional This text will be shown below edit and upload forms. It can be used to offer special characters not present on most keyboards for copying/pasting, and also often makes them clickable for insertion via a javascript. Since these are seen as specific to a wiki, however, this message should not contain anything but an html comment explaining how it should be used once the wiki has been installed.

Does this appear for the rest of you? - -sche (discuss) 22:39, 7 September 2012 (UTC)[reply]

Some interface messages, such as MediaWiki:Edittools and MediaWiki:Common.js, have documentation that starts with that; other interface messages, such as MediaWiki:Difference-title, have documentation that does not. I assume it indicates that the interface message is "optional" in some way, though I don't really know what the template should contain that would make it make more sense. —RuakhTALK 23:01, 7 September 2012 (UTC)[reply]
Where can we find such documentation's wiki code? I ask because it may call the missing template with some parameter(s) that may be of interest.​—msh210 (talk) 07:58, 9 September 2012 (UTC)[reply]
Good question. *looking...* O.K., it looks like the documentation for a message is implemented as the "translation" of the message into the pseudo-language coded qqq; so, we can see the wikitext of documentation for "optional" messages by looking at None of them seems to pass any parameters to {{optional}}. However, this exercise also brings me to realize that the relevant template {{optional}} is translatewiki:Template:Optional, so we can look at that. —RuakhTALK 12:58, 9 September 2012 (UTC)[reply]

™ ® ©[edit]

Given that our policy is to not indicate the trademark status of words (see WT:TM and the discussions linked to from its talk page), these should be removed. - -sche (discuss) 22:43, 7 September 2012 (UTC)[reply]

I have removed the symbols from all the entries like [[Antabuse]] (q.v.). The only entries which use these characters are the entries on the concepts (trademark, etc), <10 entries which use the symbols in quotations, and ≈100 entries which contain manually-formatted references to etc which should use templates instead (e.g. adjectival). - -sche (discuss) 06:57, 8 September 2012 (UTC)[reply]

Grouping of uppercase and lowercase letters[edit]

Some of the tabs currently list all uppercase letters first, then all lowercase letters (A B C ... Y Z a b c ... y z). Others show them alternating (A a B b C c ... Y y Z z). Personally I find the latter more intuitive, because they're really the same character, just different graphical variants. Should we do this generally? —CodeCat 19:19, 9 March 2014 (UTC)[reply]

I agree. --WikiTiki89 20:23, 9 March 2014 (UTC)[reply]
After taking a look at the Greek section (which separates them, ΑΒΓ...αβγ) vs the African section (which sets them side by side, ⱭɑƁɓ...), I'm inclined to agree. - -sche (discuss) 20:45, 9 March 2014 (UTC)[reply]

Reducing the number of sections[edit]

I find it both undesirable and unnecessary that there are so many sections ("Templates", "Headers", "Latin/Roman", etc). On my computer, they do not all display in a single drop-down menu; instead, the drop-down menu comes with its own scroll-bar that must be used to reach some of the sections. I propose to tack the "Double-Diacritics" characters onto the end of the "Latin/Roman" section (I don't think they need their own section; if you're writing something that requires double-diacritic characters, chances are it requires single-diacritic characters, too). I also propose to merge the "IPA" and "enPR" sections (into a section I'll prosaically call "IPA and enPR"), and the "Headers" and "Templates" sections. Thoughts? - -sche (discuss) 19:37, 9 March 2014 (UTC)[reply]

I'd prefer to completely eliminate the "headers" and "templates" sections. The purpose of this tool is to allow people to write things they couldn't otherwise. But those are just plain ASCII, so they're not necessary. —CodeCat 20:02, 9 March 2014 (UTC)[reply]
Plus the set of templates that a given editor commonly uses varies widely by editor. All of the general widely used templates are short enough to just type out. Headers I also think we can get rid of. Also the Sign languages section has no special characters at all, just sign-language-related technical terms spelled out in English. --WikiTiki89 20:23, 9 March 2014 (UTC)[reply]
I'm down with eliminating the "headers" and "templates" sections entirely. I can see some benefit to the "sign language" section: it would help people get the spelling and capitalization and spacing of the elaborate terminology correct ... if people were actually adding sign language entries. But I don't think people are, so I wouldn't mind if the section were removed. - -sche (discuss) 20:53, 9 March 2014 (UTC)[reply]
Don't be so quick - less than 1.5 hours from idea to execution compared to months in RFD and RFV sections. I work mostly with en-to-fi translations and new Finnish articles. Both "Templates" and "Headers" save a lot of repetitive, mindless writing from me. Move them to the bottom of the list, if you like. There they won't disturb you. --Hekaheka (talk) 08:27, 11 March 2014 (UTC)[reply]
Another idea is to combine the headers and templates into one section. --WikiTiki89 08:32, 11 March 2014 (UTC)[reply]
Better still - then I don't need to keep jumping between the two. --Hekaheka (talk) 17:30, 11 March 2014 (UTC)[reply]
Alright, I've re-added the sections, now combined into one. I tentatively put it after the "Misc" section, but before the block of "different languages' alphabets". - -sche (discuss) 18:04, 11 March 2014 (UTC)[reply]
Thank you! --Hekaheka (talk) 04:32, 12 March 2014 (UTC)[reply]

Accented Cyrillic[edit]

It has become more difficult to enter accented Cyrillic after the "fix", tested on iPad. Especially considering that people may have a Cyrillic keyboard, it's adding accents, which is missing on keyboards, that is usually cumbersome. I suggest to put the string of accented vowels back. --Anatoli (обсудить/вклад) 00:02, 10 March 2014 (UTC)[reply]

@Atitarev Actually the fact that people have Cyrillic keyboards is why I think it is easier to replace the accented letters with just the accents needed to create them. If you type "и" and then press the acute accent, it will create "и́". Unless you mean that you are having trouble pressing the acute accent on an iPad. --WikiTiki89 02:08, 10 March 2014 (UTC)[reply]
It also means that when adding accents to existing text, you don't have to re-type the letters. --WikiTiki89 02:10, 10 March 2014 (UTC)[reply]
I can press the acute accent on an iPad but it's too small. (iPad don't use mouses, you have to use your finger) and it's cumbersome to press buttons in a tall text area. I have added a lit of accented vowels here, at WT:RU TR and WT:UK TR for a reason. It's easier to just click on и́", rather than type "и" and then press the acute accent (just like pressing í, rather than i then the acute accent), although the acute accent on its own is also good (for adding accents to existing text). --Anatoli (обсудить/вклад) 06:31, 10 March 2014 (UTC)[reply]
The other advantage to having just one button for the accent is that it is always in the same place, so that when you're typing and you need an accent, you don't have to look for the right letter on the screen, you just type the letter on the keyboard and press the accent. It's similar to how you type capital letters by pressing shift and then the letter, rather than duplicating every letter on the keyboard. As for the button being too small, that is a real problem. I wonder if just increasing the font size of the accent mark will help. --WikiTiki89 06:37, 10 March 2014 (UTC)[reply]
I'm telling you that from practical point of view, your edit made it harder, although having separate acute and grave accents is beneficial. The string of accented vowels wasn't taking too much space. On a system without Cyrillic keyboards, just clicking а́ is more convenient than а then the acute accent. --Anatoli (обсудить/вклад) 06:55, 10 March 2014 (UTC)[reply]
I'm also telling you from my experience of typing on computers with no Cyrillic keyboard. It's disorienting to have to search through two separate lists of letters rather than just search through one list and have the accent always be in the same place. I guess it's a matter of opinion. --WikiTiki89 07:06, 10 March 2014 (UTC)[reply]
I have made the accent marks appear bigger, can you test it on the iPad? --WikiTiki89 06:43, 10 March 2014 (UTC)[reply]
It's a little better but editing Wiktionary on iPad is not the best experience in general, when the screen jumps up and down on pressing Edittools buttons, and having to press more buttons makes it worse. Can we add the accented vowels back, please? On the same line? --Anatoli (обсудить/вклад) 06:55, 10 March 2014 (UTC)[reply]
Yes, I'll add them back. I can't guarantee they will be on the same line, since that will depend on your screen size. --WikiTiki89 07:06, 10 March 2014 (UTC)[reply]

I see grave accents have been added. Those are good for Bulgarian (where stress is usually indicated with a grave rather than an acute, as in East Slavic languages) and for Serbo-Croatian, but to be complete we need to add the grave over Ъъ for Bulgarian and over Рр for Serbo-Croatian. Also, what about the other accentuation diacritics for S-C? Also, now that transliteration is generated automatically for, I believe, all Cyrillic languages, can't we eliminate the Transliteration: line from the Cyrillic menu? —Aɴɢʀ (talk) 20:19, 10 March 2014 (UTC)[reply]

I think the grave accents were there before anyway, that's why I added them back. I have nothing against adding the other accents, except that I don't know which ones need to be added. As for transliteration, even though it is usually automatic, the characters are still useful occasionally when manually transliterating. Also don't forget that with the combining accent buttons, any missing character can still be accented. --WikiTiki89 20:24, 10 March 2014 (UTC)[reply]

Abugida vowel diacritics[edit]

Does anyone know why the vowel diacritics in Devanagari and Burmese (and maybe other abugidas as well, I haven't checked) have stopped being insertable? Does anyone know how to fix it? —Aɴɢʀ (talk) 19:00, 6 June 2014 (UTC)[reply]

Try using the same code as with Cyrillic diacritics. I had the same problem with Arabic diacritics, which used to work fine. Just a suggestion, not sure, if this will work. --Anatoli (обсудить/вклад) 03:58, 9 June 2014 (UTC)[reply]


There’re many characters absent from this feature, and given my current privileges, there’s not a damn thing that I can do to meliorate this. I would spend an hour listing all of the valid characters, but frankly I lack faith in you people, so I’ll just list a few notable ones:

  1. , . This is common in archaic Romanian orthography. (I know that these’re not official unicode letters, but neither are some P.I.E. letters nor many IPA combinations.)
  2. ׃. Very important for ancient Hebrew. is used by some Judaist mathematicians. There’re also four letter combinations available, but these could be considered typographic.
  3. is used when German is written in ALLCAPS.
  4. ǹ, Ǹ, , Ǵ, , , , , , … it goes on.
  5. , , K

--Æ&Œ (talk) 03:41, 9 June 2014 (UTC)[reply]

Telling people you lack faith in them is not actually an effective way of getting them to do things for you. Just sayin'. As for this page, it really needs to include only letters that are likely to be widely used in dictionary entries. Adding / seems uncontroversial to me. ׃ and are punctuation marks and are unlikely to be used in entries. They might be used in usage examples, but probably only either by people who already have a convenient way of entering them or by cut-and-paste. is actually very rare even when German is written in all caps, but even if it were common, we don't list entries in all caps. The precomposed characters under point 4 can be added if they're actually used in writing systems. What languages do we need them for? I'm pretty sure and are deprecated in favor of the two-character sequences °F and °C, and K is available on every ASCII keyboard and so doesn't need to be here. —Aɴɢʀ (talk) 09:15, 9 June 2014 (UTC)[reply]

⟨ᵻ⟩ and ⟨ᵿ⟩[edit]

The symbols ⟨ᵻ⟩ and ⟨ᵿ⟩ aren't IPA. Some dictionaries use them as cover symbols for /ɪ/ alternating with /ə/ and /ʊ/ alternating with /ə/ in English, but we don't use phonetic symbols that way here. We just write two pronunciations, one with /ɪ/ or /ʊ/ (as the case may be) and one with /ə/. Even if they were IPA symbols, they'd stand for lowered versions of /ɨ/ and /ʉ/, which is not how those English dictionaries are using them, since English doesn't have /ɨ̞/ and /ʉ̞/. We need to remove them from any pronunciation sections where they're used; indeed, using them causes the page to appear in Category:IPA pronunciations with obsolete or nonstandard characters. —Aɴɢʀ (talk) 12:57, 22 December 2016 (UTC)[reply]

@Aɴɢʀ: It's a very convenient shorthand, don't you think? Might it be worth taking this to the Beer parlour? — I.S.M.E.T.A. 13:01, 22 December 2016 (UTC)[reply]
No, it's not. It's very misleading, because it's (1) using nonstandard characters (2) in a way other than how they were intended. We don't need to use shorthand, because we're not paper. —Aɴɢʀ (talk) 13:06, 22 December 2016 (UTC)[reply]
@Aɴɢʀ: Well, fine. I'll stick to using just ⟨ɪ⟩ and ⟨ʊ⟩, in that case, since they're the realisations that are universally acceptable because they are the most conservative. Perhaps you'd like to add definitions for the official IPA usages to and ᵿ. — I.S.M.E.T.A. 13:18, 22 December 2016 (UTC)[reply]
Thank you. — I.S.M.E.T.A. 13:45, 22 December 2016 (UTC)[reply]
Sure. —Aɴɢʀ (talk) 13:53, 22 December 2016 (UTC)[reply]

Proto languages[edit]

Hi, can someone add ə́ ə̄ ə̄́ to the Proto Languages section? Those are common ligatures I find myself having to manually cobble together each time. --{{victar|talk}} 18:01, 2 December 2018 (UTC)[reply]

For future reference, this was done here. — Eru·tuon 16:17, 2 September 2019 (UTC)[reply]

Arabic diacritics[edit]

I have requested help with Arabic diacritics at Wiktionary:Grease_pit/2018/September#Arabic_diacritics_in_MediaWiki:Edittools but didn't get any response and no action was taken. I am using Chrome. --Anatoli T. (обсудить/вклад) 02:03, 3 December 2018 (UTC)[reply]

Missing templates[edit]

Could someone please add these:

  • * {{l||}}
  • * {{lb||}}
  • === Phrase ===

--So9q (talk) 05:16, 2 September 2019 (UTC)[reply]

I added the header (and other frequent PoS headers from User:Erutuon/mainspace headers) and * {{l||}} (the cursor is in the position of the language code), but I added # {{lb||}} because it's more common (~575,000 search results) than * {{lb||}} (685 results). — Eru·tuon 06:11, 2 September 2019 (UTC)[reply]
Thanks! Fantastic. Could you add these too?
  • # {{synonym of|}}
  • * {{sense|}} {{l|}} <- maybe only the first part?
  • === Proverb ===
  • # {{rfdef|lang=en}}
When I want to insert a === Translation header I ALWAYS also want the top and bottom. Please replace ====Translations==== with: ====Translations====\n{{trans-top|}}\n{{trans-bottom}}\n
And a new section with:
  • {{ping|}}
  • {{reply to|}}
Additionally can you put a \n in front and after all ==='s--So9q (talk) 12:10, 2 September 2019 (UTC)[reply]
This is a lot of ideas. I definitely think that including {{trans-top}} and {{trans-bottom}} with the Translations header is a good idea. Having the tool add a newline after the headers is a good idea; I'm not sure about putting a newline before though. Then again I never use the header buttons.
Right now the script can't insert whitespace characters (except for space) in the inserted text. I came up with a modified version of the script that allows newlines to be included with the syntax [nl]. (If you install it, view User:Erutuon/edittools.) window.editToolsShowNewlines controls whether the newlines are shown in the edittools button or not. — Eru·tuon 18:36, 2 September 2019 (UTC)[reply]
Okay ditch the newlines before. I just found out today that davebot inserts newlines where needed so I don't bother too much about them anymore.
If we could switch to the mediawiki extension charinsert that en:Wikipedia use I could easily customize myself by adding a snippet to my common.js. see Do you know why we roll our own?--So9q (talk) 00:02, 3 September 2019 (UTC)[reply]
I guess nobody cared to update to the new framework. Wikipedia probably used something like this years ago. — Eru·tuon 00:12, 3 September 2019 (UTC)[reply]
Oh, actually I think I looked into this. One problem is that the Charinsert framework doesn't allow adding things like classes or tooltips to the buttons. For instance, the Avestan menu has transliterations of the letters, and descriptions of the punctuation marks, as tooltips and formats the letters with the Avst class. The framework doesn't allow this, so it would need to be modified. There would be advantages to generating the menu with JavaScript: it could make the repetitive stuff (for instance, code point names in the tooltips in the "Modifiers and combining diacritics" menu) more readable and easier to edit. — Eru·tuon 01:05, 3 September 2019 (UTC)[reply]
@erutuon This is the improved template section, note the newline \n I tried adding to trans-top. Note also I deleted the der-top and rel-top and related templates as they should only be used in special circumstances.
<p class="speciallang mw-editfont-monospace" id="edittools-Templates and Headers" style="display: none;">
<span class="charinsert"><nowiki>{{+}} {{en-noun}} {{en-adj}} {{en-verb}} {{en-adv}} {{en-proper&nbsp;noun}} {{plural&nbsp;of|+}} {{present&nbsp;participle&nbsp;of|+}} {{past&nbsp;of|+}} {{comparative&nbsp;of|+}} {{superlative&nbsp;of|+}} {{misspelling&nbsp;of|+}} {{inflected&nbsp;form&nbsp;of|+}} {{alternative&nbsp;spelling&nbsp;of|+}} 
{{cog|+|}} {{trans-top|+}} {{trans-mid}} {{trans-bottom}}</nowiki></span>
<span class="charinsert"><nowiki>*&nbsp;{{l|+|}} {{col2|+|}} {{col3|+|}} {{col4|+|}}</nowiki></span>
<span class="charinsert"><nowiki>#&nbsp;{{lb|+|}}</nowiki></span>
<span class="charinsert">===Alternative&nbsp;forms=== ===Etymology=== ===Pronunciation=== ===Adjective=== ===Adverb=== ===Glyph&nbsp;origin=== ===Hanja=== ===Hanzi=== ===Idiom=== ===Interjection=== ===Kanji=== ===Noun=== ===Numeral=== ===Participle=== ===Phrase=== ===Prefix=== ===Preposition=== ===Pronoun=== ===Proper&nbsp;noun=== ===Romanization=== ===Suffix=== ===Symbol=== ===Verb===  ====Usage&nbsp;notes==== ====Synonyms==== ====Antonyms==== ====Derived&nbsp;terms==== ====Related&nbsp;terms==== ====Translations====\n{{trans-top|+}}\n{{trans-bottom}} ===See&nbsp;also=== ===References===</span>
<span class="charinsert"><nowiki>{{rfclarify|+}} {{rfdef|+}} {{rfe|+}} {{rfelite|+}} {{rfref|+}} {{rfv|+}} {{rfquote|+|}} #:&nbsp;{{rfquotek|+}}</nowiki></span>
Thanks in advance--So9q (talk) 10:51, 9 October 2019 (UTC)[reply]

Add markup for inline references in misc section[edit]

Please add <ref></ref> in the misc section, or in the template section, for quick addition of inline citations and references.--OpenNotes1 (talk) 08:12, 19 April 2020 (UTC)[reply]

Lowercase g with cedilla[edit]

@Erutuon: is "ģ" correct? Why is the cedilla not below the letter? I was recently trying to insert a lowercase g with a cedilla below and ended up having to construct it using the combining diacritics section. — SGconlaw (talk) 09:41, 10 January 2021 (UTC)[reply]

@Sgconlaw: Several Unicode code points whose names contain "with cedilla" are typically rendered in fonts with a comma diacritic because at one point Unicode thought the comma and cedilla diacritics were not really distinct. Now Unicode recognizes them as distinct, and the characters should be named "with comma", but unfortunately Unicode character names can't ever be changed. The usual rendering of the ģ character in fonts, with a comma diacritic, is apparently correct for Latvian.
I think when you add the cedilla diacritic to the g it'll display as a comma unless you add a zero-width non-joiner between it and the letter: ģ (combining diacritic) versus g‌̧ (ZWNJ and combining diacritic). The latter may not look good in all fonts or font rendering engines; that is, the cedilla may or may not be actually attached to the g as opposed to separated from it with a gap or floating off to the right. (But it looks good for me right now.) I'm not sure what language would actually even want a true g-with-cedilla. Furthermore, if you manually enter g followed by the cedilla combining diacritic, they'll be transformed into the g-with-cedilla character by the MediaWiki software when you save the page, undoing your careful work. (Hence I used the HTML character references.)
Curious where a g with cedilla came up since I hadn't heard of you being involved in Latvian... — Eru·tuon 22:07, 10 January 2021 (UTC)[reply]
@Erutuon: it appeared in the 2008 quotation in homo Aristophaneus, and it was the first time I’ve encountered this character. In the source, the character appeared as a lowercase g with a cedilla or comma below it; I don’t know if that was correct or not. — SGconlaw (talk) 23:01, 10 January 2021 (UTC)[reply]
It occurs to me that perhaps our computers are rendering the character differently. In the edit tools, I see the character as a g with a cedilla or comma above rather than below it. It’s the only character where the cedilla or comma appears above the character. — SGconlaw (talk) 04:51, 11 January 2021 (UTC)[reply]
I think the position of the comma isn't significant and you're safe using a g with comma no matter whether the comma is above or below. w:Comma#Diacritical usage says it's put above, at least in the fonts it's talking about, merely because g has a descender and not because the position of the comma is significant. In other articles on diacritics, it's explicitly mentioned when a diacritic has a different meaning depending on whether it's placed above or below. And w:Latvian orthography lists a g with comma but does not separately list g with comma above and g with comma below as separate letters, so they must be variant glyphs with the same meaning. — Eru·tuon 08:29, 1 February 2021 (UTC)[reply]
@Erutuon: OK, thanks for investigating. — SGconlaw (talk) 10:01, 1 February 2021 (UTC)[reply]

Add templates in "Templates and Headers"[edit]

Hi. Now the synonyms and antonyms must be written with a template below the definition, instead of with a head.

So I suggest adding this in "Templates and Headers" section. And the {{q}} and {{gloss}} templates.


--Vivaelcelta (talk) 12:29, 19 September 2021 (UTC)[reply]

Please add ===Further reading=== to "Templates and Headers" after ===References===[edit]

See also Wiktionary:Votes/2017-03/"External_sources",_"External_links",_"Further_information"_or_"Further_reading" --Fytcha (talk) 17:37, 24 November 2021 (UTC)[reply]

===See also=== L3/L4[edit]

@Sgconlaw: I'm not so sure about making this an L4. Firstly, use between L3 and L4 is somewhat equal: User:JeffDoozan/stats/sections/latest (64k L3 vs 75k L4) Secondly, as it is used to link to semantically related words, I'd argue it should be a subordinate of the etymologies (hence L3 by default because most words have only one etymology), not a subordinate of the parts of speech. — Fytcha T | L | C 〉 13:07, 14 January 2022 (UTC)[reply]

@Fytcha: hmmm, I recall in the past some editors changed it from being an L3 to an L4 heading after "Translations", so that's what I've been doing for a while. I had a look at "Wiktionary:Entry layout" but it doesn't expressly say whether it should be L3 or L4. That policy page just states that it should be after "Translations" (L4) and before "References" (L3). One could argue that it should be subordinate to the part of speech because editors tend to use it to put terms that are linked in some way to the particular entry (for example, a term that expresses a similar sentiment but is a different part of speech), but which aren't suitable for other headings like "Synonyms", "Antonyms", "Derived terms", "Related terms", and so on. — SGconlaw (talk) 13:19, 14 January 2022 (UTC)[reply]