Hi, all... I'd like to revive some interest in improving support for
mobile browsers.
Extremely limited WAP-based browsers are at least sort of served by the
experimental WAP gateway, but there are a lot of smartphones and other
handheld devices that get on the "real" web with greater or lesser
degrees of success, and I'd like to see us improve the default look &
feel of MediaWiki on them.
At the moment I think we can roughly divide the mobile browsers into two
categories:
* Those that render much like a full desktop browser and let you zoom as
necessary (iPhone/Mobile Safari, Opera Mini, ...?)
* Those that have very limited CSS and JavaScript or strip a lot of
stuff down (Opera Mini in "mobile view" mode, most others?)
At the moment, all I've got access to are an iPhone and the Opera Mini
simulator applet, so that's what I'll be putting the occasional bit of
time into. These already pretty much "just work", but the UI can be very
awkward due to the desktop-size layout; I'd like a cleaner handheld
stylesheet that lets most pages be legible when you get to them.
If you've got another device and you'd like to help testing and
developing for it, please stake your claim at:
http://www.mediawiki.org/wiki/Mobile_browser_testing
Alternatively if you've got a spare device you can donate to us, that'd
be great too! (Especially if it doesn't need a service subscription to
get on the net...)
-- brion vibber (brion @ wikimedia.org)
Quick info needed for a question I was asked:
If/when do Wikimedia sites plan to start using the HTML5 <VIDEO>
element to serve up Ogg Theora? (Is there similar for Ogg Vorbis?)
Soon? Release of Firefox 3? Whenever? If someone's using Safari or a
Nokia, will it suggest their experience will suck less with a real web
browser? What's the plan?
- d.
Hi,
I'm an admin of a intranet mediawiki (version 1.10.1) portal. As a policy,
I've suggested all the users to have at least one category for the page that
they create. Users can use the existing category OR they are free to create a
new category wherever required.
But it seems users are still creating pages without any category. How can I
forcefully apply this policy so that users cannot create a page without a
category? Is there any way to impose this rule in mediawiki.
Has anyone tried this earlier? Kindly suggest a way to put this policy in
there.
I'm a programmer too and manage to read/write php if this requires a code
change.
Thanks in advance,
Swapnil
Per http://bugzilla.wikimedia.org/show_bug.cgi?id=12655 ...
On our newer, Ubuntu-based Apache configuration we've been using sSMTP
as a minimal local SMTP sending agent. This emulates the 'sendmail'
binary and simply passes messages off to a hub server with no local
queuing... but it's not without its problems.
sSMTP forces the message's 'From' header and the SMTP envelope sender
address to be the same, which causes some problems for us when that
'From' address is a user's offsite e-mail:
* Servers which validate SPF records may reject the messages outright
* In case of delivery problems, bounce messages will be sent back to the
user, possibly including the recipient's address which is supposed to be
kept private.
As a workaround for such configurations I've introduced a config var
$wgUserEmailUseReplyTo. When set, a wiki-specific address is used as
'From', and the user's address is put in 'Reply-To'.
This is uglier -- you don't see a clean 'Sender' column in your mail
client -- but mails will get through and private data won't get tossed
around inappropriately.
In the long term I'd like to see us either dump sSMTP (a local-only
postfix or something would work fine) or patch it to let the envelope
sender be set separately.
-- brion vibber (brion @ wikimedia.org)
Warning: array_slice() [function.array-slice]: The first argument should be an
array in /opt/lampp/htdocs/mediawiki-1.11.0/languages/Language.php on line 1153
can somebody tell me, what's the reason for this warning-message?
i didn't change anything in this file so far. i've just installed the
hierarchy-extension. since this moment, this message occures...
greets
demagggus
On Jan 20, 2008 4:22 PM, <aaron(a)svn.wikimedia.org> wrote:
> - line-height: 15px;
> + line-height: 14px;
You know, there's a reason people avoid px-based measurements,
especially for fonts (and line-height as well). IE does not respect
users' font size preferences for fonts given absolute sizes (px, pt,
in, etc.). This is reportedly true even in IE7, although that does
have a (misconceived and arguably useless) page zoom feature that can
overcome this limitation. It's not really acceptable for
accessibility to use absolute units for font-related measurements; use
ems. For things like the width of boxes, logically then you'd also
want to use ems, because it doesn't help much to have a larger font
that doesn't fit. For stuff like borders it doesn't matter much,
though.
Hi,
subject tells a lot about overall thing, and media is writing a lot
about the acquisition too, so no need to expand on general topics too
much.
though, of course, Wikipedia runs on MySQL, and there is some
relation to the story that way too, but this story also means I'll be
employed by Sun.
I usually kept my professional work completely separately from the
wikipedia work - that both gave me freedom, and allowed me to avoid
any conflict of interest.
Though I've seen quite a few "MySQL is Wikipedia's choice, cause they
have infiltrated the organization with engineers", it is somewhat
opposite - I went to work for MySQL AB because it could use the
skills I grew at Wikipedia in many quite interesting ways.
Sun, though, is a big company, which has hardware, operating systems,
application servers, etc in their portfolio.
Though people from tech team know that I enjoy rational technology
solutions with irrational flavor of being open-source - conflicts of
interest may seem probable in community and public opinion (as there
already were mentions about mysql).
I'll continue to avoid being proxy of corporate interests, though of
course, if there will be opportunity to progress open technologies
both at my work and at wikitech, will voice the ideas and suggest
solutions.
Oh, and that was one hell of wikivacation week :)
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
Ok, you know what I'm talking about: "You have new messages (last change)."
My question/proposal is this: how difficult would it be, from a
technical POV, to change "(last change)" to "(previous change)". In
other words, I'm proposing this change:
CURRENT:
(1) the software knows when a user has last visited their own talk page
(conventional name: DATE:LASTVISIT)
(2) the software knows when a user's own talk page has been modified
last (conventional name: DATE:LASTCHANGE)
(3) on each page access, the software compares DATE:LASTVISIT with
DATE:LASTCHANGE, and if the last change is more recent than the last
visit, it offers two links: one straight to the user's talk page, and
the second to a diff between the current and the previous version of the
user's talk page
PROPOSAL:
(1) no change
(2) no change
(3) no change, except the second link would be pointing to a diff
between the current version and the version just before DATE:LASTVISIT,
whenever that might be.
The pragmatic advantage to this change would be that people could
actually notice ALL changes in their talk pages between their previous
and the current visit (as opposed to the current implementation, which
only shows the last change, which is a pretty arbitrary metric). And
technically I can't see any cost (except for the cost associated with
the actual changes in the code, of course) -- but I might be wrong.
What do you think?
Gutza
While the recent changes to our Squid caching behavior mean more good
stuff stays in cache, improving performance, it's also made it harder to
clear bad stuff out of the cache.
One particularly irksome issue is "blank pages" -- when PHP dies due to
a bug or hitting a memory or time limit, you just get blank output. When
this comes before we've set our cache-control headers, the current Squid
settings mean that gets cached and shown to everybody else who comes to
that page.
This is rather troublesome for non-default actions and Special: pages,
since an ?action=purge won't help you -- you have to ask a developer to
log in and clear the URL manually. Ouch!
To combat this, I've added a default 'Cache-control: no-cache' header
into our local CommonSettings.php file, which comes early in code execution.
When everything goes ok, proper caching headers will override it... but
if the script dies partway through, that no-cache header gets sent out
along with the blank output, and the squids won't keep it.
The next refresh or the next visitor will be a new request, and a
transitory bug won't be stuck in cache.
-- brion vibber (brion @ wikimedia.org)
(from [Mediawiki-1])
Description:
I upgraded from 1.10 to 1.12alpha phase3 (checked out from 2008-01-14).
Now thumbnails are being created in the thumb directory but not shown
from there. Instead only some images are shown, and if they are shown
they are shown via the thumb.php file only.
Problem identified:
MediaWiki more or less constantly provide Thumb.php with a width that
is 1 pixel too large, which makes Thumb.php generate an error.
This applies for images that are smaller than the standard size for
thumbnails and the image previews at the image articles.
Something wrong with my configuration? Or a bug in MediaWiki?
Example:
I have an image that I try to view with [[Image:MyImage.jpg|thumb]],
which creates a thumbnail with URL
http://my-server-url/w/thumb.php?f=MyImage&width=170, which says
" Image was not scaled, is the requested width bigger than the source?"
Manually changing the url to
http://server.com/w/thumb.php?f=MyImage&width=169 makes the image show up..
The same for an image that does not show up on the image article.
The preview image has URL
http://my-server-url/w/thumb.php?f=MyOtherImage&width=369, which says:
" Image was not scaled, is the requested width bigger than the source?"
Manually changing the url to
http://server.com/w/thumb.php?f=MyOtherImage&width=368 again makes the
image show up..
(Samuel)
Regards, on behalf of Samuel,
// Rolf Lampa