This tend to diverge away from the chrome and into the content, which is a lot more difficult to change. (Urgh, way to long…)
Anyway, I have this really-really weird idea that “staff” should provide (extremely good) design elements, and then local projects would chose to use them in favor of their own because they are better than what the have locally. Those elements should typically provide some features that would otherwise be to difficult or expensive to make locally, thus the projects would want to use them.
Example 1: The staff could provide a complete set of design symbols for featured articles, not the jammed together mix that is used now. At some projects they even claim that the current kludges are what WMF want to use, and that they are “Wikipedia”. Pretty weird.
It should be pretty easy to set up a project “Design elements: featured articles”. We probably need them to have sufficient details for badges, indicators, and pages. They should have symbolic names, and they should probably adapt to the chosen skin. Remember, if the design element is an SVG then it might be styled.
Remember to add a page indicator from the item on the local page itself. Now we only add badges in the sidebar.
Added feature: The design elements will look good over all projects and skins, and they will look consistent. (Increased conformance over projects leads to decreased boundaries between the projects, that is less “us and them”.)
Example 2: The staff could provide necessary modules for common tasks like an infobox, navbox, taxbox, succession box, etc. There are not many of them. Most of them will use structures at Wikidata, with some local adaptation.
The present use of modules tries to support existing templates, but I believe that is a wrong approach. By doing this we perpetuate present problems with the templates. Instead of redirecting calls to modules through templates we should simply call the modules as {{module:infobox}} in the articles, and only add arguments as necessary to solve problems. The module should check out the type of item (P21) and act accordingly. (Yes it is possible, but then modules must implement and use a __tostring metamethod. It is a tech-ting.)
Added feature: I guess editors will be glad to finally have infoboxes that work as expected in all articles, and the conflicts between various infoboxes would go away . (The soccer fans will probably hate it, they can't style the infobox in the colors of their favorite soccer team. Don't tell them they can still mess with the colors through template styles.)
Example 3: The staff could provide well-defined help pages, that could be localized at Meta, and the localized page transcluded into the local project. It should be possible to link to such pages as if they were local, and even if locally overridden they should always exist.
It is a pretty large undertaking to define all necessary help pages to kick off a local project. To have some help pages, even in English or some other language, would be a real boon. Also to link those pages we need a slightly more advanced help indicator. Now we only have one link that follows the page, but there are probably several given the role and state of the user.
Added feature: It would be possible to find the help pages, thus making the editing simpler. (Some oldtimers will probably get a grudge over their favorite nit-pick items being thrown out on the common pages, and will thus insist on keeping their favorite help page.)
On Sat, Dec 14, 2019 at 9:38 AM Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
Yes, and that's why I really, really, really want to hear more feedback on it from various communities of editors, including criticism. That's also why in my proposal I write that it's a requirement that communities must be able to override any central functionality, and I only speak about the generic principle of making templates global, mentioning particular templates only as examples. I leave everything else to the communities.
The parts about which I wrote that they will have to be done mostly by staff are the parts that require heavy PHP coding, code review, and testing, and as far as I know, most of the people who know the relevant areas of code well are on staff. (I might be wrong. Also, everything I'm saying here are my own assessments, and they don't represent the WMF in any way.)
However, the more volunteer developers and editors participate in it, the better—not because it saves money, but because it makes the project more "owned" by the community.
בתאריך שבת, 14 בדצמ׳ 2019, 09:12, מאת John Erling Blad jeblad@gmail.com:
I get a little scared when I read “probably, but not necessarily, mostly by staff” because all kind of central standardization creates a whole lot of arguing in the individual subprojects. If that standardization means changing a whole lot of templates I'm afraid it will create much more fighting than real solutions. I'm a little “Marvin” here…
On Fri, Dec 13, 2019 at 10:14 AM Amir E. Aharoni amir.aharoni@mail.huji.ac.il wrote:
בתאריך יום ה׳, 12 בדצמ׳ 2019 ב-23:37 מאת Pine W <
wiki.pine@gmail.com
>:
I'm thinking out loud here. Are there any estimates of would be
required in
terms of time (both staff time and community time) and money to make templates and other tools be much easier to globalize across wikis and across skins? I'm looking for an answer that is more specific than "a
lot",
but isn't a promise or a detailed estimate.
Difficult to say.
I won't make an actual time estimation, because I'm very bad at doing it, and because I have too many conflicts of interest ;)
However, I do hope to give you something more specific than "a lot". I envision the following feasible plan for "global modules and templates, phase 1":
- Make a localization framework for modules. (
https://phabricator.wikimedia.org/T238417 ; probably, but not
necessarily,
mostly by staff)
- Develop a documentation page and a framework for making robust modules
(
https://phabricator.wikimedia.org/T238532 ; probably, but not
necessarily,
mostly by staff).
- Make modules storable and loadable from a global repository, and
*actually enable it on all Wikimedia projects* ( https://phabricator.wikimedia.org/T41610 ; probably, but not
necessarily,
mostly by staff).
- Migrate most local modules from all the wikis to using global modules,
and deleting all the migrated local modules. This will have to be done by the editors communities in many wikis, and it will only be feasible if
all
the points above are planned and executed well. The challenges I expect
at
this step are: ** Making sure that just the right amount of things are global and everything that communities want to override locally can be conveniently overridden. ** Making tough choices about which modules to use when several
communities
developed modules with similar functionality. For example: English,
French,
Russian, Spanish, and Hebrew Wikipedias have modules for loading Wikidata values. They aren't the same, but they probably should be. Merging them into a global module will require a lot of good-faith collaboration.
Note that I only mentioned modules. Templates have some extra challenges. But once modules are done well, a "phase 2" of this project, that would tackle templates, will become possible. Also, global gadgets will have to be a separate project. Maybe the same localization framework can be used for both modules and gadgets, but I cannot think of anything else that
they
really have in common.
All of the above is my interpretation of discussions in the recent Tech Conf in Atlanta (other people may have a significantly different interpretation). See these Phab tasks, and the web of other tasks linked
to
them: https://phabricator.wikimedia.org/T234661 https://phabricator.wikimedia.org/T52329 _______________________________________________ Wikimedia-l mailing list, guidelines at:
https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l
New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list, guidelines at: https://meta.wikimedia.org/wiki/Mailing_lists/Guidelines and https://meta.wikimedia.org/wiki/Wikimedia-l New messages to: Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe