Updating strings for FlaggedRevs for the Flagged Protection/Pending Revisions/Double Check launch

List overview All Threads
Download

newer

older

Bugzilla Weekly Report

Wikimania 2010: Call for...

Rob Lanphier

22 May 2010 22 May '10

8:13 p.m.

Hi everyone, I'm preparing a patch against FlaggedRevs which includes changes that Howie and I worked on in preparation for the launch of its deployment onto en.wikipedia.org . We started first by creating a style guide describing how the names should be presented in the UI: http://en.wikipedia.org/wiki/Wikipedia:Flagged_protection_and_patrolled_rev… Then we sat down and did the string substitution. I've got some double checking left to do, but it's pretty much ready for deployment. I've put the patch here for now: https://bugzilla.wikimedia.org/show_bug.cgi?id=23623 The original plan that Aaron and I hatched up was that I would check in the changes into trunk, and then he would fix. However, seeing the"FlaggedRevs - Do you forget about other projects? " thread on foundation-l gave me pause: http://lists.wikimedia.org/pipermail/foundation-l/2010-May/thread.html#58577 We fully recognize that the strings we plan to use on en.wikipedia.orgprobably don't make sense in a lot of different contexts, even English language wikis. We really want to get this release out the door, but we don't want to leave a huge mess in the process. Is there an expedient but correct-enough approach to solving this problem? Rob

Show replies by date

Roan Kattouw

22 May 22 May

10:51 p.m.

2010/5/22 Rob Lanphier <robla(a)wikimedia.org>rg>:

...

We fully recognize that the strings we plan to use on en.wikipedia.orgprobably don't make sense in a lot of different contexts, even English language wikis. We really want to get this release out the door, but we don't want to leave a huge mess in the process. Is there an expedient but correct-enough approach to solving this problem?

This was suggested on foundation-l by Chad, but I'll repeat it here: reuse messages as little as possible. If you're using the word "foobar" in two slightly different meanings and think other languages might want to translate each instance differently, use two different messages with the same English content. This allows translators (and sysops customizing stuff in the MediaWiki: namespace) to use different translations for each of them. Roan Kattouw (Catrope)

Rob Lanphier

23 May 23 May

1:18 a.m.

On Sat, May 22, 2010 at 1:51 PM, Roan Kattouw <roan.kattouw(a)gmail.com>wrote;wrote:

...

Hi Roan, Let me make sure I understand your proposal by walking through an example that's actually in the patch: "revreview-hist-basic" In an old version, this was "sighted revision". In the current version, it's "checked revision". In the proposed new version, it's "accepted revision". That particular message is used in quite a few places in the code: ./specialpages/ReviewedVersions_body.php:69: : wfMsgHtml( 'revreview-hist-basic' ); ./FlaggedRevs.hooks.php:108: 'sightedRev' => wfMsgHtml( 'revreview-hist-basic' ), ./FlaggedArticleView.php:635: : 'revreview-hist-basic'; ./FlaggedArticleView.php:813: : 'revreview-hist-basic'; ./FlaggedArticleView.php:1306: : 'revreview-hist-basic'; ./FlaggedArticleView.php:1318: : 'revreview-hist-basic'; ./FlaggedArticleView.php:1332: : 'revreview-hist-basic' This, of course, isn't the norm, but it isn't exceptionally rare, either. A typical use of this in context: ./FlaggedArticleView.php-1303- if ( $oldRevQ !== false ) { ./FlaggedArticleView.php-1304- $msg = $oldRevQ ./FlaggedArticleView.php-1305- ? 'revreview-hist-quality' ./FlaggedArticleView.php:1306: : 'revreview-hist-basic'; ./FlaggedArticleView.php-1307- } else { ./FlaggedArticleView.php-1308- $msg = 'revreview-hist-draft'; ./FlaggedArticleView.php-1309- } ./FlaggedArticleView.php-1310- $form .= "<td width='50%' align='center'>"; It seems what you're suggesting is the following: Step 1. Simply leave revreview-hist-basic as "checked revision" (or even go back to "sighted revision") Step 2. Create a new revreview-hist-accepted, setting it to "accepted revision" Step 3. ? This is where I get a little fuzzy. What would you suggest at this point (proposal A or B)? Proposal A: Step 3. Put in an if($wgYetAnotherGlobal) statement, using revreview-hist-basic or revreview-hist-accepted based on the value of that global ...or Proposal B: Step 3. Replace revreview-hist-basic with revreview-hist-accepted unconditionally. Proposal A seems to make the code pretty complicated, and is a pretty big change in aggregate. There are a lot of strings that need that treatment. Proposal B doesn't buy us much, and the cost is much higher than simply replacing the strings. Rob

