Re: [Wikitech-l] is this list's archives searchable?

[Federico Leva (Nemo)]

Mailing list archive search is https://phabricator.wikimedia.org/T19390
There are however multiple specialised search engines for our mailing 
lists out there: https://meta.wikimedia.org/wiki/Mailing_lists/Overview


Nemo

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

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Isarra Yos]

Is there any way to use addModuleStyles() so that it outputs 
browser-conditional stylesheets? Such that such a one could apply only to IE8-? 
That's really what I need here.

On 15/11/15 00:17, Krinkle wrote:

Just wanna make a small correction here to avoid confusion.

The top and bottom queue are both JavaScript-enabled, using 'position' =>
'top' only controls where the load() command is placed (at the top or
bottom, naturally). Neither of these will run in IE 8 after January.

What Florian is referring to does exist. That is the "styles-only" queue It
is triggered by using addModuleStyles(). This method will ensure the module
is included in a regular  stylesheet. These modules don't have a
position, as stylesheets are always in the top.

One could consider these stylesheets as part of the top queue (based on
where they are in the HTML), but we don't do that in our documentation to
avoid confusion as instructions you may find about using the "top queue"
will refer to the 'position' attribute as used by addModules() – which is
not what you want in this case.

These styles-only modules are still processed by ResourceLoader (e.g. LESS
can be used, minified, and cached as usual). We've always used this skin
styling and other styles associated with server-side generated page output
(e.g. thumbnail styles, table of contents, skins etc.).

Primarily because it performs better (browsers discover these urls and
start fetching when statically looking ahead in the html parse stream). And
because it's a more stable and a semantically correct way to associate
styles. For instance, JavaScript runtime could intermittently fail for any
number of reasons even in modern browsers, as well as on mobile browsers.
In such scenarios the stylesheet  more important, and users effectively get
the fallback experience (as opposed to a page with no styling, which would
happen if we don't do that).

-- Krinkle


On Fri, Nov 13, 2015 at 10:02 AM, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:


I'm not totally sure, but if you put your styles into a top queue module,
the module would be delivered through RL (with all it's features, including
LESS compilation) and the browser requests it without JavaScript (it should
be added into one of the RL link tags in head). The change to disable JS on
IE8 should affect bottom queued modules, only (the requests for these
modules are initialized by JS).


-Original-Nachricht-
Von: "Isarra Yos" >

Using js got around this whole problem as with that you can simply check
the browser there and then conditionally mw.loader.load a size-free
module for IE8.

Is there any other way around this?



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



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

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Isarra Yos]

I agree that it's important to move away from desktop-first, but 
switching to mobile-first isn't the answer either. For complex products 
(discussion boards, skins, anything that could benefit from a lot of 
space), there are going mobile-specific styles same as any other 
resolution - do ANY as the 'main', and you're having to undo and 
override those styles on every other one, which results in unnecessarily 
complicated and large code, which just makes it all that much harder to 
maintain and work with.


As an example, this is an important part of why it's been so hard to 
make Vector properly responsive - so many of the desktop styles needed 
to be overridden in order for any mobile design to be applied. (This 
would have applied in either direction because its desktop and mobile 
layouts are so completely different.) But suppose that same step had 
been replaced with instead separating out the desktop styles into a 
separate stylesheet for a similar amount of effort, and with each as 
separate, independent stylesheets - code for both desktop and mobile 
would be made cleaner, and far easier to iterate upon. (People wanted me 
to iterate on what's there now and I couldn't even figure out where to 
begin. Not that I'm that good at CSS in the first place, but that code 
is scary.)


What we need to do is get better at distinguishing and leveraging the 
common styles, and using common variables and mixins, because this is 
how you make consistent overall styles and also simplify the overall 
thing. Then build these into something that works for each platform.


