[Wikitech-l] Per-language URLs for multilingual wikis (RFC T114662)

[Daniel Kinzler]

Hi all!

During next Wednesday's RFC meeting on IRC, we are planning to discuss
introducing "Per-language URLs for pages of multilingual wikis". This is an
exploratory discussion, with no expectation of a final decision. We are looking
for concerns and suggestions.

If you care about improved support for multi-lingual wikis, please visit
 and comment before next week's
"live" meeting on IRC. And of yourse, join that meeting, if you like!

Thanks,
Daniel


PS: Don't want to click the link? Let me copy that for you... but please
comment on phab rather than here.


Context:
Some wikis show page content depending on the user's interface language (for
instance wikidata.org and commons.wikimedia.org, or other wikis using the
Translate extension). All language versions (renderings) of a page are served
from the same URL, which is problematic for web caching. This is the reason we
currently do not allow anonymous users to change their interface language. This
makes it hard for use multilingual wikis without logging in.

See also for context:
* {T114640}

Proposal:
* For multilingual wikis, the user language is part of the request path: e.g. we
would use `/wiki-de/` instead of `/wiki/`.
* The plain `/wiki/` path would act as a 302 redirect to the language specific
path (based on the user's language, or a best guess or cookie as implemented by 
ULS)
* When viewing a page via a language-specific path, all links on the page (both
content and skin) point to pathes specific to that language. Both content and
skin are shown in the user's ui language (as far as possible, using whatever
mechanism for content translation or internationalization is available)
* When viewing a page in a language different from the user's preferred language
(according to user preferences or the cookie set by ULS), a warnign bar is shown
at the top, giving the user the option to
## switch to the version in their own language (according to user 
preference)
## change their user language to the current page's language
## hide the bar for a while (a day, or the browser session, or so).

Challanges:
* Make the Linker class aware of the target language (probably needs a complete
refactoring), so it generates links to the right path.
* Make all code that generates links in the skin use the Linker class (directly,
or via the Parser), so the path is consistent.
* Allow efficient purging of the entire "bundle" of all the renderings of a
given page when the page's content changes.
* Should translated names for namespaces and special pages be supported on the
language specific pathes? (would be nice, but tricky)
* Provide a way to explicitly link to a specific language rendering from
wikitext, e.g. `{{#link|Foo|lang=de-ch}}`

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Help test SessionManager on WMF beta cluster

[Antoine Musso]

Hello Pywikibot devs and users,

The Wikimedia reading infrastructure team has been working hard on
overhauling the way MediaWiki handles sessions.  It had a few issues and
we had to roll it back.

Bryan Davis announced on wikitech-l the feature has been merged again in
master and it is now enabled on the beta cluster.

I am wondering whether one/all of you could run Pywikibot tests against
the beta cluster to stress out the SessionManager?   Maybe one would be
creative enough to write tests exercising login/logout/creation of users?

We get logs saved on https://logstash-beta.wmflabs.org/


Remember: use a different password!

Below is Bryan original announce. Lets follow up on wikitech-l.

-- 
Antoine Musso

Le 04/02/2016 22:33, Bryan Davis a écrit :
> One of the conclusions from the recent SessionManager rollout failure [0] was:
> 
> "we should have recruited and coordinated testing by developers and
> users inside and outside of the WMF while the code was only on the
> beta testing cluster"
> 
> SessionManager is back on the WMF beta cluster [1] now after being
> briefly removed for the 1.27.0-wmf.12 release cycle, so an
> announcement seems in order. The beta cluster implements a SUL
> authenticated wiki farm that is completely separate from the Wikimedia
> production SUL system. Helping test SessionManager there would involve
> logging in, logging out, creating new user accounts and generally
> wandering around the wikis doing things you would normally do in
> production while keeping an eye out for session related issues.
> 
> If you spot something (or just think you spotted something) file a
> Phabricator task with as many details as you can provide and tag it
> with the #reading-infrastructure-team project. For session related
> issues getting traces of the headers and cookies used in the requests
> that are failing is most helpful. You can also poke around in the
> logging interface [2] to try and find associated error messages.
> 
> If you find other bugs, report them in Phabricator too. :)
> 
> Also please remember NOT TO USE passwords in the beta cluster that
> match the passwords you use anywhere else on the planet!
> 
> 
> [0]: 
> https://wikitech.wikimedia.org/wiki/Incident_documentation/20160123-SessionManagerRolloutFailure
> [1]: http://deployment.wikimedia.beta.wmflabs.org/wiki/Main_Page
> [2]: https://logstash-beta.wmflabs.org/#/dashboard/elasticsearch/default
> 
> Bryan
> 




