[Wikitech-l] Git for idiots

[Petr Bena]

Hello,

I would like to remind that I made this guide some time ago:

https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots

It always quite sucked and still does, but I tried to slightly rewrite
it now, so it should contain more accurate information.

I would like to keep it as a super simple manual / cheat sheet for
git, that is as much clear and simple as possible.

If you ever struggled with git, maybe it could help you. If you are a
git expert you may want to contribute to it? The name of the guide may
not be a best choice, so I might eventually move it to [[Git for
dummies]] or something like that, so that it sounds a bit more
friendly.

I don't know if we already have any super simple guide / cheat sheet
for git, where you could find everything essential on 1 page (and it
was a wiki page editable by everyone), but I think we don't. We might
use this as one?

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

Re: [Wikitech-l] Git for idiots

[Petr Bena]

Now I also found this awesome guide:
https://www.mediawiki.org/wiki/User:Aude/Git

Perhaps it would worth merging and putting to some central location?

On Tue, Nov 10, 2015 at 5:58 PM, Petr Bena  wrote:
> Hello,
>
> I would like to remind that I made this guide some time ago:
>
> https://www.mediawiki.org/wiki/User:Petrb/Git_for_idiots
>
> It always quite sucked and still does, but I tried to slightly rewrite
> it now, so it should contain more accurate information.
>
> I would like to keep it as a super simple manual / cheat sheet for
> git, that is as much clear and simple as possible.
>
> If you ever struggled with git, maybe it could help you. If you are a
> git expert you may want to contribute to it? The name of the guide may
> not be a best choice, so I might eventually move it to [[Git for
> dummies]] or something like that, so that it sounds a bit more
> friendly.
>
> I don't know if we already have any super simple guide / cheat sheet
> for git, where you could find everything essential on 1 page (and it
> was a wiki page editable by everyone), but I think we don't. We might
> use this as one?

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

Re: [Wikitech-l] Summit proposal: Turning the Table of Contents into a discrete object

[C. Scott Ananian]

Worth noting that parsoid output does not include the ToC, since it is
expected to be generated after the fact.
  --scott
On Nov 10, 2015 3:20 AM, "Marcin Cieslak"  wrote:

> On 2015-11-10, Isarra Yos  wrote:
> > Hi! I would like to turn the mw ToC into a discrete object within the
> > codebase. Write a ToC class and pull all the random building parts out
> > of the parser and five levels of pageoutput, and make it stop messing up
> > the page caching and stuff. Make this class a thing, separate from the
> > content itself, that can appear on the page or be toggled or messed with
> > or added to or moved or whatever by extensions.
> >
> > I have a proposal about this for the developers summit which is about as
> > specific: https://phabricator.wikimedia.org/T114057
>
> Wow, very good, I would no longer need
> https://www.mediawiki.org/wiki/Extension:DeToc
>
> Lots of nuances probably though.
>
> Saper
>
>
> ___
> 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] Git for idiots

[Nick Wilson (Quiddity)]

On Tue, Nov 10, 2015 at 10:54 AM, Legoktm  wrote:
>
> Hi,
>
> On 11/10/2015 09:06 AM, Petr Bena wrote:
> > Perhaps it would worth merging and putting to some central location?
>
> Yes, that sounds like a good idea. I typically recommend
>  to
> people who are confused with git.
>

+1, as someone who uses it rarely enough to /always/ have to consult the FAQs.
I compiled a list at https://www.mediawiki.org/wiki/Git/Tips#See_also
and posted at https://www.mediawiki.org/wiki/Topic:Ssg7cjp65lw1oc7y

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

Re: [Wikitech-l] Yandex?

[Legoktm]

On 07/02/2015 12:55 PM, Legoktm wrote:
> On 07/01/2015 06:50 PM, Ricordisamoa wrote:
>> Il 02/07/2015 03:28, Legoktm ha scritto:
>>> I noticed: "Yandex coming up soon!" under ContentTranslation. Are there
>>> more details about what this means?
>>
>> https://phabricator.wikimedia.org/T89844 I think
> 
> Thanks for the pointer. After some more digging, I found
> .
> 
> So it appears that ContentTranslation will be contacting a third-party,
> closed source service? Are users going to be informed that this is the
> case? What data is being sent?
> 

It appears[1] this has quietly gone ahead without any response here,
which is disappointing.

[1]
https://www.mediawiki.org/w/index.php?title=Content_translation/Documentation/FAQ=1935992=1780766

-- Legoktm

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

Re: [Wikitech-l] Git for idiots

[Legoktm]

Hi,

On 11/10/2015 09:06 AM, Petr Bena wrote:
> Perhaps it would worth merging and putting to some central location?

Yes, that sounds like a good idea. I typically recommend
 to
people who are confused with git.

-- Legoktm

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

[Wikitech-l] RFC: make Parser::getTargetLanguage aware of multilingual wikis

[Daniel Kinzler]

Hi all!

Tomorrow's RFC discussion[1] on IRC (22:00 UTC at #wikimedia-office) will be
about my proposal to use  Parser::getTargetLanguage to allow wiki pages to be
generated in different languages depending on the user's interface language [2].

