[3.0] Fall back when a language string is missing

[albertlast]

Description

Lang::getTxt() returns '' for a key it cannot find — never null:

// Don't waste time when getting a simple string.
if ($args === [] && \count($txt_key) === 1) {
	return self::${$var}[$txt_key[0]] ?? '';
}

So ?? never fires after it. Six calls pair getTxt() with a fallback that cannot be reached, and take the empty string instead. ?: is what was meant.

The smiley tooltips are the visible one

Sources/Editor.php looks a tooltip up as icon_ plus the lowercased description, and falls back to the description. Eight of the twenty two smileys SMF ships have no matching key, so eight buttons in the editor's emoticon drop-down carry an empty tooltip:

Description	Key looked up	In General.php
Huh?	icon_huh?	icon_huh
Roll Eyes	icon_roll eyes	icon_rolleyes
Lips Sealed	icon_lips sealed	icon_lips
Evil, Azn, Afro, Police, Angel	icon_evil, …	(none)

Straight off the reply page on a stock install, before and after:

 "tooltip": "Cool"           "tooltip": "Cool"
 "tooltip": ""          →    "tooltip": "Huh?"
 "tooltip": ""          →    "tooltip": "Roll Eyes"
 "tooltip": "Tongue"         "tooltip": "Tongue"
 "tooltip": "Embarrassed"    "tooltip": "Embarrassed"
 "tooltip": ""          →    "tooltip": "Lips Sealed"

Any smiley an admin adds through Admin → Smileys has the same problem, since nothing writes an icon_ string for it — that is the case the fallback exists for.

The rest

• Actions/Admin/Themes.php and Actions/Profile/ThemeOptions.php, ×2 each: a theme variant or colour mode with no translated name loses its name entirely instead of falling back to its identifier. Not reachable on a stock install, since the default theme sets neither theme_variants nor has_dark_mode.
• Themes/default/MaintenanceTemplate.php: the installer and upgrader emit <meta charset="">, because lang_character_set is not a 3.0 string at all. index.template.php writes UTF-8 literally; I kept the fallback rather than hard-coding it, since Actions/Admin/Languages.php still treats lang_character_set as an editable setting for older language packs.

I left the two getTxt(…) ?? '' in Parser.php and Unicode/Utf8String.php alone — they are the same mistake, but the fallback and the actual result are both '', so changing them would be noise.

Found while splitting #7933; not part of the theme, so it goes straight to release-3.0. Related to #9397, which fixes the calls that name the wrong language file — same sweep, different defect.

Issues References (Fixes|Related|Closes)

Related to #7933