And if we're going to support stupid broken things, we need to 
explicitly support them with some sort of fallback that doesn't require 
a lot of manual rejigging. I'm not sure IE8, as an ancient desktop 
browser, getting mobile styles is really any better than an ancient 
mobile browser getting desktop styles.


On 14/11/15 22:39, Jon Robson wrote:

The solution to this is to do true mobile first development e.g. wrap your
desktop and tablet styles in media queries. Rendering a mobile site in IE8
is an acceptable trade off and ensures the content remains readable which
is the most important thing here.

We (Wikimedia devs) still build desktop first in all our major projects and
we really need to shift away from this. We can't simply build for desktop
and then adapt it to work on mobile which seems to be a common
misconception by anyone who hasn't built things for mobile. This approach
is costly as we end up rebuilding things we've already built to make them
work on mobile. We used to have a mobile department that pretty much did
this as a full time job but now that has gone we really need to adopt this
tried and tested approach.
On 13 Nov 2015 2:20 a.m., "Isarra Yos"  wrote:


Perhaps I should clarify why this is a problem. In fully responsive skins,
you generally have separate stylesheets for desktop, mobile, really big
desktop, whatever in order to keep the CSS rules simple and not redundant
(to avoid having mobile overriding desktop rules or visa versa, you just
only send the mobile styles to mobile, the desktop to desktop). You do this
by setting maximum and minimum screen sizes in the @media queries, but the
problem is, IE8 does not support this, and will not load a stylesheet at
all if these sizes are set. So you need to give it the desktop styles some
other way, without the @media size rules present.

While it is possible to simply add CSS to the page header using
outputPage, probably bypassing RL and all that entirely, this only works
with CSS, not LESS, because all the LESS magic is happening within RL. So
without RL, that means you need to render your desktop stylesheet into CSS
for this, which means you now need to maintain it in two different places
even though it's the same rules in both.

Using js got around this whole problem as with that you can simply check
the browser there and then conditionally mw.loader.load a size-free module
for IE8.

Is there any other way around this?

On 12/11/15 02:56, Isarra Yos wrote:


Is there a way to conditionally load RL modules for folks using IE8?
Because I couldn't figure out any proper way to do that in my skins and
I've just been using js to do it instead as a result.

But that's not going to work anymore. But it's also stupid regardless.

On 12/11/15 02:11, Krinkle wrote:


Hey all,

Starting in January 2016, MediaWiki will end JavaScript support for
Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
Users with this browser will still be able to browse, edit, and otherwise
contribute to the site. However, some features will not be available to
them. For example, the enhanced edit toolbar will not appear, and the
notification buttons will take you to a page rather than a pop-out.

This change will affect roughly 0.89% of all traffic to Wikimedia wikis
(as
of October 2015). For comparison, 0.33% of traffic comes from Internet
Explorer 6, and 1.46% 

Re: [Wikitech-l] Update about on-going work on Notifications, especially cross-wiki notifications

[Pine W]

Agreed. If I had a binary choice between investing in Echo and investing in
Flow, I would be inclined to choose Echo.

Pine
On Nov 14, 2015 7:08 AM, "Derk-Jan Hartman" 
wrote:

