"Nick Pisarro" <nickp(a)aperture.com> wrote in
Based on the unstable branch, the article
for maintaining msg values is an interesting idea, but I believe this
would be better built as a dynamically built page, i.e. as
"special:all_messages", rather than as a static page in the database.
This would get around the use of external links to edit the variables
instead of internal links. Is this done to avoid the slow operation of
resolving [[...]] at run time? The problem is that this makes the database
non-portable between wiki sites.
This causes a problem at our site because we update the database on a
development server and then move it to our working server. It means I have
to manually edit this page to change all the external links marked up on
It may also cause problems because WikiMedia distributes the wikipedia
database. That database also will not be portable.
I notice that on the wikipedia site, the similarly sized article
"Wikipedia:MediaWiki custom messages" does use internal links and seems to
resolve in about the same amount of time.
We plan to actually change the variable '$wgServer' at run time. We want
to present the server address differently if the user links to our site
via our VPN intranet versus coming in through an external URL via the
Internet. So, we rather not have the server domain defined in the
database, but always dynamically determined.
Yes, I think a special page listing the namespace contents would be a good
idea. I'm not sure why I didn't do that to start with. But please note:
soon, all custom messages will be moved to a different namespace (probably
Template:) and only the internal messages will be in MediaWiki:.
By making All_messages a special page, you can hide it
to all but sysops,
developers and/or bureaucrats, who are probably the ones who should see
and maintain these variables.
No, all users should be able to view, comment on, and ideally edit the
MediaWiki namespace. Some messages cannot be edited by all users because
either they are written in unfiltered HTML, or because changing them could
make reversion difficult. Many non-sysops have made useful contributions to
the MediaWiki namespaces, usually asking a sysop to make a given change for
It also will mean that, that as a developer,
if you add variables to "$wgAllMessagesEn" this page will be up to date
without having to run an install procedure.
I also notice this page is built from the variable '$wgAllMessagesEn'. If
this were built as a 'special' page, it could build using the language the
site actually represents.
Actually, the table is not simply built from $wgAllMessagesEn, it's built
from the localised language file. However, localised language files are
usually missing a few messages. The English language file is the only one
which can be relied upon to be up-to-date with the features. So the script
draws the keys from the English file, and the values from the local file if
the message exists, or the English file if it does not. This allows sysops
to maintain the interface translation, there's no need to update the
localised language files anymore except for the various items which are not
in the MediaWiki namespace.
-- Tim Starling