Thomas Dalton

1:47 a.m.

On 23 May 2010 00:18, Rob Lanphier <robla(a)robla.net> wrote:

...

It seems what you're suggesting is the following: Step 1. Simply leave revreview-hist-basic as "checked revision" (or even go back to "sighted revision") Step 2. Create a new revreview-hist-accepted, setting it to "accepted revision" Step 3. ?

No, that's not the suggestion at all. As I understand it, your new version doesn't use the phrase "checked revision" at all, so there is no need to have a message saying it. The suggestion is that if "accepted revision" is used to mean two slightly different things (so might be translated in two different ways) in different places, there should be two messages both set to "accepted revision" with each message used for a particular meaning of the phrase. I can't think of an example and I'm not sure there are any for this particular feature, but it is a good general principle to keep in mind with any MediaWiki interface work.

Rob Lanphier

2:17 a.m.

On Sat, May 22, 2010 at 4:47 PM, Thomas Dalton <thomas.dalton(a)gmail.com>wrote;wrote:

...

On 23 May 2010 00:18, Rob Lanphier <robla(a)robla.net> wrote:

It seems what you're suggesting is the following: Step 1. Simply leave revreview-hist-basic as "checked revision" (or even

back to "sighted revision") Step 2. Create a new revreview-hist-accepted, setting it to "accepted revision" Step 3. ?

The problem as I understand it is this. Other wikis (e.g. German, Polish) are using FlaggedRevs as originally designed, with many different flags corresponding to "sighted", "quality", "accuracy" and so on. The proposed implementation on English Wikipedia is binary: either an article is accepted or its not. Many strings in the English version were changed to correspond to this usage. Enter bug 23615: https://bugzilla.wikimedia.org/show_bug.cgi?id=23615 Quoting the issue:

...

About one and a half years ago, when we enabled on pl.wiki FlaggedRevs there was one main idea - we want fight vandalism, but do not exercise editorial control. Moreover, Polish community by introducing FlaggedRevs was convinced for this tool because of the *neutral* vocabulary. There existed keywords like "sighted", "review", "mark"... Now you introduce new keyword like "checked", "approve". I am afraid that this is a very bad idea because many people will think that Wikipedia is controlled by certain people. I would like to call on you to once again reconsider the changes in the interface.

