Wikipedia talk:Manual of Style/Text formatting

Giardiniera

If I'm reading and understanding MOS:FOREIGNITALIC correctly, Giardiniera does not qualify for an italics title (using {{Italics title}}) as using italics "...does not apply to loanwords or phrases that see everyday use in non-specialized English, such as qi, Gestapo, samurai, esprit de corps, e.g., i.e., etc.—as these have become English-language vocabulary...", which I would argue that Giardiniera is now in everyday use in English. However, there is a user who diagrees with me on this, so rather than dragging this out, I'd thought I'd come here and try to establish some sort of consensus. Thoughts? Also, I have no idea about whether this is correct or not. I would assume these two issues are related, but I have not looked into the {{lang}} bit. Jauerback^dude?/_dude. 14:12, 17 February 2026 (UTC)

Italic semantics

Should we have more templates to compliment {{em}} for MOS:NAT, MOS:WAW, etc. better indicate the semantics of italics? ~Kvng (talk) 14:46, 9 May 2026 (UTC)

No, that would merely complicate editing with no obvious benefit. Wiki markup is easiest and should stay the default. Gawaon (talk) 14:50, 9 May 2026 (UTC)

I've seen a number of recent edits converting italics to {{em}}. Should these be discouraged?

@Gawaon, the documentation for {{em}} does make a case for its benefit: editors...can use this template as a baseline insurance against accidental or uninformed replacement by bots and human editors, as well as to add web accessibility. Does this hold any water for you? ~Kvng (talk) 15:06, 9 May 2026 (UTC)

It's inapplicable to MOS:NAT and MOS:WAW, where emphasis is in any case not intended. Gawaon (talk) 17:29, 9 May 2026 (UTC)

Agreed, that's why I'm asking whether it would be useful to have another template (or more) for MOS:NAT, MOS:WAW, etc., cases. They would all render as italics but, for instance, a screen reader may be able to make use of the semantic information. ~Kvng (talk) 20:13, 9 May 2026 (UTC)

How would a screen reader use it? Gawaon (talk) 20:55, 9 May 2026 (UTC)

I could imagine a rhythm change and inflection like people use when they do air quotes with their fingers. ~Kvng (talk) 14:57, 12 May 2026 (UTC)

According to MDN Web Docs, The <em> element represents stress emphasis of its contents, while the <i> element represents text that is set off from the normal prose, such as a foreign word, fictional character thoughts, or when the text refers to the definition of a word instead of representing its semantic meaning. (The title of a work, such as the name of a book or movie, should use <cite>.). So the current MOS:EMPHASIS is correct: using <em> or {{em}} for rare cases where we use emphasis (e.g. when preserving emphasis in quotes), but normal wiki italic markup for MOS:WAW and MOS:NONENGITALIC. We could consider switching to <cite> for MOS:NAT, but {{em}} doesn't seem to be the right sematic markup for this. --Yodin^T 16:51, 9 May 2026 (UTC)

Yes, the current division of works seems okay enough: {{em}} for emphasis, which we rarely use in the article space, while wiki markup is for works of titles and words as words, which are not emphasized, but simply rendered in italics. Personally I don't bother with the difference when writing talk page comments (as visible in this one), but if other editors are more careful here, that sure is fine with me. Gawaon (talk) 17:29, 9 May 2026 (UTC)

I think we probably should. There should be em for emphasis, something for the cite HTML for titles of things, and something for waw ({{lang}}? I don't know what HTML that makes but here is an example hmm it doesn't get italicized in en by default, what a shame). Default italics will be left as an ambiguous default. Dingolover6969 (talk) 06:05, 5 June 2026 (UTC)

I don't even think these will usually display differently in any way (although the semantic information will allow for arbitrary styling later); I just think it's better not to lose the semantic information I'm trying to put into the page. Even if only the other editors get to see it — it will help them.

And, of course, anyone who wants to be "lazy" and just keep using single quote marks should feel free to. (Likely 99% of editors.) This should just be a "best practice". Dingolover6969 (talk) 22:42, 21 June 2026 (UTC)

If there is not strong opposition I would propose to create {{waw}} and {{tii}} for words as words and title italics, respectively. {{waw}} could be rendered with <i> and {{tii}} with <cite>. We could improve the templates in the future if/when we identify additional applications. ~Kvng (talk) 21:50, 21 June 2026 (UTC)

