Meta:Babel/Archives/2012-01

Importing edits and then refusing to attribute them properly

First of all, I've no idea if this is a good place to post this - please advise if not.

Apparently for every Wikimedia per-language wiki where local admins decide to randomly scoop my edits, they get assigned to the local Joy account. This may or may not actually be me. The prime example for this is the German Wikipedia, where a bunch of my English edits were imported under de:User:Joy, which is controlled by a different person, who is largely inactive (only 4 edits made a while ago and not responding to Talk).

I've asked about it in various places, starting in June and July 2010 at Steward requests/SUL requests, to no avail. In July 2011 I asked at de:Wikipedia:Benutzernamen ändern/Benutzernamens-Übernahme, to no avail. Unfortunately the German Wikipedia policy is stricter than most if not all others, and they just won't let me 'usurp' the username. This has been status quo for many years apparently - see explanation from a German bureaucrat. At de:Wikipedia Diskussion:Benutzernamen ändern/Benutzernamens-Übernahme, I laid out my case, and found more users with the same problem.

I eventually concluded that this may in fact be copyright violation territory, because those edits no longer get properly attributed to their actual authors, and that is a clear license requirement.

The SUL process would seem to generally allow users to smooth over these attribution issues by way of account usurpation, but I had to jump through countless hoops to get anything done - see en:User:Joy/SUL, Steward requests/SUL requests#Joy - and still didn't manage to get the primary problem fixed with it.

However, it's still plain wrong to have people import edits while failing to check if the import would actually screw up attribution.

This needs to be fixed ASAP because it's escalating - another affected user recently told me how they found another set of edits imported from non-Wikimedia MediaWiki instances, extending the potential field of account conflicts, well beyond the reach of any SUL process.

--Joy 23:10, 8 November 2011 (UTC)

The problem is actually less and less important (frequent) thanks to SUL, but I agree that it's a problem. The database does store such edits in a different way, so perhaps MediaWiki could be fixed to handle them differently, but I think that the only viable solution is to stop such imports and delete such revisions where usernames conflicts. There's no reason to import the whole history if it's not going to be deleted in its original wiki; a link to the original page is enough with the "new" (2009) license and terms of use, and de.wiki should have changed its habits a while ago. If they don't want to, just ask selective deletion of those pages. Nemo 09:04, 9 November 2011 (UTC)

See, that's another part of the problem. Why is it my duty to ask for intervention, and then spend a lot of time explaining, negotiating, waiting? It's a complete disaster when you consider that I've invested a lot of effort in my username on en:, including some of those edits that were imported, and then in the SUL process, and yet I got nothing because the process currently enforces a 100% protection of both the people who did the sloppy imports, and the person holding the other account who made a comparably trivial contribution yet is no longer responding to any queries. The system should not be so tilted in favor of people who did very little to deserve any such special treatment. --Joy 08:25, 11 November 2011 (UTC)

I understand that you're frustrated, so I made the request myself. Nemo 15:27, 11 November 2011 (UTC)

Offtopic interpretations of the attribution requirement

The problem is smaller than it may seem, because Wikipedia articles do not have authors, but contributors on behalf of the project. As a user, you have no author rights that can be violated. For that reason there is no need to import entire histories either. Copying a single version with a permalink in the edit summary suffices. Regards, Guido den Broeder 11:09, 12 November 2011 (UTC) I've no idea where you're getting this contributors on behalf of the project stuff. Each editor retains autorship and copyright on each of their contributions that qualifies as a work that can be protected by copyright. At no point did I or anyone else transfer my copyright assignment to the project, Wikimedia Foundation or whatever. --Joy 11:24, 12 November 2011 (UTC) You don't have a copyright to transfer (unless you copied text that you wrote elsewhere first). Guido den Broeder 23:50, 15 November 2011 (UTC) You are wrong about this. Editors retain copyright. Seb az86556 01:26, 16 November 2011 (UTC)" If you had attribution rights before editing, you keep them. However, editing Wikipedia does not give you any new rights. Guido den Broeder 01:41, 16 November 2011 (UTC) At least for the United States, that's the same thing and doesn't make any difference. Anything you write, type, create, paint, or sing and record, you hold the copyright to in the moment you write it, whether officially published or not. Thus, I hold the copyright to these very words as I type them right now. Seb az86556 08:50, 16 November 2011 (UTC) Sorry, but no. Guido den Broeder 12:17, 16 November 2011 (UTC) Sorry but yes. Read applicable US legislation. Seb az86556 13:12, 16 November 2011 (UTC) See below. Guido den Broeder 23:33, 17 November 2011 (UTC)

