Hi.
I tried to write a Scribunto module in Lua today on Meta-Wiki called
"Sort": <https://meta.wikimedia.org/wiki/Module:Sort>. I struggled a lot
to get an environment set up where I could easily test blocks of code, so
I'm looking for any help/guidance I can get.
The debug console seems finicky. Its line numbers never seem to make
sense. For example, I input this into a fresh console:
---
function p.asc(frame)
return frame.args[1]
end
---
Then I try ...
= print(p.asc())
Lua error in console input at line 6: attempt to index local 'frame' (a
nil value).
I have no idea what line 6 refers to. Earlier when I was testing it was
saying line 14. The line numbers never seem to match up to what I think
I'm testing.
If I paste this into the console:
---
local p = {}
function p.asc(frame)
return frame.args[1]
end
function p.desc(frame)
return p.args[1]
end
return p
---
I get "Lua error in console input at line 18: 'end' expected (to close
'function' at line 1) near 'return'."
There's a note on the edit screen about using mw.log(), but with various
inputs, I still can't seem to get anything working properly with the debug
console. For example:
---
function p.asc(frame)
t = {}
t['bar'] = 'baz'
mw.log(t)
return frame.args[1]
end
---
This prints nothing at all when pasted into the debug console. If I try "=
print(t)" or "print(t)" I get "nil".
Related to this, even when I'm able to get something to print or mw.log(),
I usually end up printing the strings "table" or "nil", rather than the
contents of a table. Is there a var_dump equivalent for Lua that can be
used? Lua seems to be very focused on tables for storage, but dumping
what's currently in a table at particular points in the code feels
excruciating. I feel like I must be missing something. This is related to
<https://bugzilla.wikimedia.org/show_bug.cgi?id=48173>.
Is there a better way to write/debug Lua modules? Any help writing these
modules (or simply getting a working sort module on Meta-Wiki) would be
appreciated.
MZMcBride
Hello,
The Universal Language Selector (ULS)[1] provides a flexible way to
configure and deliver language settings like interface language,
fonts, and input methods (keyboard mappings). It combines the features
of two earlier Mediawiki extensions Narayam[2] and WebFonts[3]. From
June 11, 2013 on, ULS will be made available to all Wikimedia wikis in
5 phases[4].
# Phase 1: In the first phase, ULS will replace the Narayam and
WebFonts extensions on 84 wikis[5]. User preferences from the replaced
extensions will not be preserved. Affected communities will be
informed by the Wikimedia Language Engineering team of the upcoming
change.
# Phase 2: In the 5 weeks that follow, ULS will be deployed on
Wikipedias in size 11-20,
# Phase 3: All projects without language versions
# Phase 4: English language Wikipedia
# Phase 5: All other wikis
The ULS can be visible in two ways:
1. In the sidebar for wikis with language versions, like Wikipedia, or
2. In the personal toolbar at the top of wiki pages for wikis without
language versions, like Wikimedia Commons and Meta-Wiki.
Based on the geographic location of users, the initial set of language
preferences is presented. Users can set the input methods and fonts to
that they want to use. Logged-in users can also change the language
for the MediaWiki menu items.
ULS is already available on several Wikimedia wikis like Wikimedia
Commons[6] and Meta-Wiki[7]. The beta installation of English
Wikipedia on Wikimedia Labs[8] shows what will be available as the
look and feel. A cog icon is present in the “Languages” section of the
sidebar menu. Clicking the cog icon opens the Language settings panel
that can be used to set the display and input settings.
Please have a look at the Universal Language Selector feature
description[9] or the Frequently Asked Questions[10] for more detailed
information.
Thank you.
regards
Runa
[1] https://www.mediawiki.org/wiki/Extension:UniversalLanguageSelector
[2] https://www.mediawiki.org/wiki/Extension:Narayam
[3] https://www.mediawiki.org/wiki/Extension:WebFonts
[4] https://www.mediawiki.org/wiki/UniversalLanguageSelector/Deployment/Planning
[5] https://www.mediawiki.org/wiki/UniversalLanguageSelector/Deployment/Plannin…
[6] https://commons.wikimedia.org/wiki/
[7] https://meta.wikimedia.org/wiki/Main_Page
[8] http://en.wikipedia.beta.wmflabs.org/
[9] https://www.mediawiki.org/wiki/Universal_Language_Selector
[10] https://www.mediawiki.org/wiki/Universal_Language_Selector/FAQ
--
Language Engineering - Outreach and QA Coordinator
Wikimedia Foundation
https://meta.wikimedia.org/wiki/User:Runab_WMF
I recently try to modernize an extension [1] to use the /_Html _/class
and found a problem (at least for me) .
Like to receive your comments, and tips.
In several cases, I had to use Htlm::rawElement (*) instead of the safer
Html::element because of a nested <div> structure I want to generate like
<div id=outerdiv>
outertext-with- -or-something-character
<div id=innerdiv>
innertext
</div>
</div>
Html::rawElement( 'div',
array( 'some-outer-attributes' => 'some-outer-attribute-values'),
$outertext .
Html:element( 'div'
array( 'some-inner-attributes' => 'some-inner-attribute-values'),
$innertext
)
After having compared Html methods rawElement and Element, and after
having asked around the #mediawiki
I found that I have to escape the content manually and could/should use
basically one of these two possibilities:
i) The #mediawiki recommended *htmlspecialchars*()
ii) Inside Html:element method I found
*
strtr( $contents, array(**
** // There's no point in escaping quotes, >, etc. in the contents of**
** // elements.**
** '&' => '&',**
** '<' => '<'**
**)*
*Both *are not suited for my case, when $outertext has this " "
character in it.
After looking around in class Html and class Xml I found,
that some of the methods use $wgContLang->normalize( $string ), and this
works for me, too.
I put this is into a private wrapper function escapeContent() =
*$wg**ContLang->normalize() (not shown here)
*
Html::rawElement( 'div',
array( 'some-outer-attributes' => 'some-outer-attribute-values'),
* ***$wg**ContLang->normalize****( $outertext ) .
Html:element( 'div'
array( 'some-inner-attributes' => 'some-inner-attribute-values'),
$innertext
)
I am however not happy with that approach, because I do not know, if it
is correctly applied.
Therefore my questions to you:
1. Is my approach of applying Html class and using ->normalize()
correct ?
2. What could I do better, perhaps should I apply a certain
Sanitizer::method - or what else ?
3. Perhaps I am fully wrong, then please guide me to find a correct
solution.
I will be available on #mediawiki during the evening hours (UTC+2;
Wikinaut )
[1] https://gerrit.wikimedia.org/r/#/c/67002/
Hello!
I've got a serious issue with ResourceLoader.
WHAT FOR it's made to load extension ____styles_____ DYNAMICALLY using
JavaScript?!!!!
It's a very bad idea, it leads to page style flickering during load.
I.e. first the page is displayed using only skin CSS and then you see
how extension styles are dynamically applied to it. Of course it's still
rather fast, but it's definitely noticeable, even in Chrome.
Why didn't you just output <link rel="stylesheet" href="load.php?<ALL
MODULES>" /> ??????????
Am I free to implement it and submit a patch?????
--
With best regards,
Vitaliy Filippov
On Tue, Jun 4, 2013 at 7:56 PM, Tyler Romeo <tylerromeo(a)gmail.com> wrote:
> AuthPlugin never used to handle this kind of stuff. The only extensions
> that use AuthPlugin are those that provide *supplemental* authentication
> services. Notice that E:LDAPAuthentication uses AuthPlugin, but
> E:TwoFactorAuthentication does not. AuthPlugin has never handled additional
> authorization logic, and I don't see any reason why it should.
>
>
So... I'm just now noticing this fork of OATHAuth and it's slightly
infuriating. I would have gladly accepted changes, and the license has been
changed to GPL3 or higher, when OATHAuth is GPL2 or higher, so I can't even
take changes without changing OATHAuth's license!
Was there any reason for this? Can we avoid forks like this? Please?
- Ryan
Hi,
I'm retaking the work I started a couple of weeks ago in the Amsterdam
Hackathon about improving code coverage of the Upload code. At the
moment my main question is how to test all the code paths dealing with
files not written to the FS because of permissions, missing dirs, etc.
Is there a recommended way to do this already in the PHPUnit tests? I
have checked a couple of tests and haven't found anything similar but
if you can point me to one test, or let me know what's the best way to
try that, I can take it from there.
Thanks in advance.
David E. Narvaez