Love it. I would start using it immediately. Especially for those tricky situations where I want to indicate a piece of text in a non-english language is the title of a major work.

I would suggest that unless there's any better idea for waw, it should use lang|en|i=yes, like so. This is approximately the correct semantic and will serve to reassure the reader if they inspect closely that the word *isn't* being italicized because it's foreign (for example: the word pace is not the word pace). On that note, sometimes I also want to indicate that a word is waw *and* non-English, so I hope they play well together. I guess maybe the ideal solution would involve changing the hovertext lang produces from "English language text" to "English language words-as-words" for waw. So maybe waw would be its own thing, just with a language parameter all its own, or compose well with lang somehow. But don't let the perfect be the enemy of the good here 🙂. Dingolover6969 (talk) 22:20, 21 June 2026 (UTC)

I assume tii stands for "title italic". This would be a fine first stab, but I think the ideal template would be tmajor (title of major work) and it would automatically italicize or not based on Wikipedia's rules for italicizing titles (ie, do not italicize Chinese). We may have to fiddle with the css to accomplish this, eventually, since I think cite just emphasizes everything by default, implemented in the browser. Dingolover6969 (talk) 22:36, 21 June 2026 (UTC)

Maybe there should be a separate template for every case in MOS:NAT? A boat name is not a title of a work after all, nor is a gene. So allowing all that to be expressed semantically as well would be good, since we're fixing the situation. Dingolover6969 (talk) 22:38, 21 June 2026 (UTC)

I think we've already got that in Template:Ship. pburka (talk) 02:04, 22 June 2026 (UTC)

Neat, thanks! Dingolover6969 (talk) 02:14, 22 June 2026 (UTC)

Reviewing MOS:ITALIC more carefully:

• MOS:NAT lists five different types of title. Do we want to try to differentiate these? Your {{tmajor}} proposal seems like it would be a subset of my proposed {{tii}} for this semantic class.
• MOS:NONENGITALIC is already handled by {{Lang}}
• {{Dfni}} already exists for technical terms, the most common situation I'm working with.
• MOS:ITALSCINAMES lists a few different cases for italicizing species names. Do we want to create a template to help with this? Do we want to try to differentiate these?
• {{var}} and {{mvar}} already exists for variables.

In summary, I think {{waw}}, {{tii}} and {{tmajor}} would all be immediately useful additions to a family of italics templates that already exist. We could do even more to account for other types of titles and species names. ~Kvng (talk) 23:30, 21 June 2026 (UTC)

Oh, I guess you consider everything in MOS:NAT titles, that explains it. I think it would be a misnomer to call the name of a ship or gene a "title", which is why I proposed "tmajor" and conceived of it as targeting only the major works rule. Although I also agree that court case names are titles, and the other ones are still at least arguable.

Anyway, I generally agree with all of what you said above. And also the concept of maximal specificity in semantic italicization. If people are going to bother figuring out the right type of italics to use, we might as well go whole hog and let them indicate whether it's for a gene or an airplane or a genus or a species. This will also allow us to granularly change the styling on these later if italicizing species, for example, goes out of style. Dingolover6969 (talk) 02:32, 22 June 2026 (UTC)

Side note: I suspect the only reason that scientific names are italicized is that they're all technically Neo-Latin and thus italicized as non-English, but MOS:ITALSCINAMES specifically tells you not to lang them that way. Dingolover6969 (talk) 02:35, 22 June 2026 (UTC)

As Gawaon said above, this seems to overcomplicate things unnecessarily. If you're just using <i>...</i> for words as words, then why do you need another template to do this? If you're planning to invent your own semantic markup and hope that screen readers will adopt the format then that seems completely the wrong way around – we should be implementing existing semantic markup standards instead. The only case I can see where we don't do this is with titles, which could use <cite>...</cite> rather than italics. But to implement this across Wikipedia would require a serious discussion of the pros and cons, with significant input from across the community if you want it to be adopted. At a minimum, I would recommend notifying WP:VPR of your plans, and asking for feedback either here or there. --Yodin^T 09:09, 22 June 2026 (UTC)