I would like to take this opportunity to gather some input beforehand about how
we can improve MediaWiki's support for multilingual wikis on the parser level.
In particular, I'm interested to learn about the implications my proposal has
for the Translate extension, the templates currently used on commons, sites that
use automatic transliteration, etc.


Some context: Currently, MediaWiki doesn't really have a concept of multilingual
content. But some wikis, like Commons and Wikidata, show page content in the
user's language, using a veriety hacks implemented by extensions such as
Translate and Wikibase. It would be nice to make MediaWiki aware of multilingual
content, and add some limited suppor for this to core. Some bits and pieces
already exist, but that don't quite work for what we need.

One issue is that parser functions (and Lua code) have no good way to know what
the target language for the current page rendering is. Both ParserOptions and
Parser have a getTargetLanguage method, but this is used *only* when displaying
system messages in a different language on pages like MediaWiki:Foo/fr.

I propose to change core so it will set the target language in the parser
options to the user language on wikis/namespaces/pages marked as multilingual.
This would allow parser functions and Lua libraries to generate content in the
desired target language.


There is another related method, which I propose to drop, or at least move:
Title::getDisplayLanguage (resp ContentHandler::getDisplayLanguage). This seems
to be used by wikis that apply transliteration to page content, but it's a but
the semantics ar ea it unclear. I propose to drop this in favor of
ParserOptions::getTargetLanguage, since the display language is not a property
of the page, but an option defined for the rendering of the page.


Another related issue is anonymous browsing of multi-lingual content. This will
either go past the web cache layer (as is currently done on commons), or it's
simply not possible (as currently on wikidata). I have put up an RFC for that as
well[3], to be discussed at a different time.


[1] 
[2] 
[3] 


-- Daniel Kinzler


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

Re: [Wikitech-l] Yandex?

[C. Scott Ananian]

Transcribing from the last Metrics Meeting (
https://www.youtube.com/watch?v=ePV-7nhO-z0 around minute 54, and then
more specifically in response to a question at 55:35): "We have
apertium running... we are going to add the yandex service... we found
out that different languages have different translation tools... so it
really depends on which language pairs ... we are looking for *many*
plugin [backends]."

Cc'ing Santhosh, who was the presenter.

Hope that helps.
 --scott

On Tue, Nov 10, 2015 at 1:47 PM, Legoktm  wrote:
> On 07/02/2015 12:55 PM, Legoktm wrote:
>> On 07/01/2015 06:50 PM, Ricordisamoa wrote:
>>> Il 02/07/2015 03:28, Legoktm ha scritto:
 I noticed: "Yandex coming up soon!" under ContentTranslation. Are there
 more details about what this means?
>>>
>>> https://phabricator.wikimedia.org/T89844 I think
>>
>> Thanks for the pointer. After some more digging, I found
>> .
>>
>> So it appears that ContentTranslation will be contacting a third-party,
>> closed source service? Are users going to be informed that this is the
>> case? What data is being sent?
>>
>
> It appears[1] this has quietly gone ahead without any response here,
> which is disappointing.
>
> [1]
> https://www.mediawiki.org/w/index.php?title=Content_translation/Documentation/FAQ=1935992=1780766
>
> -- Legoktm
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
(http://cscott.net)

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

Re: [Wikitech-l] Yandex?

[John Mark Vandenberg]

On Wed, Nov 11, 2015 at 5:47 AM, Legoktm  wrote:
> On 07/02/2015 12:55 PM, Legoktm wrote:
>> On 07/01/2015 06:50 PM, Ricordisamoa wrote:
>>> Il 02/07/2015 03:28, Legoktm ha scritto:
 I noticed: "Yandex coming up soon!" under ContentTranslation. Are there
 more details about what this means?
>>>
>>> https://phabricator.wikimedia.org/T89844 I think
>>
>> Thanks for the pointer. After some more digging, I found
>> .
>>
>> So it appears that ContentTranslation will be contacting a third-party,
>> closed source service? Are users going to be informed that this is the
>> case? What data is being sent?
>>
>
> It appears[1] this has quietly gone ahead without any response here,
> which is disappointing.
>
> [1]
> https://www.mediawiki.org/w/index.php?title=Content_translation/Documentation/FAQ=1935992=1780766

As the user is isolated from the communication with Yandex , I don't
see it as a huge problem.  Using Qualtrics seems to be a much more
serious problem, and nobody seems to care about that.

Yandex is sort of similar to a "MP4 upload only" support, only without
the patent concerns.  Relying on it comes at the risk that the service
stops, but the free content created is not infected.  More likely,
Yandex will start asking WMF for money, and WMF decides to pay because
it is 'easier' than terminating using the service.

Anyway, I've added it to

https://meta.wikimedia.org/wiki/Open_source

--
John Vandenberg

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

Re: [Wikitech-l] RFC: make Parser::getTargetLanguage aware of multilingual wikis

[Brian Wolff]

On 11/10/15, Brad Jorsch (Anomie)  wrote:
> This in general reminds me of https://phabricator.wikimedia.org/T4085.
>
> Also, if page content can vary based on user language, what to do about bug
> reports that Special:WhatLinksHere, category listings, file usage data at
> the bottom of file description pages, and so on don't report a
> link/template/category/file that only exists on the page when it's viewed
> in a non-default language? Yeah, we already have that with {{int:}} hacks,
> but you're talking about making it more of a feature.

If I remember correctly, we already parse the page once in the user
language, and once in the content language (canonical parser options)
in order to prevent this issue.

I think the biggest thing we could do for multi-lingual support, is
introduce {{USERLANGUAGE}} magic word (and equivalent for lua) so
people stop using int hacks which is a poor user experience, even by
wikitext standards. Most arguments against it are about parser cache
splitting, which is silly, as people already split the parser cache on
a massive level using {{int: hacks on commons, and the table of
contents on pretty much every other wiki (As an aside, TOC really
shouldn't split parser cache imo, and that's something I'd like to fix
at some point, but as it stands, any page with a ToC is split by user
language)

The biggest gotcha to look out for imo, is things like number
formatting in parser functions. Sometimes users write templates that
make assumptions about the number formatting, and it can vary by page
language (however, its entirely possible to make proper templates that
don't do that). [Sometimes number formatting seems to use content
language, sometimes it seems to use functionLang]

As for actual proposal, I'm a fan of being able to associate a
language with a specific revision, to override the default wiki
language on a per revision basis. I think it might be interesting to
be able to set 'mul' as the content language, in order to make the
pages always be in the user language, but that's the sort of thing I
think needs some testing to discover forgotten about assumptions about
language that MediaWiki might make.

--
bawolff

> On Tue, Nov 10, 2015 at 2:07 PM, Daniel Kinzler 
> wrote:
>
>> Hi all!
>>
>> Tomorrow's RFC discussion[1] on IRC (22:00 UTC at #wikimedia-office) will
>> be
>> about my proposal to use  Parser::getTargetLanguage to allow wiki pages to
>> be
>> generated in different languages depending on the user's interface
>> language [2].
>>
>> I would like to take this opportunity to gather some input beforehand
>> about how
>> we can improve MediaWiki's support for multilingual wikis on the parser
>> level.
>> In particular, I'm interested to learn about the implications my proposal
>> has
>> for the Translate extension, the templates currently used on commons,
>> sites that
>> use automatic transliteration, etc.
>>
>>
>> Some context: Currently, MediaWiki doesn't really have a concept of
>> multilingual
>> content. But some wikis, like Commons and Wikidata, show page content in
>> the
>> user's language, using a veriety hacks implemented by extensions such as
>> Translate and Wikibase. It would be nice to make MediaWiki aware of
>> multilingual
>> content, and add some limited suppor for this to core. Some bits and
>> pieces
>> already exist, but that don't quite work for what we need.
>>
>> One issue is that parser functions (and Lua code) have no good way to know
>> what
>> the target language for the current page rendering is. Both ParserOptions
>> and
>> Parser have a getTargetLanguage method, but this is used *only* when
>> displaying
>> system messages in a different language on pages like MediaWiki:Foo/fr.
>>
>> I propose to change core so it will set the target language in the parser
>> options to the user language on wikis/namespaces/pages marked as
>> multilingual.
>> This would allow parser functions and Lua libraries to generate content in
>> the
>> desired target language.
>>
>>
>> There is another related method, which I propose to drop, or at least
>> move:
>> Title::getDisplayLanguage (resp ContentHandler::getDisplayLanguage). This
>> seems
>> to be used by wikis that apply transliteration to page content, but it's a
>> but
>> the semantics ar ea it unclear. I propose to drop this in favor of
>> ParserOptions::getTargetLanguage, since the display language is not a
>> property
>> of the page, but an option defined for the rendering of the page.
>>
>>
>> Another related issue is anonymous browsing of multi-lingual content. This
>> will
>> either go past the web cache layer (as is currently done on commons), or
>> it's
>> simply not possible (as currently on wikidata). I have put up an RFC for
>> that as
>> well[3], to be discussed at a different time.
>>
>>
>> [1] 
>> [2] 
>> [3] 
>>
>>
>> -- 

Re: [Wikitech-l] RFC: make Parser::getTargetLanguage aware of multilingual wikis

[Brad Jorsch (Anomie)]

On Tue, Nov 10, 2015 at 4:00 PM, Brian Wolff  wrote:

> On 11/10/15, Brad Jorsch (Anomie)  wrote:
> > Also, if page content can vary based on user language, what to do about
> bug
> > reports that Special:WhatLinksHere, category listings, file usage data at
> > the bottom of file description pages, and so on don't report a
> > link/template/category/file that only exists on the page when it's viewed
> > in a non-default language? Yeah, we already have that with {{int:}}
> hacks,
> > but you're talking about making it more of a feature.
>
> If I remember correctly, we already parse the page once in the user
> language, and once in the content language (canonical parser options)
> in order to prevent this issue.
>

We parse in the content language to avoid T16404
, which is somewhat the opposite.

My concern here is that if varying page content on user language becomes a
supported thing, people will probably complain that
{{#ifeq:{{USERLANG}}|en|[[Category:Foo]]|[[Category:Bar]]}} (or the
equivalent in Lua) on a site with 'en' as the default won't show the page
when you look at Category:Bar, even though it probably will show
Category:Bar at the bottom of the page in non-English languages.

T16404  was about the fact that
doing the equivalent with {{int:}} hacks used to sometimes put the page in
Category:Foo and sometimes in Category:Bar, depending on the language of
whoever last edited (or null-edited) the page.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] RFC: make Parser::getTargetLanguage aware of multilingual wikis

[Brad Jorsch (Anomie)]

This in general reminds me of https://phabricator.wikimedia.org/T4085.

Also, if page content can vary based on user language, what to do about bug
reports that Special:WhatLinksHere, category listings, file usage data at
the bottom of file description pages, and so on don't report a
link/template/category/file that only exists on the page when it's viewed
in a non-default language? Yeah, we already have that with {{int:}} hacks,
but you're talking about making it more of a feature.

On Tue, Nov 10, 2015 at 2:07 PM, Daniel Kinzler 
wrote:

> Hi all!
>
> Tomorrow's RFC discussion[1] on IRC (22:00 UTC at #wikimedia-office) will
> be
> about my proposal to use  Parser::getTargetLanguage to allow wiki pages to
> be
> generated in different languages depending on the user's interface
> language [2].
>
> I would like to take this opportunity to gather some input beforehand
> about how
> we can improve MediaWiki's support for multilingual wikis on the parser
> level.
> In particular, I'm interested to learn about the implications my proposal
> has
> for the Translate extension, the templates currently used on commons,
> sites that
> use automatic transliteration, etc.
>
>
> Some context: Currently, MediaWiki doesn't really have a concept of
> multilingual
> content. But some wikis, like Commons and Wikidata, show page content in
> the
> user's language, using a veriety hacks implemented by extensions such as
> Translate and Wikibase. It would be nice to make MediaWiki aware of
> multilingual
> content, and add some limited suppor for this to core. Some bits and pieces
> already exist, but that don't quite work for what we need.
>
> One issue is that parser functions (and Lua code) have no good way to know
> what
> the target language for the current page rendering is. Both ParserOptions
> and
> Parser have a getTargetLanguage method, but this is used *only* when
> displaying
> system messages in a different language on pages like MediaWiki:Foo/fr.
>
> I propose to change core so it will set the target language in the parser
> options to the user language on wikis/namespaces/pages marked as
> multilingual.
> This would allow parser functions and Lua libraries to generate content in
> the
> desired target language.
>
>
> There is another related method, which I propose to drop, or at least move:
> Title::getDisplayLanguage (resp ContentHandler::getDisplayLanguage). This
> seems
> to be used by wikis that apply transliteration to page content, but it's a
> but
> the semantics ar ea it unclear. I propose to drop this in favor of
> ParserOptions::getTargetLanguage, since the display language is not a
> property
> of the page, but an option defined for the rendering of the page.
>
>
> Another related issue is anonymous browsing of multi-lingual content. This
> will
> either go past the web cache layer (as is currently done on commons), or
> it's
> simply not possible (as currently on wikidata). I have put up an RFC for
> that as
> well[3], to be discussed at a different time.
>
>
> [1] 
> [2] 
> [3] 
>
>
> -- Daniel Kinzler
>
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Yandex?

[C. Scott Ananian]

According to my listening of that Metrics meeting, it does seem like
WMF is going to have to pay Yandex for using its service.  But as you
say, that doesn't infect the actual translation text, which goes into
wikipedia and extends the free content available for everyone.
 --scott

On Tue, Nov 10, 2015 at 3:31 PM, John Mark Vandenberg  wrote:
> On Wed, Nov 11, 2015 at 5:47 AM, Legoktm  wrote:
>> On 07/02/2015 12:55 PM, Legoktm wrote:
>>> On 07/01/2015 06:50 PM, Ricordisamoa wrote:
 Il 02/07/2015 03:28, Legoktm ha scritto:
> I noticed: "Yandex coming up soon!" under ContentTranslation. Are there
> more details about what this means?

 https://phabricator.wikimedia.org/T89844 I think
>>>
>>> Thanks for the pointer. After some more digging, I found
>>> .
>>>
>>> So it appears that ContentTranslation will be contacting a third-party,
>>> closed source service? Are users going to be informed that this is the
>>> case? What data is being sent?
>>>
>>
>> It appears[1] this has quietly gone ahead without any response here,
>> which is disappointing.
>>
>> [1]
>> https://www.mediawiki.org/w/index.php?title=Content_translation/Documentation/FAQ=1935992=1780766
>
> As the user is isolated from the communication with Yandex , I don't
> see it as a huge problem.  Using Qualtrics seems to be a much more
> serious problem, and nobody seems to care about that.
>
> Yandex is sort of similar to a "MP4 upload only" support, only without
> the patent concerns.  Relying on it comes at the risk that the service
> stops, but the free content created is not infected.  More likely,
> Yandex will start asking WMF for money, and WMF decides to pay because
> it is 'easier' than terminating using the service.
>
> Anyway, I've added it to
>
> https://meta.wikimedia.org/wiki/Open_source
>
> --
> John Vandenberg
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l



-- 
(http://cscott.net)

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

[Wikitech-l] Skinning tutorial

[Isarra Yos]

As a bit of a follow up to the talk I did last week, I wrote up a 
tutorial on-wiki how to make a skin: 
https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_motherfucking_skin
The plan is to eventually replace Manual:Skinning with that and some 
subpages with specific info, but if anyone wants to run through now, see 
if it's useful, try it out, see if anything is missing or wrong, I'd 
appreciate the help making it better.


-I

ps - Yes, I may have read motherfuckingwebsite.com a few too many times 
before writing that up. I, uh, sort of apologise.


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

Re: [Wikitech-l] RFC: make Parser::getTargetLanguage aware of multilingual wikis

[C. Scott Ananian]

I believe the title language support is for the LanguageConverter
extension.  They used to (ab)use the `{{DISPLAYTITLE:title}}` magic
word in order to use the proper language variant, something like:

`{{DISPLAYTITLE:-{en-us:Color; en-gb:Colour}-}}`

Then support was added to avoid the need for this hack, and just Do
The Right Thing.  I don't know the details, but presumably
`Title::getDisplayLanguage` is part of it.


On Tue, Nov 10, 2015 at 4:00 PM, Brian Wolff  wrote:
> contents on pretty much every other wiki (As an aside, TOC really
> shouldn't split parser cache imo, and that's something I'd like to fix
> at some point, but as it stands, any page with a ToC is split by user
> language)

Then you'll be interested in taking a look at
https://phabricator.wikimedia.org/T114057
 --scott

-- 
(http://cscott.net)

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

[Wikitech-l] [RFC] Balanced templates (was: [RFC] Hygienic templates)

[C. Scott Ananian]

The RFC proposal for "hygienic templates" got improved a bunch -- and
renamed to "balanced templates" -- during the parsing team off-site.  It
seems like it's worth resending this to the list.  Comments on the updated
draft welcome!



As described in my Wikimania 2015 talk

 (starting at slide 27
),
there are a number of reasons to mark certain templates as "balanced".
Foremost among them: to allow high-performance incremental update of page
contents after templates are modified, and to allow safe editing of
template uses using HTML-based tools such as Visual Editor or jsapi
.

This means (roughly) that the output of the template is a complete
DocumentFragment
: every
open tag is closed and there are no nodes which the HTML adoption agency
algorithm
 will
reorder.  (More precise details below.)

Template balance is enforced: tags are closed or removed as necessary to
ensure that the output satisfies the necessary constraints, regardless of
the values of the template arguments or how child templates are expanded.
You can imagine this as running tidy (or something like it
) on the template output before
it is inserted into the document; but see below for the actual
implementation.

The primary benefit of balanced templates is allowing efficient update of
articles by doing substring substitution for template bodies, without
having to expand all templates to wikitext and reparse from scratch.  It
also guarantees that the template (and surrounding content) will be
editable in Visual Editor; mistakes in template arguments won't "leak out"
and prevent editing of surrounding content.

***Wikitext Syntax***

After some bikeshedding, we decided that balance should be an "opt-in"
property of templates, indicated by adding a `{{#balance:TYPE}}` marker to
the content.  This syntax leverages the existing "parser function" syntax,
and allows for different types of balance to be named where `TYPE` is.

We propose three forms of balance, of which only the first is likely to be
implemented initially.  Other balancing modes would provide safety in
different HTML-parsing contexts.  We've named two below; more might be
added in the future if there is need.


   1. `{{#balance:block}}` would close any open ``/``/``/``
   tags in the article preceding the template insertion site.  In the template
   content all tags left open at the end will be closed, but there is no other
   restriction.  This is similar to how block-level tags work in HTML 5. This
   is useful for navboxes and other "block" content.
   2. `{{#balance:inline}}` would only allow inline (i.e. phrasing) content
   and generate an error if a ``/``/``/``/``/``/`
   `/`` tag is seen in the content.  But because of this, it //*can*//
   be used inside a block-level context without closing active ``/``/`
   `/`` in the article (as `{{#balance:block}}` would).  This is
   useful for simple plain text templates, e.g. age calculation.
   3. `{{#balance:table}}` would close ``/``/`` but would allow
   insertion inside `` and allow ``/`` tags in the content.
(There might be some other content restrictions to prevent fostering.)

We expect `{{#balance:block}}` to be most useful for the large-ish
templates whose efficient replacement would make the most impact on
performance, and so we propose `{{#balance:}}` as a possible shorthand for `
{{#balance:block}}`.  (The current wikitext grammar does not allow `
{{#balance}}`, since the trailing colon is required in parser function
names, but if desired we could probably accommodate that abbreviation as
well without too much pain.)

Violations of content restrictions (ie, a `` tag in a `
{{#balance:inline}}` template) would be errors, but how these errors would
be conveyed is an orthogonal issue.  Some options for error reporting
include ugly bold text visible to readers (like `{{cite}}`), wikilint-like
reports, or inclusion in `[[Category:Balance Errors]]`.  Note that errors
might not appear immediately: they may only occur when some other included
template is edited to newly produce disallowed content, or only when
certain values are passed as template arguments.

***Implementation***

Implementation is slightly different in the PHP parser and in Parsoid.
Incremental parsing/update would necessarily not be done in the PHP parser,
but it does need to enforce equivalent content model constraints for
consistency.

PHP parser implementation strategy:

   - When a template with `{{#balance}}` is expanded, add a marker to the
   start of its output.
   - In the Sanitizer leave 

Re: [Wikitech-l] RFC: make Parser::getTargetLanguage aware of multilingual wikis

[Brian Wolff]

On 11/10/15, Brad Jorsch (Anomie)  wrote:
> On Tue, Nov 10, 2015 at 4:00 PM, Brian Wolff  wrote:
>
>> On 11/10/15, Brad Jorsch (Anomie)  wrote:
>> > Also, if page content can vary based on user language, what to do about
>> bug
>> > reports that Special:WhatLinksHere, category listings, file usage data
>> > at
>> > the bottom of file description pages, and so on don't report a
>> > link/template/category/file that only exists on the page when it's
>> > viewed
>> > in a non-default language? Yeah, we already have that with {{int:}}
>> hacks,
>> > but you're talking about making it more of a feature.
>>
>> If I remember correctly, we already parse the page once in the user
>> language, and once in the content language (canonical parser options)
>> in order to prevent this issue.
>>
>
> We parse in the content language to avoid T16404
> , which is somewhat the opposite.
>
> My concern here is that if varying page content on user language becomes a
> supported thing, people will probably complain that
> {{#ifeq:{{USERLANG}}|en|[[Category:Foo]]|[[Category:Bar]]}} (or the
> equivalent in Lua) on a site with 'en' as the default won't show the page
> when you look at Category:Bar, even though it probably will show
> Category:Bar at the bottom of the page in non-English languages.
>
> T16404  was about the fact that
> doing the equivalent with {{int:}} hacks used to sometimes put the page in
> Category:Foo and sometimes in Category:Bar, depending on the language of
> whoever last edited (or null-edited) the page.
>
>

Ah. I read your previous email too fast.

Maybe we should have something like:

{{#langswitch:
en=foo
fr=le foo
..
}}

which works like normal #switch, except without dead-branch
elimination. (And for bonus points, implements language fallback
sanely).

Or maybe an in-core feature {{#langtransclude:foo}}, which works like
normal {{foo}}, except it translcudes the language subpage instead
(and does smart fallback, and records a transclusion link record for
all the 2-3 letter subpages of the template).

Whatever else we do, I'm really not a fan of the syntax that translate
extension does. If we implement something in core to make
multilingualism easier, I really hope we go with more sane syntax.
[And I say that as a person who love's MW's general crazy syntax]

--
-bawolff

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

Re: [Wikitech-l] Skinning tutorial

[S Page]

(A plug for https://phabricator.wikimedia.org/T114071 "Let's discuss the
skin creation process")

That and Isarra's tech talk inspired me to improve
https://www.mediawiki.org/wiki/Manual:Skinning : part 1 now has a picture
showing some components, part 3 no longer talks about old i18n, etc. I also
dragged https://www.mediawiki.org/wiki/Manual:QuickTemplate into 2015.

The tutorial is pretty good IMO, the problem is it forced repetition. part
1 "Here are some page elements you need to worry about"; part 2 "Let's
output some of those page elements"; part 3 "How to test these page
elements". But maybe that's OK.


On Tue, Nov 10, 2015 at 11:40 AM, Isarra Yos  wrote:

> As a bit of a follow up to the talk I did last week, I wrote up a tutorial
> on-wiki how to make a skin:
> https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_motherfucking_skin
> The plan is to eventually replace Manual:Skinning with that and some
> subpages with specific info, but if anyone wants to run through now, see if
> it's useful, try it out, see if anything is missing or wrong, I'd
> appreciate the help making it better.
>
> -I
>
> ps - Yes, I may have read motherfuckingwebsite.com a few too many times
> before writing that up. I, uh, sort of apologise.
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l




-- 
=S Page  WMF Tech writer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

[Wikitech-l] Transitioning wikistats pageview reports to use new pageview definition

[Nuria Ruiz]

Hello!

The analytics team wishes to announce that we have finally transitioned
several of the pageview reports in stats.wikimedia.org  to the new pageview
definition [1]. This means that we should no longer have two conflicting
sources of pageview numbers.

While we are not not fully done transitioning pageview reports we feel this
is an important enough milestone that warrants some communication. BIG
Thanks to Erik Z. for his work on this project.

Please take a look at a report using the new definition (a banner is
present when report has been updated)
http://stats.wikimedia.org/EN/TablesPageViewsMonthlyCombined.htm

Thanks,

Nuria


[1] https://meta.wikimedia.org/wiki/Research:Page_view
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Skinning tutorial

[Isarra Yos]

On 10/11/15 21:59, S Page wrote:

The tutorial is pretty good IMO, the problem is it forced repetition. part
1 "Here are some page elements you need to worry about"; part 2 "Let's
output some of those page elements"; part 3 "How to test these page
elements". But maybe that's OK.


This may just be because I did it at three in the morning; it probably 
doesn't need that much. I'll see if I can clean that up a bit. >.>


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

Re: [Wikitech-l] RFC: make Parser::getTargetLanguage aware of multilingual wikis

[Brad Jorsch (Anomie)]

On Tue, Nov 10, 2015 at 4:39 PM, Brian Wolff  wrote:

> Maybe we should have something like:
>
> {{#langswitch:
> en=foo
> fr=le foo
> ..
> }}
>
> which works like normal #switch, except without dead-branch
> elimination. (And for bonus points, implements language fallback
> sanely).
>

That might work in itself. But then {{foo|var={{#langswitch:... would
probably still have potential issues, and the same sort of thing in
Scribunto however it's implemented there.


> Or maybe an in-core feature {{#langtransclude:foo}}, which works like
> normal {{foo}}, except it translcudes the language subpage instead
> (and does smart fallback, and records a transclusion link record for
> all the 2-3 letter subpages of the template).
>

You'd also have to parse all those 2-3 letter subpages to get their links,
categories, subtemplates, and so on.


-- 
Brad Jorsch (Anomie)
Senior Software Engineer
Wikimedia Foundation
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Summit proposal: Turning the Table of Contents into a discrete object

[Marcin Cieslak]

On 2015-11-10, Isarra Yos  wrote:
> Hi! I would like to turn the mw ToC into a discrete object within the 
> codebase. Write a ToC class and pull all the random building parts out 
> of the parser and five levels of pageoutput, and make it stop messing up 
> the page caching and stuff. Make this class a thing, separate from the 
> content itself, that can appear on the page or be toggled or messed with 
> or added to or moved or whatever by extensions.
>
> I have a proposal about this for the developers summit which is about as 
> specific: https://phabricator.wikimedia.org/T114057

Wow, very good, I would no longer need 
https://www.mediawiki.org/wiki/Extension:DeToc

Lots of nuances probably though.

Saper


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

Re: [Wikitech-l] "Try the free Wikipedia app" banners

[Toby Negrin]

Hi all -- I wanted to follow up on this thread with the results of the test:

https://www.mediawiki.org/wiki/Wikimedia_Apps/Finland_Banner_Test

TLDR: While we saw a big increase in installs and opens, we found that the
campaign did not significantly increase pageviews, leading us to conclude
that readers are interested in using an app, but given the current
experience would  rather use the mobile web than the native app.

-Toby

On Wed, Sep 9, 2015 at 11:51 AM, Ryan Lane  wrote:

> On Wed, Sep 9, 2015 at 7:08 AM, Adam Wight  wrote:
>
> >
> > Another misconception or oversight I want to bring up is that Fundraising
> > is the team pioneering the 2/3-page or full-page banners.  We're driving
> > readers from the website to completely closed and somewhat evil payments
> > platforms.  If there's any relevant or even irrelevant research about
> > interstitials, please apply it to our work, cos we're about to have a
> huge
> > impact on the English-speaking community in December.  Any complaints
> about
> > the Finnish mobile experiment and dogpiling on the awesome apps
> developers
> > seem incredibly misplaced while I'm walking around with this "Kick Me"
> sign
> > on my backside.
> >
> >
> I'm couldn't fully grok what point this was making, but whether it's this
> mobile experiment or fundraising doing 2/3 or full-page banners, they're
> terrible. This has been a major complaint by numerous people over the past
> few years. Please tell me you're not considering interstitials, 2/3 page,
> or full page banners for fundraising? This may be the year I actually start
> boycotting the Wikimedia fundraiser, if so.
>
> - Ryan
> ___
> 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] Skinning tutorial

[Isarra Yos]

On 11/11/15 02:06, S Page wrote:

On Tue, Nov 10, 2015 at 2:39 PM, Isarra Yos  replied:


On 10/11/15 21:59, S Page wrote:


The tutorial is pretty good IMO, the problem is it forced repetition


This may just be because I did it at three in the morning; it probably
doesn't need that much. I'll see if I can clean that up a bit. >.>


D'oh, I'm sorry, I meant the on-wiki three-part skinning thing that's been
around for a while and introduces in a nutshell as "This page is part 1 of
a three-part tutorial".


Oh, I want to murder that. Have I mentioned that? I think I have, but if 
I haven't, I'D LIKE TO MURDER THAT. It doesn't even say how to do the 
important bits, while focussing on bits nobody in their right mind will 
ever even touch, with no real structure or sensible organisation. It's 
ludicrous.



Re:
https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_motherfucking_skin

I have a dream where both extensions/BoilerPlate and skins/Example are a
script that prompts for your extension or skin name, clones it into
YourProject, sets up the example as a non-master remote (so you can track
updates to the skeleton), and does the mindless file renames and search and
replace to YourProjectName. [1]


Or not even having the remote necessarily (letting people just download 
it so they can mess around without necessarily leaving any sign around 
they did), but yes, that sounds very useful.



Also you can probably delete any random things that say 'composer' or

'grunt' or whatever in the filenames. Not really sure why those are in the
example skin. That's a bit confusing.

Nope, they're gold. It means you can run npm test and composer test and
automatically have a growing set of basic tests and coding checkers run for
you.  See BoilerPlate's README.md [1] , maybe the same instructions should
be copied to skins/Example.


Isn't that all broken by default because it's still using the example 
config?



The good advice in your Step 4 and Testing could fit well into Skinning
Part 3.


Frankly the fact that there are three parts means most users are never 
going to make it to part three. Which is also something to... not do?



[1] Legoktm built such a thing for Wikimedia libraries,
https://github.com/wikimedia/generator-wikimedia-php-library#readme
[2] https://github.com/wikimedia/mediawiki-extensions-BoilerPlate#readme




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

Re: [Wikitech-l] Skinning tutorial

[S Page]

On Tue, Nov 10, 2015 at 2:39 PM, Isarra Yos  replied:

> On 10/11/15 21:59, S Page wrote:
>
>> The tutorial is pretty good IMO, the problem is it forced repetition
>
>
> This may just be because I did it at three in the morning; it probably
> doesn't need that much. I'll see if I can clean that up a bit. >.>


D'oh, I'm sorry, I meant the on-wiki three-part skinning thing that's been
around for a while and introduces in a nutshell as "This page is part 1 of
a three-part tutorial".

Re:
https://www.mediawiki.org/wiki/User:Isarra/How_to_make_a_motherfucking_skin

I have a dream where both extensions/BoilerPlate and skins/Example are a
script that prompts for your extension or skin name, clones it into
YourProject, sets up the example as a non-master remote (so you can track
updates to the skeleton), and does the mindless file renames and search and
replace to YourProjectName. [1]

> Also you can probably delete any random things that say 'composer' or
'grunt' or whatever in the filenames. Not really sure why those are in the
example skin. That's a bit confusing.
Nope, they're gold. It means you can run npm test and composer test and
automatically have a growing set of basic tests and coding checkers run for
you.  See BoilerPlate's README.md [1] , maybe the same instructions should
be copied to skins/Example.

The good advice in your Step 4 and Testing could fit well into Skinning
Part 3.

[1] Legoktm built such a thing for Wikimedia libraries,
https://github.com/wikimedia/generator-wikimedia-php-library#readme
[2] https://github.com/wikimedia/mediawiki-extensions-BoilerPlate#readme

-- 
=S Page  WMF Tech writer
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l

Re: [Wikitech-l] Yandex?

[Luis Villa]

I haven't been directly involved in a while, but we were certainly not
paying Yandex last time I looked at the arrangement. Appropriate legal
steps were also taken to protect the licensing of the content, and
appropriate technical steps to protect PII of editors, among other things.

FWIW-
Luis

On Tue, Nov 10, 2015 at 1:12 PM, C. Scott Ananian 
wrote:

> According to my listening of that Metrics meeting, it does seem like
> WMF is going to have to pay Yandex for using its service.  But as you
> say, that doesn't infect the actual translation text, which goes into
> wikipedia and extends the free content available for everyone.
>  --scott
>
> On Tue, Nov 10, 2015 at 3:31 PM, John Mark Vandenberg 
> wrote:
> > On Wed, Nov 11, 2015 at 5:47 AM, Legoktm 
> wrote:
> >> On 07/02/2015 12:55 PM, Legoktm wrote:
> >>> On 07/01/2015 06:50 PM, Ricordisamoa wrote:
>  Il 02/07/2015 03:28, Legoktm ha scritto:
> > I noticed: "Yandex coming up soon!" under ContentTranslation. Are
> there
> > more details about what this means?
> 
>  https://phabricator.wikimedia.org/T89844 I think
> >>>
> >>> Thanks for the pointer. After some more digging, I found
> >>> <
> https://www.mediawiki.org/wiki/Thread:Talk:Content_translation/Specification/Yandex_backend
> >.
> >>>
> >>> So it appears that ContentTranslation will be contacting a third-party,
> >>> closed source service? Are users going to be informed that this is the
> >>> case? What data is being sent?
> >>>
> >>
> >> It appears[1] this has quietly gone ahead without any response here,
> >> which is disappointing.
> >>
> >> [1]
> >>
> https://www.mediawiki.org/w/index.php?title=Content_translation/Documentation/FAQ=1935992=1780766
> >
> > As the user is isolated from the communication with Yandex , I don't
> > see it as a huge problem.  Using Qualtrics seems to be a much more
> > serious problem, and nobody seems to care about that.
> >
> > Yandex is sort of similar to a "MP4 upload only" support, only without
> > the patent concerns.  Relying on it comes at the risk that the service
> > stops, but the free content created is not infected.  More likely,
> > Yandex will start asking WMF for money, and WMF decides to pay because
> > it is 'easier' than terminating using the service.
> >
> > Anyway, I've added it to
> >
> > https://meta.wikimedia.org/wiki/Open_source
> >
> > --
> > John Vandenberg
> >
> > ___
> > Wikitech-l mailing list
> > Wikitech-l@lists.wikimedia.org
> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>
>
>
> --
> (http://cscott.net)
>
> ___
> Wikitech-l mailing list
> Wikitech-l@lists.wikimedia.org
> https://lists.wikimedia.org/mailman/listinfo/wikitech-l
>



-- 
Luis Villa
Sr. Director of Community Engagement
Wikimedia Foundation
*Working towards a world in which every single human being can freely share
in the sum of all knowledge.*
___
Wikitech-l mailing list
Wikitech-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l