From Meta, a Wikimedia project coordination wiki

Editing Title and Meta Tag

However i can edit title and Meta Tag.

For HTML? Just edit the <title> content and <meta> attributes, obviously. For Wikimedia or MediaWiki in general? The <title> is from MediaWiki:pagetitle with $1 replaced by the page title. You can also change the header content with the DISPLAYTITLE magic word (might not work on all wikis). The meta tag is pretty constant on Wikimedia wikis. For MediaWiki, mw:Manual:FAQ#How_do_I_add_meta_tags.3F. PiRSquared17 (talk) 02:33, 2 May 2014 (UTC)

Translate wiki pages to another wiki

wikipedia:User:Gryllida/ExternalTranslate.js adds a translate tab to translate an article to another wiki. Please test and fix whatever you find useful to fix... Gryllida (talk) 05:50, 1 May 2014 (UTC)

Thanks; please let mail:translators-l know. --Nemo 06:38, 1 May 2014 (UTC)
done. Gryllida 03:38, 2 May 2014 (UTC)
Sorry, I can't test this because I don't know anything about software. But can I ask, who the intended users of this script are? Lloffiwr (talk) 11:14, 3 May 2014 (UTC)
Hi Lloffiwr,
The target audience is all contributors of all sister projects whose pages are translateable as a whole.
To use it, add "importScript('User:Gryllida/ExternalTranslate.js');" into your Special:MyPage/common.js: you will see a Translate tab at each article top.
This currently works on all namespaces including those that make no sense (I.e. Search:*) but once someone comes up with a list I'll add it in.
You might also find some more documentation of the concept at Grants:IdeaLab/External Translate‎.
--Gryllida 02:55, 6 May 2014 (UTC)


Hola tengo una pregunta:

  1. ¿En que puedo ayudar en Wikimeta?

eso adios This Is It MJ (talk) 00:18, 7 May 2014 (UTC)

¡Hola 9oo! Puedes traducir al español. Si te interesan las traducciones, visita Meta:Babylon/es. Hay otras maneras de ayudar. ¿Cuáles son tus intereses? PiRSquared17 (talk) 00:44, 7 May 2014 (UTC)

Attribution of translation for :wmf:Terms of Use/de