I too remain unconvinced that this should be implemented just for the benefit of a small minority of editors – only 1%, if Dingolover6969's estimate is correct. This would then mean that nearly everyone is writing technically incorrect wikitext. Possibly gnomes would clean up after them, but that would create lots of noisy, near-cosmetic edits that clutter page histories and watchlists. Even if these gnomes existed and corrected all '' markup into the semantically right form, this would make Wikipedia less editor- and newbie-friendly, since templates are arguably scarier and harder to get used to than the relatively plain '' markup. This would also hurt VisualEditor's usability, since instead of just pressing the italics button, people would have to select the right template from among various options.

If there were a convincing use case of this actually and immediately helping screen readers, it might nevertheless be worth it, but no such case has been made. I don't think we should add this purely on the off chance that italicizing species goes out of style before Wikipedia does. Gawaon (talk) 10:46, 22 June 2026 (UTC)

I think dfn is instructive here. I'd wager 99% of editors don't know what dfn is — not as a tag, nor a template, nor as dfni. I also don't find most explanations of how DFN is supposed to be useful as very salient. Eg, from the template page:

Without the second parameter, it does not do anything user-facing, and is just a form of meta-data that can be detected and acted upon by internal and external software (statistics-gathering bots, rich Web 2.0 applications, etc.), and can provide valuable contextual information to editors.

But, I think it's fine. Dingolover6969 (talk) 11:27, 22 June 2026 (UTC)

Standards are commonly based on user practices and needs that arose before the standard — which we could start implementing technically here, but which ultimately go back to the English language conventions received from generations before us. Dingolover6969 (talk) 11:06, 22 June 2026 (UTC)

Agreed that *prescribing* the use of a template that makes html cite tag (or prescribing any other scheme for templates that do italics, for that matter) would require a bit of a bigger discussion than we've had so far. (Since I feel like more than 4 editors would be interested in the consensus about these things.) But just making the templates such as waw that apply the styling mentioned in the MOS, and allowing them to be used, doesn't. Which may or may not have been the scope of OP's suggestion. Dingolover6969 (talk) 11:15, 22 June 2026 (UTC)

Based on recent comments, I'm going to back off my proposal for now. My most important request is already served by {{dfni}}. I will make sure all of the templates we've turned up here are in Category:Semantic markup templates and otherwise improve documentation, making what we already have a bit easier to find.

Discussion at Wikipedia talk:Manual of Style/Biography § Discrepancy between MOS:BOLDREDIRECT and MOS:NICKCRUFT (and other problems)

 You are invited to join the discussion at Wikipedia talk:Manual of Style/Biography § Discrepancy between MOS:BOLDREDIRECT and MOS:NICKCRUFT (and other problems). —Myceteae‍🍄‍🟫 (talk) 20:20, 29 May 2026 (UTC)

MOS:BOLDREDIRECT when also a section heading

Is there any need to bold a redirect term within a section when it's also the exact name of that section's heading? I've seen different views on this but the MOS doesn't seem to rule on it. Belbury (talk) 08:57, 9 June 2026 (UTC)

Section headings don't count as paragraphs or running text, so in my understanding MOS:BOLDREDIRECT applies regardless of whether a heading happens to have the same name. Gawaon (talk) 11:00, 9 June 2026 (UTC)

WP:RBOLD frames the bolding of redirect terms as being to reduce astonishment ("Hang on ... I wanted to read about this. Why has the link taken me to that?" Make it clear to the reader that they have arrived in the right place.), which does make it sound as if it may be unnecessary in cases where the section heading closely matches what our reader was looking for.

In not counting it as text, are there any technical situations in which a reader wouldn't see the heading? Belbury (talk) 18:51, 15 June 2026 (UTC)

By that logic, MOS:BOLDLEAD would be unnecessary since it simply puts the article title in bold, repeating what's already there and visible to all readers. But I don't think that kind of logic is meant to be applied when bolding the subject of an article or a redirect. Gawaon (talk) 08:29, 16 June 2026 (UTC)

I don't know if there's exact verbiage about it, but I think it should probably follow the same rules as a normal Wikipedia article lede: bold if the term occurs in the running text, but don't feel pressured to put that term in the running text if it's unneeded (eg if a redirect "history of Portugal" went to Portugal § History, there is no need to write "history" or "history of Portugal" just because) Dingolover6969 (talk) 18:27, 10 June 2026 (UTC)

Agree that we should have bold in this case. The article title is not far from the start of the lead and we definitely still want bold there. ~Kvng (talk) 21:39, 21 June 2026 (UTC)

Discussion at Wikipedia talk:Manual of Style § Bot task to remove erroneously italicized commas

 You are invited to join the discussion at Wikipedia talk:Manual of Style § Bot task to remove erroneously italicized commas. Sdkb ^talk 01:13, 11 June 2026 (UTC)

Italics and non-English acronyms

While editing some articles on champagne, I was adding {{lang}} templates and began wondering what to do for foreign-language acronyms, such as AOC (appellation d'origine contrôlée), or CIVC (Comité Interprofessionnel du vin de Champagne). My inclination is to leave them in plain type, since I wouldn't try to use French pronunciation if reading the acronym out loud (i.e. I'd say eh-oh-see, not ah-oh-say). Was this correct, or should acronyms of foreign terms be italicized? pburka (talk) 22:56, 21 June 2026 (UTC)

I have hesitated in these cases as well, but I think you have the right heuristic. If you pronounce it with the English letter names, no italics. Anglophones in Quebec might say TVA as tay-vay-ah (not sure if they actually do), in which case lang|fr| should be used. Indefatigable (talk) 02:37, 22 June 2026 (UTC)

Formatting for Tech pags; KB vs KiB example

Is there a clear decision on what preference to use for tech pages that use data sizes like KB vs KIB, MB vs MiB, etc...? I ask as you can see from these 2 pages ARM_Cortex-A720 and ARM_Cortex-A78 one uses the i version and other primally not. Yes I know the difference between the 2 but they are being used interchangeably and could create confusion. ContentEditman (talk) 12:17, 8 July 2026 (UTC)

We do have a clear policy that has been discussed extensively: see MOS:COMPUNITS. Many maintainers of the manual of style are weary of these discussions, so beware of that if you decide to open another one. Indefatigable (talk) 13:38, 8 July 2026 (UTC)

Haha well this is Wikipedia so I would not be surprised many have strong beliefs on Tech topics. Just to be clear I am not pushing one or the other. I did a small edit and saw many using different formats and did not know if I was wrong or there was already an agreement on what should be used. I see both formats on similar pages, sometimes same page, and was surprised. ContentEditman (talk) 15:37, 8 July 2026 (UTC)

Puzzling revert

To help editors use the valuable feature of anchoring redirect targets when they appear deep in the article I added this sentence to the paragraph following "After following a redirect:" For terms outside the lead section, bold ticks marks around a visible anchor template, {{va}}, will ensure that the term is highlighted when readers visit the redirect. My improvement was reverted by @FaviFake with a puzzling summary:

• that's nt really a great place to put this advice. It doesn't only apply when boldface is used, and it doesn't only apply to terms outside the lede either

The summary is not relevant to my change. Of it only applies when boldface is used, the advice says to use boldface! The advice is >>not<< useful in the lead because adding anchors to the lead is completely unnecessary.

I added this line because I searched around to find just this kind of advice. I think it should be included. Johnjbarton (talk) 20:18, 11 July 2026 (UTC)

the advice says to use boldface
The {{va}} template is useful in all cases, not just when the text is formatted. I don't understand why it should be mentioned in such a niche case if it can apply to any text on the page.

adding anchors to the lead is completely unnecessary
Why? If there are many bolded terms, highlighting the one from which the user was redirected is very useful, even in the lede. FaviFake (talk) 23:08, 11 July 2026 (UTC)

My change is specific advice for this important niche case. I included it within the appropriate section. I did not enumerate all possible reasons to use {{va}} because my change was not about that template in general, it was about one specific use. The point of the sentence is to help editors discover {{va}}, which I have never seen after many thousands of edits.

Adding anchors to the lead is unnecessary because readers land there by default. If you think all redirect targets should use {{va}}, that's fine by me. The combination I was looking for was bold+anchor. Getting "highlight on landing" is a bonus. So how about this version:

• Using a visible anchor template within bold like this: '''{{va|term}}''' , will render as term and highlight the term when readers visit the redirect.

Johnjbarton (talk) 02:19, 12 July 2026 (UTC)

But the section is about the use of boldface, and the {{va}} template doesn't even render its argument bold. So I have to agree with FaviFake that its inclusion is off-topic and doesn't belong there. It would likely be more confusing than helpful. Gawaon (talk) 03:15, 12 July 2026 (UTC)

I did not enumerate all possible reasons to use {{va}} because my change was not about that template in general, it was about one specific use.
Yeah. I'm saying that, if you want to recommend {{Va}}, do where that recommendation wouldn't be off-topic. You could add that same recommendation to every other part of this page, or the MOS in general for that matter. The text being formatted has nothing to do with it being a good anchor target. FaviFake (talk) 10:47, 12 July 2026 (UTC)

I've used {{va}} in this way in a few instances. It is indeed a very niche practice. I use it when the bolded term is not in the lead, but the section where it lives is not really about the bolded term and redirect. Definitely a niche situation. Incidentally, the user experience with this on desktop at least is not great. I've been WP:ASTONISHed when I've tripped on these. Because of this, I disagree with FaviFake's suggestion that we might want to use these in the lead. I'm not opposed to documenting the niche if we can figure out a way that doesn't distract from the non-niche cases. ~Kvng (talk) 00:03, 21 July 2026 (UTC)

Can you elaborate on the issues on desktop? A redirect lands on 1) the top of a page or 2) lands elsewhere in the page due an anchor, in both cases (hopefully) related to the redirect. Per MOS:BOLDREDIRECT these are commonly bolded, so bolded in the intro or bolded elsewhere. So the common practice is equivalent to '''{{subst:anchor|redirect term}}''' for case 2. My suggestion is simply to use the va form for the anchor.

