Actually Mediawiki has a default content language (for the whole wiki), and a settable property for each page, that allows to set the content language for a page (but this is not editable easily, and not in the wikitext, but using a special page for setting its property.
I wonder why we need such property: when it is not set, it should be possible to use a "magic function" of the parser that would override the "default content language of the wiki", and use it by default to render the page (this is mostly for pages intended for readers of another language than the default language of the wiki: e.g. an "ambassy page" on a "monolingual" wiki like Wikipedia, or pages made specifically for a language (e.g. in wikisource: it would be set according to the original language of the publication: there are not necessarily one language per wikisource edition, various ones are grouping multiple "related" languages, or many unrelated languages like the "beta" wikisource which is international; for really international sites like Commons, or Meta, the default content language should remain English, that magic keyword would be restricted, i.e. ignored if we are not in a the "Project:" namespace "Commons:" or its talkspace, and otherwise dedicated pages on other namespaces can still be overriden to a different language, using the special page properties, with its access restrictions if applicable).
Now about user talk pages: users should freely allow their own user pages and talk pages to use the default language they prefer. Now that all pages can have a correct default language, the effect of parsing "~~..." to generate a date would use the current setting... or could generate a "{{#time:}}" function call (with a datetime value in ISO8601 format) that would render directly in the page's content language (which may be changed easily). It could also generate a "{{#time:}}" function call with a language parameter indicating that it must render in the *visitor's prefered language*" (aka "int:Lang", as set in the Universal language selector or in visiting user's preferences). Note that Mediawiki already makes different renderings (an caches) for every page according to the visitor's language, each time the pared wikitext of the page includes a call to the "int:" namespace. But in this case the generated date value must be encapsulted in a "<bdi>{{#time:...}}</bdi>" tag to avoid breaking the rendering of talks (imagine the visitor's language is arabic, the datetime is rendered in Arabic, in a talk written in English).
Now how to avoid a complex syntax when editing and signing a talk page in plain wikitext ? Is there a shortcut that allows tracking date values for existing signed messages, so that users would be harassed by the syntax (but so that the wikitext remains plaintext, editable externally, i.e. not requiring an UI extension and control while typing)? e.g. "__TIME__20201231235845__", which would be saved with the correct syntax and would generate the correct encapsulation for user's language or the page content language or the site's default language according to user preferences or page settings (properties of the page, e.g. for a book in wikisource, or for a user page or user talk page, as set by its owner and not the visitor) or to site settings (dedicated namespaces preconfigured, or the site's default language). As well the "~~.." syntax would generate the sam special code instead of saving a prerendered date in plain wikitext and in a static language.
Additionally, when the wikitext renderer of Mediawiki will generate the HTML, it could as well emit microformats allowing the visitor to use local tools on their browser (or an plugin tool in their browser) so that when hovering the date/time, they could have different views of it (e.g. for another language, or another timezone, without needing the server to render the page again of needing the visitor to change their user preferences on the wiki itself). It could allow for example feeding an "ical" event for user's personal agenda (thanks to the valid microformats emitted in the HTML). It would as well be useful for other things than just signatures: any indication of date/time in any page (and then we would no longer need to provide "equivalences" in the wikitext. The editor would contain a tool allowing to set the date correctly with a custom user-friendly "datetime editor" (notably in the WYSIWIG editor) without generating an invalid "__TIME__20201231235845__" magic tag (the total number of digits may be variable, but the year should be set, unless there'is an option in the thag that indicated it starts by a month number, or a day of the month number, or just a an hour of the day: "placeholder "letters before the numeric can specify it: "__TIME__Y1231235845__" "__TIME__YM31235845__", "__TIME__YMD235845__") The number of digits per date field must however be fixed (or there should be hyphen separators). It is possible to specify just the first few fields, not all of them, so we can drop seconds, or minutes and seconds, or the hours/minutes/seconds to set only the date, or day/hours/minutes/seconds, or month day/hours/minutes/seconds to set on the the year (e.g. "__TIME__2020" to indicate that only the year is specified, or "__TIME__Y1231" to indicate that only the month and day of the month is specified. In all cases, the value would be in UTC timezone (the effective timezone, language and calendar to render the data in the generated HTML will be varaible according to site or user preferences, but microformats will still be valid and emitted for the UTC timezone and independantly of the language, in ISO 8601 format).
With this, we would have really international talks that can be tracked by any user (that don't need to understand the timezones, calendars and languages used by others).