Thanks, but I was hoping we would actually fix the general problem, rather than just adding you to the list of people whose time was wasted on fixing particular issues :) If we achieve consensus that this should be fixed, the problem should be fixed by a computer program, for everyone. --Joy 11:22, 12 November 2011 (UTC)

We don't need consensus. It's very unlikely that MediaWiki will ever be changed to fix this problem, which can be avoided if import is used correctly; but I've added a note to bugzilla:7240 (linked from de.wiki). Nemo 13:10, 13 November 2011 (UTC)

I'm the one called "another affected user" above, and I know that there are other affected users too. For example, I read about a suggestion to switch on imports on Swedish Wikipedia (outcome: no imports to Swedish Wikipedia) where some User:StefanB was talking about imports to German Wikipedia, miscrediting them to a local de:User:StefanB.

Quoting the Creative Commons licence: "If You Distribute, [...] You must, [...], keep intact all copyright notices for the Work and provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable)". That is, German Wikipedia must provide the pseudonym (Joy) of the contributor. Looking at a random history page, I see that German Wikipedia indeed does provide the pseudonym. On the other hand, above the "edit summary" line, I see the text "You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license." German Wikipedia provides a hyperlink (to de:User:Joy). Is any hyperlink, pointing to any URL of the distributor's choice, fine? --Stefan2 22:36, 13 November 2011 (UTC)

This is exactly the reason of the problem. To provide a reasonable yet silly analogy: Baron Alexander von Bach as "Bach" created something, and then we link that "Bach" to Johann Sebastian Bach, as well as list it work under the latter's contributions. That would be just plain wrong. To claim it's not wrong would be completely disingenuous. --Joy 11:24, 14 November 2011 (UTC)

I agree that it is a problem, but I'm not sure if it is against the licence or not. If it is not against the licence, I'd say that there's a typo in the licence at the very least. --Stefan2 12:23, 14 November 2011 (UTC)

IANAL, but I don't see any way to read http://wikimediafoundation.org/wiki/Terms_of_use or http://creativecommons.org/licenses/by-sa/3.0/legalcode where this is legitimate. For example, the legalese says "If You Distribute, [...] the Work [...] You must [...] provide, reasonable to the medium or means You are utilizing: (i) the name of the Original Author (or pseudonym, if applicable) if supplied, [...] (iii) to the extent reasonably practicable, the URI, if any, that Licensor specifies to be associated with the Work, unless such URI does not refer to the copyright notice or licensing information for the Work" - it explicitly talks about associating URIs with work, and here we go associating an URI that we know to be wrong - with work. "It's a bug" only goes so far - this is indefensible. --Joy 23:52, 14 November 2011 (UTC)

Sorry, I didn't notice the URI part in the licence when I wrote the above. --Stefan2 13:36, 15 November 2011 (UTC)

Offtopic interpretations of the attribution requirement II

Joy, the text above the edit summary line and the terms of use (and license) don't contradict each other. Your mistake is that you think the word 'author' in the license means 'Wikipedia user'. It doesn't, it pertains to authors who distribute an already existing work through Wikipedia. Guido den Broeder 02:20, 16 November 2011 (UTC) Writing for Wikipedia is an act of authorship. At least in the U.S., copyright in an original work of authorship exists the moment the work is created. ~ Ningauble 14:47, 16 November 2011 (UTC) This is the Berne convention, and the USA legislation is not even the strictest about this part. Nemo 09:16, 17 November 2011 (UTC) The Bern convention does not apply to employees or equivalent, unless you have explicitly been granted the rights - which is not the case. Guido den Broeder 23:31, 17 November 2011 (UTC) Contributing to Wikipedia is not a work-for-hire (or I seriously need to ask for a raise). ~ Ningauble 19:48, 18 November 2011 (UTC) This question pops up several times a year, but the answer stays the same. It does not matter whether you are paid or not. Wikipedia controls the manner and the means by which the encyclopedia is created. Therefore, you are equivalent to an employee and the work-for-hire copyright reversal applies. Guido den Broeder 01:20, 19 November 2011 (UTC) en:Wikipedia:Copyrights: "The Wikimedia Foundation does not own copyright on Wikipedia article texts and illustrations." "The text of Wikipedia is copyrighted (automatically, under the Berne Convention) by Wikipedia editors and contributors [...]" By the above quote, it seems that English Wikipedia editors explicitly have been granted the rights. Anyway, this seems rather irrelevant to the discussion. I see this more as a moral and practical issue: it is more polite to the author and less confusing for people reading the history if edits aren't miscredited. --Stefan2 10:57, 19 November 2011 (UTC) As demonstrated by all relevant documentation quoted above, the condition of licensing an editor's copyrighted work to the Foundation and everyone else is that the aforementioned terms of the relevant licenses are respected. This matter is not irrelevant; if the license terms are not followed, all further use and distribution of such material constitutes copyright infringement, IOW this behavior is illegal. --Joy 19:52, 19 November 2011 (UTC) Hi Stefan2, the lead of that en:Wikipedia policy is partly incorrect and at odds with the body of the page. The WMF does indeed not have copyright either, it serves mostly as a provider. Instead, however, the copyright belongs to the individual project. The practical issue is not that practical, as this example shows. It happens often enough that a handle on one project belongs to a different person than the same handle on another. Guido den Broeder 13:45, 20 November 2011 (UTC)

