Last modified: 2007-03-29 20:08:11 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 6340 - SpeciaL:Allmessages filtering to be more consistent, quicker, and user friendlier.
SpeciaL:Allmessages filtering to be more consistent, quicker, and user friend...
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
unspecified
PC All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://ksh.wikipedia.org/wiki/Special...
:
: 7925 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-17 11:45 UTC by Purodha Blissenbach
Modified: 2007-03-29 20:08 UTC (History)
3 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Purodha Blissenbach 2006-06-17 11:45:18 UTC
1. Klicking the button "Show only modified" aka
{{MediaWiki:Allmessagesmodified}} does (after a long while) show only entries
with modifies texts. Klicking a second time reverts to "show all". I suggest to
change the button text to say so.
2. There is no "Show only unmodified" option. I suggest having one, which would
obviously come handy when translating the interface.
1+2: I suggest to combine those selections into radiobuttons, or a
<selext>-structure, with 3 options: "Show all", "Show only modified", "Show only
unmodified"

3. Since one, when translating the interface, might not be interested in changes
made in the previous default language before the translation process started, I
suggest contemplating an additional choice of "Show only (un)modified
before/after 'somedate'" (if that's not too complicated)
(Another way towards this goal might be adding a checkbox to each field, or a
"comments" field, with an option to perform selections against it)

4. The "Message name filter" field should be accompanied by an explanatory text,
saying:
 a. that filtering is case sensitive,
 b. names are matched, when the characters you typed in the form
    appear as a substring anywhere inside the name
 c. you have to type them one by one, waiting for the selection
    according to characters 1..n be made and displayed,
    before typing character (n+1) will be possible,
 d. depending on system type and speed, the script performing each of those
    selections is likely to lock you computer (or Browser) up for minutes,
 e. putting a cursor (back) into the "Message name filter" field will re-start
    the selection proccess, be it necessary, or not,
 f. "Show only modified" will be automatically de-selected by hitting the
    "Message name filter" field, with or without entering data.

5. Since observation 4.f in its present form appears undesirable to me,
   I suggest to either:
   include message name filtering under the abovementioned radio button choices,
   or - my preference - have it act in addition to them.

6. Since observation 4.d appears very undesirable to me, I suggest to add a
   blinking "selection being processed - please wait", or similar, display,
   box, an hourglass, or something else of that kind, while the script is
   perfoming a selection.

7. On multitasking systems, allow other tasks to execute while selections
   are being made.

8. Since 4.c, 4.d, 4.e appear undesirable, I suggest to 
  a. add a checkbox or single radio button to enable/disable
     the selection script,
  b. immediately interupt the script at each character typed
     into the "Message name filter" field, or a klick made
     to any of the other selector fields; restart/continue
     its operatation only if there was a change of parameters,
     or the selection had not been completed already before.
Comment 1 Niklas Laxström 2006-06-17 12:15:40 UTC
The javascript based filtering is going to be removed because of blocking issues
in some browsers. It may or may not be replaced with server side filtering,
depending on how much it is needed.

I have the code on my own wiki, but it's not cleaned up for production use, and
depends on the restructuring of all language files.
Anyway it would solve the technical problems you mentioned (message name
filtering would be removed to make way for more usefull settings).
Comment 2 Rob Church 2006-06-17 12:47:26 UTC
Please don't file reports where the summaries contain negative language like
that again, ever. It's downright offensive and implies a lack of care and
concern, which is certainly not the case.
Comment 3 Purodha Blissenbach 2006-06-17 14:50:49 UTC
Understood. 
These are the filters I use most often while translating:
- "displayed" or "final" message content (I use browser "search" on the
Special:Allmessages HTML page)
- "raw" mesage content (I use browser "search" on the Special:Allmessages PHP page)
in either case, some target strings, e.g. "talk", cannot be located since they
appear too often elsewhere in the page.

- not yet translated? (look up by hand)

Also very helpful would be:
- selection by "field of application", "context", or target page, so as to
translate contextual message snippets in their respective context,
- a means to inspect and verify pages that the wiki with its curent data base,
installation, etc. does not display, e.g. "there is no article in this wiki",
"cannot ...XYZ... because wgXYZ was not selected", "data base access timed out",
etc.

@Rob Church: btw. I am restoring the Summary text to my original, which had been
replaced by Niklas Laxström with comment #1.
If there is an offense in it, it's purely unintentional. Please amend if you
feel so.
Comment 4 Niklas Laxström 2006-06-17 15:04:25 UTC
My apologies.
Comment 5 Ilmari Karonen 2006-12-16 20:16:27 UTC
*** Bug 7925 has been marked as a duplicate of this bug. ***
Comment 6 Ilmari Karonen 2006-12-16 20:18:11 UTC
The responsiveness of the javascript filter should be somewhat improved by
r18373; the main improvement is, paradoxically enough, a delay that keeps the
filter from kicking in until you stop typing for half a second. Unfortunately,
there's no getting around the basic fact that Special:Allmessages is a huge
page, and any changes to it take a while to render.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links