I think it would be even better to have a {{redirect anchor}} the bolds and anchors to avoid the arcana of "subst". Johnjbarton (talk) 03:00, 21 July 2026 (UTC)

The landing is with the anchor at the very top of the browser window. In the case of FaviFake's suggestion to use these in the lead, that typically leaves the first sentence or paragraph of the lead off the top of the window. The reader gets better context if there is full lead text or the relevant section header in their window. Maybe a technical fix that would land the anchor in the middle of the window would make these more usable. ~Kvng (talk) 13:32, 21 July 2026 (UTC)

italics on other scripts

Apparently we don't have consistent guidance on not using italics on Cyrillic. I appear to have missed this 2016 edit. I found a discussion at Wikipedia talk:Manual of Style/Text formatting/Archive 8#MOS:BADITALICS vs WP:SHIPNAME from 2023 where folks were saying we should just habitually italicize in other scripts, which markedly differs from the earlier discussions in Wikipedia talk:Manual of Style/Text formatting/Archive 1, which seems more in line with the earlier spirit of the guideline - the difference of script suffices to distinguish it on the page.

This recent example where I noticed it is at Đuro Daničić#Books, which is a lengthy list that includes mostly foreign-language text, and a lot of Cyrillic. So we're effectively expecting the average English reader to make sense of that by not only comprehending foreign language text, but also letters in another script, and then also italicized letters. It's optimistic to say the least. --Joy (talk) 15:27, 14 July 2026 (UTC)

>So we're effectively expecting the average English reader to make sense of that by not only comprehending foreign language text, but also letters in another script, and then also italicized letters.

As the editor who added all those titles, I did not expect that at all. I provided the original titles for any readers who can read them, and then I also provided the translated titles to make them completely intelligible to all en.wiki readers in general. (Listing only translated titles and not mentioning the original ones would be unacceptable, of course.) As far as I know, titles of works are italicised in order to distinguish them from the surrounding text, to make it easier to follow; the same practice exists in Serbian, and thus for anyone who can read Serbian Cyrillic it is desirable to see the titles in italics, rather than in type identical to the author's name, publisher, and place of publication (all of them also in Cyrillic). On the other hand, those who can't read Serbian Cyrillic won't be aided by non-italicising, and might only be aided by complete romanisation of the titles – if they know BCMS without its Cyrillic alphabet (which is something I haven't done in this case, since the number of such readers is probably minor, and it would take up a lot of space and make the list even more cumbersome to follow). Basically, 99% of Wikipedia users don't know what's Рјечник, Рјечник, Rječnik or Rječnik, but for those who do know it's best to see Рјечник; the needs of the rest will be met by translating it as Dictionary.

It can also be noted that the last section of the list ("Bibliography") uses {{cite}} templates where the Cyrillic titles are automatically italicised as well.

The rule for non-italicising should apply to cases such as uezd: "An uezd (also spelled uyezd or uiezd; Russian: уе́зд (pre-1918: уѣздъ))", where we simply don't italicise a common noun in non-Latin script.

— Phazd (talk|contribs) 20:06, 14 July 2026 (UTC)

