Note that the default implementation of the proposed template (actually in the mediawiki protected space) would just use the existing {{#timel:}} ParserFunction for converting it, even if this does not take into account user's preferences for its language/script. However, more advanced wikis will then be able to customize this template to offer internationalization accourding to user's language, by using a format that will be automatically localized using another ressource from {{int:}}, or some other normal templates specific to the local wiki and managed locally).

Also the code generated may also use a global $wgXXXX configuration variable in PHP, to specify the name of the template to insert in discussions instead of the static name "mw:date-time" proposed here (the benefit being that old discussions may still be readable if additional parameters, or parameters using another format gets generated in a future MediaWiki version or in an extension hook handling this timestamp formatting for signatures).

Note also that this would be especially useful for Multilingual wikis (such as Commons, but also localized Wikipedias that use multiple scripts with distinct sets of digits such as Persian/Farsi, and most Indic languages, and as well to display the date and time in the preferred user's timezone instead of the default UTC for everyone).

I know that this was discussed some years ago for old versions of Mediawiki, but now Mediawiki has made significant progresses in its implementation of caches, so supporting multiple locales for the same page should be much less an issue today as it was in the past). Note also that this does not mean that user's locale preferences will need to be implemented in all wikis (only those wikis that are deployed with enough ressources to support multiple rendering of the same page in distinct locales, may opt in to use an autotranslatable date-time format in the local implementation of the proposed template).

Note finally that some localized Wikimedia sites (including large ones) already implement multiple rendering locales for the same language, such as Chinese.

Mediawiki's internal page caches are already handling this user preference, so I don't think that performance is a big issue (notably because the implementation of the timestamp formatting template can be extremely simple (and very small in terms of code size) in wiki source page caches, where it will be almost always resident ue to its very frequent use in all discussion pages, if this enhancement feature is enabled and deployed.

Why should we make it available for templates when we can just as well format the time directly into users preferred time format (or the default for the language at least)?

(In reply to comment #4)

Why should we make it available for templates when we can just as well format
the time directly into users preferred time format (or the default for the
language at least)?

The signature is subst'ed into the saved wikitext, so its formatting is fixed from there on out. You could format signatures from Persian users in Persian format, but that'd make Commons look like a huge mess. What Phillipe is asking for is some kind of variable timestamp format that obeys the preferences of the viewing user.

I wonder to what degree this isn't already done by LiquidThreads, though.

(In reply to comment #5)

The signature is subst'ed into the saved wikitext, so its formatting is fixed
from there on out.

That's the thing we are debating to change. However I don't see the point of going as far as leaving the formatting to a template, we can just as well do it dynamically (more importantly, better) with a magic word.

How would you use a magic word?
You could use a parser function, but that's pretty much the same as using a template (the solutions are equivalent to me).

Yes I meant a parser function. The thing is that parser function can access user's preferred timezone preference while a template can not.

(In reply to comment #4)

Why should we make it available for templates when we can just as well format
the time directly into users preferred time format (or the default for the
language at least)?

Yes, but want I watn is that this format is NO longer static for all users. So use a template as it is easy to do, but if you use the existing builtin parser functions, it won't localize the date in a format that users can read according to their preferences.

So if you want, you may implement it via a new parser function that can take into consideration the user's locale, but be prepared to exceptions, as this is not just dependant on its language. Generating a standard template would allow other improvements for the rendering, when there will be, later, more parser functions to implement it.

Note that there already exists a magic keyword from which you can know the user's locale. So this can already be done with a template, without adding a new parser functions. An in the future, there could exist more magic keywords or builtin functions that will retreive other local info than just the language: there should not be any need to change the template name generated, but this template implemetnation can easily be updated to offer new customizations according to new detectable user preferences in their locale (say: language, script, 12/24h format, abbreviated/long form...): how many new parser functions will we need ?

What I propose is simpler: just generate the template with a default implementation and let this implementation be customized at any time on all wikis.

(In reply to comment #5)

(In reply to comment #4)

Why should we make it available for templates when we can just as well format
the time directly into users preferred time format (or the default for the
language at least)?

The signature is subst'ed into the saved wikitext, so its formatting is fixed
from there on out. You could format signatures from Persian users in Persian
format, but that'd make Commons look like a huge mess. What Phillipe is asking
for is some kind of variable timestamp format that obeys the preferences of the
viewing user.

The signature preference os for the user signing the message. It has nothing to do with the format of the timestamp added after it, and that should NOT depend on the user signing the message, but on the user reading it !

And don't forget that LiquiqThread is not unversally adopted, and has no use in many pages where we must still be able to sign, such ad community vote pages.

Finally, many users don't want LiquidThreads in their own talk page. LiquidThread is only one option that is activated on specific pages by insterting some template.

(In reply to comment #10)

The signature preference os for the user signing the message. It has nothing to
do with the format of the timestamp added after it, and that should NOT depend
on the user signing the message, but on the user reading it !

Why do you think it would suddenly depend on the writing user's preference when it has never been so?

Instead I am saying that we can create a new parser function that does the job properly by reading the time format preference from the user. The templates you are referring to are hacks at best and we can't use those for the default implementation. There is just no need to be able to customize the output with templates which are not suitable for the job.

"Why do you think it would suddenly depend on the writing user's preference... ?"

Because this is explicitly what for I started this thread. It HAS to depend on user's preferences, instead of site's preferences like it is done now. Did you read the first message explaining why it is desirable for correct internationalization ?

Finally, if you really want a new parser function, this should just be one that will be able to retrieve a selected user preference, such as:

{{#pref:key}}

where the key will be a unique selector (possibly locale-neutral) for accessing items within the user's preference (I assume that user preferences are stored as a dictionnary of key=value pairs), acting much like a getenv(key)

With it you'll be able to retrieve indifferently:

• the user's preferred language (possibly set by default in the preferences by default to match the UI language set in its browser)
• the user's preferred script (for languages that have multiple scripts)
• the user's preferred time format (12h with am/pm vs.24h)
• the user's preferred timezone (possibly set by default in the preferences by default to match the timezone set in its browser, or UTC if this cannot be determined and has not been set in preferences)
• the user's preferred date format (full, abbreviated, or possibly relative such as "one hour ago", or "two years ago")

Note also that:

1. some locale information could be private data (so don't assume that these parameters can be set in a subpage of the user page, because user pages are public)
2. care should be done so that such data cannnot be silently used on other templates that could make them public to everyone : beware of the effect of cached pages : the impact will be that pages in the cache will have to depend on the effective value of those specific locale elements used (this is already the case for the language), and so the same page would have to be cached multiple times depending on the values of these localized items (possibly by building an ordered list of those items, then hashing this list with MD5 or SHA1, and using this hash to mark the version to use to/from the cache) ;
3. the default anonymous user (when not logged on) could also have locale preferences detected from its browser. Otherwise, the site's default locale will still apply.

All those parameters can then be used conditionally when building the template effectively used on each wiki, and references when saving a message signed with four-tildes, or just the timestamp with five tildes.

For formatting dates with these parameters, we already have the builtin #time: parser function (or #timel:, but it does not change the result if we specify the date-time elements), it should be enough.

Yes, it is very simple to do in Mediawiki (even if for now we don't have a lot of information accessible from user's data), with almost no change (just replace the static date-time formatting in the PHP code, by a static call to the standard template implementing the formatting specifically for each wiki).

(In reply to comment #11)

Why do you think it would suddenly depend on the writing user's preference

I have absolutely NOT said that, you have not understood or misread !

And in fact all I explained was the opposite: the timestamp format MUST ABSOLUTELY NOT depend on who is signing the message (even if he can choose what to include in his signature and that must be honored for every one reading him), and SHOULD PREFERRABLY NOT depend on site "preferences".

All this is speaking ONLY about improving the timestamp format and nothing else, because this is what is saved in pages.

In other words, when I'll sign a message with "~~~~" what will be saved in the page will be:

[[User:Verdy p|Verdy p]] {{mw:date-time|2010|12|31|23|59|59}}

instead of:

[[User:Verdy p|Verdy p]] 31 December 2010, 23:59:59 UTC

where ONLY the part "[[User:Verdy p|Verdy p]]" comes from my signature preferences (independantly of who is reading the saved page).

(In reply to comment #12)

Because this is explicitly what for I started this thread. It HAS to depend on
user's preferences, instead of site's preferences like it is done now. Did you
read the first message explaining why it is desirable for correct
internationalization ?

Please stop assuming I don't get it. We are talking about the same thing (writer is the person who signs his message, as opposed to any reader).

Finally, if you really want a new parser function, this should just be one that
will be able to retrieve a selected user preference, such as:

{{#pref:key}}

Cannot do that, it would break caching and some people expect their preferences to be private.

3. the default anonymous user (when not logged on) could also have locale

preferences detected from its browser. Otherwise, the site's default locale
will still apply.

Cannot do that either, because of caching, again.

I'm proposing a solution we can implement and which is very simple compared to yours.

Note also that we already have the support for internationalizable templates with the special "int:" namespace (whose value is stored in the "mediawiki:" namespace. This is extensively used in Translatewiki.net's wiki itself; it will benefit from the same efforts for internationalization and translations, and can be deployed as easily as when distributing new translations.

What you propose will NOT avoid the cache problem: we really want to have the same page rendered differently between users reading the wiki (but it could help if the saved page was unique. In other words, your solution solves absolutely nothing and just complicates things even more for no benefit at all !

The cache on the opposite already has the support to deliver distinct renderings of the same wiki source page, according to user's UI language (only).

For now all we have is a client-side javascript () that only works with dates saved in the US-English format, and incorrectly matches all dates that it may find by parsing all the contents in the page. It is not reliable, and does not work across wikis (in addition to not being accessible for WAI). So this user-selectable plugin does not work (in addition it is not deployed).

The main problem for me is when I visit an site written in Indic scripts, or in Chinese, Arabic, Persian... these dates are undecipherable without lots of efforts and knowledge of its language (for month names, week day names...). And users in these wikis have the same difficulties when they try to read-write the discussions found in other Latin-written wikis. Even for Latin-written wikis, those dates are sometimes very confusive (due to their translation, or because of swapped fields, notably between d/m/y or y/md/d order, or because of unusual timezones that are indicated using a locally translated string, which is undecipherable for lot of people).

(In reply to comment #14)

(In reply to comment #12)

Because this is explicitly what for I started this thread. It HAS to depend on
user's preferences, instead of site's preferences like it is done now. Did you
read the first message explaining why it is desirable for correct
internationalization ?

Please stop assuming I don't get it. We are talking about the same thing
(writer is the person who signs his message, as opposed to any reader).

Finally, if you really want a new parser function, this should just be one that
will be able to retrieve a selected user preference, such as:

{{#pref:key}}

Cannot do that, it would break caching and some people expect their preferences
to be private.

Once again you did not read. I already warned in my message about which kind of data should be accessible or not. However, if this data is only accessed from a template that will never generate it in the output (so it could be used only from the protected mediawiki space), there's no danger: the only pupose will be to conditionally format the timestamp elements specified in parameters.

And my first request did not include that "#pref". It just wanted a template using the same features already implemented (including the magic keyword that gives the UI language of the reading user. Don't say it does not work, this is false and is already used now in "translatewiki.net" as the preferred method for translating everything.

And my proposal does not require any new parser function, or any modification to the existing code for caching pages... This is exactly the same logic as when using {{int:}} to translate the MediaWiki interface or for "autotranslating" templates.

I understand the problem and I also understand how MediaWiki works what makes sense. Yet however you fail to consider my solution (perhaps you still misunderstand it after many tries?) and dismiss it without justification. After that you go on and talk about various possibly related things that bring nothing useful to this conversation. It annoys me a lot and it is definitely *not* *helping* to get this bug fixed. Please think about that.

(In reply to comment #16)

And my first request did not include that "#pref". It just wanted a template
using the same features already implemented (including the magic keyword that
gives the UI language of the reading user. Don't say it does not work, this is
false and is already used now in "translatewiki.net" as the preferred method
for translating everything.

If you mean {{UILANGCODE}}, it's an ugly hack that is only in translatewiki.net and is not preferred for anything. Neither is {{int:}}, but I'm not going to talk about that.

Just once more: with a template you cannot access reader's time preference, and barely the reader's language with ugly hacks. With a parser function we can access both and addition we can make sure that caching works correctly.

(In reply to comment #17)

After
that you go on and talk about various possibly related things that bring
nothing useful to this conversation. It annoys me a lot and it is definitely
*not* *helping* to get this bug fixed. Please think about that.

That's because you think it can't be done and reject all possible solutions that I am discussing the alternatives. But my initial proposal was the simplest, and the less costly.

{{UILANGCODE}} is not so ugly. It already does what you want: accessing the user's preferred language (which can also be overriden by reloading the page with "?lang=" query string in the URL. This already works extensively on Commons (not just Translatewiki.net), and the {{int:}} syntax (which also accesses to the same variable internally) is also working very well since quite a long now.

That's why a simply template can be built to format dates according to user's UI. I am already discussing these because this really helps to have this bug fixed, only to convince you that the solution is simple and will easily deployed, inclusing on small third-party wikis that only support a single language (the content of the template will be part of the other translatable ressources)

For example the minimum deployment for supporting {{int:date-time|yyyy|mm|dd|hh|mm|ss}} will be this very basic code:

{{#time:c|{{{1}}}-{{{2}}}-{{{3}}}T{{{4}}}:{{{5}}}:{{{6}}}Z}}

Then replace only the "c" with the default format for the language of the wiki, such as "d F Y H:i:s".

If you want to take into account the user's language, use something like:

{{#switch:{{UILANGCODE}}

}}

(extend it on each wiki for the list of locale formats you want to support, by just modifying this protected template ; no need to upgrade MediaWiki each time or to restart it with an updated PHP hook code).

But if you want a specific builtin parser function, why not, as long as it will allow the same localizations according to reader's UI preferred locale (and to the lang= query parameter in the URL to override it), and as long as pages won't be saved with a static (and not reliably parsable) preformatting.

A template with one hundred options is barely "simple".

It works as userland, but a parserfunction can do it better.

For instance:
function wfBug25746Function( $parser, $time = '' ) {

return $parser->getFunctionLang()->date( wfTimestamp( TS_MW, $time ) );

}

would automatically give you the time in the user language for interface messages and in content language for pages.

Replacing $parser->getFunctionLang() with $wgLang would always give it in the user language, BUT you could get pages cached in other users format.

It can be adjusted, but my main concern is that it would force using different caches (in fact, this is already done for different languages, due to the edit links but it's something to fix, not a path to follow).

And if you begin splitting on things like 12/24h formats, much more.

Note that you can end up with a very complex feature, but so costly that it won't be enabled on WMF.

What I suggested remains valid: place the effective code that will be generated in a protected template, even if this template will use some custom parserfunction.
Not all wikis will need such parser function (and the complexity of multiple rendered versions of the same page in their cache).
In other words, I still think that the signature should not generate staitc code but code that can be tuned on each wiki, and parsed easily (not based on plain text), independantly of how the protected template will work or will use internally to perform the effective rendering (this template could use UILANGCODE, or could use a static format, or the parserfunction you suggest, it does not matter, what is more important is that the tildes for timestamps should not be saved in an irreversible ambiguous way, but still preferably in a compact format that is easily readable and editable).

My suggestion of generating something like {{mediawiki:datetime|2010|12|31|23|59|59}} remains as the simplest form that any editor would read easily. you should not care about what will be in this internationalization template.

But if you rally want a parser function, just do it, it will not change things radically, because you'll still have exactly the same decisions to do about how to cache the rendered pages, except that there will remain no possible customization of this behavior for each wiki accourding to their local cache policies. Using a template in a protected namespace as a delegate would avoid avoid to patch the hardwired behavior of the suggested parserfunction, even if you implement it later or add further options (these options should not be visible in messages, they should netter be tuned directly in the protected template, whose implementation will be almost always extremely basic).

(In reply to comment #16)

However, if this data is only accessed from a
template ...

How would user preferences being used or accessed inside the template?
We currently have no other mechanism than providing a parser function for it. Maybe one function for each setting, maybe one function for all settings
with a parameter selecting which setting is to be accessed.

Then, as a matter of economic coding, why not pass the formatting string (template) as yet another parameter to the parser function as well, letting
all the formatting happen there?

This is independent of its source, it could be a global fixed wiki setting,
a string from the MediaWiki name space, or an individual reader preference,
even a cookie for logged-out users would be possible. Of course it could
be explicitly passed to the formatting parser function from wikitext

The order in which these possible souces need to be checked is obvious.
Inside a parser function, caching can be dealt with, mechanims to do so
are already in place - think of wikis having script or dialect variations
such as Chinese or Serbian or Khasak, that do this type of caching already.
Since there are several more uses for the abovementioned decisionmaking,
it is likely to become a common subroutine in the MediaWiki code base
sooner or later, if it is not already there.

Inside parser function code, we can easily do string arithmetic which is
excessively slow and expensive if done in templates with parser function
calls. Thus, we can have a parser function use a string argument for the
date which is human and machine readable, sortable and comaprable, such
as in:

{{#formatdateandtime|2011-12-31 23:59:59 }}
{{#formatdateandtime|2011-12-31 23:59:59 | UTC }}
{{#formatdateandtime|2011-12-31 23:59:59 | -800 | <formatstring> }}

where the date-time is always UTC, the 2nd parameter gives the time zone
that is currently used to insert fixed format dates and times, and a
format string can be used ba users wanting to manually select one.

Did I forget anything?

You've not understood. What is needed is NOT generating custom formats for dates & time, but being able to generate a suitable HTMML text *with* its markup, that allows a numeric timestamp to be recognized as such (as a timestamp), reliably (not depending on a weak text parser trying to find where there may be a datetime in the webpage's text), so that a user-specific setting (working for example with a client-side javascript) will be reliably able to format this date according to user preferences.

For this, the template does *not* even need to access to user preferences.
So instead of generating a "blind" format such as:

2011-12-31 23:59:59

in the web page (or any other format), the template would only generate something like this:

<span class="datetime">2011-12-31 23:59:59</span>

or, if the solution must be able to use a date time with a default localized format according to the default language of the wiki (say in French), it would generate something like:

<span class="datetime" data="20111231235959">lundi 31 décembre 2011, 23h59 UTC</span>

The result of this is that the HTML page becomes parsable reliably, and users can have an *optional* javascript (loaded from its preferences) that will reformat the timestamp using the parsable data contained in the markup which gives its interpretation.

Then users can have their own locale preferences about how a prerendered date can be reformatted. All users are then continuing to sign normally their posts, using the usual sequence of tildes, that will in fine generate a reference to a standard template generaring this preformatted date, along with its interpretation defined by the markup also generated by the wiki-specific template (this template would be wiki-specific only because it would implement a default format for the preformatted datetime)

Of course this template can easily use the {{#formatdatetime|}} parse function you indicate for generating the preformatted date, and also generate the surrounding microformat markup (that gives the semantic of the formatted text).

Note that a client-side javascript does not even need access to user's preferences to be stored on the server (so the user does not even need to be logged on). The main reason is that a client browser already knows the user's preferred locale, and this is also accessible to a javascript (for example the javascript can also look at the value of the MIME header "Accept-Language:é present in the HTTP query).

Finally you may wonder: why a template ?

Just look at which kind of additional markup must be present in the generated datetime, and you'll immediately see that this would not be very easy to edit when posting messages, quoting them, reediting them. A template invokation can be much more compact and still easy to interpret. The invokation of a protected template hides the details of how the additional markup is generated, to work in cooperation with a client-side javascript (also installed on the wiki).

It is much simpler to edit a message containing:

Blah blah... -- [[User:user name|user name]] {{int:datetime|2011|12|31|23|59}}

rather than a message containing:

Blah blah... -- [[User:user name|user name]] <span class="datetime" data="20111231235959">lundi 31 décembre 2011, 23h59 UTC</span>

And stil definitely better than messages currently containing:

Blah blah... -- [[User:user name|user name]] lundi 31 décembre 2011, 23h59 UTC

which is impossible to adapt reliably to user's preferences. But all these messages will still be posted initially using:

Blah blah... ~~~~

Do you understand now ?

Bug 19992 discusses similar client-side time zone as well.

On another note, why not close this current bug just sending the right time zone from the server (like it is done for the page history)? And if the new, client-side, way of handling of time zones is developed, all of the time zone uses should be done in the same fashion?

(In reply to comment #24)

Bug 19992 discusses similar client-side time zone as well.

On another note, why not close this current bug just sending the right time
zone from the server (like it is done for the page history)? And if the new,
client-side, way of handling of time zones is developed, all of the time zone
uses should be done in the same fashion?

(In reply to comment #14)

(In reply to comment #12)

...

3. the default anonymous user (when not logged on) could also have locale

preferences detected from its browser. Otherwise, the site's default locale
will still apply.

Cannot do that either, because of caching, again.

I'm proposing a solution we can implement and which is very simple compared
to
yours.

This is related to bug 3665.

Note that using the existing #dateformat function would effectively make edits very ugly, due to its existing syntax, which should be simplified in discussions. But that's exeactly the place where a template that internally uses the parser function could help (yes it will have parameters but these parameters should still be easy to interpret when editing, and should be as compact as possible).

May be a single parameter using ISO 8601 syntax would be enough.
Initially I proposed:

{{datetime|2011|12|31|23|59}}

But this could as well just be:

{{int:datetime|2011-12-31T23:59Z}}

or without even using any shared template a parserfunction dedicated to the default formatting of datetimes timestamps in message signatures:

{{#datetime:2011-12-31T23:59Z}}

Or if the wiki already knows how to parse date using the localized format already generated for the default language of the wiki:

{{#datetime:31 décembre 2011 23:59 UTC}}

(of course, this last example would be for a wiki whose default language is French here). It just explicitly insert the markup that this is a date and most contributors of the wiki will be able to interpret it. And then it generates the correct format localized in the user language.

Using first a template-based solution (named using a consistant naming in the MediaWiki "int:" namespace which is already dedicated to its internationalization) could allow experimentation for seeing the impact on caches (the template will choose whever to use, or not, the user's language or just use the default language of the wiki; date formating rules would then be imported in this "int:" namespace only for languages supported by the wiki, and a monolingual wiki would just have a single rule in this namespace for its own default language).

Another improvement could be that, when editing the page, the content of the MediaWiki-libs-Timestamp parameter would also be reformatted in the language of the editing user; then reparsed when saving the edit using the user's locale and reformatting it in the wiki's default language.

But I fear that this behavior could have potential defects in some pages if such transforms of the edited text are applied automatically and silently when saving the edited message. My opinion is that the edited page should just contain a static date format, even if it will be reformatted when only viewing the page according to user's language.

Okay, trying to move this bug forward... currently we have:

• ~~~: substituted contents of [[MediaWiki:Signature]]

• ~~~~: substituted contents of [[MediaWiki:Signature]] + UTC timestamp (i.e., ~~~~~)

• ~~~~~: UTC timestamp

Could we make the latter half of ~~~~ and ~~~~~ use a substituted MediaWiki message? Something like [[MediaWiki:Signature-timestamp]]?

(In reply to comment #28)

Where I write "UTC timestamp", this is actually imprecise. Wikimedia wikis default to UTC, but the signature timestamp time zone is actually based on some configuration variable.

The great thing of bugzilla is that I don't have to sign this comment with four tildes ("~~~~"). Nonetheless my name and date/time of comment do appear right above. This is done in a wikimedia.org environment. So technically it should be possible to get rid of the four tilde stuff entirely on Wikipedia talk pages. Thanks for your attention.

(In reply to Ad Huikeshoven from comment #30)

This is done in a wikimedia.org environment. So technically it
should be possible to get rid of the four tilde stuff entirely on Wikipedia
talk pages. Thanks for your attention.

Not sure exactly what you mean by wikimedia.org environment.

But, in any case FYI:

• the bugzilla behavior is not what's requested here (search for "liquid" earlier in this bug and see [[mediawikiwiki:extension:LiquidThreads]])
• Bugzilla and MediaWiki are unrelated software projects
• the projects don't even use the same programming language

Great minds think alike: T230653: Use a parser function to encapsulate signatures