Hello, readers of any German wikipedia page are redirected for "Nutzungsbediungen" to the page wmf:Terms of Use/de. As far as I can see, the page was created by My impression is, that the text is a copy and paste from, (with the displayed page title "Nutzungsbdingungen", I don't understand which is the actual page title).

A first draft of the German translation was created by me (my last edit there seems to be at 29 October 2011), later the translation was revised by other contributors.

I can't log in at the wmf-wiki. My request is, that the revision history of should be exported to the wmf-wiki, and added to the revision history wmf:Terms of Use/de, in order to comply with the free license (probably Creative Commons Attribution-ShareAlike License), so that the authorship of the creators of the translation, among them myself, is documented and e.g. visible to the readers of of the German wikipedia, Rosenkohl (talk) 20:25, 15 April 2014 (UTC)

In this edit summary, a link is provided to the Meta page the text was copied from. "You agree that a hyperlink or URL is sufficient attribution under the Creative Commons license." PiRSquared17 (talk) 20:29, 15 April 2014 (UTC)
Sorry, I would prefer to talk about this with someone official from the Wikimedia foundation. However, of course this edit summary you cited would be no sufficient attribution at all. Neither will any reader who is looking for the authors of the translation find this edit summary; nor does this edit summary say that in fact the whole original page is a paste and copy. On the contrary, the page history invokes the impression as if it was originally created on the wmf-wiki, Rosenkohl (talk) 20:46, 15 April 2014 (UTC)
Sorry. For Foundation wiki feedback, see Foundation wiki feedback. Meta:Babel is for Meta-Wiki issues. I'm not sure what you mean. It is common practice to put "copied from [[link]]" in edit summaries, which seems to comply with the attribution requirement. Pinging Mdennis (WMF). PiRSquared17 (talk) 21:01, 15 April 2014 (UTC)
Thanks, then I will try it at Foundation wiki feedback. "this edit summary" you cited refers to an edit were 1,011 bytes are deleted from a page with 48,196 bytes. So the edit with this summary does not create the content, but only changes parts of it. But the license requires the attribution of the content which was originally used to create the page in the first place, Rosenkohl (talk) 08:34, 16 April 2014 (UTC)
Hello, User:Rosenkolh. All editors to our projects agree that a hyperlink or URL is sufficient attribution under the Creative Commons license, as per the Terms of Use itself and the "save page" text. Unfortunately, my note in edit summary acknowledging that the page was "created from the meta version Terms_of_use/de, which see for atttribution" failed to provide a working link (I forgot the prefix, it seems, not to mention adding an extra t to attribution), so I've added another note in edit summary with a working link, here. --Maggie Dennis (WMF) (talk) 16:53, 16 April 2014 (UTC)

Hallo User:Mdennis. Thanks for your efforts, and for adding the edit [1] on 16:50, 16. April 2014 to the revision history of wmf:Terms of Use/de. However I am not at all satisfied with this edit, for reasons which I already did explain in this discussion:

  • I must ask you to imagine that you were a reader of wmf:Terms of Use/de who is looking for the orignal authors of the page's content. Such a reader will neither find, nor understand the revision comment
"created with content copied from meta:Terms of use/de, which see for attribution".
  • a revision comment for any edit usually refers to the actual edit to which it belongs, if not otherwise stated. So the revision comment "created with content copied from meta:Terms of use/de, which see for attribution" seems to indicate that not the original page, but this particular edit [2] was "created with content copied from meta:Terms of use/de, which see for attribution". But the edit itself does not change the page's content. No reader of the revision history will be able to understand without further explanation that the revision comment "created with content copied from meta:Terms of use/de, which see for attribution" actually is supposed to refer not to this minor edit on 16:50, 16 April 2014‎, but instead to the whole page created as created on 15:05, 19 April 2012.
  • Saying "created with content copied from meta:Terms of use/de, which see for attribution" is not a complete English sentence, since the object ist missing: the comment does say that something has been created, but it does not explain what exactly has been created. And furthermore, the comment does not explain when exactly this "creating" took place.
  • I see two options: either the real revision history of is imported to wmf and added to :wmf:Terms of Use/de. I know that cross-wiki imports are technically possible, at least between different language versions; and importing the revision history would be the clearest solution, so I don't understand why an import is not done in the case of this page to which I once had contributed.
  • However, if for some reason it turns out impossible to import an revision history from meta to wmf, there should be added some revision comment to the history of :wmf:Terms of Use/de which is findable and clearly understandable for any reader looking for the origin of the content of the page, telling which version has been created when with content from Terms of use/de.
  • That is, at least there should be revision comment in [3] clearly stating:
"The original page Terms of Use/de was created on 15:05, 19 April 2012‎ with content copied from meta:Terms of use/de, which see for attribution"

I will be indepted if some of these proposed solutions could be feasible, Rosenkohl (talk) 18:10, 1 May 2014 (UTC)

Can you please move this discussion to FWF again? It's really not relevant for this page, sorry. PiRSquared17 (talk) 02:35, 2 May 2014 (UTC)
Sure, I now added the same request again there two days ago, without getting a response yet. The problem at this moment I see is that Wikipedia is still refering to, without what I consider as proper attribution, Rosenkohl (talk) 20:11, 7 May 2014 (UTC)

Throttle on Emailuser - overkill?

Hi all. I've been organising an event as described at Wikimedia Conference 2014/Social events, and have been using the emailuser function to contact those that have signed up. I sent the first batch of emails at around 10:30 UTC today until I ran into the message "As an anti-spam measure, you are limited from performing this action too many times in a short space of time, and you have exceeded this limit. Please try again in a few minutes." I've just tried sending another email now (at 18.20 UTC) and I *still* get that message. That's rather longer than just a few minutes! At the very least the message should be updated to explain that it will be many hours rather than a few minutes, but really the length of the limit seems far too long, and shouldn't be longer than 10 minutes or so. I'm not sure how to propose that it gets reduced apart from posting here - can anyone help? (I've now sent all of the emails I need to, via enwp, so this is no longer an urgent problem for me.) Thanks. Mike Peel (talk) 18:27, 7 April 2014 (UTC)