If your assessment is really as high as 99% on that metric, then we should consider whether the percentage of readers for whom there's no actual utility to the list also approaches that high a number. Ultimately, what are the odds that the average reader expects a general encyclopedia article to be a repository of all these foreign titles - WP:NOTDATABASE comes to mind.

With regard to the citation templates, they actually have a |script-title= parameter. --Joy (talk) 21:47, 14 July 2026 (UTC)

99% of WP readers do not need the article at all (who cares about some old linguist from a peripheral European country?), not just the list of his works. 99% of WP readers don't need 99% of WP articles in general. So what is even your point here? Maybe we could delete the entire encyclopedia? Many authors have this sort of more or less complete lists of works on WP, such as Alexander Pushkin#Works, some of them separated into articles of their own, which can end up as "featured", e.g. Fyodor Dostoevsky bibliography. Would you invoke WP:NOTDATABASE in these cases too?

The foreign titles are the correct titles, the only ones these books have been published and can be reliably identified under. If titles are to be provided, they have to be the original ones at a minimum, rather than editor-made translations and transliterations that wouldn't be verifiable without the originals side by side (not that translations and transliterations aren't desirable or valuable, and easier to use in the running text, quite the opposite, but the necessity of the originals shouldn't be up for debate).

Anyway, this isn't even a discussion of when to use and not to use italics anymore.

As for cite templates having the option to not italicise the titles, that's well noticed and it should be aligned with the guideline, or the opposite. As far as I'm concerned, the question should be resolved by following the usual orthographic practices in different languages, because at the end of the day the text should be readable to those who can read it and follow the orthographic norms of the language that it is written in. For comparison, we already follow non-English capitalisation of non-English work titles, e.g. Dnevnik jedne ljubavi.

— Phazd (talk|contribs) 22:54, 14 July 2026 (UTC)

P.S. The necessity of preserving the original text is exemplified by mistakes in transliteration that have taken place in practice. Just two days ago I corrected the Bulgarian transliteration table at Romanization of Bulgarian and drew the attention of Wiktionary editors at Wiktionary:Wiktionary:Grease pit/2026/July#Correct Bulgarian romanisation (ъ → ă or "). Thankfully the problem has been resolved there by editing a certain number of templates, but on Wikipedia itself I'm afrain there's many remnants of this mistaken nonexistent transliteration that will be impossible to hunt down, created simply because someone many years ago didn't distinguish between ă and ǎ. — Phazd (talk|contribs) 23:06, 14 July 2026 (UTC)

I don't understand why you're so quick to go for reductio ad absurdum here. In general, why are you being so combative? ISTR this being a non-crazy discussion about what amount of foreign-language titles are reasonable to include in the article and how. For example, maybe the readers will appreciate reading a biography and a summary of the most important works related to it, but we don't have a good way to present a laundry list of works that require so much translation and formatting to conform to a style guideline that ultimately doesn't benefit the readers. --Joy (talk) 07:57, 15 July 2026 (UTC)

The difference between any biography and a Dostoevsky bibliography is that the latter probably has more readership. Interestingly, that is a featured list, and most of the entries in tables have English titles that link to standalone articles, so it's easy to recognize that those are major works. Likewise, their names in the other script are not italicized there. That's what I expected to be the meaning of this style guideline. That's mostly how the FL looked at time of review in March 2014. Same goes for the lead sections of those articles on those works. --Joy (talk) 08:31, 15 July 2026 (UTC)

@Joy No, this was originally supposed to be (judging by your initial maintenance tag and the page where you opened this topic) just a discussion on whether to use italics on non-Latin work titles, within or outside lists of works. Your tendency to focus on criticising the structure and purpose of one specific list of works is so nitpicky and based on made-up arguments and metrics that I can't help but regard it as hostile, and respond accordingly. I won't argue about the list here anymore, there are existing guidelines and MoS pages where we can more clearly discuss the problem if you believe it to be necessary. Please let me know if you want to open such a discussion.

As far as italics go, the only argument against them remains the idea that laymen will find the form Рјечник less useful/readable than Рјечник, which is of course not true. On the other hand, I've provided the argument in favour of using italics above.

