Template talk:Lang/Archive 4

-Latn stuff
So, how are we going to move forward for things like. Do we just start creating these templates (and if so, with what calls to the module?), or do we want to use and pass a parameter to it, or ...? I may have missed some prior discussion on this, but so much has been going on I wanted to explicitly ask about this before taking any action. — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  16:32, 13 December 2017 (UTC)
 * This topic hasn't been discussed. Were it up to me, I would say: don't fork  → .  In the old days you would have had to fork but now, there is Latn so use that.


 * Additionally, I think that by using the parameter we can think about a bot task to rewrite instances of templates like and  to use  and then delete  and.
 * —Trappist the monk (talk) 11:44, 14 December 2017 (UTC)

— SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  17:09, 19 December 2017 (UTC) — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  23:32, 20 December 2017 (UTC)
 * Quick test cases:
 * → fu
 * → fu
 * → casa
 * → casa
 * The output is inconsistent. If we're going to italicize by default in that template family, that needs to apply to Latn output or people are going to get confused, and we'll have inconsistent results in our output. There is no use case for Latn script output being non-italic where the same output in a Latin-script language would be italicized, or vice versa. The only variance of any kind I'm aware of is that, per MOS:TITLES, the title of a work that should be italicized is italicized in Greek and Cyrillic (and by extension other alphabets close to Latin) but not in CJK (nor by extension others that have no relationship to Western letterforms, e.g. Arabic and various Indian languages); and that's a manual case-by-case tweak, not something the template needs to "know" about. Given the amount of Latn I intend to use, now that we have that feature, having to also manually italicize would be seriously onerous.
 * It all goes back to the presumed 'default' states doesn't it?  templates default to italic rendering unless that condition is overridden by no.  In your example,  defaults to italic because it's a  template but that is overridden with no because that was the template's state when I converted it to use Module:lang.
 * When there are competing and possibly contradictory parameters as in your example,, one must prevail or there must be an error message. I chose italic to be the winner when competing with Latn (because fu might be a proper name – which was what started all of this).  To make your example work, you must write:
 * → fu
 * I think that all of this is documented at Template:Lang-lo.
 * —Trappist the monk (talk) 17:54, 19 December 2017 (UTC)
 * I understand that's what's happening now; it's just undesirable, because 99% of the time it's not going to be a proper name and we will want the italics, for language if we emit Latn.  It's already a hassle – but one we're used to – that, etc., don't italicize while , etc., do when in Latin-based scripts.  It gets into "this is so confusing I want to shoot someone" when it veers back in the other direction and doesn't italicize when Latn.  It's re-inspire the original idea of creating  templates that emit the expected italics that are consistent with , etc., etc. Another way of putting it, for a class of templates that does italicize, the only logical output for Latn is the italics, for the same reason as the original italicization. For such a template group, Latn  italics, rendering Latnyes redundant and a waste of time.  Or in other words,  essentially    , simultaneously (conceptually speaking).  This is  problematic in in the  case, because we cannot do either of the obvious wikimarkup things: both   and   will fail (for different reasons).  If there's a way to make the latter case stop failing that might be good, too, though it has the benefit of preventing people wrongly italicizing non-Latin-based scripts with  .  I'm not trying to have a sport argument or philosophical debate with you. I'm super-impressed by all the work so far, but am  you to fix this one issue, because having to deal with it, as-is, may waste untold of person-hours for many editors over the long haul: manually adding undefined a zillion times, and using searches to find a zillion cases where people left it out and then going and fixing them (again and again and again), and writing bots to do it, and arguing with people confused by the docs, and etc.  If you're telling me this can only be addressed at the language-specific template level, then that's very depressing, but it sounds like its not ("I chose italic to be the winner ...").  Aside: In the case of don't-italicize-a-proper-name, we'd want , and this would be very, very rare because we generally don't use lang markup around proper names except for titles of works sometimes, and when using a place or personal name in a words-as-words manner, e.g. a cross-language comparison like "Munich (München)" – both cases that usually call for italics. Virtually all Latn cases will need the italics.  When referring to a Laotian named Fu, we'd just use Fu, without markup at all (or most of us would – there's no policy about it or anything; maybe it will become more common, but I doubt it).
 * I understand that's what's happening now; it's just undesirable, because 99% of the time it's not going to be a proper name and we will want the italics, for language if we emit Latn.  It's already a hassle – but one we're used to – that, etc., don't italicize while , etc., do when in Latin-based scripts.  It gets into "this is so confusing I want to shoot someone" when it veers back in the other direction and doesn't italicize when Latn.  It's re-inspire the original idea of creating  templates that emit the expected italics that are consistent with , etc., etc. Another way of putting it, for a class of templates that does italicize, the only logical output for Latn is the italics, for the same reason as the original italicization. For such a template group, Latn  italics, rendering Latnyes redundant and a waste of time.  Or in other words,  essentially    , simultaneously (conceptually speaking).  This is  problematic in in the  case, because we cannot do either of the obvious wikimarkup things: both   and   will fail (for different reasons).  If there's a way to make the latter case stop failing that might be good, too, though it has the benefit of preventing people wrongly italicizing non-Latin-based scripts with  .  I'm not trying to have a sport argument or philosophical debate with you. I'm super-impressed by all the work so far, but am  you to fix this one issue, because having to deal with it, as-is, may waste untold of person-hours for many editors over the long haul: manually adding undefined a zillion times, and using searches to find a zillion cases where people left it out and then going and fixing them (again and again and again), and writing bots to do it, and arguing with people confused by the docs, and etc.  If you're telling me this can only be addressed at the language-specific template level, then that's very depressing, but it sounds like its not ("I chose italic to be the winner ...").  Aside: In the case of don't-italicize-a-proper-name, we'd want , and this would be very, very rare because we generally don't use lang markup around proper names except for titles of works sometimes, and when using a place or personal name in a words-as-words manner, e.g. a cross-language comparison like "Munich (München)" – both cases that usually call for italics. Virtually all Latn cases will need the italics.  When referring to a Laotian named Fu, we'd just use Fu, without markup at all (or most of us would – there's no policy about it or anything; maybe it will become more common, but I doubt it).
 * An important reason for the existence of these templates is that which is unseen. The templates make for correct html so that your browser or your screen reader does the right thing.  You should not rely on Latn as a guaranteed way of rendering text in italics.  There are 90 language codes in the IANA subtag registry that expressly include   – there are 44 other languages that suppress other scripts.  One of those things yet to be done is to add support to the module so that we can detect   so that we don't write  – we write that now but shouldn't.  And an oh-by-the-way: script isn't supported by  because you can add the script subtag directly to the language code in the template call, something that you can't do with the matching  template.
 * Pretty much the last thing that I want to do is break every existing template – that's multiple hundreds of thousands of articles.  I'm actually astonished that the count of articles in  only just peeked over 10,000 after I finished converting most of the 600+  templates to use the module.  When I did that, in most cases I set italic only when the wikitext version of the template did not italicize  .  The notion that 'all'  templates rendered in italic is largely false; a lot of them did/do, a lot of them didn't/don't.  But, right now, the vast majority of  templates are rendering just as they were before the change.
 * I confess, for all of these words, perhaps I'm losing the plot. If you are expecting that all  templates act exactly the same way, they don't because they never did.  I do wonder if we might create an initial-italic-state parameter that might be used where we now use italic in the  templates'  .  This new parameter would set the template's 'default' italic rather than have the module assume that all  templates are the same and so have the same 'default'.  If we did that, for those language codes that permit Latn, it would not be necessary to write  .  initial-italic-state would be a required parameter in every  template so that we can replace the current module's global italic setting.   would not be changed.
 * Another way might be to have the templates that aren't italicized call a different initial function in the module so  where the   function sets  .  This is probably better because it will likely be easier to implement.  Or not.
 * There will still be the issue of Latn competing with no. I still choose to have italic win.  Were we wanting to write, say, the Arabic name for a certain recalcitrant mountain using Latin script, we would have to write:
 * We require Latn because we use it to make the correct  attribute and to turn off right-to-left support.  Because Latn is stronger than , italics would be applied.  But, because Mohamed's Mountain is a proper name that should not be rendered in italic font, we require no which must be stronger than Latn.
 * —Trappist the monk (talk) 01:38, 21 December 2017 (UTC)
 * I have implemented the second of my two ideas in Module:lang/sandbox, created, and tweaked to test.  Results in my sandbox.
 * specifies an initial  because it calls  .  That style can be overridden by Latn without the need to also set yes:
 * → fu
 * —Trappist the monk (talk) 12:41, 21 December 2017 (UTC)
 * No time right now (work calls), but  is not what   is for. 'Mohamed's Mountain' is a gloss, not a Latin transliteration of or encoding of Arabic. That would be ǧbl mḥmd (among many other approaches for latinizing/romanizing Arabic), for Arabic script جبل محمد. Maybe there are  templates for language that usually/always use a Latin-based script and which are not italicizing; most of them do, so this is an inconsistency problem to fix, not an excuse for us to make things even more confusing.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  21:57, 21 December 2017 (UTC)
 * You know, sometimes I wonder that people can communicate at all. The Mohamed's Mountain example was merely an illustration. I did write the Arabic name assuming, more fool I, that it is understood to be a placeholder and not an accurate transliteration of actual Arabic.  The purpose of the illustration is to show that for proper names transliterated into Latin script, we require:
 * Latn
 * so that the html  attribute is correct
 * so that the html  attribute, normally associated with code   is properly omitted
 * no
 * to undo the automatic italic font style set by latn
 * —Trappist the monk (talk) 22:32, 21 December 2017 (UTC)
 * Ah, okay. Well, I had been on my way out the door to catch a train, so maybe I didn't read that carefully enough.  Anyway, the lack of consistent behavior is the issue, nothing more.  I'm not making any kind of philosophical point, or even a preferences one (why were  and  ever doing something different, italics-wise, for the same language encoding in the first place? Doing either italics or no italics predictably would be preferable, whichever default people want it to be; doing the italics when the script is Latin-based [usually or via  ] would be the most practical, since most uses do need to be italicized – that's a "don't waste editors' time assessment, nothing more).  Maybe we just need to have an RfC to normalize it all after the re-coding dust settles.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  16:51, 23 December 2017 (UTC)
 * doing the italics when the script is Latin-based [usually or via ] would be the most practical is what most of the templates do now – languages that are written in multiple scripts are problematic: which script do you choose as the 'default'?  Fortunately for me, someone else has already taken the trouble to make those decisions so all that I have done is to continue to use the default that that someone chose.
 * Making do the same thing is difficult for a couple of reasons:  it has always rendered in normal font style so where italic rendering is required, italic wiki markup is applied either inside (where the template can detect it) or outside (where the template cannot detect it).  We would need to create some sort of mechanism to know from the language code (a big-damn table listing all language codes that are to default render in Latin script – yuck), or a mechanism to read the content of   and make a decision from that – is  text in , or all of the text in the display portion of a wikilink, Latin script?  We might crib something from Module:Language/scripts (  looks promising).  We should also make sure that the   test (I hate camelCase) doesn't fail on punctuation because some languages use rather a lot of it: .  This latter doesn't, of course solve the problem of the tradition that  never automatically italicizes its content.
 * —Trappist the monk (talk) 17:52, 23 December 2017 (UTC)
 * I have moved the weaker-initial-style code to the live module and have an AWB script that I am using to revise the individual templates; 50 done, 550ish to go.
 * —Trappist the monk (talk) 20:41, 23 December 2017 (UTC)
 * In the sandbox is an experiment that auto-italicizes when  holds only Latn script.  Latn script, for the purposes of this new function, are those characters specified in these Unicode code charts:
 * C0 Controls and Basic Latin U+0020–U+007E
 * C1 Controls and Latin-1 Supplement U+00A0-U+00AC, U+00C0–U+00FF
 * Latin Extended-A U+0100–U+017F
 * Latin Extended-B U+0180–U+024F
 * Latin Extended Additional U+1E00-U+1EFF
 * Latin Extended-C U+2C60–U+2C7F
 * Latin Extended-D U+A720-U+A7FF
 * Latin Extended-E U+AB30-U+AB6F
 * Alphabetic Presentaion Forms U+FB00-U+FB06
 * Halfwidth and Fullwidth Forms U+FF01-U+FF3C
 * This code only applies to
 * italicizes Latn text:
 * except when  is   or  :
 * does not italicize non-Latin text:
 * does not italicize mixed scripts:
 * allows interwiki links to non-Latn Wikipedias:
 * I don't know if this should be kept or not. Automation is handy but contributes to laziness and complacency and that impacts the quality of the encyclopedia.  I have fixed too many cs1|2 templates that were created by automated tools to believe that automation fosters quality.
 * —Trappist the monk (talk) 18:10, 26 December 2017 (UTC)
 * Support. It seems that lang/sandbox retains outside and inside italics ( →  and   → ) which addresses my earlier concerns at . -- Michael Bednarek (talk) 01:03, 27 December 2017 (UTC)
 * ignores both inner and outer italic markup just as does.  The difference is that  detects the text 'Der Ring des Nibelungen' as German written with characters from the Unicode Latin code set so it switches from   to.
 * —Trappist the monk (talk) 10:26, 27 December 2017 (UTC)
 * So the italic output of my example has nothing to do with the Wikitext italic markings I used? Let's see: " → " – indeed. Hmm, so what happens if I want to use "München" without italics? "  → " (unbidden italics) versus "  → München" (no italics). Baffled, Michael Bednarek (talk) 14:49, 27 December 2017 (UTC)
 * Baffled? Really?  'München' is a word constructed from characters that are members of the Unicode Latin code sets.   sees that and applies italic styling;  is blind to the construction of the text that it wraps.  Neither template is able to 'read' the text that it wraps and make decisions based on that reading.  If they could, then Der Ring des Nibelungen would be italicized because it is a title; München would not because it is a name; neither determination relying on the alphabet in use.  We could, I suppose, toss a couple more parameters onto the pile: title would italicize text for all languages except for CJK; name would render text in upright font regardless of script but would yield to italic.  Don't hold your breath for these.
 * —Trappist the monk (talk) 15:27, 27 December 2017 (UTC)
 * Except the sandbox isn't applying language tags when surrounded by italics:
 * with no  or   being output, whereas
 * correctly outputting the  —  OwenBlacker (talk; please &#123;&#123;ping&#125;&#125; me in replies) 13:23, 28 December 2017 (UTC)
 * Good catch, that. The module outputs the correct thing:
 * MediaWiki does whatever it does to convert the enclosing italic wiki markup to  which give this:
 * 
 * I speculate that as part of MediaWiki's cleanup, some bit of code sees the nested  and removes the inner pair leaving
 * Der Ring des Nibelungen
 * I think that this means that we must always use a tag for the   and   attributes and wrap that in  when italics are required.  I'll make the necessary change sometime today.  This issue should probably be pursued at phabricator but I'll leave that to a later date or to someone else. Our use of  here appears to me to be in compliance with html5.
 * —Trappist the monk (talk) 14:28, 28 December 2017 (UTC)
 * Fixed, I think. Module output is:
 * which MediaWiki converts to:
 * 
 * and which cleans up as
 * —Trappist the monk (talk) 15:59, 28 December 2017 (UTC)
 * with no  or   being output, whereas
 * correctly outputting the  —  OwenBlacker (talk; please &#123;&#123;ping&#125;&#125; me in replies) 13:23, 28 December 2017 (UTC)
 * Good catch, that. The module outputs the correct thing:
 * MediaWiki does whatever it does to convert the enclosing italic wiki markup to <i ></i> which give this:
 * <i ></i>
 * I speculate that as part of MediaWiki's cleanup, some bit of code sees the nested <i ><i ></i></i> and removes the inner pair leaving
 * <i >Der Ring des Nibelungen</i>
 * I think that this means that we must always use a tag for the   and   attributes and wrap that in <i ></i> when italics are required.  I'll make the necessary change sometime today.  This issue should probably be pursued at phabricator but I'll leave that to a later date or to someone else. Our use of <i ></i> here appears to me to be in compliance with html5.
 * —Trappist the monk (talk) 14:28, 28 December 2017 (UTC)
 * Fixed, I think. Module output is:
 * which MediaWiki converts to:
 * <i ></i>
 * and which cleans up as
 * —Trappist the monk (talk) 15:59, 28 December 2017 (UTC)
 * Fixed, I think. Module output is:
 * which MediaWiki converts to:
 * <i ></i>
 * and which cleans up as
 * —Trappist the monk (talk) 15:59, 28 December 2017 (UTC)
 * —Trappist the monk (talk) 15:59, 28 December 2017 (UTC)
 * —Trappist the monk (talk) 15:59, 28 December 2017 (UTC)

Gelobet seist du, Jesu Christ, BWV 91
I am sorry, I don't have time to check if my question was answered already and how? I returned after Christmas and looked at its cantatas, including Gelobet seist du, Jesu Christ, BWV 91, and saw to my irritation that the lang-template somehow was changed, and the title doesn't show properly any more. This concerns thousands of my edits. Tell me that it's only a bad dream please. --Gerda Arendt (talk) 18:09, 27 December 2017 (UTC)
 * Yep, is in flux as is evidenced by the length of this talk page (which should be given a reading when you can find the time because what happens here concerns you – participation is good too).  I think that the current version of  is broken in that it is too strict in how it asserts its default styling.  For the concern that you have voiced here, the sandbox version might be better but it's different in other ways:
 * → Gelobet seist du, Jesu Christ
 * → "Gelobet seist du, Jesu Christ"
 * → "Gelobet seist du, Jesu Christ, daß du Mensch geboren bist"
 * } → Kyrieleis
 * All of the sandbox renderings are, I think, properly italicized except the title of Luther's hymn. The goal is to not require  wikimarkup  for the large number of Latin-script usages of the template and to make sure that non-English text written with Latin script is italicized (non-English, Kyrieleis, as a transliterated word written with Latin characters, should be italicized, right?).  This lies on top of another goal to produce correct underlying html for all instances of this template and the 650-ish  templates.
 * It will not be possible for the template to get it right all of the time – Luther's hymn, for example – because templates cannot see beyond the opening  or the closing   so they cannot know that the context for a particular instance of the template is not to be italicized.
 * What to do then? For the time being: nothing.  If things go as I anticipate, a correct solution will lift itself from the muck and the mire.  If your perfect happiness depends on everything being exactly as it was before, alas, I think that will not happen (Luther's hymn).  For the most part, those things that were italicized with wiki markup will render correctly (non-Latin scripts excepted).
 * —Trappist the monk (talk) 19:38, 27 December 2017 (UTC)
 * All of the sandbox renderings are, I think, properly italicized except the title of Luther's hymn. The goal is to not require  wikimarkup  for the large number of Latin-script usages of the template and to make sure that non-English text written with Latin script is italicized (non-English, Kyrieleis, as a transliterated word written with Latin characters, should be italicized, right?).  This lies on top of another goal to produce correct underlying html for all instances of this template and the 650-ish  templates.
 * It will not be possible for the template to get it right all of the time – Luther's hymn, for example – because templates cannot see beyond the opening  or the closing   so they cannot know that the context for a particular instance of the template is not to be italicized.
 * What to do then? For the time being: nothing.  If things go as I anticipate, a correct solution will lift itself from the muck and the mire.  If your perfect happiness depends on everything being exactly as it was before, alas, I think that will not happen (Luther's hymn).  For the most part, those things that were italicized with wiki markup will render correctly (non-Latin scripts excepted).
 * —Trappist the monk (talk) 19:38, 27 December 2017 (UTC)
 * What to do then? For the time being: nothing.  If things go as I anticipate, a correct solution will lift itself from the muck and the mire.  If your perfect happiness depends on everything being exactly as it was before, alas, I think that will not happen (Luther's hymn).  For the most part, those things that were italicized with wiki markup will render correctly (non-Latin scripts excepted).
 * —Trappist the monk (talk) 19:38, 27 December 2017 (UTC)


 * Thank you for a thoughtful answer, which still leaves me puzzled. I believe that Requiem, Magnificat and Kyrieleis became part of English, and should not be italic, but still I so far thought the lang-template might help understanding from what language a word came, and help a screenreader pronounce. I wonder if I should go over my GAs and FAs and remove the template until things will get better, but I REALLY have more fun things to do. We proclaim such articles are among the best Wikipedia has to offer, and now they don't manage to show a piece title correctly! We have c. 200 cantata articles alone, every single one using the template more than once. --Gerda Arendt (talk) 20:29, 27 December 2017 (UTC)
 * From MOS:FOREIGNITALIC:
 * "If looking for a good rule of thumb, do not italicize words that appear in Merriam-Webster Online."
 * Requiem, Magnificat, yes; Kyrieleis, not there. Spelled correctly?  If it has become part of English, then it shouldn't be marked up with  as Ancient Greek, right?
 * There are two purposes for . One is to style the text that it holds according to MOS:FOREIGNITALIC.  The second, just as important, maybe more so, is to render correct html so that browsers and screen readers know what to do with the text held by the template; this can get a bit confusing when we switch from left-to-right English into right-to-left Yiddish written with a Hebrew script.  The first part, we know, is broken; the second part is not.
 * Were I you, I would not go over my GAs and FAs and remove the template until things will get better because the corollary to that is: now that things are better, I should go over my GAs and FAs and restore the template.
 * —Trappist the monk (talk) 22:45, 27 December 2017 (UTC)
 * Were I you, I would not go over my GAs and FAs and remove the template until things will get better because the corollary to that is: now that things are better, I should go over my GAs and FAs and restore the template.
 * —Trappist the monk (talk) 22:45, 27 December 2017 (UTC)


 * When do you expect improvement? - Sorry about Kyrieleis, - seems that it only entered German ;) - short for "Kyrie eleison". Which translates to Lord, have mercy! --Gerda Arendt (talk) 23:02, 27 December 2017 (UTC)
 * You want me to predict the future? If only I could ...  It is my general practice to talk about changes and make sandbox changes which allows time for me to rethink and time for comments from other editors before I commit to anything.  As a guess, sometime around the new year ...
 * —Trappist the monk (talk) 01:07, 28 December 2017 (UTC)
 * A week more or less is no problem, but if we get close to TFA day and nothing happened, I'll remove the template. We can't present something that obviously doesn't follow the MoS in the title, twice. --Gerda Arendt (talk) 20:15, 28 December 2017 (UTC)

italics and proper names
There have been a few comments on this talk page saying that non-English proper names are not to be italicized: I recently stumbled upon WP:NCPLACE which appears to disagree. I went looking for something to support the comments above and did not find it. Where is it written that non-English proper names are not to be italicized?
 * while italics are commonly used for words in other languages, they are not used for proper names – Justlettersandnumbers
 * because we don't use italics for proper names – Justlettersandnumbers
 * We need to be able to selectively disable ... the auto-italicization of non-English content in ... templates that auto-italicize ..., so that the style is not applied to proper names – SMcCandlish
 * Expected behavior of versus is that the former will always produce non-italic output; it's too often used for proper names which are not italicized in most contexts. – SMcCandlish

—Trappist the monk (talk) 15:00, 19 December 2017 (UTC) — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  17:09, 19 December 2017 (UTC) — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  02:58, 29 December 2017 (UTC)
 * MOS:ETY is what I usually cite for that, . McCandlish is more likely than I to know if it is also covered elsewhere. Justlettersandnumbers (talk) 15:58, 19 December 2017 (UTC)
 * Right in front of my face and I didn't see it. Always been a failing of mine, Mom says so.
 * —Trappist the monk (talk) 16:10, 19 December 2017 (UTC)
 * The shortcut MOS:BADITALICS gets even closer to it (same section, though). In theory, we shouldn't even need to spell that out, because it's common sense. No one writes "US President Donald Trump had an informal meeting with Mexican President Enrique Peña Nieto and several other Latin American dignitaries in Buenos Aires, Argentina, before returning to Washington, DC." That's not a recognizable style advised in any style guide anywhere. But I guess just enough people have gone around italicizing non-English proper names that we had to insert an "AJ rule" to stop doing it. (That seems plausible – I've encountered just enough italicization of non-English PNs to consider it a nuisance.) Non-English titles of books, films, etc., take italics, but they would anyway because they're titles (MOS:TITLES). Short works and sub-works go in quotation marks, and should also be italicized inside the quotes as non-English. It's sometimes not uniformly done with song titles and such if they're familiar to English speakers. It probably shouldn't be done if the work itself isn't really in a non-English language except for bits of it; "Que Sera, Sera (Whatever Will Be, Will Be)" seems to be more hair-splitting than anyone cares for. Non-English article titles in journals and such should be italicized within the quotation marks by default; but, per WP:CITEVAR, if our article is consistently using a citation style, and it happens to be one which forbids that [and I'd want to see the rule stating that! People make up too much BS about citation styles.], then the italics could be dropped.  When we're comparing the English and non-English names of things, that's a words-as-words case (MOS:WAW), so italics are employed even for a proper noun in that special case: "Munich (München)". MOS:BADITALICS/WP:ETY covers this, I think.  Historically, this has often not been done very consistently in leads, so it'll be fine if the template does it by default.
 * User:SMcCandlish, your stance above took me by surprise. I have a distinct recollection of you writing somewhere else that non-English titles of songs and other short works, e.g. "Bist du bei mir" and the waltz "Wiener Blut", are to be surrounded by quotation marks and not italicised. This principle, formulated at WP:NCM, has been consistently applied to articles about arias and art songs.
 * Aside: The changed behaviour of Lang in this regard is the cause of Gerda's and my consternation. I don't understand why the rewriting of Lang attempted to cure ills which practically didn't exist. The template applied markup (bold, italics) as directed, and it marked text as foreign. Nothing wrong there. Whether those tags were always within some esoteric rules is a matter proper documentation and editor education. Attempting to automatically correct erroneous use of templates will always end in tears. Rule of software development: 1) when re-implementing (re-writing) a function, don't change its functionality, or its compulsory parameter set – just rewrite it. 2) If you need new functionality, write a new function; then think about migration. -- Michael Bednarek (talk) 02:21, 29 December 2017 (UTC)
 * Italics: People don't seem to agree on this, so I was taking the "be consistent and avoid inventing exceptions" approach. If NCM wants there to be an additional exception (besides personal/organizational and place proper names), namely for song titles and the like in quotation marks, I don't really have much of an objection, as long as we apply consistently (e.g. to the German title of "99 Red Balloons", and so on). Coding wisdom: I don't disagree with any of that, and didn't make the changes.  However, this really only applies when the extant usage is widespread and ingrained.  There's nothing at all wrong with normalizing the behavior of the lang templates, updating their extant documentation, and correcting instances that don't comply.  People get used to such changes very quickly, especially when the change is an increase in consistency between templates. If given text like "Non-English equivalents of the rank of count include Graf (Germany), hakushaku (Imperial Japan), konde (Basque), conte (Italian), comte (French), conde (Spanish) ...", no one should have to go read the documentation of a dozen lang templates to apply the correct markup and get consistent results – they should all work the same for basic use cases.

More questions on italics
What is the intention for the provision of italics when called as (rather than as )? Historically, we've always needed to supply the italicisation manually and Template:Lang has made no effort to do so, but it seems that Template:Lang is applying not-italics automatically. Reading the code comment: suggests this is the issue, as I'm seeing   being output — overriding any surrounding italics set by   unless I send yes into the lang call.

Rather than applying a  attribute, perhaps it might make more sense to vary the tag used to contain the   attribute — using either   or   as appropriate? — OwenBlacker (talk) 10:29, 25 December 2017 (UTC)
 * I also see lots of uses where  previously emitted the title in italics, as it should be, but now it doesn't (ex.: Der Ring des Nibelungen), unless yes is applied (ex.: Der Ring des Nibelungen [and the wikitext italic markup should then be removed for good measure]), which is a pain. Can we have the previous behaviour back, please? -- Michael Bednarek (talk) 13:05, 25 December 2017 (UTC)


 * The intent is that each and  template shall be wholly responsible for font style of the text that it wraps.  Each template starts with a weak notion of what style it shall apply.  For, the style is  ; for the individual  template, the style is determined by which entry function is called by the template's  :   or.
 * For, the weak style can be overridden by specifying  script IANA subtag (where the registry permits that) or by yes.  Similarly, for the individual  templates, Latn will override the weak style set by   as will yes.
 * The comment that you quoted refers to this code snippet used in  where the return value is evaluated:
 * The comment that you quoted refers to this code snippet used in  where the return value is evaluated:
 * The comment that you quoted refers to this code snippet used in  where the return value is evaluated:


 * The table at html italic markup vs wiki italic markup shows how it works.
 * Module:Lang uses the  attribute and its properties because coding that was cleaner and, to me, more understandable than flip-flopping element tags.  I'm pretty sure that using the <em ></em> element for its typical 'style' is contrary to its semantic meaning: stress emphasis; see html5 @ w3c.
 * There is discussion suggesting that we should break with history and have auto-italicize when all of the text that it wraps is written using the Latn script.  We're not there yet.
 * —Trappist the monk (talk) 13:54, 25 December 2017 (UTC)
 * So in the meantime, 600,000 transclusions will not work as before and as intended? -- Michael Bednarek (talk) 14:04, 25 December 2017 (UTC)
 * Exaggerations have their place, I suppose, but that place is not here.
 * These  searches (italic markup outside the template and italic markup inside the template) suggest that the issue is somewhat less than 600k articles.
 * I have an awb script that will replace both outer and inner italic markup with appropriate parameters but am holding off on that until I can get around to making the module support automatic-italics-for-Latn-script-text – no sense in adding yes and then going back and taking it away because the module can apply italic style automatically. Perhaps in the interim, I'll set the  weak style to  .  If I do that, you should expect that in future, it will return to.
 * —Trappist the monk (talk) 16:06, 25 December 2017 (UTC)
 * The inline CSS is quite annoying. German text is shown by my common.css in a Fraktur font with the font-style property set to normal. This font-style property is now being overrided by the inline font-style property being added by the module, making the Fraktur oblique, which is as unnecessary as it is for non-Latin scripts, since Fraktur is already visually distinct. I can in turn override the obliqueness by putting !important at the end of the property (as I have to do for all the annoying script-formatting templates that contain inline font-family properties), but the code editor doesn't like !important and displays warnings (⚠). As far as flexibility is concerned, it would be better to use i tags. (I agree that em tags would be inappropriate.) I also think it's inelegant to use inline CSS, and it's certainly more concise to use i rather than . It also troubles me that the font-style is being set absolutely without regard to the context. It seems likely to cause problems. — Eru·tuon 19:57, 25 December 2017 (UTC)
 * So what is this, beat-up-on-Trappist-the-monk-day?
 * I have some sympathy for your plight, but only some. I would venture to guess that most Wikipedia readers do not have custom css that undoes MOS-approved styling and it is for 'most readers' that we have MOS which says how non-English text is to be formatted.
 * I proposed the  solution  to little comment.  I cannot know that you object to something if you do not say that you object.  But that is why I have written so many words on this page: I have written them so that you and other editors can know what it is that I'm thinking and have their say before I act.
 * —Trappist the monk (talk) 23:05, 25 December 2017 (UTC)
 * So what is this, beat-up-on-Trappist-the-monk-day?
 * I have some sympathy for your plight, but only some. I would venture to guess that most Wikipedia readers do not have custom css that undoes MOS-approved styling and it is for 'most readers' that we have MOS which says how non-English text is to be formatted.
 * I proposed the  solution  to little comment.  I cannot know that you object to something if you do not say that you object.  But that is why I have written so many words on this page: I have written them so that you and other editors can know what it is that I'm thinking and have their say before I act.
 * —Trappist the monk (talk) 23:05, 25 December 2017 (UTC)
 * I proposed the  solution  to little comment.  I cannot know that you object to something if you do not say that you object.  But that is why I have written so many words on this page: I have written them so that you and other editors can know what it is that I'm thinking and have their say before I act.
 * —Trappist the monk (talk) 23:05, 25 December 2017 (UTC)


 * Hey, sorry you're feeling pressured here. I do understand that you're doing a lot of work, some of which is pretty intricate, and it's really frustrating to have people filing incomplete bug reports of a work in progress. I definitely do appreciate the work you're doing here to make these templates more useful and more robust. I'm also noticing some differences for the same reason as — I have custom fonts set up for a handful of languages — but there are other problems too, as are being mentioned below. I'm sorry I hadn't seen your discussion about using  ; I struggle to stay on top of Talk: pages with a watchlist that's unmanageably long. (Similarly, I hadn't replied on the   /   conversation above, as you didn't know to ping me and I forgot to come back to look.
 * I tend to do a fair amount of drive-by language tagging (both with lang and lang-xx, as appropriate). While the template is in a state of flux, I've been removing surrounding italics and adding yes, to avoid people reverting the language tagging due to the change in formatting because foo isn't applying language tags (as I just commented above). I'm much more worried about the bugs that most users will see — with error messages about italic markup and italics being overridden by the template — than I am about custom fonts not showing (which is merely a mild irritation).
 * I'd suggest it's worth ensuring the code improves invisibly to logged-out users, be that by reduplicative code for when italics surround the template and are applied by it or by running AWB scripts more than once at different stages. But if you anticipate getting the bulk of the work done pretty quickly, then maybe that's less of an option. But effectively breaking one of the most widely-used template sets is definitely worth avoiding. If only so you don't get people like me and Erutuon pestering you while you're trying to concentrate on coding a better template :)
 * — OwenBlacker (talk) 13:00, 28 December 2017 (UTC)
 * I'm sorry that my tone was unnecessarily harsh. As to your proposal for the use of inline CSS, I had read it but didn't have any clearly formulated thoughts yet, until I saw the italicized Fraktur. It's a silly example: few people care to assign fonts to languages, and fewer use Fraktur. (I suspect that the MOS would recommend that Fraktur not be italicized, if it had any reason to say anything about it: it's so different from regular Latin script.) But I think the principle of avoiding inline CSS as much as possible is still worth following. — Eru·tuon 22:05, 29 December 2017 (UTC)

Message ( (help))
Can you please (!) help us with that thing somehow? I don't know how many articles are being defaced with this warning, but the outcome goes beyond any attempts at a manual fix. I see this warning virtually anywhere I go these days. The worse part is that whatever text was there originally, it has been replaced with this error message entirely, so the translation cannot be seen. Isn't there a better way?  Poeticbent  <span style="color:#FFFFFF;font-size:7.0pt;font-weight:bold;background:#FF88AF;border:1px solid #DF2929;padding:0.0em 0.2em;">talk 17:23, 25 December 2017 (UTC)
 * Right there on the category page that you linked in this topic's header it says, as I write this:
 * "The following 200 pages are in this category, out of approximately 8,323 total."
 * The italic markup is very likely the most common error message. The most common causes of that message are described in the help text (some form of which has been linked by the error messages since 7 November 2017).  Did you read the help text?  If you did and it did not lead you to a correct solution, can you show me the article that resists fixing so that I can help?
 * —Trappist the monk (talk) 19:43, 25 December 2017 (UTC)
 * I work a lot with the World War II inter-language articles. Here's the last example I ran into today: Ukrainian People's Militia. And thanks for writing back, . But please, don't ask me to fix it myself, while I'm working on other things an just researching similar subjects. Thanks for understanding. —  Poeticbent  <span style="color:#FFFFFF;font-size:7.0pt;font-weight:bold;background:#FF88AF;border:1px solid #DF2929;padding:0.0em 0.2em;">talk  20:17, 25 December 2017 (UTC)
 * Umm, remove the italic markup from this:
 * → Українська Народна Міліція
 * to make this:
 * → Українська Народна Міліція
 * See MOS:BADITALICS. Cyrillic text, except when it is the title of a book of other major work, is not italicized. This is a case where the initial editor chose to italicize the Cyrillic and no one noticed.  The template, at the time that Ukrainian People's Militia was created, did not and has not since rendered italic text, so the purpose here was not to 'undo' italic markup provided by the template.  The new version of the template has merely pointed out this long-standing error.
 * I've added this example to the help text.
 * —Trappist the monk (talk) 22:43, 25 December 2017 (UTC)
 * Dear, I asked you kindly to do something about that overriding template. The same concerns were raised by User:Altenmann below. Instead of addressing my concerns about the template, you seem to be looking at others to perform manual labour. Can you please remove (!) the warning. The warning is the real problem, NOT the italics. Please remove the absurdist scare-mongering in red from articles defaced with this overriding message. I just clicked on: the Mińsk Mazowiecki Ghetto and here it is, again.  Poeticbent  <span style="color:#FFFFFF;font-size:7.0pt;font-weight:bold;background:#FF88AF;border:1px solid #DF2929;padding:0.0em 0.2em;">talk 19:21, 28 December 2017 (UTC)
 * The error message was there for a reason (now fixed by a third party). The template was malformed:
 * In this implementation the text is a mix of right-to-left Yiddish written with the Hebrew script and a left-to-right transliteration (I presume – it could be some other language for all I know) written with the Latin script. The template was never intended to support mixed scripts in that way.  The error message is merely drawing attention to an improper use that has been improper since the article was created.
 * Yes, I am looking at others to perform manual labour. I do not read Yiddish, or Polish, or Italian, or Bengali, or ... so must rely on those of us who do have these skills to properly write these templates.  Those of us who do have those skills won't know that the template is broken unless we somehow show that the template is broken.
 * —Trappist the monk (talk) 10:57, 29 December 2017 (UTC)
 * An answer in best traditions of Bastard Operator from Hell. You broke what was working for ten years. Manual labor?? WTF? Templates are supposed to decrease manual labor. The sloppy programming which disrupted hundreds of articles must be reverted. Can someone launch RFC on this? - üser:Altenmann >t 15:12, 29 December 2017 (UTC)
 * The lang templates were "working" only in the sense that a Rube Goldberg machine "works". They were a loose amalgamation of hacks and workarounds and mixed-up code that frequently displayed text in contravention of the Manual of Style and that frequently emitted incorrect HTML. They used a variety of language codes that were not in the ISO 639 standards, and there was no easy way to track the usage of those codes and correct them; they had to be fixed manually, through a painstaking and tedious manual process. Trappist has begun a process that editors have been discussing for years now, but that nobody was willing to take on (until now): the laborious and painful conversion of these templates to conform to MOS, to use a single system for all languages, and to perform some basic error-checking. As with any conversion of this scale, this process will involve some automated fixes, some semi-automated fixes, and some manual labor. The result will be a set of lang templates that all work in a way that is consistent with MOS and with one another.
 * I do have one suggestion, though, which is to display the previous template's output, even if it is broken, along with an error message, as we do with the CS1 templates. I see the current method of completely hiding the template's output as less than optimal, a disservice to the reader during this time of transition. – Jonesey95 (talk) 15:30, 29 December 2017 (UTC)
 * Another possibility might be to reduce the font size of the error message, or indeed to display it only in edit mode as with some infobox errors. And yes, many thanks are due to Trappist for taking this on – it's been a mess for years, and was long overdue for attention.
 * In the sandbox, perhaps not perfect but better:
 * For the common case where editors have used when they should have been using something else
 * Every error message now follows the raw text from the template; html markup for the text is not rendered.
 * —Trappist the monk (talk) 18:06, 29 December 2017 (UTC)
 * Much better, thanks, but can you please remove  from the message, because it makes no sense whatsoever; for the reader, the outcome could look something like this: (Rusian: тундра tûndra, help ) and please make it smaller.  Poeticbent  <span style="color:#FFFFFF;font-size:7.0pt;font-weight:bold;background:#FF88AF;border:1px solid #DF2929;padding:0.0em 0.2em;">talk 19:23, 29 December 2017 (UTC)
 * For the common case where editors have used when they should have been using something else
 * Every error message now follows the raw text from the template; html markup for the text is not rendered.
 * —Trappist the monk (talk) 18:06, 29 December 2017 (UTC)
 * Much better, thanks, but can you please remove  from the message, because it makes no sense whatsoever; for the reader, the outcome could look something like this: (Rusian: тундра tûndra, help ) and please make it smaller.  Poeticbent  <span style="color:#FFFFFF;font-size:7.0pt;font-weight:bold;background:#FF88AF;border:1px solid #DF2929;padding:0.0em 0.2em;">talk 19:23, 29 December 2017 (UTC)
 * Every error message now follows the raw text from the template; html markup for the text is not rendered.
 * —Trappist the monk (talk) 18:06, 29 December 2017 (UTC)
 * Much better, thanks, but can you please remove  from the message, because it makes no sense whatsoever; for the reader, the outcome could look something like this: (Rusian: тундра tûndra, help ) and please make it smaller.  Poeticbent  <span style="color:#FFFFFF;font-size:7.0pt;font-weight:bold;background:#FF88AF;border:1px solid #DF2929;padding:0.0em 0.2em;">talk 19:23, 29 December 2017 (UTC)
 * Much better, thanks, but can you please remove  from the message, because it makes no sense whatsoever; for the reader, the outcome could look something like this: (Rusian: тундра tûndra, help ) and please make it smaller.  Poeticbent  <span style="color:#FFFFFF;font-size:7.0pt;font-weight:bold;background:#FF88AF;border:1px solid #DF2929;padding:0.0em 0.2em;">talk 19:23, 29 December 2017 (UTC)

Italic error - how to handle it properly
This case illustrates the most basic problem with wikipedia development: close to zero understanding and/or respect of the basics of user interface. And this discussion is best illustration.Did you read the help text? Who reads the fucking manual today? The proper approach is error message containing the advice: "...contains italc markup. Please remove it." Instead I have my watchlist full of edits removing the lang-ru templates altogether by well-meaning but clueless editors. Last but not the least: if code detected and reported italics markup then what prevented it from handling it normally? - üser:Altenmann >t 20:14, 27 December 2017 (UTC)

Alternatives to error messages in the rendered output
It probably makes more sense to have all error messages show up in preview (they way they do for citation template errors, at top of editing window) instead of in the displayed output for readers, to whom the errors are meaningless and annoying/confusing. Might also make sense to use a hidden cleanup category. — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  08:32, 30 December 2017 (UTC)

Further italics problems
Now of these work to produce italic output: but this does, even though the idea was that this would throw an error (last I looked, in previous thread on italics handling): Even if this doesn't throw an error, it's not really the ideal markup, since the italicization isn't literally part of the foreign material, but meta-style applied around it in the English-language context. — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  12:14, 30 December 2017 (UTC)
 * → Cuindlis
 * → Cuindlis
 * → Cuindlis
 * I suppose you might be told to use yes:  → Cuindlis. -- Michael Bednarek (talk) 12:45, 30 December 2017 (UTC)
 * Don't be snide, it doesn't help the conversation. Yes, yes works (that is, after all, the purpose of that parameter) and will be required when   is not wholly Latin script (assuming that editors do not reject auto-italics as an option).
 * —Trappist the monk (talk) 13:17, 30 December 2017 (UTC)
 * Addressed in the sandbox, I think:
 * → →  – italic because auto-italics detected all-Latn-script-text
 * → →  – duplicate external markup will be removed by MediaWiki; after html rendering looks like this:
 * → →  – internal markup will be ignored by browsers; after html rendering looks like this:
 * See the most recent tables at html italic markup vs wiki italic markup.
 * The error message for italic markup in is disabled while there are still old-form  templates that call  (those are the templates listed at most lang-?? templates switched to the module).
 * —Trappist the monk (talk) 13:17, 30 December 2017 (UTC)
 * The error message for italic markup in is disabled while there are still old-form  templates that call  (those are the templates listed at most lang-?? templates switched to the module).
 * —Trappist the monk (talk) 13:17, 30 December 2017 (UTC)
 * —Trappist the monk (talk) 13:17, 30 December 2017 (UTC)

html italic markup vs wiki italic markup
Editor Izno has changed Module:Lang/sandbox with.

To me, this looks like the similar change (discussion) that was made to many of the templates and since reverted. Because of that, I'm inclined to revert Editor Izno's change without we first establish that the current template is proven to be causing these unspecified lint errors.

Is there unequivocal evidence of such damage?

—Trappist the monk (talk) 15:37, 29 November 2017 (UTC)
 * Because wikitext  is ambiguous as to opening or closing tag, use like   (which the documentation apparently calls for!) causes the future parser plus RemexHTML to emit , which causes a number of the lang-related errors in Special:LintErrors/html5-misnesting (the other vast majority are related to using an inline template where a block template is called for, as I noted above). The current processor plus HTML Tidy actually nukes all of the italics markup entirely, which is also probably undesirable . I have not tested the change to see if it fixes the problem or not.
 * This can be evidenced on War and Peace with Russkiy Vestnik, which currently generates ; which  generate   in the future (using the Parser migration tool to get that HTML directly from future version source); and which clearly  generate   as the current editor intent.
 * (Now, whether the external italics should be there as the correct editor intent is irrelevant to the technical question and can't be evaluated by the template anyway, per a whole lot of the discussion about Lua-fying above.)
 * The concerns stated by the editors in the discussion on WOS's talk page are mostly illegitimate in this context. The reason we use  in the MOS is because that's primary an article-driven styling for wikitext and we use wikitext in articles because that's the wiki way (I doubt anyone needs to understand here why we use wikitext in articles). We are not so-constrained in the template space where we typically bump into concerns or limitations regarding well-formed HTML.
 * Justletter's use of  to add bolding rather than italics is not documented as a valid use case nor do I believe it should be supported internal to the template. Items which should receive bolding for some other reason (MOS:BOLD) should also take the italics where italics are called for as highlighting non-English non-Latin text in my opinion. --Izno (talk) 16:22, 29 November 2017 (UTC)
 * And indeed, this revision shows that my change fixes the problem, with correct HTML provided by both the current and future parsers. --Izno (talk) 17:31, 29 November 2017 (UTC)
 * Yeah, I agree that  is ambiguous; it exists so will be used.  The  documentation that suggests italic markup outside the template is, I think, suspect.   did not, at the time the documentation was written, render any italics so some mechanism was necessary to apply those italics.  Now comes Module:Lang which can, more-or-less intelligently, read the IETF language tag and italic and decide what to do with the 'text' based on that reading.  Yeah, it can't see outside of its parent template so it doesn't / can't know that it is contributing to misnested html.
 * Is this issue only related to instances of templates that specify   script in the IETF tag parameter?  If so, we can remove that functionality, though I'd rather not, because it seems an obvious thing to have the template/module do (and editors can still override the automatic italics with no).
 * Really? This is 'correct'? where one <i ><i ></i></i> is nested inside of another?  Clearly it 'works', but just as clearly, one of the <i ></i> is superfluous:
 * →  <i>Russkiy Vestnik </i>
 * Perhaps that's a job for a bot down the road: to remove the extraneous wikimarkup outside the template.
 * Pinging editors from the other discussion because you mentioned some of them without pings.
 * —Trappist the monk (talk) 18:31, 29 November 2017 (UTC)
 * Thank you for the ping, Trappist. I agree with that my use of single primes to create bold, non-italic text is undocumented, but it's a lot simpler than using noitalic and triple primes. It worked, so I did it; I'd like not to need to do it. I've asked above for proper support of bold text rather than this or any other clumsy work-around. I envisage a bold parameter which would default to no but could be set to yes. Is that something that could easily be realised? Ideally, if set to yes it would automatically set no, unless that is purposely over-ridden. I had assumed that some sort of a bot run would eventually be needed to sort out this "undocumented use" of mine and others like it. Once again, my thanks to those who are working on making this better. Justlettersandnumbers (talk) 19:21, 29 November 2017 (UTC)
 * I think a bold is quite reasonable and obviously do-able... but why? What is the use case for bold italics, and why is that use case not better met by both bold and italics (bold for whatever meaning you are attempting to assign to the markup and italic for the non-English language meaning)? MOS:BOLD provides for very few uses bold. --Izno (talk) 22:54, 29 November 2017 (UTC)
 * For templates that use Module:Lang, bold font can be achieved with standard wikimarkup:
 * → bold text
 * Don't want italic? set no.
 * —Trappist the monk (talk) 13:07, 30 November 2017 (UTC)
 * They're not primes, they're apostrophes. If you use primes, ′′like this′′ or ′′′this′′′, they're displayed literally. -- Red rose64 &#x1f339; (talk) 21:28, 30 November 2017 (UTC)
 * I can contrive an example that you might see elsewhere (especially in fiction or in briefly writing about some memory): . You wouldn't close the first italic tag when you reach the second open italic tag because you had not yet reached the end of your voiced thought. Maybe one that might actually appear would be some quotation about the USS Enterprise in another language e.g.   (mind you,   might be preferable but not as easy to integrate into this module--Erutuon has a comment in that direction).
 * In the general case, it's not incorrect for this markup to render like so, and I believe either browsers implement the switching natively in their default CSS files or that we currently have something in one of the CSS files Wikipedia sends to the browser instructing the browser to do so. It's only in this specific case that we have identified that the italics on the inside and the italics on the outside are superfluous.
 * I believe this issue presents itself where any italics are used, automated or not, not solely with  script in the tag. I think it preferable to keep the automated functionality in the template. I agree that we should fix the cases where   is used (I am unsure that it is bot-able per WP:CONTEXTBOT, but probably is WP:AWBable). I think we should also detect cases like JLAN's apostrophers (e.g.  ) and a suitable fix for that issue programmed also (whether that's removal of the offending characters internal to the template or addition of a separate parameter--the functionality for which I have just queried Justlettersandnumbers). --Izno (talk) 22:54, 29 November 2017 (UTC)
 * I understand that it is sometimes appropriate to nest <i ></i> tags.
 * If I understand you, every template that does not directly use Module:Lang (they do use the module indirectly through ) and that has hard-coded italic wiki markup, will be causing lint errors.  Is that correct?
 * What are JLAN's apostrophers?
 * —Trappist the monk (talk) 13:07, 30 November 2017 (UTC)
 * It is possible that every one will cause lint errors. I do not know for certain, however.
 * JLAN's apostrophers == Justlettersandnumbers's apostrophes. --Izno (talk) 13:55, 30 November 2017 (UTC)
 * Ah, right. Your example  differs from Editor Justlettersandnumbers's example .  Still, in both cases, I think that the module is doing the correct thing in that it does not convert a single apostrophe into Roman bold-face font.
 * —Trappist the monk (talk) 18:57, 30 November 2017 (UTC)
 * I believe this search is pretty close to the upper bound of all articles where this bolding hack is present that can be fixed with TTM's suggested fix. In review, I don't think a bold is necessary. However, the templates used appear to need to be able to take italic as a passthrough their parent template. (Or is it the case that Template:language with name is going away?) --Izno (talk) 19:27, 1 December 2017 (UTC)
 * Well, it's not a suggested fix per se, rather, it's a progression. As we migrate the  templates to use Module:lang directly, the bolding hack will fail to work and the text that was hacked will be rendered single-quoted in italic font.  We cannot / should not change all  templates in a single operation.  It will take time.  If anyone is reading this and cares about hacked instances of these templates, keep an eye on the template pages that are of interest to you so that when the template is switched to use the module, you can undo the hacks and write the template instances correctly.
 * isn't going away but it will no longer be used by the templates.  The functionality currently provided to unconverted  templates by  has been subsumed into Module:lang.
 * —Trappist the monk (talk) 20:27, 1 December 2017 (UTC)
 * If is used, it would probably be best to move the language (and any other) attributes there (</i>) instead of having two tags . For what it's worth, that's what we do on Wiktionary. — Eru·tuon 22:35, 29 November 2017 (UTC)
 * Moving that direction is probably a bit more complex than my suggested change for right now, while the module is a bit in motion. It might help prep the module for a block implementation as well as the current inline implementation. --Izno (talk) 22:59, 29 November 2017 (UTC)
 * This sort of markup is perfectly suited to the transliteration rendering of the templates because the transliteration is always Latin script and so always italicized:
 * —Trappist the monk (talk) 18:57, 30 November 2017 (UTC)
 * So, it seems that the template has been updated, for which many thanks (due, I believe to ). But it's been updated with the change of handling of wiki-markup for italic text, such that forms such as   now display as &#39;Livorno&#39; instead of Livorno, exactly the bug I complained of further up this page on 16 October. So I ask again, as I asked then: if the change is an important improvement, can someone please give some hint as to how the various affected pages could be tracked down and fixed? I have tried searching for , for example, but that does not yield useful results (our search engine ignores the crucial apostrophe). Ideas? Justlettersandnumbers (talk) 18:52, 9 December 2017 (UTC)
 * Do the search with a regex:
 * —Trappist the monk (talk) 18:59, 9 December 2017 (UTC)
 * I'm still trying to understand: [...] why? What is the use case for bold italics, and why is that use case not better met by both bold and italics (bold for whatever meaning you are attempting to assign to the markup and italic for the non-English language meaning)? MOS:BOLD provides for very few uses bold. My expectation is that wherever WP:MOSBOLD calls for bolding, and where WP:MOSITALICS would call for italics, should receive both. The search I linked above works. --Izno (talk) 19:34, 9 December 2017 (UTC)
 * , because we don't use italics for proper names (hence the requests for the capability to disable italics in the template), but do sometimes need to bold-face them. Thanks,, will try. It'd be really good if the documentation for our search engine actually gave some advice on how to search for things. Justlettersandnumbers (talk) 19:41, 9 December 2017 (UTC)
 * OK, I just happened across this: Rocco and His Brothers. Why does using italics for a proper name in English (in accordance with our MOS) trigger such an alarming warning? I don't see any reason why lang-en needs to be used there, but nor do I see any reason for it to create such a bloodbath. Could we perhaps tone down or eliminate such messages for this non-fatal error? Justlettersandnumbers (talk) 23:07, 9 December 2017 (UTC)
 * In general, templates are responsible for the 'style' of the rendered output. All of the 600ish  templates have a default setting to italicize or to not italicize according to the language's writing system.  When that writing system is a Latin script, the templates default to italic rendering in accordance with MOS:FOREIGNITALIC.  The English language version of the template  does not italicize because this is the English Wikipedia where we do not italicize normal English text.
 * Because of this, use of at en.wiki is mostly pointless; the template's documentation says as much.  For your example, it is correct to italicize Rocco and His Brothers because it is a film title per WP:ITALIC but there is really no need to use  there and, my opinion, no need to label Rocco and His Brothers as English text.
 * The error message is there because, instead of wiki markup, these templates use a parameter to control the italic rendering which is not in keeping with the hard-coded method used by the old templates. It is necessary to know where templates with italic markup are located.  You noticed, so the mechanism must work.  Each error message has a link to help information at  so that editors can learn what the error message means and then take appropriate action.  As I write this, of the 636,000ish pages that transclude Module:lang, there are 9200ish pages with errors; a number that appears to be going down.
 * —Trappist the monk (talk) 00:30, 10 December 2017 (UTC)
 * Lang-en (without something more specific) is probably only useful for English-language text inside quoted non-English language text, e.g. . Even with something more specific, like   it's only useful for a) pre-modern dialects, b) linguistic markup of regionalisms, and c) direct comparisons of things like US versus UK English.  I sometime encounter it (in ref citations especially, of all places) simply to mark up something as American or British or whatever, and this is pointless and annoying.  I remove such instances on-sight.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  08:12, 10 December 2017 (UTC)
 * So, it seems that the template has been updated, for which many thanks (due, I believe to ). But it's been updated with the change of handling of wiki-markup for italic text, such that forms such as   now display as &#39;Livorno&#39; instead of Livorno, exactly the bug I complained of further up this page on 16 October. So I ask again, as I asked then: if the change is an important improvement, can someone please give some hint as to how the various affected pages could be tracked down and fixed? I have tried searching for , for example, but that does not yield useful results (our search engine ignores the crucial apostrophe). Ideas? Justlettersandnumbers (talk) 18:52, 9 December 2017 (UTC)
 * Do the search with a regex:
 * —Trappist the monk (talk) 18:59, 9 December 2017 (UTC)
 * I'm still trying to understand: [...] why? What is the use case for bold italics, and why is that use case not better met by both bold and italics (bold for whatever meaning you are attempting to assign to the markup and italic for the non-English language meaning)? MOS:BOLD provides for very few uses bold. My expectation is that wherever WP:MOSBOLD calls for bolding, and where WP:MOSITALICS would call for italics, should receive both. The search I linked above works. --Izno (talk) 19:34, 9 December 2017 (UTC)
 * , because we don't use italics for proper names (hence the requests for the capability to disable italics in the template), but do sometimes need to bold-face them. Thanks,, will try. It'd be really good if the documentation for our search engine actually gave some advice on how to search for things. Justlettersandnumbers (talk) 19:41, 9 December 2017 (UTC)
 * OK, I just happened across this: Rocco and His Brothers. Why does using italics for a proper name in English (in accordance with our MOS) trigger such an alarming warning? I don't see any reason why lang-en needs to be used there, but nor do I see any reason for it to create such a bloodbath. Could we perhaps tone down or eliminate such messages for this non-fatal error? Justlettersandnumbers (talk) 23:07, 9 December 2017 (UTC)
 * In general, templates are responsible for the 'style' of the rendered output. All of the 600ish  templates have a default setting to italicize or to not italicize according to the language's writing system.  When that writing system is a Latin script, the templates default to italic rendering in accordance with MOS:FOREIGNITALIC.  The English language version of the template  does not italicize because this is the English Wikipedia where we do not italicize normal English text.
 * Because of this, use of at en.wiki is mostly pointless; the template's documentation says as much.  For your example, it is correct to italicize Rocco and His Brothers because it is a film title per WP:ITALIC but there is really no need to use  there and, my opinion, no need to label Rocco and His Brothers as English text.
 * The error message is there because, instead of wiki markup, these templates use a parameter to control the italic rendering which is not in keeping with the hard-coded method used by the old templates. It is necessary to know where templates with italic markup are located.  You noticed, so the mechanism must work.  Each error message has a link to help information at  so that editors can learn what the error message means and then take appropriate action.  As I write this, of the 636,000ish pages that transclude Module:lang, there are 9200ish pages with errors; a number that appears to be going down.
 * —Trappist the monk (talk) 00:30, 10 December 2017 (UTC)
 * Lang-en (without something more specific) is probably only useful for English-language text inside quoted non-English language text, e.g. . Even with something more specific, like   it's only useful for a) pre-modern dialects, b) linguistic markup of regionalisms, and c) direct comparisons of things like US versus UK English.  I sometime encounter it (in ref citations especially, of all places) simply to mark up something as American or British or whatever, and this is pointless and annoying.  I remove such instances on-sight.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  08:12, 10 December 2017 (UTC)
 * —Trappist the monk (talk) 00:30, 10 December 2017 (UTC)
 * Lang-en (without something more specific) is probably only useful for English-language text inside quoted non-English language text, e.g. . Even with something more specific, like   it's only useful for a) pre-modern dialects, b) linguistic markup of regionalisms, and c) direct comparisons of things like US versus UK English.  I sometime encounter it (in ref citations especially, of all places) simply to mark up something as American or British or whatever, and this is pointless and annoying.  I remove such instances on-sight.  — SMcCandlish ☏ ¢ &gt;ʌⱷ҅ᴥⱷʌ&lt;  08:12, 10 December 2017 (UTC)

I have been wondering of late if the correct solution to the 'italics problem' wouldn't be to use css in the tag. For text that is to be italic the templates would write:

and for upright, non-italicized text:

We might extend the italic parameter to allow for a third value  which would have the templates write
 * (or just leave out the font-style property)

—Trappist the monk (talk) 14:07, 14 December 2017 (UTC)
 * 1) normal text with italic text in the rendering – like this if yes
 * 2) italic text with normal text inside of italic markup – like this if no
 * 3) italic text with italic inherit text inside of italic markup – like this if unset
 * 4) normal text dictates normal inherit text in the rendering – like this if unset
 * &lt;i> is correct/fine per the spec. --Izno (talk) 14:31, 14 December 2017 (UTC)
 * As far as it goes, yes. But we can't do case 2 and use italic to control the template's rendering:
 * some italic text with normal text embedded and more italic text
 * For this case we have to override the wiki markup somehow. If we keep the wiki markup in the module, as it is now implemented, we can write:
 * some italic text with normal text embedded and more italic text
 * but that is semantically incorrect and confusing. The font-style property allows us to say that   means no and   means yes and   means 'use the already set style'.  Also, by doing this we switch a property rather than a whole tag which to me seems cleaner.
 * —Trappist the monk (talk) 15:18, 14 December 2017 (UTC)
 * but that is semantically incorrect and confusing. The font-style property allows us to say that   means no and   means yes and   means 'use the already set style'.  Also, by doing this we switch a property rather than a whole tag which to me seems cleaner.
 * —Trappist the monk (talk) 15:18, 14 December 2017 (UTC)