This might come from here. It was lowered from 200/day. PiRSquared17 (talk) 18:45, 7 April 2014 (UTC)
Ah, thanks! So maybe I should take this to Bugzilla? Thanks. Mike Peel (talk) 19:00, 7 April 2014 (UTC)
This is an important rate limit to have, and I really hope it isn't changed. The emailuser function is often abused for harassment. This rate limit can be overcome with the 'noratelimits' right - perhaps a global group could be created with that right for temporary use in cases like this, if the sender isn't a sysop on the project they are emailing from. Ajraddatz (talk) 19:08, 7 April 2014 (UTC)
Agree with Ajr above, removing such a limit in benefit of the seldomly positive mass mailing is not what we want. Could admin, or even bot flag bypass this problem? Savhñ 12:11, 15 April 2014 (UTC)
Here locally admins, crats, stewards, bots and members of the "accountcreator" group (which, for reasons everyone can imagine, exists everywhere but is only assignable locally on wikis where that has been specially set up) have the right Not be affected by rate limits. --MF-W 17:24, 15 April 2014 (UTC)
The solution is to use MassMessage, but according to usage policy: you should create a list page where users will register themselves with their Wikimedia user page. MassMessage can deliver messages to user group pages, project talk pages, and user talk pages. Users will receive emails only if they have opted in for that in their local wiki preferences (users may have multiple user talk pages, on different wikis, and could register these pages separately (for example to receive emails only when someone or MassMessage posts to one small wiki (such as this one Meta-Wiki), while not receiving emails for their primary wiki accounts that they visit regularly and for which they will prefer looking at their talk page directly).
Writing to many people directly by email (even if they have allowed it in their local wiki preferences), is a bad practice, meany people don't like that, especially in your case where they only expected to participate to your event and have managed themselves how, when and where they want to communicate with your project... So instead, suggest them to register their talk page (or a subpage in their account) in your subscription page, and make sure that your message includes a link back to the list page where they can unregister.
A good example using MassMessage is the weekly Tech/News here in Meta. verdy_p (talk) 00:59, 10 May 2014 (UTC)

Privacy Policy-related Site notices not appearing on Special:Allmessages

As far as I can tell, e.g. MediaWiki:Centralnotice-PPChangeNotice2014-ToUAnnounceText1 isn't listed at Special:Allmessages (I went through, page by page, Ctrl-F-ing "changing on", and didn't find anything). Is this a bug? It Is Me Here t / c 17:08, 18 May 2014 (UTC)

AFAIK, not all pages in MediaWiki namespace are listed at Special:Allmessages. Special:PrefixIndex can be used as an alternative though. --Glaisher [talk] 17:27, 18 May 2014 (UTC)


Why OTRS tickets are hidden for non logged users? — The preceding unsigned comment was added by Rezonansowy (talk) 22 February 2014, 11:40 (UTC)