> Thank goodness. Finally we might be able to start fully building out the
> promise of powerful, targeted and appropriate messaging that Echo always
> was the the kick off for.
> I especially like the acknowledgment of the 'volume knob'. Balancing the
> 'noise' of messaging is going to be really important.
>
> I've always been a big proponent (Nick knows this all to well :D ) of
> investing in this area, seeing it as one of the few places of investment
> that can bring our communication between community members, but also the
> communication between foundation and editors to a level that is required to
> sustain and improve what we have right now, but most definitely to take our
> communities into the future. I predict big returns on improving this area.
> Awesomeness.
>
> DJ
>
> > On 13 nov. 2015, at 23:41, Nick Wilson (Quiddity) 
> wrote:
> >
> > Hi, this is an update on the work we in the Collaboration team are
> > doing. Our focus is on cross-wiki notifications and other back-end
> > improvements to that system.
> >
> > Our long-term goals are to make various improvements to the Notification
> system.
> >
> > Notifications are at the core of many different on-wiki activities.
> > Making notifications easy to find and use can help those processes. We
> > are focusing our immediate plans on supporting cross-wiki
> > notifications. These will help editors stay informed about the changes
> > they care about on every Wikimedia project on which they work. This is
> > especially important for the editors who work on more than one wiki.
> > Examples include if you upload to Commons, curate on Wikidata, or edit
> > in two or more languages.
> >
> > The team has spent the last few weeks researching the existing and
> > proposed features. This has included examining existing tools such as
> > Crosswatch. We've been considering the problems of:
> >
> > * technical performance (scaling the requests across 800+ wikis),
> > * user preferences (both existing and desired),
> > * user interface design possibilities (how it should work),
> > * how to release an initial, user-testable version for feedback and
> > improvement, and
> > * how to measure the impact of the project (reducing the time it takes
> > to process a notification).
> >
> > We are also doing user research via 1-on-1 interviews. In these we ask
> > active editors about their current notification usage and pain-points.
> > Using a prototype we are evolving, we get feedback on directions to
> > take the design.
> >
> > == Details and further reading ==
> > You can read more about the technical details at:
> >
> https://www.mediawiki.org/wiki/Requests_for_comment/Cross-wiki_notifications
> > .
> >
> > Some of the new backend improvements to Echo:
> > https://phabricator.wikimedia.org/T107823 ("Rewrite
> > EchoNotificationFormatter") and linked tasks.
> >
> > User preference options are:
> > * https://phabricator.wikimedia.org/T117670 ("Define Cross-wiki
> > Notifications settings")
> >
> > User interface design possibilities cover several questions. For
> > example, how should cross-wiki notifications look within the pop-up?
> > How and when should we add enhancements to the Special:Notifications
> > page to filter things? We are drafting and discussing these in:
> >
> > * https://phabricator.wikimedia.org/T114357 (Clarifications to the
> > currently confusing "primary/secondary" link, and proposed future
> > enhancements)
> > * https://phabricator.wikimedia.org/T114356 (Bundled notifications)
> > * https://phabricator.wikimedia.org/T115264 (Controlling notification
> > 'volume' based on the type or location)
> > * https://phabricator.wikimedia.org/T115845 (Clearer use of the
> > notification badges (coloured number in personal toolbar))
> > * https://phabricator.wikimedia.org/T115316 (Better organization of
> > the Special:Notifications page)
> >
> > Note: Most of these are not part of the cross-wiki notifications
> > feature. We won't for sure roll all these out together with the main
> > change.
> >
> > We started user research at https://phabricator.wikimedia.org/T114086
> > and it continues at https://phabricator.wikimedia.org/T116741 . (Note:
> > You can sign-up as a volunteer at https://wikimedia.org/research .)
> >
> > A user-testable release is still just in planning. We decided on a
> > Beta Feature on each wiki as the most scalable and least confusing of
> > all the do-able options. Read our plans in
> > https://phabricator.wikimedia.org/T114237 ("Present cross-wiki
> > notifications as a beta feature to users"). This will help users to
> > try the feature anytime, disabling it if it interferes with their work
> > in some context, and easily suggest how the tool could be improved.
> >
> > There is no system for users 

Re: [Wikitech-l] Update about on-going work on Notifications, especially cross-wiki notifications

[MZMcBride]

Pine W wrote:
>Agreed. If I had a binary choice between investing in Echo and investing
>in Flow, I would be inclined to choose Echo.

Can you please elaborate on why you would prioritize Echo over Flow? The
Wikimedia Foundation has made the same decision and it's mind-boggling to
me. I'd really like some greater insight into the thought process here.

MZMcBride



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

Re: [Wikitech-l] Update about on-going work on Notifications, especially cross-wiki notifications

