Template talk:Lang/Archive 4

Rather than applying a style attribute, perhaps it might make more sense to vary the tag used to contain the xml:lang attribute — using either <span> or <em> as appropriate? — OwenBlacker (talk) 10:29, 25 December 2017 (UTC)

I also see lots of uses where ''{{lang|de|Der Ring des Nibelungen}}'' previously emitted the title in italics, as it should be, but now it doesn't (ex.: Der Ring des Nibelungen), unless |italic=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)

(edit conflict)

The intent is that each {{lang}} and {{lang-??}} 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 {{lang}}, the style is normal; for the individual {{lang-??}} template, the style is determined by which entry function is called by the template's {{#invoke:}}: lang_xx_normal() or lang_xx_italic().

For {{lang}}, the weak style can be overridden by specifying -Latn script IANA subtag (where the registry permits that) or by |italic=yes. Similarly, for the individual {{lang-??}} templates, |script=Latn will override the weak style set by lang_xx_normal() as will |italic=yes.

The comment that you quoted refers to this code snippet used in lang() where the return value is evaluated:

	args.italic = validate_italic (args.italic);								-- nil or font-style property value

	if nil == args.italic then													-- nil when |italic= absent or not set or |italic=default; args.italic controls
		if 'latn' == subtags.script then										-- script set to latn
			args.italic = 'italic';												-- DEFAULT for {{lang}} templates is upright; but if latn script set for font-style:italic
		else
			args.italic = 'normal';												-- italic not set; script not latn; set for font-style:normal
		end
	end

The table at html italic markup vs wiki italic markup shows how it works.

Module:Lang uses the font-style 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 {{lang}} 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 insource: 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 |italic=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 {{lang}} weak style to inherit. If I do that, you should expect that in future, it will return to normal.

—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 style="font-style: italic;". 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 font-style solution ten days ago 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

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-xx

}}, as appropriate). While the template is in a state of flux, I've been removing surrounding italics and adding |italic=yes, to avoid people reverting the language tagging due to the change in formatting because ''{{lang|es|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)