I'm not sure if the licence is followed, but there is also the issue with confusion: people may believe that text written by one person in fact was written by some other person. I'm not too happy about this confusion part myself; it may look as if I have written something I haven't written, or vice versa. Besides, it is harder to identify the original author if you can't always assume that it is the local user. On the other hand, now that the edits already have been imported, it is probably better to keep them than to go into the edit history and selectively remove certain edits, since it would make it hard to read the history section.

If the edits are from an external Mediawiki installation, importing them might be the only way to guarantee that the licence always will be followed. You are required to link to a history page, and external installations may be taken down, removing the history (and then, I suppose, requiring an article deletion here since you no longer can point at the original history). However, with imports, the history remains on Wikimedia's installation, making it possible to keep the articles even if the source installation goes down.

Maybe someone with database access would be able to reattribute edits to a local German account held by Joy? It wouldn't solve the problem completely (for example: there could be new imports in the future) and it wouldn't solve the SUL issue.

By the way, German Wikipedia is not the only wiki importing. --Stefan2 22:36, 13 November 2011 (UTC)

Bugzilla:13798 deals with more or less the same issue. --Stefan2 00:02, 14 November 2011 (UTC)

There is maybe no licence violation right now, but there could maybe be problems if accounts are renamed. According to the licence, I believe that en:User:Joy has to be credited as "Joy" in the history. This is currently the case. However, if de:User:Joy were to be renamed into de:User:Not Joy, the history would probably change so that the edits made by en:User:Joy are credited to "Not Joy". My interpretation of this is that de:User:Joy needs to ask for permission from en:User:Joy in order to be allowed to rename his own account. What is your opinion about this? --Stefan2 00:14, 14 November 2011 (UTC)

If the de:user:Joy is renamed, the imported edits under this name would stay in place. Only real edits would be moved. Ruslik 06:17, 15 November 2011 (UTC)

Lots of false statements here !! Joy is right. The Foundation explains in large that it does not own any copyright on any work f the project and that it does not act as an editor. It does not endorse the content, and does not reslle it. It just acts as a service provider for allowing members of a commnity to share their own work between themselves and to others. The responsability of the Foundation is just the one of a intermediate distributor.

The only copyright that the Foundation owns is for its own operating name, to register itself as an organization and defend its own assets and investments, and to be legally responsible of it, the Foundation needs to protect its own identity. It also needs to protect the distinctive trademarks and logos of its hosted projects (see the FAQ on the Wikimedia Foundation site).

The FAQ also explains that contributing does not constitutes a transfer of rights. All exclusive rights are preserved, including author's right and copyright in general. The Foundation just requires that the content being licenced by authors and right owners. A licence is definitely not a grant to give copyright to someone else, but a signed agreement that the contributor accepts to endorse, that HE is personnally the owner of the rights that he wants to licence to others.

The Foundation then just receives a licence, just like any other visitors of the hosted projects.

Yes attribution is important, and in fact it is the most important part of the licence that the Foundation requires.

And no, contributors cannot be said to be workers. No contributor has ever signed any mutual contract with the Foundation to create this work. The Foundation cannot force anyone to make any work in any time. The Foundation in exchange will never warranty any payment in exchange of such putative contract.

So yes Joy is right: users of the German Wikipedia are doing things wrong if they import contents without correctly attributing the original author. Yes the terms requires the attribution, but if it allows an hyperlink URL, the target of this URL must still reference the correct author. In other words, those importing data from Commons to w:de: should not alter the links to the original user pages on commons: to replace them by another URL to another user of w:de:.

Robots or humans must then change local links specific to the source project to external links in the Wiki code, meaning that the target page User:Joy on Commons found in the imported wiki text should continue to resolve to the page on Commons after the import to w:de:, by adding the prefix commons:User:Joy.

This should be done in fact for all users, unless you can get absolutely sure that accounts on Commons and on w:de are controled by the same user; there no such warranty, and in fact, this is a pricacy secret kept in the database, whcih is not accessible directly to bots, and can only be revealed by asking to the user on both wiki if they are the same users (you could use "CheckUser", but this requires a very restrictive privilege and this request can only be performed to counter attacks caused by the user, and the persons with CheckUser rights must not reveal any private information other than confirming or infirming if both accounts are controled by the same effective user; in case of doubts, the response will be no, but the response will be yes if both accounts have been unified by SUL).