[Pine W]

Hi MZMcBride,

The hypothetical here is that I have a binary choice between Echo and Flow.
In practice it's possible to develop them in parallel. With the
hypothetical in mind, I'll outline why I would prioritize Echo.

My thinking is that Echo is used widely on many, many wikis and is helpful
to users of all skill levels. It must be years since I've heard someone say
that they find the nature of Echo to be problematic. By contrast, the
reception to Flow is more mixed. Also, as some of us are discussing with
Lila, it may be feasible to extend VE  to talk pages and/or give some love
to the wikimarkup editor at less expense and with less disruption than the
expense and disruption involved with converting talk pages to Flow pages.

From a communications persoective, I asked recently for clarification on
the status of Flow and no one from WMF answered my question. If there is so
much uncertainty or disorganization with respect to Flow that users don't
get answers to questions that are asked in prominent venues, that makes me
wonder all the more what is happening, and therefore inclined to oppose
investing more resources in a black box until community questions are
answred.

Flow has its supporters and I think that keeping it maintained and healthy
on wikis where the communities like it is probably wise. Given the choice
of investing more resources into further development of a product that has
mixed reviews, is used on only some wikis, and about which community
questions aren't answered, seems questionable to me when investing in a
well-accepted and widely-used tool (Echo) is an alternative.

Pine
On Nov 14, 2015 9:11 PM, "MZMcBride"  wrote:

> Pine W wrote:
> >Agreed. If I had a binary choice between investing in Echo and investing
> >in Flow, I would be inclined to choose Echo.
>
> Can you please elaborate on why you would prioritize Echo over Flow? The
> Wikimedia Foundation has made the same decision and it's mind-boggling to
> me. I'd really like some greater insight into the thought process here.
>
> MZMcBride
>
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Update about on-going work on Notifications, especially cross-wiki notifications

[Derk-Jan Hartman]

Thank goodness. Finally we might be able to start fully building out the 
promise of powerful, targeted and appropriate messaging that Echo always was 
the the kick off for.
I especially like the acknowledgment of the 'volume knob'. Balancing the 
'noise' of messaging is going to be really important.

I've always been a big proponent (Nick knows this all to well :D ) of investing 
in this area, seeing it as one of the few places of investment that can bring 
our communication between community members, but also the communication between 
foundation and editors to a level that is required to sustain and improve what 
we have right now, but most definitely to take our communities into the future. 
I predict big returns on improving this area. Awesomeness.

DJ