___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Reading Q4 planning call for participation and updates

[Moushira Elamrawy]

Dear all,

Q4 planning is coming soon.  Staff and community are invited to add their
ideas and suggestions that align with the roadmap to the planning page here:
https://www.mediawiki.org/wiki/Reading/Quarterly_planning/Q4

A brief summary for Reading team updates for the last quarter is also
available here:
https://www.mediawiki.org/wiki/Reading/Reading_team_updates_November_2015_-_January_2016#Previous_Updates


Happy weekend everyone!
M
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Developer Relations Weekly Summary

[Quim Gil]

Developer Relations focus this week:

* Review Wikimedia Hackathon 2016 travel sponsorship requests and prepare
the call for proposals for 2017.
* Developer Relations strategy and annual plan.

Get the full summary with developer related news at
https://www.mediawiki.org/wiki/Developer_Relations/Weekly_summary#2016-02-04

-- 
Quim Gil
Engineering Community Manager @ Wikimedia Foundation
http://www.mediawiki.org/wiki/User:Qgil
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Data visualization for wiki

[Ivo Kruusamägi]

Thank you for that input! I'll send an e-mail to him and check that.

I'm lot more familiar with Commons and the community there, than with
software developing part. I've been leading projects Minority Translate
 and WikiComment ,
but I'm not a programmer myself and I do have very-very limited knowledge
of what is happening in that field here. Commons really needs that kind of
stuff and the lack of it is rather depressing. This idea about image
ranking that way is itself rather interesting. I've just organized
European_Science_Photo_Competition
in Commons

and
I could easily imagine how that could be used to rank incoming images there
(or just think of POTY, that should soon start). So there would definitely
be practical uses for that. It just needs to offer specific topics.

So. Are there any more comments? :) I still need a topic for that student.
I think it would be a loss for us, if we could not utilize this free
workforce offered to us.

Ivo



2016-02-05 15:16 GMT+02:00 Brian Wolff :

