hi-
i'm hopeful this is the appropriate venue for this topic - i recently
had occasion to visit #mediawiki on freenode, looking for help. i found
myself a bit frustrated by the amount of bot activity there and wondered
if there might be value in some consideration for this. it seems to
frequently drown out/dilute those asking for help, which can be a bit
discouraging/frustrating. additionally, from the perspective of those
who might help [based on my experience in this role in other channels],
constant activity can sometimes engender disinterest [e.g. the irc
client shows activity in the channel, but i'm less inclined to look as
it's probably just a bot].
to offer one possibility - i know there are a number of mediawiki and/or
wikimedia related channels - might there be one in which bot activity
might be better suited, in the context of less contention between the
two audiences [those seeking help vs. those interested in development,
etc]? one nomenclature convention that seems to be at least somewhat of
a defacto standard is #project for general help, and #project-dev[el]
for development topics. a few examples of this i've seen are android,
libreoffice, python, and asterisk. adding yet another channel to this
list might not be terribly welcome, but maybe the distinction would be
worth the addition?
as i'm writing this, i see another thread has begun wrt freenode, and i
also see a bug filed that relates at least to some degree
[https://bugzilla.wikimedia.org/show_bug.cgi?id=35427], so i may just be
repeating an existing sentiment, but i wanted to at least offer a brief
perspective.
regards
-ben
Hi folks,
Short version: This mail is fishing for feedback on proposed work on
Gerrit-Bugzilla integration to replace code review tags.
Long version:
One feature of our old code review system that was a tagging system
that made it quick and easy to assign a keyword to a revision at any
time. There were a number of uses we had for the system, which are
documented here:
http://www.mediawiki.org/wiki/Subversion/Code_review/tags
Examples of tags that we miss:
scaptrap - this change requires special care at deploy time. It may
be that it requires two components to be in sync that aren't generally
deployed in sync, or it requires a configuration change, or something
else.
fixme - this change introduces a bug (weirdly, not in our old
documentation - go figure). In Gerrit, this would be a -1 or -2 if
the code hasn't been merged yet, but post-merge, there's no uniform
way to attach that metadata.
backcompat - backwards compatibility breakers.
This has been a frequently requested feature of the upstream Gerrit
developers. However, they've been reluctant to implement such a
feature until after some unscheduled major architectural work is
completed, so we shouldn't hold our breath waiting for that.
With that in mind, we have bug 38239, assigned to Chad:
https://bugzilla.wikimedia.org/38239
Chad worked up a hacky version of tagging as a MediaWiki extension
earlier this week, which would have kept the tags in MediaWiki instead
of Gerrit. That's only one half of what might be an acceptable
solution, since the other half would need to be some Javascript in the
Gerrit user interface to allow for insertion into the MediaWiki tag
database. I discouraged Chad from continuing on this because it
seemed to me that it would have been a little *too* hacky. I
preferred that if we were going to have our own hacky solution, it
should at least be implemented as a Gerrit plugin, so that it would at
least stand a chance of becoming a well-integrated solution.
The problem with tagging generally, though, is that it ended up being
this weird parallel workflow to other systems. "fixme" was frequently
used as a substitute for filing a bug report. "scaptrap" was a
substitute for proper deployment notes, and "backcompat" was a
solution for proper developer notes. That said, it was lightweight,
which meant that it actually got used, as opposed to many "proper"
solutions, which are frequently enough work that it's difficult to
expect uniform followthrough.
The solution that Chad and I discussed is an addition to the
Bugzilla-Gerrit plugin that Christian is already working on. The idea
would be that, for any given revision, there would be a "file bug
about this revision" link. Following that link would throw to the
standard Bugzilla bug filing page, with as many fields prepopulated
based on Gerrit context as could sensibly be filled (including, at the
very minimum, a link back to the Gerrit rev, but probably also with
the assignee set to the developer who introduced the issue, the
component set based on the repo).
A Bugzilla-based solution would be an ideal replacement for "fixme",
since fixmes are basically bugs anyway. It would work reasonably well
for "scaptrap", since they generally imply something that needs to be
done prior to deployment. It would be an awkward replacement for
"backcompat" and others.
Still, the nice thing about this is that a Bugzilla-based solution is
that it's general purpose enough that it may very well find use
outside of Wikimedia-land. The BZ-Gerrit work is actually being done
as part of a larger issue tracker plugin that the GerritForge folks
have written to support Jira. Filing issues based on revisions is
likely a common request for people integrating Gerrit with their issue
tracking system.
Is a Bugzilla-based solution worthwhile enough for our purposes for a
modest (but probably not insignificant) investment in this area, or
should we prioritize other Gerrit work higher (say, for example, a
native Gerrit tagging plugin)? Assuming we move forward with
development, anything we need to consider?
I've put the bulk of this email on mediawiki.org here:
http://www.mediawiki.org/wiki/Git/Tagging
We should evolve that page into a spec for the work that Chad and
Christian will be doing.
Rob
Hi,
Last November, I started to clean up on the Glossary page on meta, as
an attempt to revive it and expand it to include many technical terms,
notably related to Wikimedia Engineering (see e-mail below).
There were (and are) already many glossaries spread around the wikis:
* one for MediaWiki: https://www.mediawiki.org/wiki/Manual:Glossary
* one for Wikidata: https://www.wikidata.org/wiki/Wikidata:Glossary
* one for Labs: https://wikitech.wikimedia.org/wiki/Help:Terminology
* two for the English Wikipedia:
https://en.wikipedia.org/wiki/Wikipedia:Glossary &
https://en.wikipedia.org/wiki/Wikipedia:WikiSpeak
* etc.
My thinking at the time was that it would be better to include tech
terms in meta's glossary, because fragmentation isn't a good thing for
glossaries: The user probably doesn't want to search a term through a
dozen glossaries (that they know of), and it would be easier if they
could just search in one place.
The fact is, though, that we're not going to merge all the existing
glossaries into one anytime soon, so overlap and duplication will
remain anyway. Also, it feels weird to have tech content on meta, and
the glossary is getting very long (and possibly more difficult to
maintain). Therefore, I'm now reconsidering the decision of mixing
tech terms and general movement terms on meta.
Below are the current solutions I'm seeing to move forward; I'd love
to get some feedback as to what people think would be the best way to
proceed.
* Status quo: We keep the current glossaries as they are, even if they
overlap and duplicate work. We'll manage.
* Wikidata: If Wikidata could be used to host terms and definitions
(in various languages), and wikis could pull this data using
templates/Lua, it would be a sane way to reduce duplication, while
still allowing local wikis to complement it with their own terms. For
example, "administrator" is a generic term across Wikimedia sites
(even MediaWiki sites), so it would go into the general glossary
repository on Wikidata; but "DYK" could be local to the English
Wikipedia. With proper templates, the integration between remote and
local terms could be seamless. It seems to me, however, that this
would require significant development work.
* Google custom search: Waldir recently used Google Custom Search to
created a search tool to find technical information across many pages
and sites where information is currently fragmented:
http://lists.wikimedia.org/pipermail/wikitech-l/2013-March/067450.html
. We could set up a similar tool (or a floss alternative) that would
include all glossaries. By advertising the tool prominently on
existing glossary pages (so that users know it exists), this could
allow us to curate more specific glossaries, while keeping them all
searchable with one tool.
Right now, I'm inclined to go with the "custom search" solution,
because it looks like the easiest and fastest to implement, while
reducing maintenance costs and remaining flexible. That said, I'd love
to hear feedback and opinions about this before implementing anything.
Thanks,
guillaume
On Tue, Nov 20, 2012 at 7:55 PM, Guillaume Paumier
<gpaumier(a)wikimedia.org> wrote:
> Hi,
>
> The use of jargon, acronyms and other abbreviations throughout the
> Wikimedia movement is a major source of communication issues, and
> barriers to comprehension and involvement.
>
> The recent thread on this list about "What is Product?" is an example
> of this, as are initialisms that have long been known to be a barrier
> for Wikipedia newcomers.
>
> A way to bridge people and communities with different vocabularies is
> to write and maintain a glossary that explains jargon in plain English
> terms. We've been lacking a good and up-to-date glossary for Wikimedia
> "stuff" (Foundation, chapter, movement, technology, etc.).
>
> Therefore, I've started to clean up and expand the outdated Glossary
> on meta, but it's a lot of work, and I don't have all the answers
> myself either. I'll continue to work on it, but I'd love to get some
> help on this and to make it a collaborative effort.
>
> If you have a few minutes to spare, please consider helping your
> (current and future) fellow Wikimedians by writing a few definitions
> if there are terms that you can explain in plain English. Additions of
> new terms are much welcome as well:
>
> https://meta.wikimedia.org/wiki/Glossary
>
> Some caveats:
> * As part of my work, I'm mostly interested in a glossary from a
> technical perspective, so the list currently has a technical bias. I'm
> hoping that by sending this message to a wider audience, people from
> the whole movement will contribute to the glossary and balance it out.
> * Also, I've started to clean up the glossary, but it still contains
> dated terms and definitions from a few years ago (like the FundCom),
> so boldly edit/remove obsolete content.
--
Guillaume Paumier
Technical Communications Manager — Wikimedia Foundation
https://donate.wikimedia.org
Hi,
is there already a schedule to update jQuery and jQuery UI to 1.9 or are
there problems at moment? I want to use the new tooltip widget of jQuery UI
1.9 [1].
Best regards,
Jan
[1] http://jqueryui.com/tooltip/
We have a first write up of how we plan to support queries in Wikidata.
Comments on our errors and requests for clarifications are more than
welcome.
<https://meta.wikimedia.org/wiki/Wikidata/Development/Queries>
Cheers,
Denny
P.S.: unfortunately, no easter eggs inside.
--
Project director Wikidata
Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin
Tel. +49-30-219 158 26-0 | http://wikimedia.de
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hi, we at the mobile team are currently working on improving our
current hit rate, publishing the half-implemented plan here for review:
== Current status ==
* X-Device header is generated by frontend Varnish from user-agent.
* There are currently 21 possible X-Device values, which we decreased to 20
this week.
* X-Device is used for HTML variance (roughly, Vary: X-Device).
* Depending on X-Device, we alter skin HTML, serve it full or limited
resources.
* Because some phones need CSS tweaks and don't support media queries, we
have to serve them device-specific CSS.
* Device-specific CSS is served via separate ResourceLoader modules e.g.
mobile.device.android.
== What's bad about it? ==
Cache fragmentation is very high, resulting in ~55% hit rate.
== Proposed strategy ==
* We don't vary pages on X-Device anymore.
* Because we still need to give really ancient WAP phones WML output, we
create a new header, X-WAP, with just two values, yes or not[1]
* And we vary our output on X-WAP instead of X-Device[2]
* Because we still need to serve device-specific CSS but can't use device
name in page HTML, we create a single ResourceLoader module,
mobile.device.detect, which outputs styles depending on X-Device.[2] This
does not affect bits cache fragmentation because it simply changes the way
the same data is varied, but not adds the new fragmentation factors. Bits
hit rate currently is very high, by the way.
* And because we need X-Device, we will need to direct mobile load.php
requests to the mobile site itself instead of bits. Not a problem because
mobile domains are served by Varnish just like bits.
* Since now we will be serving ResourceLoader to all devices, we will
blacklist all the incompatible devices in the startup module to prevent
them from choking on the loads of JS they can't handle (and even if they
degrade gracefully, still no need to force them to download tens of
kilobytes needlessly)[3]
== Commits ==
[1] https://gerrit.wikimedia.org/r/#/c/32866/ - adds X-WAP to Varnish
[2] https://gerrit.wikimedia.org/r/55226 - main MobileFrontend change
[3] https://gerrit.wikimedia.org/r/#/c/55446/ - ResourceLoader change, just
a sketch of a real solution as of the moment I'm writing this
Your comments are highly appreciated! :)
--
Best regards,
Max Semenik ([[User:MaxSem]])
I put together the 1.21.0rc1 this afternoon. I'll announce it shortly,
but, first, some observations.
* When you add or remove a configuration variable, it should have
release notes. When you update the release notes, please make sure that
you also update MW.o. A number of variables are mentioned in the
release notes that don't have a corresponding page on MW.o. The
following configuration variables are the currently redlinked on
<https://www.mediawiki.org/wiki/Release_notes/1.21>. If you can update
their on-wiki documentation, I (and I'm sure others) would appreciate it.
** $wgBug34832TransitionalRollback
** $wgEnableCanonicalServerLink
** $wgPageInfoTransclusionLimit
** $wgMaxShellWallClockTime
** $wgShellCgroup
** $wgSquidPurgeUseHostHeader
** $wgDebugAPI
** $wgAPIGeneratorModules
* Should the breaking changes be consolidated to a single section of the
release notes? Right now, they are in three different sections. I
think they should be moved to the top of their section at the very least
(I did this on-wiki).
* There remains one pending change that is not in the 1.21 release
candidate -- "Password Recovery system uses Tokens" -- because it hasn't
been merged into core yet. This change will probably have to wait until
1.22, but I'll leave it on https://www.mediawiki.org/wiki/MediaWiki_1.21
for now.
--
http://hexmode.com/
[We are] immortal ... because [we have] a soul, a spirit capable of
compassion and sacrifice and endurance.
-- William Faulker, Nobel Prize acceptance speech
I would like to announce the release of MediaWiki language extension
bundle 2013.03
This release is compatible with MediaWiki 1.20.3.
* https://translatewiki.net/mleb/MediaWikiLanguageExtensionBundle-2013.03.tar…
* sha256sum: be4c6b5f80e27396555dc09cef0cec92c78cca9eeef796a230da281734738810
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.
Amir E. Aharoni
== Babel ==
Only localization updates.
== cldr ==
=== Highlights ===
* Adding support for time units
=== Noteworthy changes ===
* (bug 38209) Remove duplicate array keys
== CleanChanges ==
Only localization updates.
== LocalisationUpdate ==
Internal code cleanup and optimization, making updates faster.
== Translate ==
=== Highlights ===
==== Translation UX ====
The new Translation UX is getting out of the beta status and becoming
release-ready.
The variable $wgTranslateUseTux can be used to control which interface
will the users see by default. The default value is true. Set it to false
to make the old green-style translations editor show by default. The user
can choose the editor version by adding tux=0 or tux=1 to the URL.
The plan is to remove the old editor in the future.
==== Other notes ====
Several internal fixes were made in File Format Support (FFS) and in core
Translate features, but no new features were introduced. See below for details.
=== Noteworthy changes ===
==== Translate UX ====
* Proofreading view added to Translate UX.
* Page view added to Translate UX. It is similar to the default "List" view,
but it gives every message more space and partially parses the messages rather
than show them as plain text.
* Added a "Discard changes" button.
* Various visual design adjustments.
* (bug 45493) Do not consider empty string to mark a translation as "unsaved"
* (bug 45481) Move focus to search for the project selector
* (bug 45488) Remove delay in enablement of "save translation" button
* Allow inserting a translation from the helper language with a click
* Workflow state selector is now only shown for groups with states
and the correct state is shown
==== File Format Support ====
* (bug 45354) XML for Android export should have escaped ' and "
* (bug 42635) Some GettextFFS messages were not unfuzzied on import:
Handling of external changes only affecting the fuzzy flag are now
handled properly on import
* Add fuzzy support to AndroidXmlFFS
* Don't create empty files in AndroidXmlFFS
* Empty msgctxt is now exported correctly in GettextFFS
* (bug 42612) Have PythonSingleFFS observe the supplied mapping
of internal language codes to product language codes
==== Other ====
* The "Recent Additions" filter displays only relevant messages -
without optional,
ignored and discouraged.
* Converted the logging code to the new LogFormatter
* (bug 44328) Do not display fuzzy translations on translation pages
* Fix and speed up translatable pages moving
* (bug 45345) Run mapped code through wfBCP47()
== UniversalLanguageSelector ==
=== Highlights ===
UniversalLanguageSelector is updated to the latest version. The latest
release of MediaWiki 1.20 supports the recent updates for the preferences
handling, and this allows users properly save their ULS preferences.
=== Noteworthy changes ===
==== Display and design ====
* (bug 42384) Don't show the tooltip if the ULS panel is on
(preventing the overlap)
* (bug 42440) Fix button state when canceling
* Styling of settings to fit the bottom of the ULS
* (bug 43568) Languages are shown multiple times
* (Bug 42439) Incorrect vertical alignment for Telugu web font
==== Webfonts ====
* Support for the Amiri webfont in the standard Arabic language (ar).
* Added the Alef font for Hebrew.
* Add Tuladha Jejeg font for Javanese
==== Other ====
* (Bug 42378) Make "disable IME tools" effects immediate as a preview
* Update jquery.uls and make it more modular
* Provide a base ULS RL module and separate UI language selection
* The non-standard language code als now redirects to the standard code gsw.
--
Amir Elisha Aharoni ። אָמִיר אֱלִישָׁע אַהֲרוֹנִי
Localization developer ። מְפַתֵּחַ תְּמִיכָה רַב־לְשׁוֹנִית
Wikimedia Foundation ። קֶרֶן וִיקִימֶדְיָה