> On 13 nov. 2015, at 23:41, Nick Wilson (Quiddity)  
> wrote:
> 
> Hi, this is an update on the work we in the Collaboration team are
> doing. Our focus is on cross-wiki notifications and other back-end
> improvements to that system.
> 
> Our long-term goals are to make various improvements to the Notification 
> system.
> 
> Notifications are at the core of many different on-wiki activities.
> Making notifications easy to find and use can help those processes. We
> are focusing our immediate plans on supporting cross-wiki
> notifications. These will help editors stay informed about the changes
> they care about on every Wikimedia project on which they work. This is
> especially important for the editors who work on more than one wiki.
> Examples include if you upload to Commons, curate on Wikidata, or edit
> in two or more languages.
> 
> The team has spent the last few weeks researching the existing and
> proposed features. This has included examining existing tools such as
> Crosswatch. We've been considering the problems of:
> 
> * technical performance (scaling the requests across 800+ wikis),
> * user preferences (both existing and desired),
> * user interface design possibilities (how it should work),
> * how to release an initial, user-testable version for feedback and
> improvement, and
> * how to measure the impact of the project (reducing the time it takes
> to process a notification).
> 
> We are also doing user research via 1-on-1 interviews. In these we ask
> active editors about their current notification usage and pain-points.
> Using a prototype we are evolving, we get feedback on directions to
> take the design.
> 
> == Details and further reading ==
> You can read more about the technical details at:
> https://www.mediawiki.org/wiki/Requests_for_comment/Cross-wiki_notifications
> .
> 
> Some of the new backend improvements to Echo:
> https://phabricator.wikimedia.org/T107823 ("Rewrite
> EchoNotificationFormatter") and linked tasks.
> 
> User preference options are:
> * https://phabricator.wikimedia.org/T117670 ("Define Cross-wiki
> Notifications settings")
> 
> User interface design possibilities cover several questions. For
> example, how should cross-wiki notifications look within the pop-up?
> How and when should we add enhancements to the Special:Notifications
> page to filter things? We are drafting and discussing these in:
> 
> * https://phabricator.wikimedia.org/T114357 (Clarifications to the
> currently confusing "primary/secondary" link, and proposed future
> enhancements)
> * https://phabricator.wikimedia.org/T114356 (Bundled notifications)
> * https://phabricator.wikimedia.org/T115264 (Controlling notification
> 'volume' based on the type or location)
> * https://phabricator.wikimedia.org/T115845 (Clearer use of the
> notification badges (coloured number in personal toolbar))
> * https://phabricator.wikimedia.org/T115316 (Better organization of
> the Special:Notifications page)
> 
> Note: Most of these are not part of the cross-wiki notifications
> feature. We won't for sure roll all these out together with the main
> change.
> 
> We started user research at https://phabricator.wikimedia.org/T114086
> and it continues at https://phabricator.wikimedia.org/T116741 . (Note:
> You can sign-up as a volunteer at https://wikimedia.org/research .)
> 
> A user-testable release is still just in planning. We decided on a
> Beta Feature on each wiki as the most scalable and least confusing of
> all the do-able options. Read our plans in
> https://phabricator.wikimedia.org/T114237 ("Present cross-wiki
> notifications as a beta feature to users"). This will help users to
> try the feature anytime, disabling it if it interferes with their work
> in some context, and easily suggest how the tool could be improved.
> 
> There is no system for users having or setting cross-wiki preferences.
> Waiting to building this would take a long time. For now, we plan to
> let you enable the Beta Feature at each wiki on which you want to test
> it. This will let you have a small-scale Beta Feature that you can all
> try out. We will be able to discover bugs, edge-cases, iterate more,
> and get even more feedback. Later, when we 

[Wikitech-l] Which hook to use and how for pre-save-modifications of wikitext?

[Purodha Blissenbach]

Hi,

I want to implement something similar to  expansion or the 
pipe-trick

in internal links in an extension.

That is, I need to execute code
- on save and preview only,
- on wikitext ony,
- on page content only,
- before the pre-save-parser treats links in the wikitext,
- altering the wikitext of the page.

I tried several hooks and ideas, but was unable to make it specific 
enough.


Help is appreciated.

Thank you.

Purodha


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

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Jon Robson]

I should also add that the reason I say this is that IE8 is not the only
browser that doesn't support media queries. There are many browsers that
were written before IE8 and installed on phones with no upgrade path. This
is just one of the biggest ones.
On 15 Nov 2015 7:08 a.m., jdlrob...@gmail.com wrote:

The solution to this is to do true mobile first development e.g. wrap your
desktop and tablet styles in media queries. Rendering a mobile site in IE8
is an acceptable trade off and ensures the content remains readable which
is the most important thing here.

We (Wikimedia devs) still build desktop first in all our major projects and
we really need to shift away from this. We can't simply build for desktop
and then adapt it to work on mobile which seems to be a common
misconception by anyone who hasn't built things for mobile. This approach
is costly as we end up rebuilding things we've already built to make them
work on mobile. We used to have a mobile department that pretty much did
this as a full time job but now that has gone we really need to adopt this
tried and tested approach.
On 13 Nov 2015 2:20 a.m., "Isarra Yos"  wrote:

Perhaps I should clarify why this is a problem. In fully responsive skins,
you generally have separate stylesheets for desktop, mobile, really big
desktop, whatever in order to keep the CSS rules simple and not redundant
(to avoid having mobile overriding desktop rules or visa versa, you just
only send the mobile styles to mobile, the desktop to desktop). You do this
by setting maximum and minimum screen sizes in the @media queries, but the
problem is, IE8 does not support this, and will not load a stylesheet at
all if these sizes are set. So you need to give it the desktop styles some
other way, without the @media size rules present.

While it is possible to simply add CSS to the page header using outputPage,
probably bypassing RL and all that entirely, this only works with CSS, not
LESS, because all the LESS magic is happening within RL. So without RL,
that means you need to render your desktop stylesheet into CSS for this,
which means you now need to maintain it in two different places even though
it's the same rules in both.

Using js got around this whole problem as with that you can simply check
the browser there and then conditionally mw.loader.load a size-free module
for IE8.

Is there any other way around this?


On 12/11/15 02:56, Isarra Yos wrote:

> Is there a way to conditionally load RL modules for folks using IE8?
> Because I couldn't figure out any proper way to do that in my skins and
> I've just been using js to do it instead as a result.
>
> But that's not going to work anymore. But it's also stupid regardless.
>
> On 12/11/15 02:11, Krinkle wrote:
>
>> Hey all,
>>
>> Starting in January 2016, MediaWiki will end JavaScript support for
>> Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
>> Users with this browser will still be able to browse, edit, and otherwise
>> contribute to the site. However, some features will not be available to
>> them. For example, the enhanced edit toolbar will not appear, and the
>> notification buttons will take you to a page rather than a pop-out.
>>
>> This change will affect roughly 0.89% of all traffic to Wikimedia wikis
>> (as
>> of October 2015). For comparison, 0.33% of traffic comes from Internet
>> Explorer 6, and 1.46% from Internet Explorer 7. Support for these was
>> dropped in August and September 2014 respectively.
>>
>> Providing JavaScript for IE 8 adds a significant maintenance burden. It
>> also bloats the software we ship to all users, without proportionate
>> benefit. This enables us to simplify and streamline the JavaScript
>> codebase
>> for all other users. Users unable to upgrade from Internet Explorer 8 will
>> have a faster experience going forward, based on well-tested and more
>> stable code.
>>
>> This change will land in the development branch in January, and so will be
>> part of MediaWiki 1.27 (to be released around May 2016).
>>
>> Tech News will announce this change as well, but please help carry this
>> message into your communities. In January, we will send a reminder before
>> the change happens.
>>
>> Yours,
>> -- Krinkle
>>
>> For details about the JavaScript-less experience, see
>> https://www.mediawiki.org/wiki/Compatibility
>> ___
>> Wikitech-l mailing list
>> Wikitech-l@lists.wikimedia.org
>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>
>
>

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

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Jon Robson]

The solution to this is to do true mobile first development e.g. wrap your
desktop and tablet styles in media queries. Rendering a mobile site in IE8
is an acceptable trade off and ensures the content remains readable which
is the most important thing here.

We (Wikimedia devs) still build desktop first in all our major projects and
we really need to shift away from this. We can't simply build for desktop
and then adapt it to work on mobile which seems to be a common
misconception by anyone who hasn't built things for mobile. This approach
is costly as we end up rebuilding things we've already built to make them
work on mobile. We used to have a mobile department that pretty much did
this as a full time job but now that has gone we really need to adopt this
tried and tested approach.
On 13 Nov 2015 2:20 a.m., "Isarra Yos"  wrote:

> Perhaps I should clarify why this is a problem. In fully responsive skins,
> you generally have separate stylesheets for desktop, mobile, really big
> desktop, whatever in order to keep the CSS rules simple and not redundant
> (to avoid having mobile overriding desktop rules or visa versa, you just
> only send the mobile styles to mobile, the desktop to desktop). You do this
> by setting maximum and minimum screen sizes in the @media queries, but the
> problem is, IE8 does not support this, and will not load a stylesheet at
> all if these sizes are set. So you need to give it the desktop styles some
> other way, without the @media size rules present.
>
> While it is possible to simply add CSS to the page header using
> outputPage, probably bypassing RL and all that entirely, this only works
> with CSS, not LESS, because all the LESS magic is happening within RL. So
> without RL, that means you need to render your desktop stylesheet into CSS
> for this, which means you now need to maintain it in two different places
> even though it's the same rules in both.
>
> Using js got around this whole problem as with that you can simply check
> the browser there and then conditionally mw.loader.load a size-free module
> for IE8.
>
> Is there any other way around this?
>
> On 12/11/15 02:56, Isarra Yos wrote:
>
>> Is there a way to conditionally load RL modules for folks using IE8?
>> Because I couldn't figure out any proper way to do that in my skins and
>> I've just been using js to do it instead as a result.
>>
>> But that's not going to work anymore. But it's also stupid regardless.
>>
>> On 12/11/15 02:11, Krinkle wrote:
>>
>>> Hey all,
>>>
>>> Starting in January 2016, MediaWiki will end JavaScript support for
>>> Microsoft Internet Explorer 8. This raises the cut-off up from MSIE 7.
>>> Users with this browser will still be able to browse, edit, and otherwise
>>> contribute to the site. However, some features will not be available to
>>> them. For example, the enhanced edit toolbar will not appear, and the
>>> notification buttons will take you to a page rather than a pop-out.
>>>
>>> This change will affect roughly 0.89% of all traffic to Wikimedia wikis
>>> (as
>>> of October 2015). For comparison, 0.33% of traffic comes from Internet
>>> Explorer 6, and 1.46% from Internet Explorer 7. Support for these was
>>> dropped in August and September 2014 respectively.
>>>
>>> Providing JavaScript for IE 8 adds a significant maintenance burden. It
>>> also bloats the software we ship to all users, without proportionate
>>> benefit. This enables us to simplify and streamline the JavaScript
>>> codebase
>>> for all other users. Users unable to upgrade from Internet Explorer 8
>>> will
>>> have a faster experience going forward, based on well-tested and more
>>> stable code.
>>>
>>> This change will land in the development branch in January, and so will
>>> be
>>> part of MediaWiki 1.27 (to be released around May 2016).
>>>
>>> Tech News will announce this change as well, but please help carry this
>>> message into your communities. In January, we will send a reminder before
>>> the change happens.
>>>
>>> Yours,
>>> -- Krinkle
>>>
>>> For details about the JavaScript-less experience, see
>>> https://www.mediawiki.org/wiki/Compatibility
>>> ___
>>> Wikitech-l mailing list
>>> Wikitech-l@lists.wikimedia.org
>>> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>>>
>>
>>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Daniel Friesen]

On 2015-11-14 2:39 PM, Jon Robson wrote:
> While it is possible to simply add CSS to the page header using outputPage,
> probably bypassing RL and all that entirely, this only works with CSS, not
> LESS, because all the LESS magic is happening within RL. So without RL,
> that means you need to render your desktop stylesheet into CSS for this,
> which means you now need to maintain it in two different places even though
> it's the same rules in both.
>
>
> Is there any other way around this?
If you were ok with IE8 support requiring Node.js, the PostCSS ecosystem
has a bunch of plugins to transform CSS (which someone could try and
plug into RL).

Such as:
https://github.com/jonathantneal/oldie

~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]


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

Re: [Wikitech-l] [BREAKING CHANGE] IE 8 will go JavaScript-less starting January 2016

[Krinkle]

Just wanna make a small correction here to avoid confusion.

The top and bottom queue are both JavaScript-enabled, using 'position' =>
'top' only controls where the load() command is placed (at the top or
bottom, naturally). Neither of these will run in IE 8 after January.