@Trappist the monk: 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 (error: {{lang-xx}}: text has italic markup (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 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, Trappist the monk. 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 talk
  20:17, 25 December 2017 (UTC)

Umm, remove the italic markup from this:

{{lang-uk|''Українська Народна Міліція''}} → [Українська Народна Міліція] Error: {{Lang-xx}}: text has italic markup (help)

to make this:

{{lang-uk|Українська Народна Міліція}} → Ukrainian: Українська Народна Міліція

See

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 Trappist the monk, 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 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:

{{lang-yi|נאוואמינסק ''Novominsk''}}

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:

{{lang-ru/sandbox|тундра ''tûndra''}} → [тундра tûndra] Error: {{Lang-xx}}: text has italic markup (help)

[тундра ''tûndra''] <span style="color:#d33">Error: {{Lang-xx}}: text has italic markup ([[:Category:Lang and lang-xx template errors|help]])</span>

For the common case where editors have used {{lang-??}} when they should have been using something else ({{?? icon}})

{{lang-ru/sandbox}} → [undefined] Error: {{Lang-xx}}: no text (help)

[undefined] <span style="color:#d33">Error: {{Lang-xx}}: no text ([[:Category:Lang and lang-xx template errors|help]])</span>

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 {{lang-xx}} from the message, because it makes no sense whatsoever; for the reader, the outcome could look something like this: (Rusian: тундра tûndra error: text has italic markup, help) and please make it smaller. Poeticbent 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

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 ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  08:32, 30 December 2017 (UTC)

Now neither of these work to produce italic output:

• {{lang|gd|Cuindlis}} → Cuindlis
• ''{{lang|gd|Cuindlis}}'' → Cuindlis

but this does, even though the idea was that this would throw an error (last I looked, in previous thread on italics handling):

• {{lang|gd|''Cuindlis''}} → [Cuindlis] Error: {{Lang}}: text has italic markup (help)

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 ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  12:14, 30 December 2017 (UTC)

I suppose you might be told to use |italic=yes: {{lang|gd|Cuindlis|italic=yes}} → Cuindlis. -- Michael Bednarek (talk) 12:45, 30 December 2017 (UTC)

Don't be snide, it doesn't help the conversation. Yes, |italic=yes works (that is, after all, the purpose of that parameter) and will be required when text 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:

• {{lang/sandbox|gd|Cuindlis}} → <span title="Scottish Gaelic-language text"><i lang="gd">Cuindlis</i></span> → Cuindlis – italic because auto-italics detected all-Latn-script-text
• ''{{lang/sandbox|gd|Cuindlis}}'' → ''<span title="Scottish Gaelic-language text"><i lang="gd">Cuindlis</i></span>'' → Cuindlis – duplicate external markup will be removed by MediaWiki; after html rendering looks like this:

  <i><span lang="gd" xml:lang="gd">Cuindlis</span></i>

• {{lang/sandbox|gd|''Cuindlis''}} → [''Cuindlis''] <span style="color:#d33">Error: {{Lang}}: text has italic markup ([[:Category:Lang and lang-xx template errors|help]])</span> → [Cuindlis] Error: {{Lang}}: text has italic markup (help) – internal markup will be ignored by browsers; after html rendering looks like this:

  <i><span lang="gd" xml:lang="gd"><i>Cuindlis</i></span></i>

See the most recent tables at html italic markup vs wiki italic markup.

The error message for italic markup in {{lang}} is disabled while there are still old-form {{lang-??}} templates that call {{lang}} (those are the templates listed at most lang-?? templates switched to the module).

—Trappist the monk (talk) 13:17, 30 December 2017 (UTC)

Editor Izno has changed Module:Lang/sandbox with this edit.

To me, this looks like the similar change (discussion) that was made to many of the {{lang-??}} 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 ''{{lang|Latin character language|Name of work}}'' (which the documentation apparently calls for!) causes the future parser plus RemexHTML to emit <i><span lang="Latin character language"></span></i><i>Name of work</i>, 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 (<span lang="Latin character language">Name of work</span>). 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 (''{{lang|ru-Latn|Russkiy Vestnik}}''), which currently generates <span lang="ru-Latn">Russkiy Vestnik</span>; which would generate <i><span lang="ru-Latn"></span></i>Russkiy Vestnik<i></i> in the future (using the Parser migration tool to get that HTML directly from future version source); and which clearly should generate <i><span lang="ru-Latn"><i>Russkiy Vestnik</i></span></i> 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 {{lang-it|'ABC'}} 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)

(edit conflict)

Yeah, I agree that '' is ambiguous; it exists so will be used. The {{lang}} documentation that suggests italic markup outside the template is, I think, suspect. {{Lang}} 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 {{lang}} templates that specify Latn 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 |italic=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><span lang="ru-Latn"><i>Russkiy Vestnik</i></span></i> → Russkiy Vestnik

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. @WOSlinker, Justlettersandnumbers, Uanfala, Jonesey95, and Scriptions:

—Trappist the monk (talk) 18:31, 29 November 2017 (UTC)

Thank you for the ping, Trappist. I agree with Izno 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 |italic=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)

@

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:

{{lang-af|'''bold text'''}} →

Afrikaans

: bold text

Don't want italic? set |italic=no.

—Trappist the monk (talk) 13:07, 30 November 2017 (UTC)

@Justlettersandnumbers: They're not primes, they're apostrophes. If you use primes, ′′like this′′ or ′′′this′′′, they're displayed literally. --Redrose64 🌹 (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): <i class="thoughtspeak">The USS <i class="shipname">Enterprise</i> was sailing from the port of San Diego when...</i>. 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. <q><i lang="es">Spanish text <i lang="en">USS <i class="shipname">Enterprise</i></i> Spanish text</i></q> (mind you, <q lang="es">...</q> 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 Latn 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 ''{{lang|Latin character language|Name of work}}'' is used (I am unsure that it is bot-able per

WP:AWBable). I think we should also detect cases like JLAN's apostrophers (e.g. {{lang|ru-Latn|'Russian in Latin characters'}}) 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 {{lang-??}} template that does not directly use Module:Lang (they do use the module indirectly through {{lang}}) 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 ({{lang|ru-Latn|'Russian in Latin characters'}}) differs from Editor Justlettersandnumbers's example ({{lang-it|'Livorno'}}). 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 {{lang-??}} 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 {{lang-??}} 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.