For such uses (normal imports, notaly those made by bot imports), never assume that accounts are owned by the same person, you 'must preserve the links to the original user on the original wiki. The problem is when importing history data: can it register the original URL, or does it only allow registering a local user account ? In that case, the local user account will be the account used by the importer. The standard history page will not be able to track the track of the history, so this has to be imported separately within the Wiki text. The same is true when importing medias from de:wp to Commons (a much more common case for images)

Or when importing from en:wp to de:wp (e.g. to translate an original English page), you'll need to import the history in the talk page, by signing and dating a new talk section with the importer name, and in the discussion citing all URLs to the original authors names, and the URL of the imported source page. You don't need to import the full history (notably submit comments), because it will be available on the source page.

When importing the original or modified wikitext or media-file, the importer must still signal in his own submission comment where to find the imported attributions and applicable licences (e.g. with a comment like "imported from w:en:Pagename (authors/licences imported on Talk:This page"), so you'll actually import on two pages (either the media page and its description page, or the wiki page and its talk page). The two imports must be coordinated and it is the responsibility of the importer to do both imports of information in a reasonable time (ideally the same day, except in cases of problems on the local server to perform both, but a well behaved bot should perform the second dated&signed import of "attributions&licences data" to the associated talk/description page in just a few seconds). verdy_p 22:47, 20 November 2011 (UTC)

Note: if any page is later splitted locally, each part of the plit 'must also reference the local source page from which it was imported, exactly the same way, to keep the track of attributions and licences. In fact I think that talk pages or description pages are not very well suited to track authors and applicable licences precisely. We should have a "Special:Licencing/PAGENAME" page in which there would be a clear summary of authors, licences and dates to any wikitext or media file; this page would be automatically generated with the summary of authors found in the history; and in the history page, we should have a link near all contributions allowing to create one or more records (one for each author, licence and dates of first/last contribution, and the URL to the original page, or description of the source if it's not online, plus OTRS verification records if applicable) to the database displayed in "Special:Licencing/PAGENAME". verdy_p 23:07, 20 November 2011 (UTC)

I've spelled it all out for you. If you still don't get it, so be it. Guido den Broeder 14:22, 21 November 2011 (UTC)

رائع فهمت بعض الشئ --حاتم العوضة 13:29, 22 November 2011 (UTC)

I'm not sure if it was mentioned here, but it seems that the Germans are discussing the matter at de:Wikipedia:Administratoren/Notizen#Importe führen zu Urheberrechtsverletzungen. I'm not sure I understand everything, but it seems that they are discussing the book function. A good example is en:Yumi Tsukirino. About a month ago, I translated the article from Japanese. If you put this article in a book, you won't include the Japanese Wikipedia editors, and so the list of editors will be incomplete. The notice telling that the article is a translation is on the talk page (usually not included in books) and the book only includes an alphabetical list of all editors (so my edit comments about the article being a translation from Japanese won't end up in the book). --Stefan2 15:44, 22 November 2011 (UTC)

See also this thread in the Wikimedia Forum archives (from this March) where the issue was discussed before (without solution). This is a question of Droit de non-paternité (article in German), too - people have a (moral and legal) right that works by others aren't credited as theirs. E.g. I noticed the contributions list of user KLN in the German Wikipedia, de:Spezial:Beiträge/KLN - these are mainly imported edits from the Danish Wikipedia, made by Danish user KLN who, according to the user pages, most likely isn't the same person. So, our poor German KLN (inactive) continues to "edit" through imported edits by Danish KLN. There are still many, many non-SUL accounts, it is a real problem when importing is used as the standard procedure for translated articles, as the German Wikipedia does. It could be embarrassing for Wikipedians when contributions by others about controversial topics, or vandalism, start appearing in their contributions list. Gestumblindi 23:46, 22 November 2011 (UTC)

I went to Danish Wikipedia to inform the Danish user about the topic since he might wish to join the discussion and checked his user talk archives for any comments about this and found a link to de:Benutzer Diskussion:DerHexer/Archiv17#Falsche Benutzerzuordnung durch Importe (link from da:Brugerdiskussion:KLN/Arkiv 3#Fejl i tilskrivning) which deals with the same matter. --Stefan2 01:11, 23 November 2011 (UTC)

BTW working link for the German discussion is de:Wikipedia:Administratoren/Notizen/Archiv/2011/11#Importe_f.C3.BChren_zu_Urheberrechtsverletzungen. --Joy 11:32, 16 December 2011 (UTC)