They can contain private information. PiRSquared17 (talk) 12:03, 22 February 2014 (UTC)
Good question. IMHO, it is needed so that people can contact Wikimedia privately and securely for things related to privacy issues (e.g. when reporting online harassment, or when reportingproblems with some admins or when someone wants to defend his position privately or appeal a decision; or when someone asks for the cration of a secret sockpuppet kept separate from another public account for editing some public contents, or when someone has had his privacy breached abusely about his current online account and wants a new account and have his old account deleted or blocked...). The OTRS team may then decide to unhide the ticket if it does not break a privacy rule and if the contacting person asks for publication of his ticket and his identity. The OTRS team may also choose to create an account (with a pseudonym) for that person asking for online privacy. If this possibilty is maintained in the OTRS system, it should be documented and the conditions to keep these tickets private should be governed by the privacy policy or the OTRS team policy. verdy_p (talk) 12:22, 22 February 2014 (UTC)
Also IMHO, I think that all tickets for issues submitted to the OTRS team should be initially private by default, including tickets from logged in users (for exampel they may need to send private proofs of identity to the Foundation, while being logged on to assert that he is effectively controling the public account for which he wants to associate this proven identity. For exampel a loggen on user may need to assert that he is effectively the owne of a copyrighted work that he submitted, or may need to prove to the Foundation (by being logged on security to his account) that his account is effectively the one asking for some admin privileges: within the ticket, that person may reveal privately his real name, email address, and other data covered by the privacy policy, without revealing it publicly to the world (most Wikimedia users and even most admins, including most developers or members of the Board of Trustees) should not have the right to inspect this private data, except possibly Checkusers, and authorized users of the OTRS team who will collectively decide if the secret can be safely thrown on the ticket, or that could edit the content of the secret ticket to publish only a part of it. verdy_p (talk) 12:42, 22 February 2014 (UTC)
On the other hand, if a copyright holder sues a person for using his copyrighted material, then it is up to the accused violator to prove that he has permission to use the material in the way he used it. If he can't do this (for example because the evidence is confidential), then he would probably lose in court, effectively meaning that the material is unfree. --Stefan2 (talk) 14:24, 26 February 2014 (UTC)
@PiRSquared17, Verdy p, and Stefan2: I think we should allow to set the OTRS tickets be public after review. We can form a policy for it. All private data could be hidden like this:
All work a n d no play makes Jack a dull boy,
All work and no play 
makes Jack a dull boy.
All work and no play makes Jack a dull boy...

Jack Torrance
Overlook Hotel, Colorado

And after:

All work a n d no play makes ■■■■ a dull boy,
All work and no play 
makes ■■■■ a dull boy.
All work and no play makes ■■■■ a dull boy...

Overlook Hotel, Colorado

— The preceding unsigned comment was added by Rezonansowy (talk)

@PiRSquared17, Verdy p, and Stefan2: What do you think?--Rezonansowy (talk) 10:50, 25 March 2014 (UTC)

Maybe you live in a lucky country which never had 20 years of fascist dictatorship, but at least in my country w:en:Secrecy of correspondence is a constitutional right. --Nemo 10:54, 25 March 2014 (UTC)
Thanks you; that's very well-phrased. However I agree with Stefan2 that parts from tickets grating permission could be publicly accessible provided the sender's consent. Therefore suggesting amending our e-Mail templates in this direction. -- Rillke (talk) 22:06, 25 March 2014 (UTC)
  • Why would anyone agree to this?
  • What practical benefit (other than satisfying people's curiosity) justifies creating a huge amount of work to the OTRS team? Protecting privacy requires human judgment. It can't be done through a simple script.
  • What would stop people from scamming this? Maybe I'd want to use this to discredit a politician, by sending in a damaging e-mail that, after "protecting his privacy", will still look like it was from him. Merely removing names from a statement like "I am Joe Politics, the leading candidate for President of Ruritania. Please remove the number of children I've had from the article about me, because I've actually got an illegitimate child that the media hasn't found out about yet" is not sufficient. WhatamIdoing (talk) 17:20, 26 March 2014 (UTC)

Guys, guys, actually I meant something like this proposed by Stefan2. I think the list of works with granted permission should be public. Also a little note about why tickets are hidden to the public (w:en:Secrecy of correspondence) would be nice. @Nemo bis: You're right :), I forgot this. --Rezonansowy (talk) 15:42, 29 March 2014 (UTC)

@PiRSquared17, Verdy p, and Stefan2:? — The preceding unsigned comment was added by Rezonansowy (talk)

Anyone??? --Rezonansowy (talk) 10:15, 17 April 2014 (UTC)

Ah. Isn't commons:Category:Items with OTRS permission confirmed enough then? I agree that it's better to ask a public licensing statement where possible (e.g. on Flickr; update docs where it's not the recommended method) but that's a bigger matter. I asked to add the link.[4] --Nemo 12:03, 18 April 2014 (UTC)
The main problem is that the OTRS system requires that most requests sent to this system will only be useful if they DO provide personal details to handle the issue (for example licencing requests where the requester proves hs identity and right on the content, or requests assistance in configuring a personal account, such as asking for an exclusion of the "no open proxy" for his IP address in order to create the account, and then provides his email address for the response. Requests must then reveal these details but only to the authorized OTRS ssystem members obeying to the strict OTRS privacy policy. Withut the details the OTRS is unusable and not useful for other people.
Also marking this way the private data would drain too much working time for OTRS members (by necessity, there are not a lot of them). If we want to keep OTRS members to the minimum, we must keep their working time as low as possible to only work on the issues themselves, but not to make such markup in order to hide the details and then create a publc version of each request.
OTRS then works better by keeping its effective content fully secret (visible only by a small selected group of authentified and trusted users, working cooperatively and each other monitoring their respective work so they cannot work alone; notably if they need to take decisions that should be appoved by another OTRS member). Bote that some actions taken by OTRS memvers are very limited; they should not discuss or make edits about public issues on the wikis (but if they need, they can leave a comment of their action by signing or marking their messages as "Decision of the OTRS team" (to facilitate the community review and the impact on the public content to give a short rationale explaining the decision taken without breaking the private details of the request they handled, such as "copyright violation", or "this content does not violate copyright", or "account creation approved for a secret user", with the public wiki signature of the OTRS member with his account name and a date).
All content sent to OTRS is assumed to be strictly private, and OTRS admins will then properly select the few elements and rephrase them if they need to communicate about some requests with the community while preserving the privacy of the requester: OTRS members should not copy-paste this content anywhere without extreme caution.. verdy_p (talk) 09:22, 7 May 2014 (UTC)
  • The problem is that if you don't know what the OTRS ticket says, then you do not know if the OTRS agent made a mistake or not, or if the person who sent the permission to OTRS was authorised to do so. Also, if you are sued, it is unclear if you could win in court by merely claiming that something is freely licensed for "confidential reasons" which you can't present in front of the court. If you do not have enough information to win in court, then the material is unfree as people can't use it in any way they like. Also, if users do not know whether their information is sufficient, the material is de facto unfree as the users do not know whether they will win in court, posing an extra use restriction on the material.
If you hide certain parts of OTRS messages, then you will still not know by whom the messages were sent, and you will still not know whether the person who sent the message was authorised to do so. I remember a case on Commons where someone accepted an OTRS ticket from someone claiming to be the child of a deceased author. Someone else later nominated the file for deletion, noting that the author didn't have any child, at least not of the correct gender. --Stefan2 (talk) 15:22, 21 May 2014 (UTC)

VisualEditor global newsletter—May 2014

This is a one-time mailing to projects that may need this information. Future newsletters will be available as opt-in only. To receive future newsletters (about one per month), please add your page to the subscribers' list at m:VisualEditor/Newsletter. You're welcome to translate to your language.

Since the last newsletter, the VisualEditor team has mostly worked on the new citation tool, improving performance, reducing technical debt, and other infrastructure needs.

Did you know?

The cite menu offers quick access to up to five citation templates.  If your wiki has enabled the "⧼visualeditor-toolbar-cite-label⧽" menu, press "⧼visualeditor-toolbar-cite-label⧽" and select the appropriate template from the menu.

Existing citations that use these templates can be edited either using the "⧼visualeditor-toolbar-cite-label⧽" tool or by selecting the reference and choosing the "⧼visualeditor-dialogbutton-reference-tooltip⧽" item in the "Insert" menu.

Read the user guide for more information.

The biggest change in the last few weeks is the new citation template menu, labeled "⧼visualeditor-toolbar-cite-label⧽". The new citation menu offers a locally configurable list of citation templates on the main toolbar. It adds or opens references using the simplified template dialog that was deployed last month. This tool is in addition to the "⧼visualeditor-dialogbutton-reference-tooltip⧽" item in the "Insert" menu, and it is not displayed unless it has been configured for that wiki. To enable this tool on your wiki, see the instructions at VisualEditor/Citation tool.

Eventually, the VisualEditor team plans to add autofill features for these citations. When this long-awaited feature is created, you could add an ISBN, URL, DOI or other identifier to the citation tool, and VisualEditor would automatically fill in as much information for that source as possible. The concept drawings can be seen at mw:VisualEditor/Design/Reference Dialog, and your ideas about making referencing quick and easy are still wanted.

  • There is a new Beta Feature for setting content language and direction.  This allows editors who have opted in to use the "Language" tool in the "Insert" menu to add HTML span tags that label text with the language and as being left-to-right (LTR) or right-to-left (RTL), like this:  <span lang="en" dir="ltr">English</span>. This tool is most useful for pages whose text combines multiple languages with different directions, common on Right-to-Left wikis.
  • The tool for editing mathematics formulae in VisualEditor has been slightly updated and is now available to all users, as the "⧼math-visualeditor-mwmathinspector-title⧽" item in the "Insert" menu. It uses LaTeX like in the wikitext editor.
  • The layout of template dialogs has been changed, putting the label above the field.  Parameters are now called "fields", to avoid a technical term that many editors are unfamiliar with.
  • TemplateData has been expanded:  You can now add "suggested" parameters in TemplateData, and VisualEditor will display them in the template dialogs like required ones.  "Suggested" is recommended for parameters that are commonly used, but not actually required to make the template work.  There is also a new type for TemplateData parameters: wiki-file-name, for file names.  The template tool can now tell you if a parameter is marked as being obsolete.
  • Some templates that previously displayed strangely due to absolute CSS positioning hacks should now display correctly.
  • Several messages have changed: The notices shown when you save a page have been merged into those used in the wikitext editor, for consistency.  The message shown when you "⧼visualeditor-toolbar-cancel⧽" out of an edit is clearer. The beta dialog notice, which is shown the first time you open VisualEditor, will be hidden for logged-in users via a user preference rather than a cookie.  As a result of this change, the beta notice will show up one last time for all logged-in users on their next VisualEditor use after Thursday's upgrade.
  • Adding a category that is a redirect to another category prompts you to add the target category instead of the redirect.
  • In the "Images and media" dialog, it is no longer possible to set a redundant border for thumbnail and framed images.
  • There is a new Template Documentation Editor for TemplateData.  You can test it by editing a documentation subpage (not a template page) at edit mw:Template:Sandbox/doc, and then click "Manage template documentation" above the wikitext edit box.  If your community would like to use this TemplateData editor at your project, please contact product manager James Forrester or file an enhancement request in Bugzilla.
  • There have been multiple small changes to the appearance:  External links are shown in the same light blue color as in MediaWiki.  This is a lighter shade of blue than the internal links.  The styling of the "Style text" (character formatting) drop-down menu has been synchronized with the recent font changes to the Vector skin.  VisualEditor dialogs, such as the "⧼visualeditor-toolbar-savedialog⧽" dialog, now use a "loading" animation of moving lines, rather than animated GIF images.  Other changes were made to the appearance upon opening a page in VisualEditor which should make the transition between reading and editing be smoother.
  • The developers merged in many minor fixes and improvements to MediaWiki interface integration (e.g., edit notices), and made VisualEditor handle Education Program pages better.
  • At the request of the community, VisualEditor has been deployed to Commons as an opt-in. It is currently available by default for 161 Wikipedia language editions and by opt-in through Beta Features at all others, as well as on several non-Wikipedia sites.

Looking ahead:  The toolbar from the PageTriage extension will no longer be visible inside VisualEditor. More buttons and icons will be accessible from the keyboard.  The "Keyboard shortcuts" link will be moved out of the "Page options" menu, into the "Help" menu. Support for upright image sizes (preferred for accessibility) and inline images is being developed. You will be able to see the Table of Contents while editing. Looking further out, the developers are also working on support for viewing and editing hidden HTML comments. VisualEditor will be available to all users on mobile devices and tablet computers. It will be possible to upload images to Commons from inside VisualEditor.

If you have questions or suggestions for future improvements, or if you encounter problems, please let everyone know by posting a note at mw:VisualEditor/Feedback or by joining the office hours on Thursday, 19 June 2014 at 10:00 UTC. If you'd like to get this newsletter on your own page (about once a month), please subscribe at w:en:Wikipedia:VisualEditor/Newsletter for English Wikipedia only or at Meta for any project. Thank you! --Elitre (WMF) (talk) 17:39, 22 May 2014 (UTC)