The Dostoyevsky bibliography, including its 2014 version, actually does italicise the Russian (Cyrillic) titles, starting with the section "Almanacs", and then everything else that follows. Evidently, editors intuitively disregarded the rule even before the 2016 change, perhaps in part due to the different formatting of the two parts of the bibliography (the former part is in tables, the latter is in prose in bullet points, where distinguishing titles through italics is more useful). In part, doubtlessly, because it's just normal to italicise book titles, at least in English. (On a second look, however, it does seem that Russians tend to not italicise book titles, but use other means of distinguishing the different parts of a bibliographic reference, as I see in Chicago Manual of Style 17th ed. §11.100, and from checking the bibiographies of Russian scholarly works. This is thus an problem I now have no definitive solution to, and I might have to retract the above idea of sticking to the original language's practice since it may lead to using too many different formatting styles.)

I think we can agree that either way the guidance should be clarified. The bolded general statement "Text in non-Latin scripts ... should neither be italicized as non-English nor bolded" is then followed by describing the exception for titles. That may leave one wondering what's the text that shouldn't be italicised, and the bold formatting seems to give it much more weight than the following exception to the rule. Hopefully I understood the rule correctly, and based on that I provided the above example with the common noun "uezd". So, I propose that the first statement be un-bolded and clarified to say that it applies to common nouns – and perhaps quotations in ordinary prose, and maybe some other cases?

— Phazd (talk|contribs) 05:27, 21 July 2026 (UTC)

Exactly, the guideline is just not consistent if it's like this. For years, it preached the italicizing was not necessary. Then this exception was carved out - but it's a huge one, because titles of sources is a huge portion of when foreign terms appear in the encyclopedia. --Joy (talk) 08:25, 21 July 2026 (UTC)

I'd say it's not outright inconsistent, but it's not formulated well, because the (indeed significant) exception is not presented appropriately in comparison to the main rule. Is there a way to ask for further feedback from more editors? — Phazd (talk|contribs) 03:58, 26 July 2026 (UTC)

I think the current MOS:BADITALICS guidance on this is fine

current contents sans formatting, for reference

If it is necessary to include terms written in a non-Latin script, they can be placed in parentheses. Text in non-Latin scripts (such as Greek, Cyrillic or Chinese) should neither be italicized as non-English nor bolded, even where this is technically feasible; the difference of script suffices to distinguish it on the page. However, titles of major works that should be italicized are italicized in scripts that support that feature (including Latin, Greek and Cyrillic); do not apply italic markup to scripts that do not (including Chinese, Japanese, and Korean).

I would even support expanding the guidance to include all cases where one would otherwise italicize, and orthogonally I would support allowing it on all scripts.

The reason is, I think it's usually pretty easy to recognize italics in other scripts, due to the slant, and as a reader that gives me info like "that's a title" or "that's a word-as-word". Dingolover6969 (talk) 06:36, 15 July 2026 (UTC)

I would like to note, as a side observation, that if we had the {{tmajor}} template proposed far above on this page, then it would make it significantly easier to harmonize a style change on this question, on the portion of pages that used that template. Dingolover6969 (talk) 06:38, 15 July 2026 (UTC)

Maybe I misunderstood something, but I can't find the mention of that template? — Phazd (talk|contribs) 05:28, 21 July 2026 (UTC)

Oh, sorry, that's a suggestion from a different discussion on this talk page that I could have linked for clarity. It's not directly relevant to the current discussion, in any case. Dingolover6969 (talk) 04:49, 27 July 2026 (UTC)

Italic titles on associations

Foreign term are written in italics. But are italics used in titles when it is about an association/group/company? I have no clear idea if the group Femmes et Sciences should be italicized or not. ReyHahn (talk) 16:56, 16 July 2026 (UTC)

No italics. To quote the page, "Some proper names—including personal names, place names, and the names of organizations—are usually not italicized as non-English vocabulary." To quote MOS:I!EPR, you can use {{langr}} Dingolover6969 (talk) 17:32, 16 July 2026 (UTC)

Thanks.--ReyHahn (talk) 18:52, 16 July 2026 (UTC)

lowercase l and uppercase I not distinguishable

In article Idia, there is an important word (a foreign language title) namely: Iyoba ... this word begins with uppercase I. Uppercase because it is a title of nobility. But when I read the word, I assume it begins with a lowercase L. I presume many other readers will also be confused. I'm doing a GA review of the article. My question is: does the WP MOS provide the options to use a serif font in this situation? I realize that WP by default uses san-serif, but certainly there must be an exception or some sort of workaround that editors can use to minimize reader confusion. Noleander (talk) 17:45, 28 July 2026 (UTC)