{{Language with name}} isn't going away but it will no longer be used by the {{lang-??}} templates. The functionality currently provided to unconverted {{lang-??}} templates by {{language with name}} has been subsumed into Module:lang.

—Trappist the monk (talk) 20:27, 1 December 2017 (UTC)

If <i></i> is used, it would probably be best to move the language (and any other) attributes there (<i lang="xx"></i>) instead of having two tags <span lang="xx"><i></i></span>. 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 {{lang-??}} templates because the transliteration is always Latin script and so always italicized:

{{#invoke:lang|lang_xx_inherit|code=el|text=Θεοτόκος|italic=no|translation=God-bearer|translit=Theotokos}}

Greek: Θεοτόκος, romanized: Theotokos, lit. 'God-bearer'

[[Greek language|Greek]]: <span lang="el" style="font-style: normal;">Θεοτόκος</span>, <small>[[Romanization of Greek|romanized]]:&nbsp;</small><span title="Greek-language romanization"><i lang="el-Latn">Theotokos</i></span>, <small>[[Literal translation|lit.]]&thinsp;</small>&#39;God-bearer&#39;

—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 Trappist the monk). But it's been updated with the change of handling of wiki-markup for italic text, such that forms such as {{lang-it|'Livorno'}} now display as 'Livorno' 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 insource: "{{lang-it|'", 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: insource:/\{\{lang\-it\|'[^']/

—Trappist the monk (talk) 18:59, 9 December 2017 (UTC)

I'm still trying to understand: [...] why? What is the use case for bold rather than 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)?

WP:MOSITALICS would call for italics, should receive both. The search I linked above works. --Izno (talk

) 19:34, 9 December 2017 (UTC)

Izno, 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, Trappist the monk, 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 {{lang-??}} 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 {{lang-en

}} does not italicize because this is the English Wikipedia where we do not italicize normal English text.

Because of this, use of {{lang-en}} 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 {{lang-en}} 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 Category:Lang and lang-xx template errors 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. {{lang|es|Mi casa es su casa, {{lang|en|brother}}.}}. Even with something more specific, like en-US 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 ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ<  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 <span>...</span> tag. For text that is to be italic the templates would write:

<span style="font-style:italic">

and for upright, non-italicized text:

<span style="font-style:normal">

We might extend the |italic= parameter to allow for a third value unset which would have the templates write

<span style="font-style:inherit"> (or just leave out the font-style property)

1. normal text with italic text in the rendering – like this if |italic=yes
2. italic text with normal text inside of italic markup – like this if |italic=no
3. italic text with italic inherit text inside of italic markup – like this if |italic=unset
4. normal text dictates normal inherit text in the rendering – like this if |italic=unset

—Trappist the monk (talk) 14:07, 14 December 2017 (UTC)

<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 {{lang|en|with normal text embedded|italic=no}} and more italic text''

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 {{lang|en|with normal text embedded|italic=yes}} and more italic text''

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 no means no and yes means yes and unset 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 font-style 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 {{lang-??}} 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 {{lang}} and {{lang-??}} templates. A better base language is in order because es-Latn is a malformed IANA language tag (Latn is a suppressed script for es – 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 {{lang}} should not write html that has the font-style:normal property for default rendering. If a font-style property is to be used, it should be used only when explicitly required by |italic=. I have construed the historic default state for {{lang}}:

default state = not italicized = |italic=no ∴ font-style:normal

In fact, it should be:

default state = not italicized = |italic=<not set> ∴ font-style:inherit

Because, in this case, the omission or inclusion of font-style:inherit 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 font-style:normal, we might as well evaluate the variable to choose <span>...</span> 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 {{lang-??}} templates will, as much as possible, produce output similar to that produced by {{lang}} 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)

Prose example with efn template following.^[a]

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.] Error: {{Lang-xx}}: text has italic markup (help)

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 tweaked to disable italic markup detection when |italic=unset which is the needed fix.^[a]

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 {{lang-de}} 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 |italic=unset tweak, detection of malformed wiki markup for {{lang}} (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)

Resolved

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: (\{\{\s*lang\-[a-z]{2,3}\s*\|)\s*''([ \p{IsCyrillic}]+)\s*''\s*(\}\})

replace: $1$2$3

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)