So the discussion was archived without any solution. By the way, it is interesting how the German admins think that very short articles like de:Brampton (Norfolk) need to be imported to make sure that the history page shows all contributors, yet they copy and paste large chunks of text to de:Wikipedia:Administratoren/Notizen/Archiv/2011/11 without importing anything. If you look at the history page for that archive, you don't see a list of the original authors, yet the text is covered by the same GFDL and CC-BY-SA licences as the short Brampton article. --Stefan2 01:37, 19 December 2011 (UTC)

That's only a related discussion; the actual request has not been rejected (nor accepted) and I've renewed it (you can find links to previous request there). Nemo 11:09, 19 December 2011 (UTC)

This is Babel, not a request page. The discussion goes where it goes, you don't own it. Guido den Broeder 01:36, 31 December 2011 (UTC)

yet they copy and paste large chunks of text to de:Wikipedia:Administratoren/Notizen/Archiv/2011/11 - yes, but this is seen as okay, I think, because contributions are signed on the page itself (as on talk pages) and so attribution is made in this way, though not in the history. Gestumblindi 21:46, 12 January 2012 (UTC)

Asking for permission

It's told to us to be bold however there are some things that I preferr not to edit without permission or prior consensus to do so. Somebody might think that's contrary to the wiki-way. That's an acceptable thought, but I do not agree. One of those are user pages and mass changes, for example. While the user pages are wiki pages, I was taught and agree that they should not be edited but for the user in question; with some minor exceptions.

Said that, I intend to fix 36 user pages that appears in the broken redirects special page, incorrectly, mostly as a result of external redirects to other projects. I would like to fix them and, before editting 36 user pages en mass I though a note asking for permission would be the right thing to do before.

Do you agree? (sorry for my bad english) Thanks. —Marco Aurelio (Nihil Prius Fide) 16:01, 19 December 2011 (UTC)

Claro. No veo ningún problema con eso. Killiondude 23:54, 19 December 2011 (UTC)

Gracias. No es que no valore tu opinión :-) pero me gustaría contar con la de alguien más pues este hilo está lejos de lo que puede considerarse un "consenso". Un saludo. —Marco Aurelio (Nihil Prius Fide) 12:37, 29 December 2011 (UTC)

Pues, tenemos w:WP:SILENCE en enwiki. Si nadie expresa una opinión contraria dentro de un tiempo apropiado... Bueno, puedes esperar para más respuestas si quieres, pero metawiki no es tan activo. :) Killiondude 19:24, 29 December 2011 (UTC)

Jeje silencio administrativo aplicado a la wiki :) —Marco Aurelio (Nihil Prius Fide) 10:37, 30 December 2011 (UTC)

May I interpret this silence as no objections? I'd really wish to get more opinions. Thanks. —Marco Aurelio (Nihil Prius Fide) 17:20, 16 January 2012 (UTC)

I think it should be fine. They can always undo it if they want to. Cbrown1023 talk 18:51, 16 January 2012 (UTC)

Ok with me. Savh^ñ 20:31, 16 January 2012 (UTC)

Translation admins user right

Hi all,

We've recently had Special:Translate installed on this wiki, and as a result, a new user right, Meta:Translation administrators has been created. Currently crats are able to assign this right to users, but not able to remove it from them. I believe this is the default setting for this extension, and, as Meta Crats can remove the admin and crat user right, I propose that we also allow them to remove the translation administrator flag. This has probably not been brought up before because it's still quite new, but I noticed it from this request for translation admin, so thought I should point it out.

Thanks,

The Helpful One 22:39, 8 January 2012 (UTC)

• I don't think this is a high priority issue & would preferr not to change this for now. As it happens in nearly all projects bureaucrats are able to assign some rights but are not able to remove them later. Nothing bad in my eyes. As this permission is currently hardly assigned (extension developers and people testing with the extension developers [ie: me]), and the extension is rather new here, and probably would be subject to some changes and improvements I feel there's no need to change the config of the site right now IMHO. Probably later if the level of flaggings/unflaggings increase I may support. If any flag is to be removed a simple SRP request will do it. However, instead of changing the way on how to remove this right, I propose to codify when, how and to whom to grant this right, and under which conditions; which is important I think. Actually there's nothing about it so. I'm keeping it per my conversation with Gerard on IRC that he wanted feedback, etc and so I've been using it to make some pages translatable (such as Promoting users); but I'm willing to relinquish it if it's any inconvenience. Thanks. —Marco Aurelio (Nihil Prius Fide) 04:01, 9 January 2012 (UTC)
• While I agree that this is not an urgent issue, I see no reason why bureaucrats should not be able to remove the rights they've granted. Jafeluv 08:19, 9 January 2012 (UTC)
• Not a big deal or really important, but still worth doing imo. No pressing reason to not make the change. Ajraddatz (Talk) 19:12, 9 January 2012 (UTC)
• "Meh" pretty much sums up my position. PeterSymonds (talk) 19:13, 9 January 2012 (UTC)

  Please create an issue in bugzilla: stating what the config should be. We'll update it. --Siebrand 19:55, 9 January 2012 (UTC)

