Talk:Global notifications/Archive 1

Wikimedia notification system

Do you have any process to let Wikipedians translate it into their language? Or you just copy and paste the English version to every languages and let it be? Have you announced anyone in those projects about what this is and what this is for? Very useless if you write but most of people DO NOT understand it. Vinhtantran 07:01, 5 November 2008 (UTC)

There will be machine translation links on top (Google, Babelfish & Co.); a placeholder is already there! How to translate all that texts into 250++ languages voluntarily? --- Regards, Melancholie 07:09, 5 November 2008 (UTC)

Somebody must do that, right? We should have a process and guideline about where the notifier will be updated (it had) and where should people will translate it. Machine translation is good for some popular language but dummy for less one (like Vietnamese). I was disappointed when I tried to translate but then it was overwrite by bot. Let me suggest, why don't you make your script to make id for the news, and after that you add or remove news, do not have to replace all? Vinhtantran 07:24, 5 November 2008 (UTC)

Translating is no problem at all; just translate it on your wiki if you want, but on another page. If I would just add and add news for news, on some wikis that page would get *huge*, as nobody is empying it (like the CommonsDelinker stuff for example), spam/vandalism sometimes wouldn't get recognised, after page changes sections couldn't be removed; furthermore changes and/or corrections have to be synchronized! Shall I write something about how to translate without losing content? --- Best regards, Melancholie 07:31, 5 November 2008 (UTC)

As I suggest above, why don't you assign ID for div tag of every news? You only have to make sure that there are id 1, 2, 3,... on every languages, you paste the fresh English content for new ID, and let people translate as they want. If some news get old or need updated, you just read the page, parse the content and remove the old ID, then post what left. About the spam, everybody who cares about news and reads it will recognize spam and remove it for you. Vinhtantran 07:42, 5 November 2008 (UTC)

Well, numbering (or text ID) would be possible (removing would require replace.py though), but I would like to have pages properly synchronized each time (new info, changed links, corrections, necessary position changes etc.). Will consider other method anyway... --- Best regards, Melancholie 07:51, 5 November 2008 (UTC)

Okay, so you should note in the Wikimedia notification system notice that "please do not make changes or translate in the synchronzed page because it will be overwritten sooner or later." Thank you for this news spreading idea and for answering me. Cheers, Vinhtantran 07:55, 5 November 2008 (UTC)

