Jump to content

Global-Wiki

From Meta, a Wikimedia project coordination wiki
The following discussion is preserved as an archive of a closed Meta-Wiki request. Please do not modify it.

Procedurally closed: There's consensus for this proposal, but spectific implemention is tracked at phab:T66475. The discussion in this page is stale and no need to keep this open.--GZWDer (talk) 07:20, 8 February 2017 (UTC)[reply]


Global-Wiki (global.wikimedia.org) or Wikibits (wikibits.org) would be a global container of wiki pages, to be linked and/or included from other wikis.

bugzilla:4547 is a request for supporting crosswiki template inclusion. This will create a global container of templates. Although Wikidata is live, we still need to copy w:Template:Infobox, w:Template:Chembox and w:Template:Taxobox to all wikis using it, this purposed a possible solution.

A global user page would be global.wikimedia.org/wiki/User:Jimbo_Wales; on any WMF project, this page would be used as fallback if the corresponding local page doesn't exist: so, anyone could create local pages on their most-edited wiki(s) and a single global page (optionally with the Translate extension) that would be displayed on 'secondary' wikis, on which the user hasn't created a user page yet.

Also, it could host global preferences, with the possibility to override them from single wikis, and global gadgets.

Templates, Scribunto, gadgets and even user pages is also useful for non-Wikimedia wikis, such as translatewiki.net and Wikia. There're no any Modules in Scribunto extension itself, and if a website want to use Lua, d:Q7253814, d:Q7328853 and so on in one languages should be copied. and GlobalTemplates should also be worked in non-Wikimedia wikis, as well as some gadgets such as HotCat... In a word, we should make global bits and pieces that can be used outside WMF in a new site like www.wikibits.org, not global.wikimedia.org.

Scribunto modules should be globalized, too. Templates and other bits and pieces like CSS and JS are an essential part of any MW wiki, but these have either to be written from scratch or XML exported from another wiki, (usually Wikipedia) - causing various headaches. Like commons for media or mediawiki.org for extensions, there ought to be a method that works to streamline/make friendly the development and usage of templates and other bits and pieces.

It also could work via Meta-Wiki (with custom "Global:" namespaces, such as meta.wikimedia.org/wiki/Global_user:Jimbo_Wales).

Summary

[edit]
This is a proposal for a new Wikimedia sister project.
Wikibits
Status of the proposal
Statusprocedurally closed
ReasonProcedurally closed, see above
Details of the proposal
Project descriptionTo make templates and other bits and pieces easier to implement.
Is it a multilingual wiki?Just the one.
Potential number of languagesIn many languages
Proposed taglineGlobal templates and other bits and pieces
Proposed URLwikibits.org
Technical requirements
New features to requireA common repository where templates and other bits and pieces are made available.

Examples for global templates

[edit]

Instead of including a local template

{{Infobox Software
|name = MediaWiki
|logo = ...}}

a template from a global data wiki is embedded:

{{global:Infobox Software/MediaWiki}}

which works as a local template would be, but centralizes the effort of keeping the data accurate and up-to-date.

Chemistry

[edit]

Those chemical substance infobox templates share some data. They could be adjusted to have multi-lingual descriptions and a project defined CSS-styled look. Maybe some data fields could be made invisible for standard users just as in w:Wikipedia:Persondata so that encyclopedic articles are not overloaded (and to comply with w:WP:IINFO).

By outsourcing all the (mostly numerical) data this could help prevent table creep.

Biology

[edit]

In fact the same technique could make WikiSpecies actually useful for all language Wikipedia:

Software

[edit]

Have a look how English Wikipedia uses sub-templates like w:Template:LSR together with sub-pages w:Template:Latest stable software release/GIMP so that just one "database-entry" is changed not the whole table.

Bibliography

[edit]

w:de:Wikipedia:BibRecord is an effort to store commonly used literature references in templates.

[edit]

w:Help:Interlanguage links are currently stored underneath every Wikipedia article and bots spam the version history by adding them. They could also be globally stored and transcluded.

Semantics

[edit]

If a new MediaWiki instance is created why not enable mw:Extension:Semantic MediaWiki which allows searching like this "texteditor platform=windows license=open-source".

Proposed by

[edit]

Alternative names

[edit]
  • GlobalWiki
  • Wikibits
  • Wikimedia Global
  • Wikimedia Commons