• Not a support or oppose. I don't really care. Surely wouldn't hurt to give bureaucrats that right as they can already remove other rights. On the other hand, it is rarely used and the two times this needs to be removed, the stewards can just do it. (Talking about the removal of this right: I don't even know any rule about it to grant it... Shouldn't this be made up firstly?) -Barras 15:28, 10 January 2012 (UTC)
• Comment. Is this usergroup necessary? Would not it be much simpler to bundle it with the sysop usergroup? Ruslik 18:16, 10 January 2012 (UTC)

Hmm, looking at Special:ListGroupRights, translation admins can only Mark versions of pages for translation (pagetranslation). There's also another user group, "Translation reviewers" that can Review translations (translate-messagereview) and Add group: Translation reviewers. I imagine this is the equivalent to the person that proof reads translation for the Steward elections, for example. No local user right (other than steward) is able to remove translation reviewers (although there aren't any presently). Your suggestion is a good one, so I'll expand on it for something to think about for the future:

• We make sysops translation admins by default, and also give sysops (or crats) the ability to make people Translation reviewers.
• If we keep the translations admin group separate, we allow translation admins to also have translate-messagereview, right too.

But yes, I agree that perhaps it might be better if we change this discussion into proposals for policy for granting the right (or guidelines), because if we're going to be using Special:Translate to centralise all Meta Translations (there's 100's of them) then it would be best to have an agreed method of granting these rights. I didn't mean to suggest that this was urgent in my first post, just something that I noticed - there's going to be a lot of work done by a few before we open it up for translators en masse. The Helpful One 18:59, 10 January 2012 (UTC)

