Hello, I'm currently partially rewriting the log system, because the
current one doesn't support i18n well enough.
I'm trying to avoid any radical changes like changes to the database
schema. My changes mostly touch
handling log entries and formatting them.
So, if you know any defects in the current log system, or have an wish
what the new should do, or know someplace where these kind of wishes
exist, please tell me.
I have scanned the list of bugs in bugzilla quickly, but it is a bit
hard to find relevant bugs when there is no logging component.
I'm aiming to solve at least these bugs:
https://bugzilla.wikimedia.org/30737 User names should be moved into
log messages.
https://bugzilla.wikimedia.org/24156 Messages of log entries should
support GENDER
https://bugzilla.wikimedia.org/24620 Log entries are difficult to
localize; rewrite logs system
https://bugzilla.wikimedia.org21716 Log entries assume sentence starts
with username
-Niklas
--
Niklas Laxström
> - Using JSON in php, when you decode what you encoded you don't always
> get the same thing back (serialize you of course do)
How is PHP's YAML support? I prefer YAML to JSON, as it's even easier
to read and parse. May not be best here, but could be an option if
the interface is less broken than the JSON one. :)
--
Greg Sabino Mullane greg(a)endpoint.com
End Point Corporation
PGP Key: 0x14964AC8
There seem to be two groups of extensions: those which are not really
maintained, and those with active maintenance and development work. We
are relatively strict keeping our new core code backwards compatible
(BC). That compatibility does not come free, but who is it for? It is
for people who are not following MediaWiki development and it is for
letting unmaintained extensions to work for a few more years.
Having said that, I think BC is important and we should continue be as
strict about it as we have been. The current practice seems to be:
1) keep the old interface available unless it makes no sense anymore
2) add @deprecated in X, warnings in X+2, removed in X+4 where X is
the current development version, the numbers may wary a little
3) update all extensions in the svn to use the new interface (with
exception, see rest of this message)
4) add warnings and remove in version stated in 2)
But I also think there is place for us core developers to help the
other group of extensions. What are we doing for people who are
actively developing and maintaining extensions, trying to keep up with
the latest interfaces and best practices? Usually these extensions want
to support multiple version of MediaWiki simultaneously. Think about the
Semantic MediaWiki extensions and the Translate extension. I will now
talk about two practices, which would in my opinion be helpful.
Instead of just updating the code of those extensions to the new
interface directly, right now we have to add conditions like if ( foo )
{ do_it_the_new_way() } else { do_it_the_old_way() }. or use more
convoluted mechanisms. Without coordination different people
make different solutions.
I propose that we adopt a practice of amending old releases with new
interfaces, essentially moving the burden from extensions to the core
code itself. This doesn't mean that the whole new code needs to be
backported. Take the RequestContext interface for example. We could
very well add methods of this kind to our classes in 1.17:
public function getUser() { global $wgUser; return $wgUser; }
I think it doesn't make sense to go further back than the latest stable
release, or maybe even just the branched release if going back to the
stable release would be particularly hard to do. For example, depending
how easy it is to add the interface to older versions, right now it
might make sense to add the new interface(s) only to 1.18 and forward,
and not 1.17. I think this is called forwards compatibility (FC).
The idea is that users are not going to update to development versions
or even major releases very fast, but they could do a minor update and
keep enjoying latest versions of their favorite extensions.
Another idea is adding @since annotations to new methods and classes
and other changes. It's not fun to check the history of every function
and determine the date it was added, just to make sure you don't
accidentally introduce breakage when someone installs your extension in
an older MediaWiki. Right now, the practice of adding @since annotations
is not consistently followed or enforced.
I would like for us to:
1) start enforcing @since annotations for new core code
2) encourage adding FC interfaces to previous branches where possible
(and to also make releases out of those branches including the
interfaces)
-Niklas
--
Niklas Laxström
What: UploadWizard bug triage
When: Wednesday, Sept 7, 19:00UTC
Time zone conversion: http://hexm.de/6v
Where: #wikimedia-dev on freenode
Use http://webchat.freenode.net/?channels=wikimedia-dev
if you don't have an IRC client
Tomorrow, I'll be working with the features team to do a triage of
UploadWizard bugs. Please join us if you'd like to find out the status
of your favorite UploadWizard bug. We'll be working from
<http://etherpad.wikimedia.org/BugTriage-2011-09>. If you have any
comments, feel free to update the Etherpad with your comments.
Thanks,
Mark.
Hi Everyone,
Please join me in welcoming our newly formed
Internationalization/Localization (I18n/L10n) features engineering
team. The I18n/L10n team will focus on design and development of open
source tools to improve screen font rendering on web browsers using
open web fonts, input method tools including keymaps and
transliteration software to support Non-Roman languages specifically
starting with Indic languages this year.
The members on this team are Siebrand Mazeland as product manager,
Niklas Laxström and Santhosh Thottingal as software engineers, and
Gerard Meijssen as technology outreach consultant.
Siebrand Mazeland got pulled into Free and Open Source software
translating the FreeBSD Handbook in 2004. After translating a few
hundred pages, and making a few edits on Wikipedia (to the FreeBSD
article of course), he rediscovered Wikipedia in 2006. As an
administrator for the Dutch Wikipedia and Wikimedia Commons, he was
introduced to "translating MediaWiki" on an obscure wiki (“Betawiki”)
run by Niklas Laxström. Siebrand finds it hard to believe that he is
still going strong on language support in open source projects after 5
years. With translatewiki.net now providing almost 20 opens source
projects with excellent translations and a community of 3,000
translators, he is thrilled to join the Wikimedia Foundation
engineering team as I18n Product Manger, along with his long-time
friends from translatewiki - Niklas and Gerard.
Niklas Laxström is a software and language engineer, with a M.A. in
Language Technology (pending thesis review). He has been a free
software contributor since about 2003, mostly focused on translation.
Niklas joined Wikimedia in 2004 and soon became an administrator of
Finnish Wikipedia and a MediaWiki translator. To aid his translation
work, he created a wiki which has grown to become translatewiki.net,
which now manages translation of dozens of free software projects in
hundreds of languages. Niklas is the author of the Translate extension
for MediaWiki. He is also president of Wikimedia Finland. Niklas has
studied a number of languages including Russian and a little Tamil. In
his spare time, he likes to go for long bicycle rides (taking the
opportunity to improve OpenStreetMap) and to watch sci-fi films
including his favorite Stargate SG-1 series.
Santhosh Thottingal is a free software developer from Kerala, India.
He has been in the aerospace and automotive related IT industry for
the last 6 years. He has contributed to many free and open source
(FOSS) projects. His projects have been around language computing,
especially in his mother tongue Malayalam . He has contributed code,
bug reports and translations to FOSS projects like GNOME, KDE,
Openoffice/LibreOffice, Firefox, TeX, GLibc, Python, Aspell, Hunspell,
m17n, scim to help improve Indic language support. He is an upstream
developer for many packages in popular Linux Distros and is lead
developer for Dhvani, an Indic language TTS, SILPA, an Indic language
computing framework and a Pango-Cairo based PDF rendering library. He
is project administrator of the Swathanthra Malayalam Computing FOSS
developer community. His contributions to Wikimedia projects include
Malayalam Wikipedia and Wikisource offline versions. He is currently a
member of Wikimedia Language Committee. Santhosh is also constantly
improving the readability of Wikimedia projects, especially in
non-Roman languages with the Webfonts Mediawiki extension. He has also
been improving the Input Tool Mediawiki extension. As a team member of
the I18n team, he hopes to develop features that all wikis can use to
display and render all languages. Santhosh comes from a farmers'
family and is passionate about farming. Also as a fan of Malayalam
literature, he has helped the Malayalam Wikisource community digitize
and archive many precious works from Malayalam literature. He blogs at
www.thottingal.in/blog.
And last but not least, in the Wiki world Gerard Meijssen is known as
GerardM. He claims to be the one who has bored people to tears about
languages and language technology via his blog and presentations. Now
he has accepted the challenge to convince people about how
improvements by the I18n/L10n team will make using MediaWiki and
editing Wikimedia projects easy and fun. Gerard will be blogging
officially on the WMF blog as well as on his personal blog about
interesting and relevant topics. He sees his role in this team as the
storyteller who will narrate the team’s progress as stories and help
transform tools developed into new opportunities. Gerard has been
involved in language standards, lexicography and terminology. He is
particularly proud of demonstrating how a multilingual dictionary
approach helps people find pictures on Wikimedia Commons. He has
worked on projects to install and update software, medical terminology
with OmegaWiki which is still an ultimate Wiktionary. He has also
translated text and software on translatewiki.net. He predicts that
“languages in non-Roman scripts will do substantially better on the
Internet as we get the word out how easy it is becoming to read and
write. And the team’s projects will be in the forefront of this and
may astound us all.”
I’m proud to welcome this team of very passionate and accomplished
people who have been bold in their many contributions to open source
software. I hope that this team continues to change the landscape of
free and open source language computing tools and help make every
Wikipedia truly open and accessible to all people in all languages.
Feel free to say hello to Santhosh, Niklas, Siebrand and Gerard online
or next time you see them in person :-)
--
Alolita Sharma
Director, Features Engineering
Wikimedia Foundation
I am note sure who might be in a position to correct this, but this list
seems the most likely..
For some reason sep11.wikipedia.org subdomain is forwarding to a spam site -
this was pointed out on OTRS earlier.
I assume this was set up as a redirect to the 9/11 memories Wiki, and that
site has since been taken over.
Can someone fix this?
Tom
On the other hand, if you never clean up cruft, you advance the date at which a rewrite from scratch becomes necessary. Code which hasn't had the entropy removed becomes brittle and hard to understand.
Sent from my Verizon Wireless Phone
-----Original message-----
From: Rob Lanphier <robla(a)wikimedia.org>
To: Wikimedia developers <wikitech-l(a)lists.wikimedia.org>
Sent: Wed, Sep 7, 2011 06:23:45 GMT+00:00
Subject: Re: [Wikitech-l] Can we make the life of extension developers easier?
On Tue, Sep 6, 2011 at 2:05 PM, Brion Vibber <brion(a)pobox.com> wrote:
> Generally speaking, we should only throw warnings or remove old interfaces
> that are actively broken (do not work correctly) or can no longer be sanely
> maintained -- removing a deprecated interface is a fairly extreme step and
> should never be done just to make things look cleaner.
>
> There may be little or even *negative* benefit to going around and changing
> all the calling code to use the new interface. I've seen *lots* of
> regressions in commits that swap something to a new interface without taking
> into account how the interface actually changed, and they're harder to track
> down because the changes are often buried in generic code clean-up.
+1000.
Rob
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l