Did so! Thank you very much for your intervention :-) Do not understand me wrong, but I think an other method would make more problems (on my side), as I cannot control pages on all wikis properly (initially wanted to use .../*.js). Will also leave a HTML comment, so people should see what's going on. --- Best regards, Melancholie 08:22, 5 November 2008 (UTC)

For a FAQ page, now see Global notifications/how-to#translation and Global_notifications/how-to#sync. --Melancholie 06:20, 12 November 2008 (UTC)

User:WikimediaNotifier/translation

Hi, I'm a jawp user (sysop), and one of translaters of Global Notifications into Japanese at jawp's page w:ja:Wikipedia:お知らせ/ウィキメディア共通 (w:ja:WP:NEWS/G). Thank you for your useful and interesting notifications! I have a question about "User:WikimediaNotifier/translation" page. You (User:WikimediaNotifier) added each links of [local translation] for each messages on 05:14, 11 November 2008 (UTC) at jawp, but how can or should we use those links and "User:WikimediaNotifier/translation" page? We translate your all messages (included message's title), so those links will not work good when we use the page for local translation page. Or only set the link to local translation page? Sorry for my bad English! --aokomoriuta 10:55, 11 November 2008 (UTC)

Nice to see that the messages are translated that often (I think I underestimated the urgent need of locally translated pages :-). I changed the page title in User:WikimediaNotifier/translation, then I added an URL anchor to your translated page as an example, see diff (but you can also remove that #{{{topic}}} in ja:User:WikimediaNotifier/template for example, if the link is not desired at all).

To create anchors, use: <span id="anchor" name="anchor">...</span> (either within, or above == ... ==)

Best regards, Melancholie 12:28, 11 November 2008 (UTC)

P.s.: What should also work (not sure if for all browsers) is <span id="anchor" name="anchor" /> --- Greetings, Melancholie 12:43, 11 November 2008 (UTC)

Thank you for your revisions at jawp! I added each anchors with w:ja:Template:Anchor, so the links (on w:ja:User:WikimediaNotifier/translation) work well now. By the way, I found localized "global notification" at frwp and cawp, but I think there're more translation pages at other project. So why don't you make a list of localized GN pages?--aokomoriuta 18:02, 11 November 2008 (UTC)

For a help page, now see Global notifications/how-to#translation and Global_notifications/how-to#anchors. --Melancholie 06:20, 12 November 2008 (UTC)

External Wikipedia Survey

This link is not (or no more?) functional.--Eruedin 12:53, 18 November 2008 (UTC)

Yes, thanks! "The survey is closed." -- will remove it. --- Best regards, Melancholie 11:26, 19 November 2008 (UTC)

GNU Free Documentation License 1.3

Can we publish(cite) Wikipedia's content under the GFDL-CC-BY-SA-3.0 dual license?--Kwj2772 07:53, 10 November 2008 (UTC)

If your community will vote for that in its majority, yes. But I would wait until the Foundation gives us detailed information about what has to be considered before; I'm not an advocate ;-) --- Best regards, Melancholie 09:23, 10 November 2008 (UTC)

I saw the sentence that the Wikimedia Foundation will organize community-wide referendum. will it be organized globally? or individually? If the referendum is organuzed globally, when will it be held? --Kwj2772 13:42, 12 November 2008 (UTC)

We may ask User:Eloquence (Erik Möller; Deputy Director), he should know. I will make him aware of this discussion! --- Best regards, Melancholie 14:43, 12 November 2008 (UTC)

Fundraising 2008

A new banner was enabled in Wikisource, but talk about donation of Wikipedia. I guess that the message should be project-sensitive, i.e. the banner in Wikisource should talk about donation of Wikisource. -- Sergey kudryavtsev 07:52, 11 November 2008 (UTC)

Hmm, which Wikisource? On en:s:Main_Page I see "Wikisource relies on your donations: please give today." and " Wikisource: Making Life Easier. " etc. Maybe a mistake in the translation for your language? --- Best regards, Melancholie 10:30, 11 November 2008 (UTC)

In Russian Wikisource. But somebody change the message several hours ago. Now the message seems according my proposal (but grammatically incorrect: invalid case). -- Sergey kudryavtsev 13:00, 11 November 2008 (UTC)

Namespace: Image => File

this will soon become a general "File:" namespace!

But when will it be? What date?--Ahonc 22:37, 5 November 2008 (UTC)

That is a good question ;-) It actually should have been done already in the middle of October, see mailarchive:wikitech-l/2008-October/039670.html (w:Real_soon_now ;-) But it just might be suddenly change some day... --- MfG, Melancholie 22:52, 5 November 2008 (UTC)

I disagree with the proposed namespace name. It's still not for the general storage of "files", but only for media files, i.e. the file types that are appropriate for a storage separated from its description page. I think the the prefix should have been "media:".

Also I do think that the "image:" prefix should not be deprecated at all. For me it will continue to mean "show me an image, possibly a thumnail, for the media that is stored under this name and described in the "media:" page. So a link to [[media:xxx.jpg]] should NEVER attempt to display any image but would just point to the description page of the media, even if it's an image.

For the same reason, there may exist several other prefixes used to transform a media file described and stored in the media:" namespace to another format.

Just think about the prefixes that could perform some data format conversion or extractions (for example taking a snapshot from a part of a video, or extracting an image from a page in a PDF, or converting audio formats to reduced quality, or to play just a small fragment of the audio or video file). Each converter (like [[image:]] itself) would have its own prefix, even if all files are stored in the same media files namespace. Each prefix ("image:", "audio:") would have its own set of options (images already support "thumb" presentation, resize options, and title options, but the size and thumb parameters do not make a lot of sense for audio files, or even PDFs that have multiple pages).

Well, after thinking about all this, you can still continue to call it "file:" instead of "media:", but please don't deprecate "image:" and think about the future to support more media converters/renderers/extractors that will need their own options and whose options MUST NOT become ambiguous or conflicting. The way I think it, "file:" will be the namespace, be "image:" will no longer be a true namespace but the indication that the referenced media file is to be rendered as an image.

If you need a terminology for this, I call it a "renderer prefix" instead of a "namespace". Keep the term "namespace' ONLY for names that point directly to a Wiki page (this will include "file:" because it points to a description page using Wiki syntax).

If you still want to keep the term "namespace", then subdivide it in two sets: a "wikispace" for most existing namespaces, and the "renderer prefix" for "image:" (and future "audioplayer:", "videoplayer:", "pdfpager:", "chatroom:", or "livecontact")... verdy_p 09:47, 10 December 2008 (UTC)

Note that live rendering may even become dynamic, such as IRC chatrooms that could be integreted as supported objects that can be rendered and embedded in Wiki pages as a simple rectangular object; just think about the possibility of contacting users directly by audio when they are connected, using a free protocol like Jabber: those discussions would not necessarily be supported by the Foundation, but by some other supported providers that offer free user-to-user VoIP services over the Internet: no more need to display the contact online by saving it on a user page: the Wikimedia server keeps this live contact address private but can relay the request to a connected user that can accept or not the communication without forcing users to reveal this contact address publicly on a stored Wiki page that maintains an undesirable archived history.). verdy_p 09:47, 10 December 2008 (UTC)

You are absolutely right. You could add this to bug 44, or file a new request for an "individually rendered prefix". I do not think that the devs will split this namespace, and renaming to the more general, broader term "file" has been submitted. But rendering the prefix (alias) individually might be a good thing for usability/intuitiveness. --- Best regards, Melancholie 20:08, 11 December 2008 (UTC)

P.s.: Using "Media:" instead of "File:" might not be that easy as "Media:" is already reserved, behaving differently than "Image"/"File". --- Regards, Melancholie 20:12, 11 December 2008 (UTC)

Edit summaries

Can we please ensure the edit summaries don't have redlinks in them by linking to Special:Inexistant etc? This is exceedingly annoying.  — Mike.lifeguard | ^@en.wb 18:33, 11 November 2008 (UTC)

Always, or would you say for new messages this would be OK? It's just that this is more eye-catchy within sometimes pretty crowded RecentChanges. --- Best regards (and sorry for any annoyance), Melancholie 04:16, 12 November 2008 (UTC)

You should not be counting on it being seen in RC in any case. I'm not sure what you mean by "always, or... for new messages" -- the ones you have already done have redlinks in the edit summaries, which cannot be changed. So for the future, please don't do that. An informative edit summary is the best; a generic one without annoyances is second-best. Thanks.  — Mike.lifeguard | ^@en.wb 05:58, 12 November 2008 (UTC)

I just considered to alert people if there is a new notification, but not on minor changes/updates. Will remove the red links; no problem. --- Was just an idea, Melancholie 06:06, 12 November 2008 (UTC)

What is this?

Lately I've stumbled upon a bot called WikimediaNotifier, it seems to hold accounts on several wikis. The bots copies this content page infrequently, but often. What exactly is the purpose of this?And why has noone been notified about this notifier yet? AndersL 16:54, 12 November 2008 (UTC)

See Global_notifications#Wikimedia_notification_system. Hmm, who/what could better notify about this notifier as this notifier itself? --- Best regards, Melancholie 17:23, 12 November 2008 (UTC)

Doh, thats the content page to this talk page, Ive already seen that. My point was:Why not use village pumps that most people actually reads, instead of creating a (probably a potentially great) service that none or few wikipdians knows about, unless they stumble upon it? AndersL 17:48, 12 November 2008 (UTC)

That is every projects choice where to put it, for example I have included it on this page on de.wikt [1], on es.wikt [2] and created a new page for another wikt I am aktive because it did not yet fit anywhere. So You can decide where it would be best seen in Your project. Hope that helps. Best regards, --birdy geimfyglið _(:> )=| 17:54, 12 November 2008 (UTC)

@AndersL: Yes, I considered that. But that would need to append the messages, without a proper possibility of updating content afterwards. But I may do that when this notifying system has been properly established. At the moment it is important for me to have one common access point (within a "tolerated" user namespace), not that many different village pumps (where "bot" blocks are likely then, don't really like the resulting discussions). It's up to the communities whether they want such notifications on their village pump pages. Currently, it is possible to include {User:WikimediaNotifier/notifications} or to include only a list of topics, see Global notifications/how-to#onlyTOC. In future anything is possible, though. --- Best regards, Melancholie 18:11, 12 November 2008 (UTC)

Wikibooks logo voting

broken image link

Hello Melancholie, WikimediaNotifier created a broken image link at [3]: There is a link to Image:B where there should in fact be a link to Image:Wikibooks-logo.svg. Greetings, --UV 21:56, 17 November 2008 (UTC)

Yes, thank you very much for this hint. I saw that too, but unfortunately just some minutes ago. Sorry for that! The reason is that I missed to make a RegExp, necessary for MediaWiki based lang/wiki variables, restrictive enough to only replace strings in specific places; links did work, but not images containing a project name. I will fix that... --- Best regards, Melancholie 00:11, 18 November 2008 (UTC)

And update the messages that were already sent out?  — Mike.lifeguard | ^@en.wb 00:21, 18 November 2008 (UTC)

Yes, I already had fixed the script; will fix the local pages with the next run. --- Best regards, Melancholie 00:25, 18 November 2008 (UTC)

FlaggedRevs review feature

ko.wp had relevant discussion. (see ko:위키백과:사랑방/2008년 제46주#검토판 기능 (FlaggedRevs)) Some user opposed because this feature FlaggedRevs may interrupt editing from anonymous account. Other protesters consisted Korean Wikipedia has not enough user who has professional knowledge and who will review every page. (I'm just mirroring users' response. I don't oppose to enable this feature.)--Kwj2772 15:16, 4 December 2008 (UTC)

Yes, having too few experts for "reviewing" articles is also a problem on the German Wikipedia so far. The "review" feature isn't used there too, yet. But my opinion is: Every single reviewed article would be great ;-) But, like I wrote only the enhanced patrolling feature is used on dewiki and on most of the other wikis that use FlaggedRevs at the moment. Note, that you can define whether the latest sighted revision (like on dewiki) or the very most current revision (like now, like usual) is shown to the public. The second one (called "patrolling-") configuration is more gentle to anonymous accounts, as the latest article version is shown by default. The big advantage of FlaggedRevs is that your articles get statuses, so no edit will be missed to be viewed by someone anymore! You would wonder how many 'bad' edits are going through on enwiki, as the usual RecentChanges patrol staff sometimes cannot cope with the huge amount of changes. With FlaggedRevs someone has to check a change. Quality will increase, especially if the dewiki configuration is used (as 'bad' edits sometimes are visible for a long time, and no single person should get a bad article version for reading!). --- Nice regards, Melancholie 17:56, 4 December 2008 (UTC)

I wish FLR extension was not installed automatically in every wiki. Especially small wikis, have very few experts and reviewers. I don't think FlaggedRevs will enforce to improve articles' quality in small wikis. FlaggedRevs in small wikis may prevent newbies' contributions so developing quality will be more difficult. So I suggest this extension should be installed in large wikis only. Or installing FLR also in small wiki, and choose a configuration which is more gentle to anonymous.--Kwj2772 13:01, 7 December 2008 (UTC)

FlaggedRevs will not be installed automatically on every wiki ;-) Every community has to request this extension, individually. --- Nice regards, Melancholie 20:58, 7 December 2008 (UTC)

Please use subpages!

It would be better if EACH global notification used a specific subpage and included a date of posting in the message. My opinion is that the subpage name should contain this date and time and a language code (like User:WikimediaNotifier/notifications/2008-12-31_23:59:00_UTC/en if your post was in English), or a distinctive title plus a language code.

Then the main page that contains all global notifications would just transclude each notitication subpage ; so the page User:WikimediaNotifier/notifications would just contain a list of subpage transclusions: the first one contains a common header that could be updated and would be transcluded from User:WikimediaNotifier/notifications/header using {{/header}} in the first row of the page, followed by the list of transclusions like {{/2008-12-31_23:59/en}} if your post was initially in English and nothing else.

In addition, when posting a new global notification, you should update a redirect link (User:WikimediaNotifier/notifications/latest will always be a redirect page pointing to the latest notification posted) that points to the last subpage you have created for your last global notification. This redirect link would then be the one to monitor for changes. This would also allow displaying ONLY the latest notification within community portals, that could import only this one like this {{User:WikimediaNotifier/notifications/latest}}. Such Global notitification should however remain small, like the simple full-width banners that you already use. It should not be a complete page (use a link in your posted banner to point to longer information).

verdy_p 08:33, 10 December 2008 (UTC)

As another idea: each of your notification subpages shuold also have its own subpage for the local translation, with a name that your posted banner will indicate for the creation of the translation. If someone creates the translation, your posting bot could detect it in the few hours that follow you initial posting, and see where it has been translated (say on Wikipedia for example), and then it could automatically update other wikis in that same language (say Wikibooks, Wikinews, Wiktionary...) to mirror this translation, avoiding duplicate work on all wikis for the same language. As an alternative, you can also force the translation link given by your banner to point only to a Wikipedia place even if you have posted your notification subpage in Wiktionary or Wikinews.

Well I've seen that your notifications page includes a way that allows to just view their embedded TOC. Please be careful (when updating your notifications) that the TOC is correctly programmed (no missing {} and no problems in the templates used by your notifications if they assume that they work identically on all wikis. I think that it's still quite dangerous to include the TOC using {{User:WikimediaNotifier/notifications|onlyTOC=1}}, notably within a community portal. It would be MUCH safer if this rendering did not depend on a parameter. The TOC should be a subpage as well, i.e. available directly at User:WikimediaNotifier/notifications/TOC. verdy_p 09:52, 10 December 2008 (UTC)

That's a good idea! Making subpages would solve some problems in addition, see [FAQ/how-to]. But I am not quite sure whether making several 'bot' edits at once and creating that many remaining sub pages isn't going to enrage some communities too much. But when I will have time to change this, I will alter the system's behaviour. The main issue is your point regarding central translations, that's really a good point. --- Thank you very much for suggesting this, Melancholie 20:27, 11 December 2008 (UTC)

Temp user pages

It would be good for user pages (and only in this namespace) to offer a way to COMPLETELY REMOVE their history (it could be a preference option that says: don't store any history for user subpages that start with "/temp"). These temp pages would be completely protected except for the user itself, they could still be public by default.

The main reason why such pages hould exist is to allow users to temporarily post a contact address that can be dropped completely: using a normal wiki page does not prevent further access to the page, unless the user asks to an admin to completely and immediately suppress his personal page or subpage, but genereally this can't be performed immediately.

Another application of these temp pages is for allowing users to create their own sandbox (which can still be publicly readable), with minimum overhead on the server: they can edit these pages as many times as they want, as there will be no history, and they can decide to delete these pages immediately and completely, without having to ask to an admin to remove the public access to the page history.

Admins should not even have the right to modify these personnal "temp" pages (but they can delete them if they are illegal or if they are found offensive and referenced or included in other public pages).

Admins would also be allowed to make these pages non public (visible only for the user that will then have no other option than just retreiving their data or deleting them completely : this is a way to avoid the Wikimedia storage space for storing and managing a personnal agenda).

Only the user can modify those "temp" pages (as long as they remain publicly accessible in readonly mode; if the user or an admin makes these temp pages private, they can no longer be modified at all, they can just be read by the owner and a very restricted set of "super-admins" such as those with IP-check privilege, or deleted completely); these user temp pages should have NO publicly accessible history (even if they are accessible in read-only mode to the public): ALL modifications made by the user are permanent, and there acn be NO rollback, exactly because there's NO history at all (and that's the main reason why those pages should be absolutely readonly for everyone except the user itself.

-- verdy_p 09:47, 10 December 2008 (UTC)

Hmm, I am not able to follow your considerations here. What topic is this referring to? --- Not sure what you mean, Melancholie 20:27, 11 December 2008 (UTC)

Get up to 1,000 € for translating!

Edit summaries like this are unacceptably annoying. Please don't do that again.  — Mike.lifeguard | ^@en.wb 20:40, 25 December 2008 (UTC)

It is fantastic that you put this on the global wire, Melancholie. I stumbled across it by accident. Betawiki has seen its busiest day ever on 25 December 2008. Users have contributed close to 6,000 edits to translations (for all products together). One user has already contributed 500 new translations to MediaWiki (in German) in the first day the bounty is open. We hope many will follow, so the need of the many will eventually outweigh the wish of the few :). Please do not hesitate and spend an hour a day for the next 6 days on Betawiki translating messages to your language. It is fun, it is needed, and you will help all speakers of your language find a more native home in every MediaWiki they visit. Cheers! Siebrand 00:14, 26 December 2008 (UTC)

Translation of the Week

Hi, I am very happy to see that TOTW is part of the global notifications, since it is undoubtedly a very important project. I would like to propose using the official TOWT-logo instead of the current one used for global notifications. Best regards --Marbot 22:57, 28 November 2008 (UTC)

Yes, that's much better :-) --- Thanks, Melancholie 10:33, 29 November 2008 (UTC)

I love it! Thank you. :-) --Marbot 14:35, 30 November 2008 (UTC)