As the subject implies, there is a variable named $wgDBmysql5. I am
inclined to believe that the purpose of this variable is to use features
only available in MySQL 5.0 or later. The specific implementation affects
the encoding in the database.
https://www.mediawiki.org/wiki/Manual:$wgDBmysql5
Right now MediaWiki installation requirements say you need MySQL 5.0.2 or
later. So my question is: is this configuration variable still necessary,
or should it be deprecated?
*-- *
*Tyler Romeo*
Stevens Institute of Technology, Class of 2016
Major in Computer Science
Bumping my proposal. I am particularly looking forward from responses from
community members.
Have an awesome New Year's Eve!
Best,
Diederik
Heya,
I just posted an initial proposal to start running a biweekly showcase to
feature all the cool things that are happening on Labs. Please have a look
at https://wikitech.wikimedia.org/wiki/Showcase, express your interest and
chime in on the Talk page to help get this off the ground.
Best,
Diederik
I was getting very bored of the tedious job of working out what to code
review and then how to pull it down so I made a tool in the MobileFrontend
repository which lets me do all this from the comfort of the command line
[1]. With the script (and a couple of python installs as referenced in the
command line) you simply run:
> make gerrit
and it prints a list of options
http://imgur.com/e5JBnQI
Simply type the number of the commit you want to review and it will pull it
down for you.
The list of reviews is ordered by the following mechanism (could be
tweaked):
* Patches closest to being merged appear at top e.g. +1s at top, -2s at
bottom
* If patches are of equal code review score, the old ones get preference as
that only seems fair.
It currently doesn't allow you to do reviews from the command line but that
would be a pretty awesome addition.
Let me know your thoughts.
[1] https://gerrit.wikimedia.org/r/#/c/103884/
Hello,
Happy New Year to all!
I would like to announce the release of MediaWiki Language Extension
Bundle 2013.12. This bundle is compatible with MediaWiki 1.21.3 and
MediaWiki 1.22.0 releases.
* Download: https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.12.tar…
* sha256sum: 2ef19e31d685dd0d6e50088ec8bbb1cd3e74c694096dfa333efb61dcfee9c3c0
Quick links:
* Installation instructions are at: https://www.mediawiki.org/wiki/MLEB
* Announcements of new releases will be posted to a mailing list:
https://lists.wikimedia.org/mailman/listinfo/mediawiki-i18n
* Report bugs to: https://bugzilla.wikimedia.org
* Talk with us at: #mediawiki-i18n @ Freenode
Release notes for each extension are below.
-- Kartik Mistry
== Babel, CLDR and LocalisationUpdates ==
* Only localization updates.
== CleanChanges ==
* Bug 58439: Fix Monobook skin by removing extra
<nowiki></div></nowiki> creating invalid HTML.
* Localization updates.
== Translate ==
=== Noteworthy changes ===
* Translator Sandbox:
** Translator Sandbox is a feature to simplify the sign-up process for
new translators. It can be enabled using "$wgTranslateUseSandbox =
true;", but it will only be useful in conjunction with the
TwnMainPage, which is not included in MLEB (at least yet).
** Stash and translator approval pages are now usable.
** When a user is accepted, a bare-bones user page with a Babel box is created.
* TUX editor:
** Bug 53748: Message group related calls were made two order of
magnitudes faster, making Special:Translate's group selector, workflow
state selector etc. fast enough even on wikis with hundreds or
thousands groups.
** Add useful shortcuts to TUX editor. All buttons to insert/replace
text (insertables and then translation aids in order; "discard
changes" is skipped) are numbered from 1 up and can be accessed with
both alt+<num> and arrow up and down.
** Update the statusbar at the bottom of the TUX message tables when
saving or proofreading.
* Added support to MediaWiki localisation format from PHP files to
JSON files. This is part of the Localization Format RFC (
https://www.mediawiki.org/wiki/Requests_for_comment/Localisation_format
).
** Add support for JSON in mediawiki-defines.txt, allowing the
handling of MediaWiki extension that us the new format. Documentation
about the updates in MessageGroup configuration can be found at:
https://www.mediawiki.org/wiki/Help:Extension:Translate/Group_configuration…
** Fixed JsonFFS for properly importing and exporting Authors.
** targetPattern in group configuration is now optional.
** Migrate the Translate extension itself to JSON based i18n files
from PHP files. This change is transparent to all users of extension.
* Support xliff 1.1 files in addition to xliff 1.2 as well, but
without validation.
=== Breaking changes ===
Special:FirstSteps has been removed from Translate. If you want the
feature, you'll have to download it separately.
== UniversalLanguageSelector ==
=== Noteworthy changes ===
* Language selector now opens an order of magnitude faster (see
https://github.com/wikimedia/jquery.uls/pull/122 for details).
* Initial support for webfonts in MobileFrontend:
** Currently, support for webfonts in MobileFrontend is disabled by
default. It can be enabled by setting $wgULSMobileWebfontsEnabled =
true; in LocalSettings.php file. Note that, even then it will only be
enabled for users who has opted in for the mobile beta mode.
=== Fonts ===
* Bug 57767: Enable Amiri font for Soranî language.
* Bug 58381, 58382: Add Lateef and Scheherazade fonts for Soranî and
Farsi languages.
* Update Autonym font to version 20131205:
** Fixed Autonym for Old Slavonic.
** Fixed glyphs for the Glagolitic script.
** Removed Reserved Font Name (RFN) and documentation updates.
--
Kartik Mistry/કાર્તિક મિસ્ત્રી | IRC: kart_
{kartikm, 0x1f1f}.wordpress.com
Hi, Google Code-in is about to start:
http://www.google-melange.com/gci/homepage/google/gci2013https://www.mediawiki.org/wiki/Google_Code-In
We have currently 72 tasks published and 13 mentors. We are still
looking for more mentors and tasks. If you are interested, contact me.
This is the first time Wikimedia participates in this program and the
only certain prediction at this point is that we all will learn a lot.
We have been warned that especially the first two weeks will be quite
messy, with many impatient newcomers landing in our community channels
and asking for help / feedback / review. Please be kind with them.
Things will eventually settle down, partially because our documentation
will be better, partially because the students interested in Wikimedia
will be familiar with the basics and will know where/how to ask.
Ideally https://www.mediawiki.org/wiki/Google_Code-In should contain
answers and links to answers for the frequently asked questions. Try to
answer GCI students with links to the appropriate pages, and try to
assure that such links are available at our GCI wiki page.
Thank you for your patience. I have no doubt that your direct or
indirect help will pay off with better documentation for all kinds of
newcomers interested in many areas of contribution.
/me goes to prepare a hot beverage. It is going to be fun.
--
Quim Gil
Technical Contributor Coordinator @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
Lately someone deleted 70 pages from the middle of several thousand page
Russian encyclopedia used by Wikisource. Everything was done by the
book: since the uploader forgot to add a license and did not fixed the
issue when notified. However deletion was done without checking the
licenses in the other pages from the book. See
https://commons.wikimedia.org/wiki/User_talk:Lozman#Copyright_status:_Fi
le:.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B8.D0.B9_.D1.8D.D0.BD.D1.86.D0.B8.D
0.BA.D0.BB.D0.BE.D0.BF.D0.B5.D0.B4.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.B8.D
0.B9_.D1.81.D0.BB.D0.BE.D0.B2.D0.B0.D1.80.D1.8C_.D0.91.D0.B5.D1.80.D0.B5
.D0.B7.D0.B8.D0.BD.D0.B0_4.2_001.jpg
<https://commons.wikimedia.org/wiki/User_talk:Lozman#Copyright_status:_F
ile:.D0.A0.D1.83.D1.81.D1.81.D0.BA.D0.B8.D0.B9_.D1.8D.D0.BD.D1.86.D0.B8.
D0.BA.D0.BB.D0.BE.D0.BF.D0.B5.D0.B4.D0.B8.D1.87.D0.B5.D1.81.D0.BA.D0.B8.
D0.B9_.D1.81.D0.BB.D0.BE.D0.B2.D0.B0.D1.80.D1.8C_.D0.91.D0.B5.D1.80.D0.B
5.D0.B7.D0.B8.D0.BD.> .
I am ready to undelete the pages, but run into the problem that
apparently there is no mass undeletion tool for cases like that. Is
there a faster method than doing it by hand?
Jarek T.
(user:jarekt <http://commons.wikimedia.org/wiki/User:Jarekt> )
Hello,
As many of you might be aware, etherpad.wikimedia.org has been
migrated a couple of months ago from the old and no longer supported
etherpad software to the new, actively supported, etherpad-lite
software. The move also involved the migration of pads from the old
software to the new, a process which was quite successful, albeit not
without glitches. Since then the old installation has been kept around
under http://etherpad-old.wikimedia.org in a read-only state in order
to facilitate people to access pads that, for whatever reason, may not
have made it to the new installation unscathed (or at all). This
service will be discontinued and taken offline on Monday, 30 December
2013. That grants 30+ days to people to copy out any necessary pads.
With that in mind, the operations team would like to remind everyone
that etherpad.wikimedia.org was never intended to be a permanent
storage for pads. Preservation of a pad is up to the people interested
in preserving that pad in another format.
Regards,
--
Alexandros Kosiaris <akosiaris(a)wikimedia.org>
Heya,
We are making good progress with creating clusters to group RFC for the
upcoming Architectural Summit. Some clusters are still too big, in
particular the following clusters can/should be split in smaller clusters
of 3-4 RFC's each.
* General Mediawiki Functionality
* Backend code modularity frameworks
* Installation
* SOA
* UI/UX: styling
Please have a look at
https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_clusters and
help us finalize the clustering!
Thanks!
Best,
D
Hi everyone,
It would be extremely useful to have summaries for all RFC clusters[1]
similar to the one I provided yesterday[2] for HTML templating. No,
I'm not volunteering :-)
As Diederik mentioned, we're going to have to figure out some way of
prioritizing all of the RFC clusters in advance of the Architecture
Summit. One way I believe we should gauge interest in these things is
by whether or not someone has taken the time to write the summary, and
what level of on-list response that summary gets. It's certainly not
the sole means or even most important, but it's indicative of whether
or not sufficient effort has been put into the online conversation.
In general, the Architecture Summit is not meant as a replacement for
mailing list conversation. It's meant as a means of accelerating
conversations that are already happening on list, but need more than
email conversation to push them more quickly to resolution.
Therefore, it makes sense to prioritize the RFC clusters that are
being talked about.
Guidelines for writing these: be fair and reasonably generous to the
authors of the RFCs. We're not shooting for encyclopedic NPOV, so
it's ok and perhaps even helpful to state what you believe the various
viewpoints are.
It may also be the case that we got the organization wrong, and that a
cluster of RFCs don't actually belong together as a cluster. If
that's the case, it would be good to highlight as part of going
through these.
Anyone willing to help out with writing summaries?
Rob
[1] https://www.mediawiki.org/wiki/Architecture_Summit_2014/RFC_Clusters
[2] "RFC cluster summary: HTML templating":
http://thread.gmane.org/gmane.science.linguistics.wikipedia.technical/74544