[edit]

Domain names

[edit]
  • commons.wikimedia.org
  • meta.wikimedia.org
  • mediawiki.org
  • global.wikimedia.org
  • wikibits.org
  • wikicenter
[edit]

Demos

[edit]

Discussion

[edit]

About GlobalTemplates

[edit]
  • Great idea, and much needed. I'm not sure that even wikidata will solve the specific issue of template transclusion; but we need a project like this that can be widely used like commons.
  • A broken template affects many people and they need to be carefully coordinated and updated. Perhaps for a given master template, the child template could reside, cached, on the site that is implementing it... and editors could toggle an optional 'safer update' flag which would require a manual revision review on that wiki before updates to that template went live on the child site. SJ talk   08:27, 16 March 2012 (UTC)[reply]
  • I would suggest the following steps:
    Check with WikiData developers whether it fits with their project. If yes, problem solved.
    If not, give more though of whether really a separate project is needed, or the project can be coordinated, for example, from Meta. I guess this second part was insufficiently discussed here.--Ymblanter (talk) 20:41, 5 June 2012 (UTC)[reply]
  • In addition, I do not have clear understanding how different langyage versions will work. Are the templates expected to be translated to all languages, for instance, at Translatewiki? If yes, some mechanism of substitution is needed, so that a user of Tamil Wikipedia will only see a template in Tamil and not in all languages translated. If not, how a non-speaker of English will manage to repair centrally a broken template? I think all these questions need to be addressed somehow.--Ymblanter (talk) 20:40, 5 June 2012 (UTC)[reply]
  • Probably, Wikidata will retrieve information for Infoboxes, but not warnings and template messages: they also should be internationalized: good proposal:) --Ricordisamoa 07:44, 11 February 2013 (UTC)[reply]
  • Can it coordinate templates with slightly different function/parameter/setting on different wikipedia? For instance, w:Template:Internal Link Helper and w:Ill2 and w:zh:Translink C933103 (talk) 21:24, 16 January 2014 (UTC)[reply]

Problems

[edit]
  • The scope of Wikipedia:WikiProject User scripts is not large enough. We need a fully independent wiki to give them the right space.
  • Non-WMF wiki administrators are having to write and debug templates. This is an extra level in difficulty from just install MW, configure slightly and then add extensions. See mw:Help_talk:Templates
  • Small or new wikis frequently don't have templates because they don't know it's a feature or because these are difficult to implement and maintain.
  • Wikipedia specific features and the logo are included in non-WMF wikis.
  • After upgrading MW to most recent stable version, following with templates and other bits and pieces is not a trivial task to get neat and tidy.
  • Similar templates are developed on more than one project leading to branching and inconsistencies.

How to implement?

[edit]
  • What would this central repository need to work smoothly?
    • Gadgets 2.0 (shared gadgets, internationalization, gadget manager) or even Gadgets 3.0 (user level repositories, category-based browsing, search)
  • Not just templates, CSS, JavaScript and what else to include?
    • JavaScript gadgets, Scribunto modules, Lua modules, templates, CSS JavaScript, user pages ...
  • Where would this central repository be held?
  • Are these interwiki transcluded or installed like extensions and updated in sync with MW releases.
    • With interwiki transclusion there ought to also be a way to avoid name clashes.
  • How to make selectable which templates, bits & pieces to include and handle interdependencies.
  • The wiki calling a template might not want or require all the available permutations, enhancements or intricate feature richness.
  • Localization.
    • This needs to convert many modules and scripts to become multilingal, see Bug 39610 for a first step in Lua. This needs to mix i18n tables from some modules, separate i18n out of the module itself, build strings with variables, translate category names displayed in user language and pointing to wiki language to help admins ...
  • Licensing (CC-BY-SA and GFDL are not recommended for software).

Plan for scripts

[edit]