What Florian is referring to does exist. That is the "styles-only" queue It
is triggered by using addModuleStyles(). This method will ensure the module
is included in a regular  stylesheet. These modules don't have a
position, as stylesheets are always in the top.

One could consider these stylesheets as part of the top queue (based on
where they are in the HTML), but we don't do that in our documentation to
avoid confusion as instructions you may find about using the "top queue"
will refer to the 'position' attribute as used by addModules() – which is
not what you want in this case.

These styles-only modules are still processed by ResourceLoader (e.g. LESS
can be used, minified, and cached as usual). We've always used this skin
styling and other styles associated with server-side generated page output
(e.g. thumbnail styles, table of contents, skins etc.).

Primarily because it performs better (browsers discover these urls and
start fetching when statically looking ahead in the html parse stream). And
because it's a more stable and a semantically correct way to associate
styles. For instance, JavaScript runtime could intermittently fail for any
number of reasons even in modern browsers, as well as on mobile browsers.
In such scenarios the stylesheet  more important, and users effectively get
the fallback experience (as opposed to a page with no styling, which would
happen if we don't do that).

-- Krinkle


On Fri, Nov 13, 2015 at 10:02 AM, Florian Schmidt <
florian.schmidt.wel...@t-online.de> wrote:

> I'm not totally sure, but if you put your styles into a top queue module,
> the module would be delivered through RL (with all it's features, including
> LESS compilation) and the browser requests it without JavaScript (it should
> be added into one of the RL link tags in head). The change to disable JS on
> IE8 should affect bottom queued modules, only (the requests for these
> modules are initialized by JS).
>
>
> -Original-Nachricht-
> Von: "Isarra Yos" >
>
> Using js got around this whole problem as with that you can simply check
> the browser there and then conditionally mw.loader.load a size-free
> module for IE8.
>
> Is there any other way around this?
>
>
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Which hook to use and how for pre-save-modifications of wikitext?

[Jackmcbarn]

Look how subst: works in the braceSubstitution function in Parser.php.
Basically, do this: if ( $parser->ot['wiki'] ) { /* do your stuff */ }.

On Sat, Nov 14, 2015 at 5:36 PM, Purodha Blissenbach <
puro...@blissenbach.org> wrote:

> Hi,
>
> I want to implement something similar to  expansion or the pipe-trick
> in internal links in an extension.
>
> That is, I need to execute code
> - on save and preview only,
> - on wikitext ony,
> - on page content only,
> - before the pre-save-parser treats links in the wikitext,
> - altering the wikitext of the page.
>
> I tried several hooks and ideas, but was unable to make it specific enough.
>
> Help is appreciated.
>
> Thank you.
>
> Purodha
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Yandex?

[Marcin Cieslak]

On 2015-11-13, Runa Bhattacharjee  wrote:

> Specifics about this can be seen at:
>
> https://www.mediawiki.org/wiki/Content_translation/Machine_Translation/Yandex#Summary_of_terms_of_Yandex_agreement
>

Thanks! This is very helpful.

The link was already in the FAQ (although a bit buried in the text), I gave it 
a bit more exposure:

https://www.mediawiki.org/w/index.php?title=Content_translation%2FDocumentation%2FFAQ=revision=1939107=1936677

Thanks a lot!

Saper


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

Re: [Wikitech-l] Git for idiots

[Marcin Cieslak]

On 2015-11-13, Purodha Blissenbach  wrote:
> Hi,
>
>> git clone 
>> ssh://review.openstack.org:29418/openstack-infra/git-review.git
>
> fatal: Could not read from remote repository.
>
> Please make sure you have the correct access rights
> and the repository exists.
>
> Greetings -- Purodha

You can use

 git clone https://review.openstack.org/openstack-infra/git-review.git

if you don't have an account on review.openstack.org with your SSH key

Saper


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