In Module:Lang/sandbox I have reworked italic handling so that it supports the  property I described above. This version of the sandbox code introduces two additional accepted values for italic. The table attempts to illustrate how the new code works: Results are similar for the templates. You can see that at my sandbox though the rendering there is a bit more cryptic.

A variant of this table should become part of the documentation for the and  templates. A better base language is in order because  is a malformed IANA language tag (  is a suppressed script for   – we should detect and do something about that) but it works here as an illustration for now.

—Trappist the monk (talk) 17:57, 20 December 2017 (UTC)

Still not right. The underlying html should not restate the norm. The norm is not italicized so should not write html that has the   property for default rendering. If a  property is to be used, it should be used only when explicitly required by italic. I have construed the historic default state for :
 * default state = not italicized = no ∴

In fact, it should be:
 * default state = not italicized = <not set> ∴

Because, in this case, the omission or inclusion of  is indistinguishable by the reader, we can omit. So I've tweaked the sandbox.

Because it is now necessary to evaluate the state of an internal variable when deciding to include or omit, we might as well evaluate the variable to choose  or <i ></i>. So I've tweaked the sandbox.

—Trappist the monk (talk) 17:46, 27 December 2017 (UTC)

I have tweaked Module:lang/sandbox so that the templates will, as much as possible, produce output similar to that produced by  given the same or analogous inputs. Compare to the table above: —Trappist the monk (talk) 16:34, 29 December 2017 (UTC)