Plus Wikimedia Scripts/Policy draft

  • All MediaWiki Gadgets and User Scripts will be hosted on this separate wiki
  • They will be on the main namespace (with the .js extension)
    • A disadvantage of keeping the JS and CSS extensions in the title is the case of subpages: "main.js/sub.js" is weird, "main/sub" is not, and "main.js/sub" is not even a subpage
  • They all will be fully internationalized and designed to work on any wiki
  • They will follow coding conventions and policies
  • There will be a lot of help pages on how to write a script
  • Each script will have its help page
  • All scripts will be released under a free license appropriated for software (GNU GPL and/or any compatible license are good, CC-BY-SA and GFDL are not)
  • All categories will refer to Gadgets and User Scripts
    • For example:
      • Category:Categories management will list scripts like HotCat or Cat-a-lot
      • Category:Wikidata will list scripts that are specially related with Wikidata
  • Access and security:
    • Option 1: specific user rights ("gadgets-edit", etc), to be given to a restricted group of registered users (Thread:Talk:ResourceLoader/Version 2 Design Specification/Gadget developers)
    • Option 2:
      • Any registered user (to avoid XSS risk by IPs) will be able to contribute to them
      • Final users will get updates only when a revision of the script is accepted by a patroller/administrator
  • Gadgets 3.0 features:
    • The Main Page will be a place in which the best scripts produced by the community are publicized
    • Each script will have a title, a description, an average rating, an icon/logo, and some reviews (maybe on the talk page)
  • Anyone will be able to install a script, simply by clicking a button (like on the Chrome Web Store) without a line of code
  • Any script could be enabled on all Wikimedia sister projects, even by default, but Gadgets 2.0 allow this to be configurable per gadget
  • Anonymous data will be collected about the scripts' usage (how many users, etc.): bug 19288

Update template

[edit]

In any case, using {{gupdate}}, would update the template and documentation from the Wikimedia central template repository. --BoldLuis (talk) 17:52, 14 May 2020 (UTC)[reply]


People interested

