Page MenuHomePhabricator
Search Advanced Search
    • Task
    [10:52] <p858snake|l> installing LQT strips </small> out of sigs but not <small> so it plays with the page display [10:52] <p858snake|l> ^ werdna [10:52] <p858snake|l> s/installing/intresting/ -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    There is an option "E-mail me on replies to a thread I am watching" in Special:preferences. Unlike the other e-mail options, this option is not disabled (greyed) when a user did not have an e-mail adderss set, or the e-mail address is not confirmed. Behavior of these options should be consistent. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://translatewiki.net/wiki/Special:Preferences
    • Task
    Current Lqt version shows all actions in the menu, for example including "drag to new location" which only logged-in users can perform. After trying to perform the drag and drop action, users see the error message "permission denied" in the last moment - instead of telling them this when starting the action. I suggest to grey out actions for which the current user does not have sufficient rights. -------------------------- **Version**: unspecified **Severity**: major
    • Task
    This bug doesn't seems to happen often, but I've noticed the following error after trying to submit a new reply to a thread: Uncaught TypeError: Cannot read property 'query' of null I was using Google Chromium 12.0.742.112 (90304) Ubuntu 11.04. -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    By default, users are warned if they try to leave a page while they're editing it. This doesn't appear to apply if you're replying to a LiquidThreads post. This seems like inconsistent interface behavior. Based on a report at http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Suggestion_to_warn_user_when_leaving_page -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    I don't know if this was already reported but the extension shouldn't let users to (accidentally) submit duplicated posts (something which is common when the internet connection is slow), such as this http://www.mediawiki.org/wiki/Thread:Talk:Article_feedback/Delete/reply_(18) -------------------------- **URL**: http://www.mediawiki.org/wiki/Thread:Talk:Article_feedback/Delete/reply_(18)
    • Task
    Would be handy on "busy" pages such as http://www.mediawiki.org/wiki/Talk:Article_feedback for example. -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    LQT currently breaks talk refactoring, which is essential in many ways (because this is a fundamental feature of wiki discussions, I consider this a bug and not a feature request). The problem has many aspects so this could be some sort of tracking bug and perhaps the discussion should happen on wiki (there have been many but I can't find all of them; I hope they weren't deleted with the special test wiki). -------------------------- **Version**: unspecified **Severity**: major **URL**: http://www.mediawiki.org/wiki/Talk:LiquidThreads_3.0#Keep_refactoring_possible
    • Task
    Category at bottom As you see in the screenshot, a category included in a thread is shown at the bottom of Special:NewMessages because http://translatewiki.net/wiki/Thread:Support/About_MediaWiki:Smw_qc_query_help/en includes it (in the first message); in the example, the thread wasn't even shown on the page because it had been marked as read. See also bug 24110. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F7935}
    • Task
    Export of one of the discussion threads (this is page ID 803932 in huwiki_p): https://secure.wikimedia.org/wikipedia/hu/wiki/Speciális:Lapok_exportálása/Téma:Szerkesztővita:Dencey/Fölösleges_információk/válasz_(3) contains invalid (truncated) probably UTF-8 for the thread poster signature. Hexdump of the export page reveals: 00000be0 74 3b 67 72 65 65 6e 26 71 75 6f 74 3b 20 66 61 |t;green&quot; fa| 00000bf0 63 65 3d 26 71 75 6f 74 3b 4c 75 63 69 64 61 20 |ce=&quot;Lucida | 00000c00 63 61 6c 6c 69 67 72 61 70 68 79 26 71 75 6f 74 |calligraphy&quot| 00000c10 3b 26 67 74 3b ce 93 ce bf cf 85 ce b2 ce b2 ce |;&gt;...........| 00000c20 bf cf 82 20 ce 98 ce b9 ce bb ce bf ce 3c 2f 54 |... .........</T| 00000c30 68 72 65 61 64 53 69 67 6e 61 74 75 72 65 3e 0a |hreadSignature>.| 0xCE byte at offset 0x00000c2a should be followed by at least one more byte to get a correct UTF-8 encoding. XML dump process fails silently - the last page in those dumps: http://download.wikimedia.org/huwiki/20110531/huwiki-20110531-pages-articles.xml.bz2 http://download.wikimedia.org/huwiki/20110614/huwiki-20110614-pages-articles.xml.bz2 is page ID 803931, after this there is no XML so whole dump is a non-valid XML. It gets compressed via bzip2, though. This problem was reported on the pywikipedia mailing list by Bináris: http://thread.gmane.org/gmane.comp.python.pywikipediabot.general/11335 -------------------------- **Version**: unspecified **Severity**: major **URL**: https://hu.wikipedia.org/wiki/Speci%C3%A1lis:Lapok_export%C3%A1l%C3%A1sa/T%C3%A9ma:Szerkeszt%C5%91vita:Dencey/F%C3%B6l%C3%B6sleges_inform%C3%A1ci%C3%B3k/v%C3%A1lasz_%283%29 **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=47885
    • Task
    Screenshot of Liquidthreads where the text includes an unsolved {{int:...}} reference. It should not be output verbatim, but do its job before the referenced string is output. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://translatewiki.net/w/i.php?title=Special:NewMessages&offset=14514&limit=25 **Attached**: {F7794}
    • Task
    This bug was initially created as a clone of Bug #29200; Brion wrote: Workarounds for failures to handle error conditions in the JavaScript code exist. The error info from the dieUsage appears to perfectly correctly make it back to the 'doneCallback' function in 'handleAJAXSave' (via the actual call in liquidThreads.doNewThread ). However, doneCallback tries to handle error conditions by submitting the same form as non-Ajax in the hopes that that code path will show an error as well, which apparently isn't ending up having the expected results. It should instead probably show the error message directly.....? Does this need more general or more specific handling for particular kinds of errors that we can't report back cleanly through this interface? -------------------------- **Version**: unspecified **Severity**: major **URL**: http://www.mediawiki.org/wiki/Extension:LiquidThreads
    • Task
    http://www.mediawiki.org/wiki/Thread:Extension:LiquidThreads/FAQ/Edit_button Someone reported: "Is there a way to put the [edit^] and [History^] buttons on the top of the page as tabs. I understand that the point in threads is to allow for discussion, however moving the buttons from their standard position makes it harder for people to use the page. I'd be willing to modify my source code if you could give me a hint at where the change might be located." I fully support this idea and filed this as enhancement bug. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://www.mediawiki.org/wiki/Thread:Extension:LiquidThreads/FAQ/Edit_button
    • Task
    The page to show and possibly restore a deleted thread lacks the thrads subject headline. Thus it may be necessary to restore it, just in order to find out that it is not about the intended theme and it gets deleted again at once. I expect the subject to be shown as well as the treads contributions. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: https://translatewiki.net/w/i.php?title=Special:Undelete&target=Thread%3ASupport%2FWikia%3AAutocreatewiki-blurry-word%2Fen&timestamp=20110429144216
    • Task
    Screenshot of Liquidthreads where buttons and links at the left extend into the text of contributions causing them to overlap. The shot is from Konquerer under Linux, other browsers overlap less. -------------------------- **Version**: unspecified **Severity**: minor **OS**: Linux **URL**: https://translatewiki.net/wiki/Special:NewMessages **Attached**: {F7448}
    • Task
    ( ! ) Notice: Undefined property: WikiImporter::$nodeType in /home/reedy/mediawiki/trunk/extensions/LiquidThreads/classes/Hooks.php on line 614 Call Stack # Time Memory Function Location 1 0.0000 645264 {main}( ) ../index.php:0 2 0.0190 3772640 MediaWiki->performRequestForTitle( ) ../index.php:104 3 0.0198 3975576 MediaWiki->handleSpecialCases( ) ../Wiki.php:63 4 0.0205 4310384 SpecialPage::executePath( ) ../Wiki.php:246 5 0.0248 4506496 SpecialImport->execute( ) ../SpecialPage.php:608 6 0.0474 6315648 SpecialImport->doImport( ) ../SpecialImport.php:67 7 0.6129 8103600 WikiImporter->doImport( ) ../SpecialImport.php:126 8 0.6190 8103976 WikiImporter->handlePage( ) ../Import.php:371 9 0.6201 8117880 wfRunHooks( ) ../Import.php:480 10 0.6201 8117880 Hooks::run( ) ../Hooks.php:38 11 0.6202 8140312 call_user_func_array ( ) ../Hooks.php:237 12 0.6202 8140928 LqtHooks::handlePageXMLTag( ) ../Hooks.php:0 When trying to import from Enwiki to my dev wiki -------------------------- **Version**: unspecified **Severity**: minor
    • Task
    When editing pieces of threads with Liquidthreads, the button 'Show Changes' below the edit window seems to randomly be shown or not shown. For one snippet, and one editing process, it seems constantly to be there or not, no matter, how often you use it, or how often you use preview. So it may appear, even if you started a new message, and it may be missing, when you are altering an existing one. -------------------------- **Version**: unspecified **Severity**: minor **URL**: https://translatewiki.net/wiki/Support#MediaWiki:Useractivity-gift_12014 See also: * {T94356}
    • Task
    The "Mark thread as read" button has an undo button. Like it, we should have an undo button for "Mark all as read" as well. It is pretty easy to accidentally click the wrong buttons since "Mark thread as read" for the topmost thread and "Mark all as read" nearly touch each other, and time consuming JavaScripts move screen contents around for quite a while without signalling when done, so one may assume that this phase was over before it really is, and thus involuntarily click the place which will later be occupied by the wrong button. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Some search suggestions I got on enwikinews: :Comments:Curfew imposed in Jammu and Kashmir, three injured and four killed/Comments from feedback form - "security men? i think u mean p..." :Comments:Hong Kong 'tutor king' applies for bankruptcy/Comments from feedback form - "nice.." They should be prefixed with Thread. I got these when I started typing Comments into the search box (So really its questionable if thread namespace things should show up at all). If I start typing thread into the box, I get the pages being prefixed with "thread:" as appropriate. -------------------------- **Version**: unspecified **Severity**: minor
    • Task
    The URL given above fails sometimes with out of memory error: [13/Mar/2011:10:37:06 +0000] "GET /w/i.php?title=Project:Translator&offset=20110227192534&limit=100 HTTP/1.1" 500 0[13/Mar/2011:10:37:18 +0000] "GET /w/i.php?title=Project:Translator&offset=20110227192534&limit=100 HTTP/1.1" 500 3183 -------------------------- **Version**: unspecified **Severity**: major **URL**: https://translatewiki.net/w/i.php?title=Project:Translator&offset=20110227192534&limit=100
    • Task
    If the wiki is set to read only, when you try and do a reply/add new post, it just sits there attempting to load it, with the spinning loader thingy... -------------------------- **Version**: unspecified **Severity**: minor
    • Task
    Screenshot of Liquidthreads where in the center a "signature" and the link list following it overlap. The "Signature" and links at the end of a contribution overlap on screen. See attached screen shot. -------------------------- **Version**: unspecified **Severity**: minor **Attached**: {F7152}
    • Task
    Each time when I select "mark as read" on a thread on the page "new messaegs (some number)" of my personal user-specific links, the page is redisplayed and both paging and scrolling are started from the newest thread. Since I do not mark newer threads as read before having read then, and I read them in roughly chronologial order, I have to page back to where I was before, then scroll down to where I was before, and continue reading. With several 100 threads and messages, this is extremely time consuming. I spend a magnitude more time waiting for pages to be sent to me just to immediately go to the next page, and scrolling down than actually reading. Unfortunately I do not have a choice to avoid using this extension, else I would. Thus I suggest to enhance paging in a way allowing to jump to specific pages/threads/messages, e.g. via a numbered list of links, or a set of number input fields such as: Go to page [__] thread [__] message [__] Of course, these numbers should be shown on the pages, next to the threads and messages. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Each time when I select "mark as read" on a thread on the page "new messaegs (some number)" of my personal user-specific links, the page is redisplayed and both paging and scrolling are started from the newest thread. Since I do not mark newer threads as read before having read then, and I read them in roughly chronologial order, I have to page back to where I was before, then scroll down to where I was before, and continue reading. With several 100 threads and messages, this is extremely time consuming. I spend a magnitude more time waiting for pages to be sent to me just to immediately go to the next page, and scrolling down than actually reading. Unfortunately I do not have a choice to avoid using this extension, else I would. Thus I suggest to include a table of contents in the personal page, so as to avoid the need of scolling to threads. Since impersonal threaded pages have one already, I believe, this would be pretty easy to do. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://translatewiki.net/w/i.php?title=Special:NewMessages&lqt_method=undo_mark_as_read&lqt_operand=4806,4809,4817,4818
    • Task
    Each time when I select "mark as read" on a thread on the page "new messaegs (some number)" of my personal user-specific links, the page is redisplayed and both paging and scrolling are started from the newest thread. Since I do not mark newer threads as read before having read then, and I read them in roughly chronologial order, I have to page back to where I was before, then scroll down to where I was before, and continue reading. With several 100 threads and messages, this is extremely time consuming. I spend a magnitude more time waiting for pages to be sent to me just to immediately go to the next page, and scrolling down than actually reading. Unfortunately I do not have a choice to avoid using this extension, else I would. Thus I suggest to include the parameters of the respective next or previous thread in the "Mark as read" link. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://translatewiki.net/w/i.php?title=Special:NewMessages&lqt_method=undo_mark_as_read&lqt_operand=4806,4809,4817,4818
    • Task
    Please repeat the "Mark as read" button link at end of each list. You usually decide to mark a series of messages as read once you've read it, and you usually are at the end of a list once you've read it. Having to scoll back for marking them read is a waste of time. I also suggest to convert this link to a real link. Making it a pseudo button or button lookalike was a bad design decision, imho. If it was a link, one could use the "open in another window/tab" feature of browsers having that, and continue reading with other messages unmolested from pages with newly arranged lists of message popping up, while otherwise one has to wait for them to display which is another real waste of time. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://translatewiki.net/w/i.php?title=Special:NewMessages&lqt_method=undo_mark_as_read&lqt_operand=8796
    • Task
    **Author:** `Nx.devnull` **Description:** Here are the steps to reproduce this bug, bear with me: 1. Disable javascript 2. Open a talk page in two tabs in your browser. 3. Click "reply" on the same comment in both tabs 4. Type something in both tabs 5. In one tab, click save page, wait for the comment to be saved. Make sure you bump the thread. 6. In the other tab, click show preview. After this, the thread you were replying to will not be shown (including the edit form), which means you just lost your comment. I've tracked down the bug to LqtDiscussionPager::getRows(). The problem is that this function calls a mysql query that selects all root threads where thread_sortkey<offset, where offset is the timestamp of the latest comment when you clicked reply. However, since the thread has since been bumped, the root comment now has a sortkey larger than this timestamp, so it won't be selected. -------------------------- **Version**: unspecified **Severity**: major
    • Task
    Currently when you visit an article page you can only see if any discussion was started or not. It would be more efficient if I could see whether any new replays or topics where made since my last visit to the talk page (if I'm logged in) and it could be indicated with a star or something. Note that this is something most reasonable dashboard has. As I'm aware the above might be very resource consuming and maybe not the most import thing... The main thing I'm proposing here is an indicator of how many unanswered topics are there on the talk page. This info could be easily cached and update upon creation of a new topic and reply to the topic. It could be displayed as a number in brackets on the talk tab (with a span title saying what this number mean). -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Document LQT code. Flicking through it, there is a lot of code without function level documentation, both parameters and return types. And with similarily named items (thread class and the threads class), it gets confusing following the hierarchy. When Ariel logged bug 26673, it made it quite hard to try and check the call tree of the line: $attribs['ThreadParent'] = $thread->superThread()->title()->getPrefixedText(); -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    See r79941 -------------------------- **Version**: unspecified **Severity**: minor
    • Task
    **Author:** `Nx.devnull` **Description:** If you have javascript disabled, clicking on the unwatch link in the thread header doesn't work. It just takes you to a default thread view without unwatching the thread. I'm attaching a modified pages/ThreadWatchView.php that fixes this. -------------------------- **Version**: unspecified **Severity**: minor
    • Task
    Since the target is (almost?) always an existing page, it would be nice to have autocompletion for the target field. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    **Author:** `quentinv57` **Description:** Hello, I tried to bypass liquid thread extension by going simply to the following page (as I needed to edit the whole page and not a specific thread) : http://liquidthreads.labs.wikimedia.org/w/index.php?title=User_talk:Quentinv57&action=edit I performed the edit I needed to perform, and now, when I click on the "History" button, I find an empty history : http://liquidthreads.labs.wikimedia.org/w/index.php?title=User_talk:Quentinv57&lqt_method=talkpage_history To say it differently, the history should take editions with no thread into account too. You can contact me on http://meta.wikimedia.org/wiki/User_talk:Quentinv57 if needed. Thanks. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    In twn we have this to prevent spam: $wgGroupPermissions['*' ]['create'] = false; However LQT doesn't handle it very well, it keeps asking captcha when trying to save. It should say it is not possible, or allow posting replies to threads regardless. -------------------------- **Version**: unspecified **Severity**: major **URL**: https://www.mediawiki.org/wiki/Thread%3AExtension_talk%3ALiquidThreads/Allow%20anonymous%20to%20post%20to%20liquid%20thread
    • Task
    I'm logged out and browsing around TranslateWIki. Going to http://translatewiki.net/wiki/Support#Archive_page_7623 and clicking Reply on a reply, then typing some words, clicking preview, and then clicking preview again. From this point on whenever I click preview again (all clicks, except the first one) cause two spin loaders to appear (two <div class="mw-ajax-loader"/> elements ). instead of one -------------------------- **Version**: unspecified **Severity**: minor
    • Task
    **Author:** `llampak` **Description:** Say we've got such a hierarchy of threads: head * 1 ** 1.1 * 2 We want simply to flatten it. head * 1 * 1.1 * 2 It's a pretty likely scenario, as people on forums of such a tree hierarchy often answer to answers, instead of to the original message. We simply want to correct someone else's mistake. It turns out to be not that simple. If you click "drag to new location" at 1.1, the only possible "dropspots" are: <drop here> head * <no dropspot here> * 1 * <no dropspot here!!!> ** 1.1 - the one we're dragging ** <drop here> (redundant one! - does nothing if you try it) * <no dropspot here> * 2 ** <drop here> * <drop here> <drop here> Technically you can do it dragging all of the threads around but it takes a lot of time and effort. Another example would be a simple reordering of threads at the same level. Again, it's possible but not easy. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Currently, even if a user add `__NOINDEX__` to its talkpage, all threads created on it are *still indexed* by search engines, since the extension creates each commont in a different page (where the user can only add the magic word *after* the topic was created). The same happens for other pages (not only user talk pages). For privacy reasons, this shouldn't happen. Specifically, the users should *not* be requested to add `__NOINDEX__` to zillions of comments in order to get all of them not being indexed. See also: * {T93657}
    • Task
    After a user created a Thread[1] and then removed it's content and inserted it in the Thread's summary, I wanted to merge the new content back to the history of Thread's page and for this, I've used [[Especial:MovePage]], whithout leaving a redirect behind, and deleting the existing Thread page when I was asked (so that I could restore it and merge the history of both pages, as described in [[Wikipedia:How to fix cut-and-paste moves]]). The problem is: when I went to the Thread page (following the link from "successful move" message), it showed the message ---- *No such thread* The thread you specified does not exist. ---- instead of the content which was previously in the summary page. This should not happen. Nevertheless, going to the history of the non existent Thread, I could see the message ---- View or restore 2 deleted edits? ---- (together with the previous one), and so I was able to restore the page. After restoring the deleted edits, the history[5] is ok, showing all edits (both from Thread and it's summary). [1] http://pt.wikibooks.org/wiki/T%C3%B3pico:Usu%C3%A1rio_Discuss%C3%A3o:Helder.wiki/Wikilivro_Profiss%C3%B5es_pelo_mundo%27. [2] http://pt.wikibooks.org/w/index.php?title=Resumo:Usu%C3%A1rio_Discuss%C3%A3o:Helder.wiki/Wikilivro_Profiss%C3%B5es_pelo_mundo%27.&redirect=no&action=edit&redlink=1 [3] http://pt.wikibooks.org/wiki/T%C3%B3pico:Usu%C3%A1rio_Discuss%C3%A3o:Helder.wiki/Wikilivro_Profiss%C3%B5es_pelo_mundo%27.?uselang=en [4] http://pt.wikibooks.org/w/index.php?title=T%C3%B3pico:Usu%C3%A1rio_Discuss%C3%A3o:Helder.wiki/Wikilivro_Profiss%C3%B5es_pelo_mundo%27.&action=history&uselang=en [5] http://pt.wikibooks.org/w/index.php?title=T%C3%B3pico:Usu%C3%A1rio_Discuss%C3%A3o:Helder.wiki/Wikilivro_Profiss%C3%B5es_pelo_mundo%27.&action=history&uselang=en -------------------------- **Version**: unspecified **Severity**: major
    • Task
    Screenshot of this bug After I've edited the comment http://pt.wikibooks.org/wiki/T%C3%B3pico:Wikilivros:Di%C3%A1logos_comunit%C3%A1rios/Imagens_usadas_no_projeto/resposta_%284%29 and changed from it's Firefox tab to another I got the following error in Firebug: data.query.threads[threadId] is undefined http://pt.wikibooks.org/w/extensions/LiquidThreads/lqt.js?283y Line 555 -------------------------- **Version**: unspecified **Severity**: minor **URL**: http://pt.wikibooks.org/wiki/T%C3%B3pico:Wikilivros:Di%C3%A1logos_comunit%C3%A1rios/Imagens_usadas_no_projeto/resposta_%284%29 **Attached**: {F7124}
    • Task
    After moving the page of a topic using [[Special:MovePage]] and marking the option "Leave a redirect behind", it is shown a confirmation of the page move. If we click in the link to the old location of the page (that with &redirect=no) it shows the message "The thread you specified does not exist.": http://pt.wikibooks.org/w/index.php?title=T%C3%B3pico:Wikilivros:LiquidThreads/Testes/resposta_(4)&redirect=no&uselang=en But the redirect do exist and is shown for example at http://pt.wikibooks.org/w/index.php?title=Especial:%C3%8Dndice+por+prefixo&prefix=Wikilivros:LiquidThreads/Testes/resposta+(4)&namespace=90 -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=25866
    • Task
    This is similar to Bug 24850, but this time it happens when moving a page from thread namespace using a bot account: the move should be marked with "b" in recent changes. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://pt.wikibooks.org/w/index.php?title=Especial%3ARegisto&type=move&user=&page=Tópico%3AWikilivros%3ADiálogos+comunitários%2FQue+tipo+de+avisos+devemos+colocar+no+Site+Notice%3F%2Fresposta+(2)&year=&month=-1&tagfilter=&uselang=en
    • Task
    On the example, only the parameter "preload" is working. The other two are not. This should be fixed. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: https://pt.wikibooks.org/wiki/Project:Diálogos_comunitários?action=edit&section=new&preloadtitle=MediaWiki:aboutsite&preload=MediaWiki:aboutsite&editintro=MediaWiki:aboutsite&uselang=en
    • Task
    There is a Link "create new topic" on the page: http://translatewiki.net/wiki/Support/Archive/2009/9 Since this is an archive page, the Link should be avoided. Currently, it looks like there is no way to do that, at least no response to the question regarding that at: http://translatewiki.net/wiki/Support#Archive_page_7623 -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://translatewiki.net/wiki/Support/Archive/2009/9
    • Task
    It would be cool if, when a thread were collapsed, there was a link on each entry in the mini-summary that would have the effect of uncollapsing that particular post and jumping to it. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    The thread collapsing disclosure indicator currently takes up its own line, which wastes vertical whitespace. It would be cool if we could float those left instead. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Deletion of the first post of a thread triggers deletion of the entire thread; undeletion doesn't do the same, as it should to be consistent (example: http://strategy.wikimedia.org/w/index.php?title=Special:Log&dir=prev&offset=20100906064357&limit=4&user=Nemo+bis ). You can argue that undeletion will be less common that deletion (for vandalism etc.), so I'm marking this as low priority. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Some talk or requests pages are necessarily very big. Apart from the absurd [[WP:AN/I]], the usual solution is to subpage them. LQT, to be really useful, should allow to easily manage such pages. Beside bug 25054 and especially until bug 20542 has not been fixed, it would be useful to be able to show only the TOC of bigger talk/requests pages, to avoid loading of full text still allowing to quickly see all recent threads. An example of system that should be replaced by this one is it.wiki's village pump ([[it:Wikipedia:Bar]]), where every discussion has its subpage and the main page contains only an index of recent discussions, updated by bot ([[it:Template:Bar3/titoli/0]] and so on: several thousands of edits per year which could be avoided by LQT with an automatic, configurable index). This could be also a sort of workaround for bug 21690 and bug 25054 (if the index dimension could be set by date and not only number of threads). If you was able to tranclude the TOC of other talks, this would also reduce the importance of bug 20542. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Bug 20961 has been fixed, but it should also be possible to set per-page how old the last included thread should be (e.g., 7 days). It makes sense that on some pages you show all recent discussions, even if they're many, because they all need the same attention (e.g. [[WP:AN/I]] and similar pages or the village pump), espcially if you can't mark a thread as closed/resolved (see also bug 24815). -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Especially on older pcs the expanding takes a while. Maybe reduce the duration to 100ms or even just 0ms? -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Obviously an accessibility problem -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    When using text based browser, such as lynx, it's not clear who responded to whom; the menus create alot of redundant space & some menu options are not usable -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    ...maybe arrange the links in a smaller font horizontally? -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    A screenshot of a protected LiquidThreads thread. After a thread is protected in LiquidThreads, the only text that changes for admins is the "[Protect]" link becoming "[Unprotect]". There should be a better warning for admins that they're editing a protected thread. Screenshot attached. -------------------------- **Version**: unspecified **Severity**: normal **Attached**: {F6853}
    • Task
    A screenshot of LiquidThreads summary view not using explanatory text above the old thread. This is somewhat related to bug 24967. When you go to summarize a thread currently, it loads a new page and below the main textarea it puts the content of the thread. This should be labeled with some explanatory text. Screenshot attached. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://liquidthreads.labs.wikimedia.org/w/index.php?title=Thread:Talk:Randompage1234/New_discussion&lqt_method=summarize&lqt_operand=2592 **Attached**: {F6848}
    • Task
    When you click "summarize" next to a thread, it doesn't use AJAX editing. Instead it loads a new page currently. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    A screenshot of the LiquidThreads signature input not working correctly. When you go to a page like http://liquidthreads.labs.wikimedia.org/w/index.php?title=Talk:Randompage1234&lqt_method=talkpage_new_thread the signature input is always in wikitext and there's no preview option. This is broken. Usually the signature input area will show the rendered signature and have a "preview" or "edit" link next to it. Screenshot attached. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://liquidthreads.labs.wikimedia.org/w/index.php?title=Talk:Randompage1234&lqt_method=talkpage_new_thread **Attached**: {F6840}
    • Task
    **Author:** `theevilipaddress` **Description:** Similar to the bug # 24621 (but IMO not exactly the same), I feel that when you move a thread to another page, and then you delete the complete old page, then there should be nothing on this page anymore, and not any placeholders left. I have encountered this issue today when moving a thread here http://translatewiki.net/wiki/Translating_talk:Wikia/Vet-metacafe_should_use_PLURAL A user had used a wrong syntax and I fixed it. I deleted the completely unnecessary redirect, but there's still a placeholder left. This should really just all go away and the page should be like every new page. Also, I'm missing a deletion log entry on this page, as it's common for all other pages. Yes, it may be a bit pointless, but for consistency and usability it should really be there. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://translatewiki.net/wiki/Translating_talk:Wikia/Vet-metacafe_should_use_PLURAL
    • Task
    The main strength of LQT is also its weakness: potentially you can reply to a five-years old huge thread and bump it to the top of the talk page and to lots of users' Special:NewMessages. Currently, users won't reply to old discussions because if you read only the page and not the history you don't find easily new messages on old sections, which are less visible; and you are actively discouraged from replying to archived discussions because nobody looks at the archives and to revive a thread you should de-archive it (and you can't). With LQT, you may even not notice that a thread is archived: try e.g. [[strategy:Thread:Talk:Task force/Wikipedia Quality/Quick update]], where the only hint you have is that "From Task force/Wikipedia Quality/Archive 1" under the title (warning! the talk page is huge – I always get an unresposive script error); and obviously if old threads are just put in some "next page" you are not supposed to move them in a subpage. Summarizing could help, but not every thread will be summarized. I think that users should be discouraged from replying threads which: are more old than x; or are e.g. in the third page (assuming 10 threads per page); or have been summarized with a consensual ssummary; or have been closed with some new "thread status" feature. Please note that due to bug 24814 it's currently impossible to completely archive and protect a talk page. In fact I wrote this as an example of that bug, but it's a separate issue. There's already a discussion on this at http://www.mediawiki.org/wiki/Thread:Talk:LiquidThreads/Redesign/Discussion_status , I think thaat we can continue there and leave this bug here as placeholder (if you wish). -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Looks like there isn't a way to protect (or semiprotect) completely a talk page with LiquidThreads, e.g. an archived talk: even if you use [edit=sysop] [move=sysop] [newthread=sysop] [reply=sysop] [cascading] , users will be able to edit existing replies (but not to summarize threads, if my test was correct). I haven't tried all the other possibile actions, but I think that at least cascading protection (or something similar) should block them all. Otherwise, it's impossible to protect pages from vandalism and even from good faith edits; while currently, if you archive a page, you put the archive in your watchlist and if someone edits it you will see it immediately; with threads it isn't so easy, although I don't remember if watchlisting a talk page will watchlist every included thread). -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    If you are in a Thread: page and you want to link a specific post, currently you can either: use the "link to" button under "more", but this gives you a link to a page where only that post is included, so you can't scroll up/down to see other posts; or arrive at this page and click the "From ..." link under the page title, which brings you to the thread with an anchor to the post; or search a child post and use "parent" button. To avoid cluttering the interface and following [[mw:LiquidThreads/Redesign]] and e.g. the interface proposed in [[mw:File:Lqt-thread-full.png]], I would suggest to use that arrows as a place where hovering the mouse would provide you an anchor link to the post, like ¶ links which appears hovering Sphinx page headers (random example: http://docs.python.org/howto/regex.html ). More problems with relative links: bug 23382, bug 24082; another suggestion for "link to" button in bug 24627. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Maybe put text in <input>s and select text automatically when the <input>s get focus. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    **Author:** `theevilipaddress` **Description:** When you move a thread to another page, a placeholder always remains at the old page where it has been. However, unlike other threads on the page, it's not deletable. While it may be good to keep them around usually, it should at least be possible to delete them since they clutter the page and the table of contents and some users might not like them. Furthermore, on some wikis, it's common practice to delete unnecessary move leftovers. For example, on the German language Wikipedia, there's an own bot that puts speedy deletion templates on all talk page redirects and move artifacts with a parentheses title. Some time ago, a bot used to delete about 300 user talk subpage redirects leftovers from userspace drafts. Thus, a delete option would be useful, even though you might not want to encourage deleting them. -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    I watch pages that use liquid threads so that I see new discussions that appear on them, this means that I automatically watch all threads on that page and get notifications about new replies to all of them. I am not interested in every discussion that takes place though, so I would like an ability to unwatch a specific thread, while still watching other existing and new threads on that page. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=40665
    • Task
    **Author:** `avarab` **Description:** Related to bug 24178, when you move a thread from FOO -> BAR you get a redirect on FOO, so your forum on FOO will be: = My thread Moved to BAR blah blah But and on BAR: = My thread The original content However, if you then decide to change your mind and move "My thread" back from BAR -> FOO you end up with this: = My thread The original content = My thread Moved to BAR blah blah I.e. there are now 2 threads under the same name, the now-broken redirect and the original. -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    **Author:** `avarab` **Description:** I'm using the following hack for this: Index: lqt.js =================================================================== --- lqt.js (revision 68624) +++ lqt.js (working copy) @@ -141,13 +141,13 @@ // Update signature editor $j(container).find('input[name=wpLqtSignature]').hide(); - $j(container).find('.lqt-signature-preview').show(); - var editLink = $j('<a class="lqt-signature-edit-button"/>' ); - editLink.text( wgLqtMessages['lqt-edit-signature'] ); - editLink.click( liquidThreads.handleEditSignature ); - editLink.attr('href', '#'); - $j(container).find('.lqt-signature-preview').after(editLink); - editLink.before(' '); + // $j(container).find('.lqt-signature-preview').show(); + // var editLink = $j('<a class="lqt-signature-edit-button"/>' ); + // editLink.text( wgLqtMessages['lqt-edit-signature'] ); + // editLink.click( liquidThreads.handleEditSignature ); + // editLink.attr('href', '#'); + // $j(container).find('.lqt-signature-preview').after(editLink); + // editLink.before(' '); } var finishSetup = function() { It'd be nice if there were a $wg variable I could set to disable signature editing. The motivation is to make the forum idiot proof. -------------------------- **Version**: unspecified **Severity**: major **See Also**: {T34096}
    • Task
    Talk page bottom with same category shown three times I've inserted a category in the talk header, in a thread summary and in a single message: it works (the single thread isn't summarized actually and it looks so, but this isn't a big issue), but the category is shown three times. This bug would be really annoying in the case of subpaged threads (e.g. subpaged village pumps with a page for each day with multiple threads in it, where every day and every thread is categorized, as e.g. in it.wiki or it.news, and where we will hopefully have transcluded threads, see http://liquidthreads.labs.wikimedia.org/wiki/Thread:Feedback/No_way_to_multi-home_a_thread%3F#No_way_to_multi-home_a_thread.3F_855 ). Example: see URL and attachment. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://liquidthreads.labs.wikimedia.org/wiki/Long_Threads **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=21268 https://bugzilla.wikimedia.org/show_bug.cgi?id=20542 **Attached**: {F6642}
    • Task
    If you click on the history tab from a thread (reply) page, the history page it goes to is broken. Steps to reproduce Goto (for example): http://en.wikinews.org/w/index.php?title=Thread:Comments:Russia_agrees_to_construct_Turkish_nuclear_reactor/Classic_Russian_Strategy/reply_(2) Click the history tab at the top of page. this goes to: http://en.wikinews.org/w/index.php?title=Thread:Comments:Russia_agrees_to_construct_Turkish_nuclear_reactor/Classic_Russian_Strategy/reply_(2)&lqt_method=thread_history This page has a table saying no results. Expected behaviour: Either the history link would go to http://en.wikinews.org/wiki/Thread:Comments:Russia_agrees_to_construct_Turkish_nuclear_reactor/Classic_Russian_Strategy/reply_(2)?action=history or http://en.wikinews.org/w/index.php?title=Thread:Comments:Russia_agrees_to_construct_Turkish_nuclear_reactor/Classic_Russian_Strategy&lqt_method=thread_history or the table on the history page would display results for that particular reply (or both). I'm unsure if the display of the thread contents below the history table is intentional or not. Note: the history link from the "more" link is fine. This is only for the history tab at the top of the page. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://en.wikinews.org/w/index.php?title=Thread:Comments:Russia_agrees_to_construct_Turkish_nuclear_reactor/Classic_Russian_Strategy/reply_(2)&lqt_method=thread_history
    • Task
    While having each post be a new page is helpful for deletion purposes I think it would be highly beneficial to not have them marked as such. Looking at a users contributions and seeing a flood of N's which are all talk page discussions increases the noise ratio to a point that it can be very very hard to find the real page creations (or for that matter other edits). -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    The accesskey in the title element of the buttons like "save" or "preview" is shown without the browser specific keys like "shift-alt" (Firefox on Windows) Bug 23456 could be related. -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    When writing a long text, and press preview, the resulting box has no scroll bar. When save that long text, the scroll bar is around the box. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: https://test2.wikipedia.org/wiki/Thread:Talk:Main_Page/Another_Test_Thread
    • Task
    Clicking link for parent does nothing but add an ID to the URL, and stays on the same page when watching a single post. Steps to reproduce: 1. Go to http://translatewiki.net/wiki/Thread:Support/Special:NewMessages_doesn%27t_work_for_me/reply_%284%29?uselang=en 2. Click "Parent" Observed: URL changes to http://translatewiki.net/wiki/Thread:Support/Special:NewMessages_doesn%27t_work_for_me/reply_%284%29?uselang=en#Special:NewMessages_doesn_t_work_for_me_3214 and parent is not visible Expected: parent becomes visible somehow. Other information: full thread is http://translatewiki.net/wiki/Thread:Support/Special:NewMessages_doesn%27t_work_for_me -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://translatewiki.net/wiki/Thread:Support/Special:NewMessages_doesn%27t_work_for_me/reply_%284%29?uselang=en
    • Task
    Currently if you delete a thread, the success message prompts you to return to the Main Page. I think it would be more logical for it to return to the page that contained the thread. Thanks, Bawolff -------------------------- **Version**: unspecified **Severity**: minor
    • Task
    as the title says -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    This happens in TranslateWiki. Special:Version there says "Version 2.0-alpha r64515". Message only becomes read after i click the "Mark as read" button. I would expect that it would be automatically marked as read after i view it, but it stays unread even after i reply to it. See also: http://translatewiki.net/wiki/Thread:Support/Messages_stay_unread -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    **Author:** `mike.lifeguard+bugs` **Description:** Per discussion on IRC: Showing edits to [[Thread:Feedback/Stopping bad signatures?/Mike.lifeguard (4)]] when the user "really" (from their point of view) edited [[Talk:Feedback]] is quite confusing. Lines in contribution lists and the like should be forged to look like section edits on the page where discussion was taking place: # (show/hide) 03:27, 5 November 2009 (hist | diff) N Thread:Feedback/Stopping bad signatures?/Mike.lifeguard (4) ‎ (Reply to Stopping bad signatures and other untraceable vandalism) (top) [rollback] becomes something like # (show/hide) 20:53, 2 March 2010 (hist | diff) m Talk:Feedback (→Stopping bad signatures? Reply to Stopping bad signatures and other untraceable vandalism) (top) [rollback] This is possibly a better approach than what's been done for RecentChanges, but is essentially the same idea. All forged lines should look the same though - one format for RC and another for contribution lists wouldn't be good. In an ideal world, even LQT history pages would use the same format as well, rather than the (eww!) table. This would provide a continuity of experience that's currently lacking, in addition to hiding ugly implementation details which are currently confusing. -------------------------- **Version**: unspecified **Severity**: enhancement **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=36096
    • Task
    On wikinews we are getting some people trying to create pages of the form [[n:Al shabaab ondiscussionpage:Comments:Somali opposition group al-Shabaab to block WFP food aid]]. As far as i can tell, people go to the opinion page, [[n:Comments:Somali opposition group al-Shabaab to block WFP food aid]], see the search discussion box right beside the create a new discussion link. They assume that text box is to start a new discussion, instead of search. They enter a title, hit enter, go to search page which has the: Create the page "Foo ondiscussionpage:Comments:Somali opposition group al-Shabaab to block WFP food aid" on this wiki! link. They click that, thinking thats how you enter a comment. This causes problems as thats not where we want people to create their comments. -------------------------- **Version**: unspecified **Severity**: normal **URL**: http://en.wikinews.org/w/index.php?title=Al_shabaab_ondiscussionpage:Comments:Somali_opposition_group_al-Shabaab_to_block_WFP_food_aid **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=21102
    • Task
    As the name says. Steps to reproduce: 1. Create a thread. 2. Reply to that thread. 3. Delete the reply. 4. View the thread history for the thread. 5. Click on the revision in which the reply was deleted. 6. Click on the "This thread" link in the change description. Expected behaviour: Link takes you to the deleted thread's page, allowing options for administrators to view its content. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    **Author:** `cbm.wikipedia` **Description:** When Liquidthreads displays content loaded via AJAX, any dynamic CSS that was created for the content will not be displayed. Example: create a new thread. Post a reply to it that invokes the SyntaxHighlight_Geshi extension (by using the source tag). When the response is first saved, the CSS to colorize the syntax will not be loaded, so the source code will be in black and white. When the page is reloaded, the CSS is added to the page HEAD element, and the source code will be colorized. This is related to bug 22061, but I haven't investigated the liquidthreads code. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    If there are long thread titles, the thread index stretches and the timestamps in the "last modified" column often look goofy with linebreaks. white-space:nowrap; should be applied to the column. It looks as though it will need its own <span> to do this. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    This is a feature request that has a little to do with workflow. In my e-mail box, I both mark messages for follow-up, but often I quickly scan a message and then mark it unread again for later follow-up. After working with Lqt for a few weeks, I rarely visit talk pages anymore. Anything I want to see from my watchlist will just be on Special:NewMessages. If I have read the new contribs to a thread** I just mark it read, and it's gone until there is new activity in it. But if I do come across an interesting topic on a non-watched page, I would like to be able to put that thread on my NewMessages page to later reading (and not only get updates from then on). I think this is not possible with the current version (or is it?). ** hmm, thinking of it, I cannot see which posts are new and which I have read - might be nice to visually indicate that (with a style?) -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    When you reply to a LiquidThreads thread, regardless of whether "watch this page" is checked, it will add the thread to the watchlist. This is broken. See also: bug 21732 ("LiquidThreads has confusing interaction with "watch" feature") -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    When a user replies to a LiquidThreads thread, the checkbox says to "watch this page." I don't know if that's supposed to be "watch this thread," or if that just means you'll now be watching the discussion header talk page thing. This is confusing. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    http://liquidthreads.labs.wikimedia.org/wiki/Thread:Talk:Testttttttttting/New_thread!/reply_(2) When you go the URL and click the "thread" tab, you're not taken to the thread, you're just linked to the specific reply. This is confusing and wrong. -------------------------- **Version**: unspecified **Severity**: normal
    • Task
    Example oldid (pulled from the IRC recentchanges feed): http://liquidthreads.labs.wikimedia.org/w/index.php?oldid=1821&rcid=1899 When you click that link, there's no way to get back to the entire thread and the talk page link isn't apparent (it's currently only the "discussion" tab). It needs a breadcrumbs trail. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    The thread action links "History Move Protect Unwatch Summarize" need tooltips (currently they have title=""). -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    When the page http://translatewiki.net/wiki/Support has been altered from a normal talk page, its content has been broken into several pages. That is counterproductive when searching for something. With the newly introduced screen clutter, it is now extremely hard and time consuming to find something anyways. Average processing times of finding answers to ones questions went up some 700 % to 30.000 % depending somewhat on how long ago answers were given, and other random things. This page is extremely unproductive now. Scattering everything over several pages makes thing only worse - needlessly. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://translatewiki.net/wiki/Support
    • Task
    Instead of paging LiquidThreads pages (or as a backup for it), we should use infinite scrolling. It feels much smoother and nicer. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Issues [[http://liquidthreads.labs.wikimedia.org/wiki/Thread:Feedback/Remove_username_(and_number_of_replies)_from_page_titles|raised at the URL]] (now broken). **See Also**: *{T20526}
    • Task
    General suggestion made by Kate on the feedback wiki. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://liquidthreads.labs.wikimedia.org/wiki/Thread:Feedback/New_messages_link **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=20541
    • Task
    Otherwise we fill up the page and people have to hunt for the relevant threads. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    As the description says :) -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Lqt in Modern skin At translatewiki.net we use the Modern skin as standard. I have found that the current the current .lqt-command line-height of 2em (which works perfectly fine in Vector and MonoBook) should really be 0 for it to work properly. Is there a way to get CSS fed from the extension based on the skin used? I have attached a screenshot of the current layout which isn't too pretty. -------------------------- **Version**: unspecified **Severity**: enhancement **URL**: http://translatewiki.net/wiki/Support?useskin=modern **Attached**: {F6184}
    • Task
    If a Lqt header contains a template that for example parses to "text" and this requires "{{text}}", then the link to the topic will contain {{text}} while the header directly above the topic text read "text". This is inconsistent behaviour I would like to see fixed. See http://translatewiki.net/wiki/Support for examples. -------------------------- **Version**: unspecified **Severity**: major **URL**: http://translatewiki.net/wiki/Support **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=57153
    • Task
    **Author:** `Bernhard.Fastenrath` **Description:** It is conceivable that somebody might want to transclude a page containing a LiquidThreads discussion. This leads to two different discussions: One on the subpage and one on the transcluding page. This is not likely to be what the user expects and can cause confusion. On the other hand it seems convenient to turn a complex talk page into multiple groups of discussions using subpages. Activating LiquidThreads is then another step that is bound to be reinvened frequently (an anti-pattern one could say). An example for such a use (but not currently containing any LiquidThreads discussions) is: http://strategy.wikimedia.org/wiki/Talk:Emerging_strategic_priorities/ESP_1_key_questions -- You may be subject to mental influences from the http://en.wikiversity.org/wiki/Topic:Post-information_society -------------------------- **Version**: unspecified **Severity**: minor **URL**: http://strategy.wikimedia.org/wiki/Thread:Village_pump/_:Template:Question/Fasten_(5) **See Also**: https://bugzilla.wikimedia.org/show_bug.cgi?id=24110 https://bugzilla.wikimedia.org/show_bug.cgi?id=20542
    • Task
    With modern browsers, changes to forms are kept in the history, so you can just click back and get your text back. If we dynamically load the edit form, then this doesn't work anymore. We should look into how we might fix this. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Why do it just for watched threads? Should be easy in theory if and only if we store ONLY the read stati, not the unread stati (that'd be kinda ridiculous). Would also need some AJAX mechanism to tell the server when we've read a message. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Spin-off of bug 20660. Also implement or piggyback on the watchlist token system. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    There should be a menu option "search", which brings up an AJAX dialog allowing you to search that particular thread. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    It should support MySQL search at a minimum, and probably Postgres if I get time. -------------------------- **Version**: unspecified **Severity**: enhancement
    • Task
    Big old icons, no numbering, nothing like that. Needs sorting out. -------------------------- **Version**: unspecified **Severity**: enhancement