Sorry for cross-posting!
Reminder: Technical Advice IRC meeting again **tomorrow, Wednesday 4-5 pm
UTC** on #wikimedia-tech.
The Technical Advice IRC meeting is open for all volunteer developers,
topics and questions. This can be anything from "how to get started" over
"who would be the best contact for X" to specific questions on your project.
If you know already what you would like to discuss or ask, please add your
topic to the next meeting: https://www.mediawiki.org/wiki/Technical_Advice_
IRC_Meeting
**Please note:** We will do a two week break due to the holiday season!
This will be the last Meeting for 2017, the next meeting after this will be
on January 3rd 2018!
Hope to see you there!
Michi (for WMDE’s tech team)
--
Michael F. Schönitzer
Wikimedia Deutschland e.V. | Tempelhofer Ufer 23-24 | 10963 Berlin
Tel. (030) 219 158 26-0
http://wikimedia.de
Stellen Sie sich eine Welt vor, in der jeder Mensch an der Menge allen
Wissens frei teilhaben kann. Helfen Sie uns dabei!
http://spenden.wikimedia.de/
Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V.
Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter
der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für
Körperschaften I Berlin, Steuernummer 27/681/51985.
Hey guys,
some years ago I stumbled across the FLIF-format, which might be very
interesting for wikimedia commons and/or Mediawiki in general.
I try to summon the fileformat and it's advantages a bit:
It's a free, patent free, lossless image compression format, which
supports RGB(A) / greyscale images as well as palette-images.
FLIF also supports animations and 16 bit/channel color-deph for still
images as well as animations. embedded ICC color profiles, Exif and XMP
metadata are supported. They started to work on RGGB-raw-file-support,
but this is not fully implemented right now.
There's a small JavaScript library which can be used until there's a
browser support given, so theres no need to wait until there is
browser-support.
A small portion of a FLIF file, can be decoded as well (progressive
decoding).
For thumbnails we can simply load a 5-10% portion of a multi-mb file and
show this as a thumbnail. If a user want a larger view, later, we just
fetch some additional data to the already saved one, removing the need
to fully download the same 'data' again.
It's also great for resposive designs, where the user might rotate his
device and know need a 50% larger resolution of the same file.
If the user click on that image, to get a fullscreen popup we can also
use the thumbnail-data and just fetch some additional KB to fullfil this
requirement of a larger resolution.
Also the browser might start rendering with a 1% portion of the file,
and show a low quality image. When some more percent are downloaded, the
browser can update the low quality image with a larger one.
###
My idea was, to convert all new uploads to FLIF at the time we receive
those files. So JPGs get a lot larger, GIF and PNG some KB smaller, but
the most interesting advantage is: we do not get any generation-loss
anymore:
If someone upload a JPG-file, we save it to FLIF. If someone want to
edit the file again, he need to download the FLIF and read it nativly
with an application or download it as PNG and upload the edited file
again as PNG. We then simply convert it back to FLIF for storage.
###
There's also an advantage for the caching proxies, they does not need to
handle image files in various sizes, which should simplify the overhead,
because we use just one filename and url for all views on that file.
###
I hope I found the right place to discuss this topic, have a nice
weekend! :)
Best regards
Ruben
Hey everyone,
The voting phase of the 2017 Community Wishlist Survey has now started.
Read the proposals and support the ones you want to support to make the
wikis better:
https://meta.wikimedia.org/wiki/2017_Community_Wishlist_Survey
Click on the categories to find the proposals. The voting will close on
December 10.
That's the important part of this email. Feel free to follow the link above
and starting voting right now.
The longer version:
The Community Wishlist Survey decides what the Wikimedia Foundation
Community Tech team will work on over the next year. The team is responsible
for addressing the top 10 wishes on the list, as well as some wishes from
smaller groups and projects that are doing important work, but don't have
the numbers to get their proposal into the top 10. The Wishlist is also
used by volunteer developers and other teams, who want to find projects to
work on that the community really wants.
Come help set the agenda.
If you want to see what the team has done in 2017, see the status report
from last month:
https://meta.wikimedia.org/wiki/2016_Community_Wishlist_Survey/Status_repor…
What you can do now:
*) Vote. This is the most important thing.
*) Spread the word. We really want people to find this, of course, and
we'll work on finding the best balance between spreading the news to
everyone and not being annoying, but please do help to spread the
information in your local community – Village Pump equivalents, IRC
channels, social media groups and so on.
*) Help translating the pages. We want the process to be as available as
possible for everyone. It's not every available if it's only in English.
*) If you want to get short updates through the notification system, you
can sign up for the Community Tech Newsletter:
https://www.mediawiki.org/wiki/Newsletter:The_Community_Tech_Newsletter
//Johan Jönsson
--
The language engineering monthly reports for September, October and
November 2017 are ready.
**Highlights for these months**
* Lots of usability and design improvements to the Content Translation
dashboard.
* There is now a way to link directly to a particular message in
Special:Translate.
* Mediawiki Language Extension Bundle 2017.10 was released.
* Style updates in Universal Language Selector and Translate to align
with WikimediaUI styleguide.
* Translatable pages are now editable with the 2017 wikitext editor.
* An issue that made it difficult to log in or save translations in
translatewiki.net was investigated and resolved.
* Translate recent changes filters now support the new filter user interface.
* The old Translate extension translation view interface was finally
removed after four and half years.
* Universal Language Selector search is much improved. It now returns
more consistent and comprehensive results and autocompletion
suggestions are more relevant.
* There is now a Latin-Cyrillic language converter for Crimean Tatar.
For more information about these and other updates, please see the full reports.
**Full reports**
https://www.mediawiki.org/wiki/User:Nikerabbit/Monthly_report/2017-09https://www.mediawiki.org/wiki/User:Nikerabbit/Monthly_report/2017-10https://www.mediawiki.org/wiki/User:Nikerabbit/Monthly_report/2017-11
For those unfamiliar with this report, its goal is to summarize all
technical changes to internationalization, translation tools and other
language support products. It also highlights the diversity of
contributors to this area and that many of them are volunteers.
-Niklas
Hi!
Recently it seems as though there's been a huge increase in the use of
exceptions within the MediaWiki ecosystem. That's perfectly fine.
Exceptions are fantastic and a standard part of any developer's toolkit.
However, there seems to be a trend in throwing exceptions for codepaths
that don't catch them prior to returning to the user. The one I'm calling
out in particular is InvalidArgumentException.
It seems as though some code paths that are relying on user-generated input
are throwing this exception. That's pretty evil. There's a couple of
reasons:
- This just returns a generic 503 error to our users. They don't know what
went wrong and they're left wondering why and filing bugs.
- Due to our current logging setup, we don't do nice parameter grouping for
exceptions. This means that each one is reported on its own, and we don't
have an idea of the scale/severity of the problem. We need to fix this, but
it doesn't preclude us being more proactive.
Basically the short version is: exceptions should only be shown to users in
the situation of *actual software errors*. They're the exception, not the
norm. What we *should* do in such situation is log the error (at the
ERROR/WARNING/etc level as appropriate) and then gracefully fall back.
I don't think we need an RfC or anything formal here, just a little bit of
common sense :)
Tldr: if there's no such user "Foo", we shouldn't return an exception when
a user tries to perform an action on it. We should return a helpful error
message, log it, and fall back gracefully.
-Chad
PS: Now that I think about it, there's been a proliferation of
RuntimeException for the exact same thing.