[edit]
  1. Matthias
  2. Kozuch 19:36, 15 January 2012 (UTC)[reply]
  3. DrTrigon 19:26, 28 January 2012 (UTC)[reply]
  4. Maxtirdatov (talk) 17:43, 5 December 2012 (UTC)[reply]
  5. Allrounder (talk) 23:08, 5 January 2013 (UTC)
  6. Jayabharat (talk) 05:11, 31 January 2013 (UTC)[reply]
  7. Bennylin 14:06, 31 July 2013 (UTC)[reply]
  8. -Benjozork (talk) 01:23, 23 October 2013 (UTC)[reply]
  9. King jakob c 2 (talk)
  10. Zhuyifei1999 (talk)
  11. Arcane21 (talk)
  12. Ypnypn (talk)
  13. 72.65.238.157
  14. Why not?Seonookim (talk) 05:48, 30 August 2013 (UTC)[reply]
  15. Surfer43 21:43, 31 August 2013 (UTC)[reply]
  16. Looks alright to me :-) Lotje (talk) 06:27, 1 September 2013 (UTC)[reply]
  17. At a first sight, it make sense. There is some technical problem (in particular, it's not really starting a new wiki project, but developing a new functionality), though, and it may create new problems. - Laurentius (talk) 14:02, 2 September 2013 (UTC)[reply]
  18. I was wondering why I can't link my Userpage with Wikidata燃玉 (Ranyv talk) 13:27, 3 September 2013 (UTC)[reply]
    @燃玉: About that: please read d:WD:Notability --Ricordisamoa 13:57, 3 September 2013 (UTC)[reply]
  19. GZWDer (talk)
  20. Wolf Lambert (talk)
  21. Cekli829 (talk)
  22. Maybe global signatures too? Armbrust (talk) 11:12, 19 September 2013 (UTC)[reply]
    That would probably fall under the "Global preferences" part. PiRSquared17 (talk) 20:02, 21 September 2013 (UTC)[reply]
    @Armbrust and PiRSquared17: indeed it does. MediaWiki preferences include signature, language settings, timezone, gender, view/edit UI, and experimental features. They all are wiki-independent and would be 'globalized' flawlessly. Global gadgets would instead need some additional work on ResourceLoader V2. --Ricordisamoa 23:55, 5 January 2014 (UTC)[reply]
  23. AugurNZ — I've been trying to do something similar with my own userspace here on Meta-Wiki. — 18:44, 22 September 2013 (UTC)[reply]
  24. I'm not sure I would be able to help out with this personally, but I support it and think it is a good idea. It Is Me Here t / c 12:10, 28 September 2013 (UTC)[reply]
  25. A logical continuation of SUL. --Синкретик (talk) 10:43, 9 October 2013 (UTC)[reply]
  26. Southparkfan 18:45, 9 October 2013 (UTC)[reply]
  27. For Project, Help and userpages it would be nice. For firts two using wd and for latter just per name. Global preferences and watchlist is also a dream of a kind. The proposal could solve global.css and global.js problem - if it would be possible to store them without using a bot for running in all wikis it will be very cool. --Base (talk) 19:08, 9 October 2013 (UTC)[reply]
    Well that sounds way more interesting then the parallel userwiki proposal. A fallback is definitely a better option than complete substitution. It should be only for userspace and perhaps for ns4 and ns12 though. As to ns12 it's also possible that some of pages on Mediawiki.org should be moved to this globalwiki model - i'd love not to have 700+ pages with exactly the same info how to e.g. create a table using wikimarkup as it's now (with exception that in tiny wikis help-pages are yet to be created) - and people like do links within project so as long as it'd work as with filedescs from commons it's cool. As to Extension Translate mentioned some adjustments should be made: we dont want all these pages listed in translation stats, so they should be "forbidden" to translate from the start. And an issue more: now it's we, Translate admins, who handle translation of pages. But on such a project it seems impossible to have it this way: I don't want to babysit everybody who likes to put his every thought on his userpage. Nor it'd be too cool to give everybody TA rights - it'd cause real mess. Nor it'd be cool to have those pages not localizable as e.g. I don't want to see my pages on Ukrainian and Russian (that's langs I'm -N and -4) wikis in English. Also it'd needed to the extension to support per page set of translatable page's lang. --Base (talk) 12:27, 5 February 2015 (UTC)[reply]
  28. So like a Commons for userpages? Assuming that this isn't rendered redundant by some of the modules that the WMF is working on, this is a good idea. I'd check with jorm first though, because I think I remember a centralized user page in his 2012 Wikimania Echo&Flow presentation. Sven Manguard (talk) 18:37, 14 October 2013 (UTC)[reply]
    @Sven Manguard: this is intended for much more than userpages only! --Ricordisamoa 22:57, 10 February 2014 (UTC)[reply]
  29. Excellent idea but why do we need multiple user pages? Why not just one main user page? Green Giant (talk) 23:12, 7 January 2014 (UTC)[reply]
    @Green Giant: Well one could have one basic userpage for most projects (with a Babel-box for example), but more well developed user page(s), where the user is most active. Armbrust (talk) 08:26, 13 February 2014 (UTC)[reply]
    @Armbrust: I can understand that but wouldn't it make more sense for each user to have one userpage and one talkpage, irrespective of which wiki they are more active on? As an example, let's say I decided to poke my nose in at Catalan or Arabic wiki (where I've barely edited), it would be more useful to have those messages posted directly on a single talkpage, instead of those users posting the message locally, and then an email being sent to my inbox. Green Giant (talk) 13:39, 15 February 2014 (UTC)[reply]
  30. Would there be a way to set up a different default for each of several languages? I don't think I would care if it used selective transclusion or some other method. PC-XT (talk) 10:46, 24 February 2014 (UTC)[reply]
  31. I would love this, especially the GlobalTemplates suggestion and the idea that the User pages would be centralized into one location. It could create a number of problems, but would be worth it in the end. --Nicereddy (talk) 03:30, 6 April 2014 (UTC)[reply]
  32. Ranjith Raj Vasam (talk)
  33. I'm also supporting UserWiki, but if I've to choose one so I'm choosing a Global-Wiki (this proposal). -- Wagino 20100516 (talk) 05:28, 30 April 2014 (UTC)[reply]
  34. I saw this linked from the discussion about UserWiki, and reading through both of them, I definitely think a fallback is better than a single one for everything. Global preferences, talkpage, etc with the option to have local ones have their own would definitely improve editing for me. Supernerd11 (talk) 17:51, 6 May 2014 (UTC)[reply]
  35. --Janezdrilc (talk) 14:00, 8 August 2014 (UTC)[reply]
  36. why not? it is cool but the logo is not adequate, you must re-examine the logo so that its resembles more more with a wiki.Startupevo1 (talk)
  37. FrankyLeRoutier (talk) 12:18, 19 February 2015 (UTC)[reply]
  38. BoldLuis (talk) 08:51, 1 August 2022 (UTC)[reply]

The above request page is preserved as an archive. Please do not modify it. Comments about this page should be made in Meta:Babel or Meta:Requests for help from a sysop or bureaucrat.