Hmm, for me they are clearly distinct, even though a sans serif font is used – the uppercase I has bars at the top and bottom, while the lowercase l lacks them. So the issue may be browser-specific.

In any case, I'd say that changing the font mid-sentence for specific words would be ugly and confusing, and should be avoided. Gawaon (talk) 02:38, 29 July 2026 (UTC)

Browser is just one possibility. Operating system, installed fonts, skin, possibly other factors too. --Redrose64 🌹 (talk) 07:28, 29 July 2026 (UTC)

I don't think there is an exception or workaround for this, except for choosing a different font in your own rendering preferences.

It is a good reason for not using the default sans-serif font for mathematical formulae, though, where it can be more common to need to distinguish $I$, $l$ (or $\ell$), $1$, and $\mid$. —David Eppstein (talk) 07:40, 29 July 2026 (UTC)

Changing font might not be acceptable, but {{rn}} (Roman numerals) can be used such as in IV or Iyoba. Johnuniq (talk) 07:53, 29 July 2026 (UTC)

That one makes much more sense for IV than for Iyoba, though. Gawaon (talk) 11:13, 29 July 2026 (UTC)

Well, if this means using some Unicode entity called "ROMAN NUMERAL XYP..." in place of the letters "I" and "V", I think it is a truly terrible idea. Imaginatorium (talk) 11:33, 29 July 2026 (UTC)

@Imaginatorium: It doesn't. All that {{rn}} does is to wrap its parameter in <span class="roman-numeral" title="Roman numeral">...</span>. Fonts for this class are defined in the first rule of Template:Roman numeral/styles.css - specifically the declaration font-family: "Nimbus Roman No9 L", "Times New Roman", Times, serif which basically tells your browser to use one of three different named serif fonts, if none are installed then to use its default serif font.

As a side-remark, you can use non-numeric letters like {{rn|SPQR}} and no error is emitted: SPQR - but it might puzzle screen reader users if that title attribute is read out. --Redrose64 🌹 (talk) 16:51, 29 July 2026 (UTC)

I wonder if that would be read out as "I, yoba", because of the span. I don't know much about screenreaders. Dingolover6969 (talk) 08:11, 31 July 2026 (UTC)

The <span>...</span> element has no semantic meaning at all. Its sole purpose is to group together zero or more characters so that they may be given common attributes, in this case class and title. --Redrose64 🌹 (talk) 16:05, 31 July 2026 (UTC)

It shouldn't really be necessary to say this, but using a "Roman numeral" label to mean something unrelated to Roman numberals is a terrible idea, even if only (85%-truly). Imaginatorium (talk) 17:09, 31 July 2026 (UTC)

I think the main problem is that no one has figured out a great way to apply such a suggestion that is much less likely to confuse than illuminate. If a word in a sentence were randomly serif that would seem weird to me, although I assume most readers won't actually notice.

In this particular case the fact that it's a non-English word and thus already in italics could make for a pretty strong case that it could also be serif, since it's already supposed to stick out. But then you might have to do that for the non-English in the whole page, so it doesn't stick out among the stick-outs... Dingolover6969 (talk) 08:25, 31 July 2026 (UTC)

Based on the above, it looks like WP does not provide a standard workaround to use serifs in words that contain uppercase "I" and lowercase "l". Which is a shame, because the default font used by many WP skins is sans-serif, so WP readers won't be able to read many words properly, such as "Iyoba" here; or even the topical Iliad. As editors, our top priority is to help readers, even if that means deviating from the rules sometimes. Anyway, there is no reason to continue a discussion - in fact, I'm not writing the article in question (Idia) ... I'm just a GA reviewer. Noleander (talk) 17:43, 29 July 2026 (UTC)

Noto Sans is a sans-serif font that uses a notably different form for the uppercase I (with bars at the top and bottom). It's open source and, in principle, we could require it as the default font and distribute it as a web font to systems that don't have it yet, keeping a generic sans-serif just as a fallback. However, I suppose such a change to the default skin would not be easy to pull off. Gawaon (talk) 03:42, 30 July 2026 (UTC)

Personally I believe we should just switch the default font to be serif, for this and other reasons. No exceptions then needed! Dingolover6969 (talk) 08:14, 31 July 2026 (UTC)