Translation review rights are currently assigned to all users, the group is basically useless (in fact it's empty). I suggest filing a request when we've decided how to use this extension on Meta (I'm going to draft something in the next few days), to avoid multiple requests. Nemo 01:59, 11 January 2012 (UTC)

They are not assigned to all users. Ruslik 05:38, 11 January 2012 (UTC)

Hm? The "Review translations (translate-messagereview)" right is listed for "Users" at Special:ListGroupRights so it sure looks like it's enabled for all users. Jafeluv 10:33, 12 January 2012 (UTC)

Ok. Ruslik 12:58, 12 January 2012 (UTC)

• I agree with Barras basically - we seem to be jumping steps a bit here. --Herby ^{talk thyme} 14:24, 11 January 2012 (UTC)

Dulegaya

I would want to see someday wikipedia in Dulegaya (Guna people language - Panama) and other amerindian languages.MCerrud 17:14, 17 January 2012 (UTC)

Hi, if you have knowledge of the language or have contact with people who know the language, you are strongly encouraged to start a test Wikipedia by following the instructions on incubator:Wp/cuk ("cuk" is the language code for Dulegaya). If you need more information, feel free to contact me or on incubator:I:Community Portal. Regards, SPQRobin (talk) 20:38, 17 January 2012 (UTC)

Three issues about mailing lists

(I'm not sure where to post, I try to do according to notice at top of the page)

I've three issues about mailing lists, I've written it the talk pages:

• Email address visibility
• Get password reminder email
• announce-l listed defunct in overview page

--SignorX 18:31, 20 January 2012 (UTC)

Chapters Committee is looking for new members

Hi,

The Chapters Committee is looking for new members. Please encourage everyone, who you think would be suitable, to apply by 15 February!

Also, if you can figure out how to edit the News template on the front page of Meta, I would appreciate, if you could put this in as I think it is relevant for the wider community.

Thanks, --Dami 21:05, 21 January 2012 (UTC)

Translation tools workshop: pick your preferred time to participate

I'm planning to give a Translation tools workshop in about two weeks. If you want to learn more about the special pages Special:PageTranslation, Special:Translate, Special:LanguageStats, Special:Translations and Special:MessageGroupStats, go to Translation tools workshop and read up! Thanks. --Siebrand 23:05, 12 January 2012 (UTC)

FYI: the workshop will be held on 2011-01-28 20:00 UTC. For other time zones, see: http://hexm.de/dn. --Siebrand 23:42, 22 January 2012 (UTC)

Russian-speaker needed I think

Hi. Can somebody please help on User talk:Дагиров Умар? He's stated he does not speak English in his last edit on his talk. I think he wants to request sysop access on cewiki. I gave links on his talk page but I think the language barrier prevent him/her to understand the instructions, etc. Thanks in advance. —Marco Aurelio (Nihil Prius Fide) 12:56, 30 December 2011 (UTC)

Thank you for the Chechen wikipedia just terrible things are happening click here I want to be an administrator to remove all. -- Дагиров Умар 16:28, 19 January 2012 (UTC)

Hello. Cewiki has local bureaucrats [1] - you need to ask them about the procedure for requesting adminship. —Marco Aurelio (Nihil Prius Fide) 18:06, 19 January 2012 (UTC)

Thanks to these members no longer go to wikipedia and it seems that they left the project and the Chechen vikipediya left without an administrator. -- Дагиров Умар 18:51, 19 January 2012 (UTC)

Sorry if you do not understand me, I use a translator by Google. -- Дагиров Умар 18:56, 19 January 2012 (UTC)

Try ce:user talk:Sasan700, who is a bureaucrat on ce, is still active, and speaks .ru, .ce, and .en so communication shouldn't be a problem. LeadSongDog 04:48, 29 January 2012 (UTC)

Enabling Liquid Thread on meta

(English) Hey, the title says it all. In order to get Liquid Thread activated on meta, we need community support, so please add your name below if you support, or oppose, it's activation.

For those of you not knowing what Liquid Thread is, it's a Mediawiki extension that improve the organisation of content in talk pages. as meta is mainly a place for discussions, it would be a great improval to get it activated and would ease discussions, both participation and reading. You can get more informations on the Mediawiki Extension page.

Liquid Thread is enabled on some Wikimedia Mediwiki, such as the Strategy wiki. Please show support. Schiste 12:56, 10 January 2012 (UTC)

Support

1. Schiste 12:56, 10 January 2012 (UTC)
2. Very hard needed in some of the long discussions. Disadvantageous in some other pages perhaps, but currently the advantages would outweigh the costs easily. It makes the overview better, especially for new users, and most especially it allows better watching of discussion pages (more specific with 'mark as read' option)Effeietsanders 12:57, 10 January 2012 (UTC)
3. We use LiquidThread on the internal-wiki of Wikimedia FR, very useful. I support. --Serein 14:00, 10 January 2012 (UTC)
4. Since it can be used on a page-by-page basis, and is amazing, I fully support this. Ajraddatz (Talk) 14:57, 10 January 2012 (UTC)
5. Support, once the devs allow it, which will only be after LQT 3.0 is released, which will be in a really long time. Why is this discussion taking place now? --Yair rand 22:52, 10 January 2012 (UTC)

   The specific reason why this is being raised now is because of the lengthy discussions going on over here: Fundraising and Funds Dissemination but the issue has been pertinent for a while. Wittylama 23:04, 10 January 2012 (UTC)

6. Yes Please. Especially for long discussions it makes it significantly easier to parse things as it bumps new threads to the top and allows you to archive things you've already read. I genuinely don't understand criticisms on the basis that what we have already is simple and easy - it's really not! It's just what we're used to and newbies are, generally, completely turned off by it. Wittylama 23:04, 10 January 2012 (UTC)
7. I think I proposed this at some point. I can't quite remember my logic when doing so, but surely it was sound logic then and it's surely still sound now. --MZMcBride 03:18, 11 January 2012 (UTC)
8. Definitely needed for some of the extensive discussion threads we've had. James F. (talk) 20:26, 12 January 2012 (UTC)

Oppose

1. Oppose - Rather strongly. I've always found LQT too complicated, confusing and hard to follow. LQTs has lots of unfixed bugs and is undergoing a redesign. I believe they will not solve the problem but will create another one, specially on new users. Please keep it simple: plain text is good and easy for everybody. Nb: a recent discussion in commons showed major opposition to the implementation too. Thanks. —Marco Aurelio (Nihil Prius Fide) 15:14, 10 January 2012 (UTC)
2. I've to agree with MA above. The current system is a really simple one and probably more friendly to newcomers here. Also, I don't really know who it works, what exactly will change etc. Most people here come from content projects using the same system as we currently do. This makes it easier for them to get in touch with meta. -Barras 15:25, 10 January 2012 (UTC)
3. See en:Wikipedia:Village_pump_(proposals)/Archive_75#Enable_LiquidThreads for arguments. My favorite one is: It's been in development hell for as long as I can remember, and that's because (IMO) it was an attempt to reinvent the wheel based on a singular vision. It's a bulky and bloated mess of dynamic animations that don't seem appropriate or efficient for our purposes. (by Equazcion). Ruslik 18:25, 10 January 2012 (UTC)
4. Fully agreeing with MA. LiquidThreads makes talk pages a mess, while there's nothing wrong with a simple wiki page. Savh^ñ 21:24, 10 January 2012 (UTC)
5. Absolutely no. LQT is full of bugs and it's not being taken care since months (years?), sv.wiki has abandoned it due to lack of support, other wikis are driven crazy by it, and it's absolutely not suitable for a big and complex wiki like Meta, it would make almost all discussions completely unmanageable. Let's wait either 1) the current extension main problems to be properly addressed, or (better) 2) LQT 3.0 to be ready. By the way, for this reasons the WMF isn't enabling this extension anywhere in the meanwhile. Nemo 01:38, 11 January 2012 (UTC)
6. Dear God no. Per Nemo, et al. Killiondude 03:05, 11 January 2012 (UTC)
7. Good god, dealing with it on strategy wiki is enough. Per Killiondude and Nemo. Theo10011 03:47, 11 January 2012 (UTC)
8. One of the most unwieldy and horrible things I've ever used. ugh. Ottava Rima (talk) 03:55, 11 January 2012 (UTC)
9. Per above: bugs + not similar with other wikimedia projects + current interface is easier IMO. (A bit astonished with that sudden process)” T_ele^s (T _{@ L C S}) 05:47, 11 January 2012 (UTC)
10. Per Marco Aurelio. Regards, Guido den Broeder 12:58, 11 January 2012 (UTC)
11. If it breaks folks browsers make that a definite "oppose". On balance No for now. Meta tends to be about the last place folk find generally so we should keep it fairly basic/simple here until many more projects are familiar with this. Thanks --Herby ^{talk thyme} 14:23, 11 January 2012 (UTC)
12. Strong oppose. The thing consistently breaks my browser, to the point of requiring a complete hardware reboot. Something like this can be reconsidered when a redesign is successfully implemented. ~ Ningauble 18:08, 11 January 2012 (UTC)
13. No, no, no. This is one extension I wish would just die, it barely works, is confusing as can be, and offers no advantages over the current, easy-to-use system. Courcelles 04:55, 12 January 2012 (UTC)
14. I agree with Marco Aurelio: "too complicated, confusing and hard to follow". I do not like Liquid Threads at all. Gestumblindi 21:49, 12 January 2012 (UTC)
15. Too complicated and slow. – Kwj2772 (msg) 07:54, 31 January 2012 (UTC)

Questions

1. Hi, as per it says on mw:Extension:LiquidThreads, "The author of this extension is no longer maintaining it! Meaning any reports for additional features and/or bugfixes will more than likely be ignored." - are there any issues that you have noticed with the extension such that we will need an active developer to maintain it? Thanks, The Helpful One 14:00, 10 January 2012 (UTC)

   Nope. We're actively using it on Wikimedia France's internal wiki and no glitches so far. Schiste 14:09, 10 January 2012 (UTC)

   I know of some imperfections, and I'm sure you can find more on bugzilla. But that is nothing special for Mediawiki. I would support further development to get rid of those, but I don't believe it should prohibit activating it now. Effeietsanders 14:15, 10 January 2012 (UTC)

   It's certainly not abandoned as a piece of software, it just needs allocation of resources to get it to the next step, as demonstrated in this recent conversation.[2] Furthermore, the WMF has detailed backend (and UI) plans for a "version 3" that will be a significant improvement on the current version[3]. Wittylama 23:04, 10 January 2012 (UTC)

   It is abandoned, the only developer is Andrew and he's not been working on it for ages. The extension is currently not supported (Eloquence on wikitech-l said it should be, but no actions followed) and LQT 3.0 is currently on hold and quite far (again, Eloquence said it's almost as difficult a project as the visual editor! would you enable a visual editor alpha for all users on Meta? this is not a test wiki). Nemo 01:45, 11 January 2012 (UTC)

   I like to concur that it is abandoned and barely even works. I constantly have to patch it to keep it working on translatewiki.net - I'm pretty sure it would just break when WMF updates to 1.19 if I didn't do that. Not to mention the usability issues and that it keeps flooding the server error every day. It saddens me every day, since I just could not imagine my wikies without LQT even with all its shortcomings. – Nikerabbit 08:42, 16 January 2012 (UTC)

2. We were told in May last year that 'deployments for LQT are on hold'. Did it change since then? Bencmq 14:51, 10 January 2012 (UTC)

   When this request was raised on bugzilla the other day the response came back that consensus on-wiki was the required first step[4] This, plus the fact that the software is running on several of the WMF's actively maintained wikis (e.g. mediawiki.org) means to me that requests for new deployment will be approved if consensus is shown. Wittylama 23:04, 10 January 2012 (UTC)

   Per bugzilla:19699#c10, further LQT deployment is on hold. Bug closed for now. Nemo 01:45, 11 January 2012 (UTC)