--- Comment #12 from Philippe Verdy <verd...@wanadoo.fr> 2010-10-13 06:28:26
"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
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:
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
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).
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
Wikibugs-l mailing list