> There is some work towards in browser image editing (see
> https://lists.wikimedia.org/pipermail/multimedia/2015-December/001219.html
> )
> but im not sure what the status of that is. In the past there was also some
> work around Extension:SVGEdit, but that seems to have died
>
>
> Gamification at commons may be interesting. There are lots of images that
> need their licenses reviewed, need categories added, etc. However getting
> user requirements for this might be tricky. The commons community can be
> very hostile if they perceive a product to not meet user requriements, so
> one has to be careful and be sure to consult the community every step of
> the way.
>
> Even just a more immersive interface for reviewing images might be useful.
>
> Once upon a time i tried to make a game out of ranking images (
> https://tools.wmflabs.org/bawolff/whichisbetter/index.php?title=Main_Page
> ), but that went nowhere. In retrospect, image ranking isn't an activity
> that people were already doing, so it was a poor choice for gamification. I
> think something involving reviewing images might get a lot more traction.
>
> --
> -bawolff
>
> On Thursday, February 4, 2016, Ivo Kruusamägi 
> wrote:
> > So, some questions:
> >
> > * how important could that in-wiki image editing capability be?
> > * has anything been done so far?
> >
> > I'd like to find some topic suitable for university student to work on.
> So
> > here it is: free workforce for wiki. Act now the get that! Offer some
> > topics. PHP related tasks preferred.
> >
> > Ivo
> >
> > 2016-02-04 14:20 GMT+02:00 Ivo Kruusamägi :
> >
> >> OK, this Graph extension seems rather advanced and even though not
> exactly
> >> what I had in mind, somewhat similar. So may I conclude it would be
> >> pointless to go into that direction? Or are there some things, that may
> >> need someone to work with them? Like (making random example): building
> very
> >> simple Visual Editor add-on to enable fast creation of some more simple
> >> graphs (like pie charts from the enormous variety of possibilities
> >> )?
> >>
> >> Could I get more information about need for image editors? *I'd like to
> >> find something that might be suitable topic for bachelor thesis* and
> >> vandering around alone inside the topic not yet known to me may not
> prove
> >> to be fruitful.
> >>
> >> As for this Commons topic. Yes, something similar to Wikidata Game, but
> >> directed towards Commons and not Wikidata. More in line with Estonian
> sites
> >> Ajapaik  (for adding geolocation information
> >> to old images), sift.pics (for determining image types) and
> >> postkaart.ajapaik.ee (for digitalizing text in old postcards).
> >>
> >> Ivo
> >>
> >> 2016-02-04 5:00 GMT+02:00 MZMcBride :
> >>
> >>> Ivo Kruusamägi wrote:
> >>> >What I'd like to see is some development, that would make it possible
> for
> >>> >user to create visualizations inside MediaWiki. Something so easy that
> a
> >>> >child could do that. Like this . Workflow
> example:
> >>> 1)
> >>> >user selects sth like Create Data Visualization, 2) has some
> selections
> >>> >about cart type, colors, etc, 3) place to write down text (title,
> axes,
> >>> >description) and 4) a table to fill in with data (values + their text
> >>> >labels). That could then be saved as one revision. After that every
> other
> >>> >user could edit this graph with the same selections and data tables
> just
> >>> >like users edit articles and edit history is saved and easy to
> compare.
> >>> >
> >>> >Image files like this
> >>> > or that
> >>> ><
> >>>
> 

Re: [Wikitech-l] Data visualization for wiki

[Brian Wolff]