Live module synched from the sandbox; template documentation updated to reflect these changes.

—Trappist the monk (talk) 12:10, 31 December 2017 (UTC)

Apparently spurious "no text" error when lang is used in Template:efn
Prose example with efn template following.

For some reason, as in the example above, when there is an error in a lang template used within an efn template, there is an apparently spurious "no text" error. It does not appear when the same lang template is used in normal prose:

Ich glaube, daß darin das Wesentliche von dem liegt, was ich sagen wollte; ich drückte darin ein wenig meine Philosophie aus, vielleicht enthält Mein Studenbuch mit seinen 167 Holzschintten potentiell alles das, was ich danach geschaffen habe, denn ich habe wo anders und später eine ganze Anzahl von Themen daraus entwickelt.

This is a minor bug, if it is a bug. – Jonesey95 (talk) 17:28, 2 January 2018 (UTC)
 * That is and is not an error in the live version of Module:lang. Since the last sync, the sandbox has been  to disable italic markup detection when unset which is the needed fix.


 * The spurious no-text is puzzling as is the interleaving of the two error messages. Module:Lang does not issue multiple error messages; it quits on the first error so it would appear that  is being called twice and one of those times it is not getting its required input.  The interleaving is, I think, a result of MediaWiki cleaning up something.
 * The unset tweak, detection of malformed wiki markup for (4 & 6+ apostrophes), and support for the new label are on-deck as the next changes to the live module, presuming anyone cares to comment before actual implementation (instead of waiting to pile-on after the fact).
 * —Trappist the monk (talk) 18:48, 2 January 2018 (UTC)
 * The unset tweak, detection of malformed wiki markup for (4 & 6+ apostrophes), and support for the new label are on-deck as the next changes to the live module, presuming anyone cares to comment before actual implementation (instead of waiting to pile-on after the fact).
 * —Trappist the monk (talk) 18:48, 2 January 2018 (UTC)

Quick AWB fix for about 900 pages
This Petscan report shows a list of about 900 pages for which this should be the quick fix. Based on the categories the articles are in, I am presuming that they all use lang-bg, followed by Bulgarian text wrapped in italics. The italic markup should be removed. Someone with AWB access and a tolerance for a bit of tedium should be able to make quick work of them. – Jonesey95 (talk) 14:23, 2 January 2018 (UTC)
 * This appears to do the job:
 * find:
 * replace:
 * I started with 814, have done 50 and will pick at it as I am moved to do so.
 * —Trappist the monk (talk) 17:53, 2 January 2018 (UTC)
 * Thanks. I found a workaround using AutoEd and have done about 60 myself. I'll pick away at them too. Your case is more general, so I will probably adapt it in the future. – Jonesey95 (talk) 18:14, 2 January 2018 (UTC)
 * These are done. Nice work. We have reduced the lang template error category's count from about 7,500 to 6,000 today. – Jonesey95 (talk) 23:00, 2 January 2018 (UTC)