I suppose in this case, there might be a simpler debate about which is a better word: "sighted", "checked" or "accepted", since I think we actually have the same goal here (we don't want to convey anything other than "someone other than an anonymous user gave this a once-over and thought it was ok to display"). That aside, there are other instances where configuration differences actually result in concept differences in the strings (see flaggedrevs-desc for an example). Maybe those instances aren't as common as I'd feared, but I'm still trying to understand what the proposed solution is when we find those cases. Rob

Thomas Dalton

2:36 a.m.

On 23 May 2010 01:17, Rob Lanphier <robla(a)robla.net> wrote:

...

As I understand it, the software has three dimensions (accuracy, depth and style) each with five levels. The fact that the enwiki implementation only uses one of those dimensions and only two of the levels shouldn't really change anything - the other 13 messages are just unused. In hindsight, the number of dimensions and number of levels shouldn't have been hard-coded at all. There just have just been a two dimensional array with the size and contents entirely customisable (either through the message system or a special configuration page). Unfortunately, it is too late for that kind of major change, so we'll just have to ignore the rest of the messages. That shouldn't have any impact on other projects, other than them not being able to rely on English as a default. The message system in this case isn't just being used to translate the interface, it is being used to customise it as well, so defaults are pretty useless anyway.

Tisza Gergo

12:52 p.m.

New subject: [Wikitech-l] Updating strings for FlaggedRevs for the Flagged Protection/Pending Revisions/Double Check launch

Thomas Dalton <thomas.dalton <at> gmail.com> writes:

...

On 23 May 2010 01:17, Rob Lanphier <robla <at> robla.net> wrote:

Both the number and the size of the dimensions is customizable - hu.wikipedia, for example, uses a single dimension with three settings (unreviewed, sighted, featured). There is a meta-dimension with pre-set levels (in the old version: none, sighted, quality, pristine) which is the one taken into account for access permissions/which version to show. How it depends on the manually set dimensions is again customizable; eg. you can set the sighted means accuracy>=1, accessibility>=1, neutrality>=2. Or (which is, I think, what most wikis did) you can have a single manually set dimension with names like "sighted" and have the hardcoded dimension mirror its value.

Gregory Maxwell

2:44 a.m.

On Sat, May 22, 2010 at 8:17 PM, Rob Lanphier <robla(a)robla.net> wrote:

...

"Accepted" might imply that revisions without that flag are not accepted. This isn't actually the case.

Rob Lanphier

3:17 a.m.

On Sat, May 22, 2010 at 5:44 PM, Gregory Maxwell <gmaxwell(a)gmail.com> wrote:

...

On Sat, May 22, 2010 at 8:17 PM, Rob Lanphier <robla(a)robla.net> wrote:

I suppose in this case, there might be a simpler debate about which is a better word: "sighted", "checked" or "accepted", since I think we

actually

have the same goal here (we don't want to convey anything other than "someone other than an anonymous user gave this a once-over and thought

was ok to display").

"Accepted" might imply that revisions without that flag are not accepted. This isn't actually the case.

Hi Gregory, Any debate about the actual terminology we deploy should occur here: http://en.wikipedia.org/wiki/Wikipedia_talk:Flagged_protection_and_patrolle… Thanks Rob Rob

Gregory Maxwell

22 May 22 May

11:09 p.m.

On Sat, May 22, 2010 at 2:13 PM, Rob Lanphier <robla(a)wikimedia.org> wrote:

...

[snip] I'm concerned that the simplified graphical explanation of the process fosters the kind of misunderstanding that we saw in the first slashdot threads about flagged revision... particularly the mistaken belief that the process is synchronous. People outside of the active editing community have frequently raised the same concerns on their exposure to the idea of flagged revisions. Common ones I've seen "Won't people simply reject changes so they can make their own edits?" "Who is going to bother to merge all the unreviewed changes on a busy article, they're going to lose a lot of contributions!" None of these concerns really apply to the actual implementation because it's the default display of the articles which is controlled, not the ability to edit. There is still a single chain of history and the decision to display an article happens totally asynchronously with the editing. The illustration still fosters the notion of some overseeing gatekeeper on an article expressing editorial control— which is not the expected behaviour of the system, nor a desired behaviour, nor something we would even have the resources to do if it were desirable. In particular there is no per-revision analysis mandated by our system: Many edits will happen, then someone with the right permissions will look at a delta from then-to-now and decide that nothing is terrible in the current version and make it the displayed version. It's possible that there were terrible intermediate versions, but it's not relevant. I have created a poster suitable for distribution to journalists http://myrandomnode.dyndns.org:8080/~gmaxwell/flagged_protection.png (Though the lack of clarity in the ultimate naming has made it very difficult to finalize it. If anyone wants it I can share SVG/PDF versions of it).

Gregory Maxwell

23 May 23 May

1:05 a.m.

On Sat, May 22, 2010 at 5:09 PM, Gregory Maxwell <gmaxwell(a)gmail.com> wrote:

...

I have created a poster suitable for distribution to journalists http://myrandomnode.dyndns.org:8080/~gmaxwell/flagged_protection.png

I have revised the graphic based on input from Andrew Gray and others. http://myrandomnode.dyndns.org:8080/~gmaxwell/flagged_protection3.png

Casey Brown

1:25 a.m.

On Sat, May 22, 2010 at 7:05 PM, Gregory Maxwell <gmaxwell(a)gmail.com> wrote:

...

I have revised the graphic based on input from Andrew Gray and others. http://myrandomnode.dyndns.org:8080/~gmaxwell/flagged_protection3.png

That version's a lot better and clearer, for the record, I can actually follow it now. :-) -- Casey Brown Cbrown1023

5081

days inactive

5082

days old

wikitech-l@lists.wikimedia.org

Manage subscription

11 comments

7 participants

tags (0)

participants (7)

Casey Brown
Gregory Maxwell
Roan Kattouw
Rob Lanphier
Rob Lanphier
Thomas Dalton
Tisza Gergo