There is some work towards in browser image editing (see
https://lists.wikimedia.org/pipermail/multimedia/2015-December/001219.html)
but im not sure what the status of that is. In the past there was also some
work around Extension:SVGEdit, but that seems to have died


Gamification at commons may be interesting. There are lots of images that
need their licenses reviewed, need categories added, etc. However getting
user requirements for this might be tricky. The commons community can be
very hostile if they perceive a product to not meet user requriements, so
one has to be careful and be sure to consult the community every step of
the way.

Even just a more immersive interface for reviewing images might be useful.

Once upon a time i tried to make a game out of ranking images (
https://tools.wmflabs.org/bawolff/whichisbetter/index.php?title=Main_Page
), but that went nowhere. In retrospect, image ranking isn't an activity
that people were already doing, so it was a poor choice for gamification. I
think something involving reviewing images might get a lot more traction.

--
-bawolff

On Thursday, February 4, 2016, Ivo Kruusamägi 
wrote:
> So, some questions:
>
> * how important could that in-wiki image editing capability be?
> * has anything been done so far?
>
> I'd like to find some topic suitable for university student to work on. So
> here it is: free workforce for wiki. Act now the get that! Offer some
> topics. PHP related tasks preferred.
>
> Ivo
>
> 2016-02-04 14:20 GMT+02:00 Ivo Kruusamägi :
>
>> OK, this Graph extension seems rather advanced and even though not
exactly
>> what I had in mind, somewhat similar. So may I conclude it would be
>> pointless to go into that direction? Or are there some things, that may
>> need someone to work with them? Like (making random example): building
very
>> simple Visual Editor add-on to enable fast creation of some more simple
>> graphs (like pie charts from the enormous variety of possibilities
>> )?
>>
>> Could I get more information about need for image editors? *I'd like to
>> find something that might be suitable topic for bachelor thesis* and
>> vandering around alone inside the topic not yet known to me may not prove
>> to be fruitful.
>>
>> As for this Commons topic. Yes, something similar to Wikidata Game, but
>> directed towards Commons and not Wikidata. More in line with Estonian
sites
>> Ajapaik  (for adding geolocation information
>> to old images), sift.pics (for determining image types) and
>> postkaart.ajapaik.ee (for digitalizing text in old postcards).
>>
>> Ivo
>>
>> 2016-02-04 5:00 GMT+02:00 MZMcBride :
>>
>>> Ivo Kruusamägi wrote:
>>> >What I'd like to see is some development, that would make it possible
for
>>> >user to create visualizations inside MediaWiki. Something so easy that
a
>>> >child could do that. Like this . Workflow example:
>>> 1)
>>> >user selects sth like Create Data Visualization, 2) has some selections
>>> >about cart type, colors, etc, 3) place to write down text (title, axes,
>>> >description) and 4) a table to fill in with data (values + their text
>>> >labels). That could then be saved as one revision. After that every
other
>>> >user could edit this graph with the same selections and data tables
just
>>> >like users edit articles and edit history is saved and easy to compare.
>>> >
>>> >Image files like this
>>> > or that
>>> ><
>>>
https://commons.wikimedia.org/wiki/File:Tree_map_exports_2010_Estonia.svg
>>> > are ridiculous and fixes like that
>>> > are not that
>>> flexible,
>>> >pretty and easy to use as what we need. So lets move forward.
>>>
>>> Are you familiar with the "Graph" MediaWiki extension? Here's a demo:
>>> . This MediaWiki
>>> extension is deployed to Wikimedia wikis, including all the Wikipedias.
>>>
>>> >There are plenty of GPL licensed solutions that could be integrated
with
>>> >MediaWiki. But I can't be only one thinking about this.
>>>
>>> You're not. :-)
>>>
>>> >So what should I know about that topic so that this work could really
be
>>> >useful? I.e. how to avoid reinventing the wheel (like building
something
>>> >already in development) and how to be sure that it could be easily
>>> >incorporated later? Who would be the perfect people to talk about this
>>> >topic?
>>>
>>> This mailing list is great for general discussion. Or we have a
>>> Phabricator installation at  where
we
>>> track bugs and feature requests. You can search around for Phabricator
>>> Maniphest task related to vectorized and rasterized image editors, such
as
>>> . You're welcome to discuss on
>>> those tasks. Integrating a 

[Wikitech-l] Tech Talk: A Hands-on Estimation Exercise, With Discussion: Feb 8th

[Rachel Farrand]

Please join for the following tech talk:

*Tech Talk**:* A Hands-on Estimation Exercise, With Discussion
*Presenter:* Joel Aufrecht
*Date:* February 8th, 2016
*Time: *18:30 UTC

Link to live YouTube stream 
*IRC channel for questions/discussion:* #wikimedia-office

*Summary: *Estimation is an unnatural activity for human brains, which tend
to hide our own ignorance from us.  This brown-bag begins with an exercise,
adapted from Steve McConnell's software estimation training, in balancing
accuracy with precision.  The exercise is fully available to remotees.
Facilitated discussion follows, on what we can learn from the exercise and
on general estimation and forecasting topics as raised.
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Tech Talk: A Hands-on Estimation Exercise, With Discussion: Feb 8th

[Bernardo Sulzbach]

On 02/05/2016 10:59 PM, Rachel Farrand wrote:


*Summary: *Estimation is an unnatural activity for human brains, which tend
to hide our own ignorance from us.  This brown-bag begins with an exercise,
adapted from Steve McConnell's software estimation training, in balancing
accuracy with precision.  The exercise is fully available to remotees.
Facilitated discussion follows, on what we can learn from the exercise and
on general estimation and forecasting topics as raised.


This seems interesting.

___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l