@Petr, good question. My goal with using the #time function was to make future re-uses of the message as simple as possible, by not requiring any updates from individual translators whenever it next needs to be sent. I had thought this method would work (if not perfectly, then at least well enough for each reader to understand it). If you/anyone knows of a better way to achieve this goal, I'd be happy to learn and use it! @Jürgen That "Thank you!" uses translations from Translatewiki, and will appear in the language that a wiki (or logged-in user at a wiki) has their preferences set for. E.g. if we add `?uselang=de' to the URL at meta-wiki, then we see it as "Danke!", which is how it will appear at all De-wikis. - https://meta.wikimedia.org/wiki/Tech/Read-only_limited_announcement/de?usel… -- Thanks for asking! :-)

Hi, On Fri, Aug 20, 2021 at 11:12 PM Nick Wilson (Quiddity) < nwilson(a)wikimedia.org&gt; wrote: Yes, that is indeed a good idea, definitely better than using untranslatable English date or something like that! The only issue is the used format. Yeah, I believe the readers should understand the result all right, it’s just that it’s obviously non-Czech, it reads artificial/strange. I thought marking the _format string_ for translation _might_ work? I. e. let the translators translate the “l F d H:i e” string inside the #time invocation; e.g. for Czech, I’d translate that to “I j. xg. Y, H:i e”. (It might need an explanatory documentation for translators – do translatable pages support /qqq documentation?) But I don’t know, does translation work inside parser functions, or will it break somehow? Even though MediaWiki does know the proper date/time format for every language (and allows the user to select his/her preferred), it uses these for outputting timestamps on e.g. history pages (or formatting the ~~~~ signatures). But I don’t think there is a magic word / parser function / something which would provide this information into wikitext? (Yeah, the user-configured option cannot be sent to the parser, as it would break caching, but at least the default format for the content language? I guess not.) -- [[cs:User:Mormegil | Petr Kadlec]]

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). Le sam. 21 août 2021 à 10:47, Jon Harald Søby &lt;jhsoby(a)gmail.com&gt; a écrit :