Hi,
In future, we will switch to completely new system of on-wiki
configuration. This will be a major change from dev point of view as
we are going to use standardised YAML format for on-wiki
configuration.
I already started drafting new config, you can see
https://test.wikipedia.org/wiki/Wikipedia:Huggle/Config.yaml for
already working version of new config.
This new format will allow for great many new features, most notable
we will finally have ability to properly escape any string, which
wasn't possible as of now. This format has strict parser which will
throw errors in case there are syntax errors and thus making syntax
mistake will no longer be easily unnoticed.
It is also properly supported by syntax highlighter so the config
pages will be easier to read.
Old format will be deprecated, but still supported for some time.
This means, we have a chance to rework completely whole project
configuration page, which is kinda messy right now, and do it right.
Final format and structure is not yet decided, so NOW it is time to
suggest changes and improvements. If you have idea about anything or
don't like how something work with current Huggle project
configuration, now it's time to fix it!
According to <
https://lists.wikimedia.org/pipermail/huggle/2017-July/000173.html> the
original message by Declan Martin has not been delivered to the list,
possibly due to the known yahoo issues with Wikimedia mailing lists. I am
copying below my reply and his original message below so those looking at
this thread can know what this is about.
---------- Forwarded message begins ----------
From: MarcoAurelio <strigiwm(a)gmail.com>
Date: 2017-07-20 0:17 GMT+02:00
Subject: Re: [Huggle] Login issue
To: List for huggle developers and support <huggle(a)lists.wikimedia.org>
Hmpf, it seems that on MacOs it is possible to use OAuth as oposed to
BotPasswords on Windows? In any case, the working is similar. I am not a
huggle dev but an user. First that comes to my mind is that you did not
authorize huggle to use rollback on enwiki. If you're using
OAuth/BotPasswords be sure to select too a group of permissions that allows
the application to use rollback. If you already have done that, be also
sure that you've Special:Mypage/huggle.css and Special:Mypage/huggle3.css
configured correctly (enable:true). If nothing helps, hopefully a more
experienced user will reply or you can create a ticket in the Huggle
project of the phabricator.wikimedia.org issue tracker. I hope that your
issue gets resolved soon.
Best regards, M.A.
El El lun, 17 jul 2017 a las 19:43, Declan Martin <declanmatthew(a)yahoo.com>
escribió:
> Hi,
> I’m getting the "Login failed on enwiki: You don't have rollback
> permissions on this project.” message when I attempt do login. I do have
> rollback permission and have used it many times. I tried getting help on
> IRC, but no one was online.
>
> Cheers,
> Dmartin969
>
> _______________________________________________
> Huggle mailing list
> Huggle(a)lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/huggle
Hi,
I’m getting the "Login failed on enwiki: You don't have rollback permissions on this project.” message when I attempt do login. I do have rollback permission and have used it many times. I tried getting help on IRC, but no one was online.
Cheers,
Dmartin969
Hi all,
I would like to inform you that new version of Huggle was released. We
are still lacking builds for Linux and MacOS, but I hope that will be
fixed soon.
This version has a massive diff of changes compared to last one and it
also took pretty long for us to release it (due to lack of active
devs). I hope that we will be faster in future when it comes to
releases, hopefully if I manage to automate packaging a bit, it
shouldn't be so much of a problem.
Most significant change and reason why it's minor version was
incremented is support for web engine based on Chromium, which also
allowed us to switch to newer Qt 5.7. So all Windows builds are now
running on newer Qt and use Chromium instead of WebKit.
Full changelog can be seen here:
https://github.com/huggle/huggle3-qt-lx/compare/3.1.22...3.2.0
Thank you
Hi all,
This is just a friendly reminder that we plan to turn off the RCStream
service after July 7th.
We’re tracking as best we can the progress of porting clients over at
https://phabricator.wikimedia.org/T156919. But, we can only help with what
we know about. If you’ve got something still running on RCStream that
hasn’t yet ported, let us know, and/or switch soon!
Thanks!
-Andrew Otto
On Wed, Feb 8, 2017 at 9:28 AM, Andrew Otto <otto(a)wikimedia.org> wrote:
> Hi everyone!
>
> Wikimedia is releasing a new service today: EventStreams
> <https://wikitech.wikimedia.org/wiki/EventStreams>. This service allows
> us to publish arbitrary streams of JSON event data to the public.
> Initially, the only stream available will be good ol’ RecentChanges
> <https://www.mediawiki.org/wiki/Manual:RCFeed>. This event stream
> overlaps functionality already provided by irc.wikimedia.org and RCStream
> <https://wikitech.wikimedia.org/wiki/RCStream>. However, this new
> service has advantages over these (now deprecated) services.
>
>
> 1.
>
> We can expose more than just RecentChanges.
> 2.
>
> Events are delivered over streaming HTTP (chunked transfer) instead of
> IRC or socket.io. This requires less client side code and fewer
> special routing cases on the server side.
> 3.
>
> Streams can be resumed from the past. By using EventSource, a
> disconnected client will automatically resume the stream from where it left
> off, as long as it resumes within one week. In the future, we would like
> to allow users to specify historical timestamps from which they would like
> to begin consuming, if this proves safe and tractable.
>
>
> I did say deprecated! Okay okay, we may never be able to fully deprecate
> irc.wikimedia.org. It’s used by too many (probably sentient by now) bots
> out there. We do plan to obsolete RCStream, and to turn it off in a
> reasonable amount of time. The deadline iiiiiis July 7th, 2017. All
> services that rely on RCStream should migrate to the HTTP based
> EventStreams service by this date. We are committed to assisting you in
> this transition, so let us know how we can help.
>
> Unfortunately, unlike RCStream, EventStreams does not have server side
> event filtering (e.g. by wiki) quite yet. How and if this should be done
> is still under discussion <https://phabricator.wikimedia.org/T152731>.
>
> The RecentChanges data you are used to remains the same, and is available
> at https://stream.wikimedia.org/v2/stream/recentchange. However, we may
> have something different for you, if you find it useful. We have been
> internally producing new Mediawiki specific events
> <https://github.com/wikimedia/mediawiki-event-schemas/tree/master/jsonschema…>
> for a while now, and could expose these via EventStreams as well.
>
> Take a look at these events, and tell us what you think. Would you find
> them useful? How would you like to subscribe to them? Individually as
> separate streams, or would you like to be able to compose multiple event
> types into a single stream via an API? These things are all possible.
>
> I asked for a lot of feedback in the above paragraphs. Let’s try and
> centralize this discussion over on the mediawiki.org EventStreams talk
> page <https://www.mediawiki.org/wiki/Talk:EventStreams>. In summary,
> the questions are:
>
>
> -
>
> What RCStream clients do you maintain, and how can we help you migrate
> to EventStreams?
> <https://www.mediawiki.org/wiki/Topic:Tkjkee2j684hkwc9>
> -
>
> Is server side filtering, by wiki or arbitrary event field, useful to
> you? <https://www.mediawiki.org/wiki/Topic:Tkjkabtyakpm967t>
> -
>
> Would you like to consume streams other than RecentChanges?
> <https://www.mediawiki.org/wiki/Topic:Tkjk4ezxb4u01a61> (Currently
> available events are described here
> <https://github.com/wikimedia/mediawiki-event-schemas/tree/master/jsonschema…>
> .)
>
>
>
> Thanks!
> - Andrew Otto
>
>
>