Hello everybody,
I'm trying to figure out the best method for internationalization/localization of MediaWiki Gadgets. There are several approaches implemented in the different available gadgets, but none of them seem to use MediaWikis client side message system. I want to use something like
mw.message('my-gadget-some-key').plain();
But this only works with message keys that are available on the client side, based on the 'messages' field of a server side module definition ($wgResourceModules). The clientside
mw.loader.implement( moduleName, scripts, styles, messages );
has a parameter for a 'messages' config object. But it does not load the translation texts for the keys automatically. Actually it expects a JavaScript object that contains keys _and_ values [1]. I've tried whether the values get overridden when a translation on the MediaWiki-namespace is available, but they don't seem to. Am I missing something important? Can you recommend a method for I18N in a gadget?
Just for the record: I've been experimenting with keeping the messages in subpages ("MediaWiki:Gadget.-/de.js") in JSON format [2] and loading them on runtime via AJAX [3]. I think this has some beauty because it's close to what MediaWiki does on the server side. Unfortunately in this case I'll have to implement a language fallback [4] by myself. Any thoughts or hints?
[1] https://www.mediawiki.org/wiki/ResourceLoader/Features#Response
[2] https://www.mediawiki.org/w/index.php?title=User%3AOsnard%2FGadget-Test%2Fd…
[3] https://www.mediawiki.org/wiki/User:Osnard/Gadget-Test.js
[4] https://www.mediawiki.org/wiki/Localisation#mediaviewer/File:MediaWiki_fall…
--
Robert Vogel
Softwareentwicklung
Hallo Welt! - Medienwerkstatt GmbH
Residenzstraße 2
93047 Regensburg
Tel. +49 (0) 941 - 66 0 80-198
Fax +49 (0) 941 - 66 0 80-189
www.hallowelt.biz
vogel(a)hallowelt.biz
Sitz: Regensburg
Amtsgericht: Regensburg
Handelsregister: HRB 10467
E.USt.Nr.: DE 253050833
Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani
https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-07-23
This Wednesday we're discussing Bryan Davis's suggested "process for using
Composer
managed PHP libraries to support MediaWiki on the WMF production and
beta clusters."
https://www.mediawiki.org/wiki/Requests_for_comment/Composer_managed_librar…
He says: "I would really appreciate comments from those of you
spend time thinking about keeping the cluster running smoothly and
securely. I would especially be excited to hear ideas about how we can
ensure that upstream security issues are tracked and responded to in a
timely manner."
2100-2200 UTC on Wednesday, 23 July, in #wikimedia-office on Freenode IRC.
All are welcome, as usual.
10pm London
5pm New York City
2pm San Francisco
Thursday 7am Sydney
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
Hi,
this is a quick status update on the planned migration of our
development planning tools to Phabricator. See
https://www.mediawiki.org/wiki/Phabricator for general info.
Several things have been worked on and achieved in the meantime:
* WMF SUL Authentication has been implemented for Phabricator.
* A separate server legalpad.wikimedia.org was deployed (a tool to
manage trusted users - workflow to be further defined with
Legal.
* A data backup system for Phabricator in place.
* Code to restrict access to tasks in a certain project is in
place (same as Bugzilla's "Security" project)
* The dedicated Phabricator server was upgraded to Ubuntu Trusty.
* Packaging for Debian using pkg-php-tools/dh_php5
The identified tasks are listed on the planning board at
http://fab.wmflabs.org/project/board/31/
Bugzilla:
When it comes to the planning of how to convert data in Bugzilla tickets
to Phabricator, we are mostly done.
The elements that a Bugzilla report includes are listed in
http://fab.wmflabs.org/T423 with links to subtasks.
Obviously, Phabricator has a different UI and different workflow
concepts than Bugzilla.
While it's not the goal to have complete feature parity in every
possible way, I'm pretty confident that we are close enough.
As people are likely more interested in what Bugzilla functionality will
be different, I'll try to summarize what I'm aware of:
* Bugzilla's products, components and keywords will be turned into
projects / tags in Phabricator.
* Bugzilla votes will be turned into tokens.
* Bugzilla's "Severity" field itself should get dropped - for
example, if there is a real need to be able to search for
critical severity (which translates to "crash"), it can become a
"crash" project in Phabricator (think of "keywords" in terms of
Bugzilla here).
* For those ~50 users who have used Bugzilla's private "Tags"
feature so far (introduced in February), this feature will be
dropped, but you will get warned before. Similar, some
Whiteboard data will likely also get dropped (or moved into the
first comment if really considered relevant).
Apart from that I am not aware of any other data we might drop or
"lose", or any other important functionality that would not be available
in Phabricator.
If you are passionate about a specific topic of task management /
development workflows && if you think after reading existing comments in
the discussion of the related task that an important aspect has not been
considered yet, please feel free to provide your input.
To follow the progress of our Phabricator migration and to help, please
see the planning board at http://fab.wmflabs.org/project/board/31/
Regular status updates are published at
https://www.mediawiki.org/wiki/Phabricator/Migration#Status
As usual, big thanks to Chase and Mukunda for their work, and to many
others for providing input, feedback and help.
Cheers,
andre
--
Andre Klapper | Wikimedia Bugwrangler
http://blogs.gnome.org/aklapper/
HI folks,
I’m working on a another MediaWiki extension and I wanted to know if there is another way to check that the web API is enabled other than just performing:
if ( $wgEnableAPI === true )
I was hoping there was some function that just returned the value of $wgEnableAPI.
If there is another way to see if the user has turned off the web API, that would be cool, too. I just need to check that it’s enabled.
Thanks in advance,
Shawn M. Jones
Graduate Research Assistant
Department of Computer Science
Old Dominion University
Email: sjone(a)cs.odu.edu
Research group: http://ws-dl.blogspot.com
Twitter: @shawnmjones
Hi Helder,
this is great news, thank you. Unfortunately there is not much information on _how_ to register the messages. I guess the code listing below "gd_shared" [1] with the line
"messages": ["foobar-welcome", "foo-bye", "recentchanges"],
shall be an example definition. It probably is intended to go on some Gadget definition page in the MediaWiki namespace, doesn't it?
Do you know about the current state of Gadgets 2.0? Last edit of the page was in February, the talk page is of July 2013 and the Roadmap [2] doesn't contain any dates.
On the talk page Krinkle states in 2013 that is almost ready but VisualEditor was more important and took the resources.
[1] https://www.mediawiki.org/wiki/ResourceLoader/Version_2_Design_Specificatio…
[2] https://www.mediawiki.org/wiki/Extension:Gadgets/Roadmap#Gadgets_2.0
--
Robert
-----Ursprüngliche Nachricht-----
Von: wikitech-l-bounces(a)lists.wikimedia.org [mailto:wikitech-l-bounces@lists.wikimedia.org] Im Auftrag von Helder .
Gesendet: Dienstag, 22. Juli 2014 22:30
An: Wikimedia developers
Betreff: Re: [Wikitech-l] Gadget I18N: Recommendation?
Gadgets 2.0 will solve this:
https://www.mediawiki.org/wiki/Gadgets_2.0#Messages
Helder
_______________________________________________
Wikitech-l mailing list
Wikitech-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
Hello and welcome to the lates edition of the WMF Engineering Roadmap
and Deployment update.
The full log of planned deployments next week can be found at:
<https://wikitech.wikimedia.org/wiki/Deployments#Week_of_July_21st>
A quick list of notable items...
== Monday ==
* Wikitech wiki
** The MediaWiki install at <https://wikitech.wikimedia.org> will be
upgraded starting at 16:00 UTC
== Tuesday ==
* MediaWiki deploy
** group1 to 1.24wmf11: All non-Wikipedia sites (Wiktionary, Wikisource,
Wikinews, Wikibooks, Wikiquote, Wikiversity, and a few other sites)
** <https://www.mediawiki.org/wiki/MediaWiki_1.24/wmf14>
** "Topic:" namespace added (for Flow)
== Wednesday ==
* Weekly fundraising banner test
== Thursday ==
* MediaWiki deploy
** group2 to 1.24wmf14 (all Wikipedias)
*** "Topic:" namespace added (for Flow)
** group0 to 1.24wmf15 (test/test2/testwikidata/mediawiki)
== Longer term ==
The plan (subject to change) for the next month or so:
* July 31st: Thumbnail styling change to testwikis
** <https://bugzilla.wikimedia.org/show_bug.cgi?id=65160>
* end of July: HHVM on all jobrunners
* end of July: Beta Feature: "in other projects" sidebar
** <https://www.mediawiki.org/wiki/Wikibase/Beta_Features/Other_projects_sidebar>
** <https://bugzilla.wikimedia.org/show_bug.cgi?id=66226>
* Aug 5 - 10: Wikimania 2014 (critical deploys only)
* Aug 14: VE as default editing experience for tablets
* Aug 12 - 15: Thumbnail styling change to non-wikipedias then
wikipedias
* Mid-August: change default thumbnail size from 220px to 300px --
** <https://bugzilla.wikimedia.org/show_bug.cgi?id=67709>
** <https://bugzilla.wikimedia.org/show_bug.cgi?id=67703>
Thanks and as always, questions and comments welcome,
Greg
--
| Greg Grossmeier GPG: B2FA 27B1 F7EB D327 6B8E |
| identi.ca: @greg A18D 1138 8E47 FAC8 1C7D |
Hi.
There are three types of private account info I've been considering:
* unexposed in the user interface/hidden/API-only user preferences;
* user session information; and
* per-action CheckUser-related information that's temporarily stored.
What I'd like to see is a single portal (e.g., Special:AccountInfo) that
combines and enhances the functionalities of these two extensions:
* https://www.mediawiki.org/wiki/Extension:AccountInfo
* https://www.mediawiki.org/wiki/Extension:SecureSessions
This portal would be a straightforward dashboard that allows users to see
and manage the private information associated with their account. Advanced
user preferences would be toggle-able (similar to chrome://config or
whatever), active sessions could be inspected or terminated, etc.
Perhaps this special page would require successfully entering the user's
current account password to avoid a bad actor jumping on a victim's
computer or other similar types of nefariousness.
MZMcBride
Hi all! Check out
https://www.mediawiki.org/wiki/Security_for_developers/Architecture -- I
just removed the {{draft}} tag.
These security guidelines help lead developers, architects, and product
managers make decisions that protect MediaWiki's users when developing new
features or refactoring old code.
All MediaWiki developers can follow these principles and process when
developing new core features or extensions. If a developer or team is
planning to have their code deployed on the Wikimedia cluster, following
these guidelines will ensure the security review process is quick and
requires minimal changes before deployment.
This guide interrelates with the Architecture guidelines
<https://www.mediawiki.org/wiki/Architecture_guidelines>, Performance
guidelines <https://www.mediawiki.org/wiki/Performance_guidelines>, and user
experience guidelines
<https://www.mediawiki.org/wiki/Wikimedia_Foundation_Design>.
Thanks to everyone who helped write these, especially Chris Steipp -- he
wrote most of it and I helped. Thanks also to the chiptunes at
https://soundcloud.com/benlandis which helped me power through. :-)
Sumana Harihareswara
Senior Technical Writer
Wikimedia Foundation
