How it works/Logically related questions

ExpandWhy Mediawiki rather than Wordpress ?
Discussion text to be put into box.

ExpandWhy Mediawiki rather than Wordpress ?
Discussion text to be put into box.

Expand

Why Mediawiki rather than Wordpress ?

Well, first Mediawiki is actually being used by the team behind Wordpress (Automattic) for their developer documentation as proof of powerfulness of its features.

Then, because the business model of Mediawiki and Wordpress are completely different. Wordpress allows an easy use but as soon as you want to expand or complete your website you are pushed (or constrained) to adopt paying solutions. Mediawiki (as well as our platform) is completely free, including any desirable advanced feature, at cost to deal yourself with the code (starting from wikicode itself, and proceeding with the creation of dedicated extensions).

Then, because the intrinsic anti-immediacy of Mediawiki constrains the creation of quality of contents: dealing with the wiki text (either created through the help of visual editor, or directly) on the one hand slows down the content creation, and on the other provides you with a set of formatting and structuring tools specifically aimed at quality and complexity.

Then because Mediawiki offers a strong versioning controlling and allows a collaborativeness that Wordpress is not able to offer: many people can work on the same content in the same time, and notwithstanding the integrity of the content is preserved, and you can access all the changes made by each of editors at any time.

Finally because through the general design of our platform (where Mediawiki is used as back-end site) the presentation of the content (i.e. the appearance of the website) can be completely decoupled by the content itself: a part of your team can solely take care of contents, and their organization or pages structure, and another part of the team can design whatever data consumer application querying the APIs, and to use the data and the semantic data returned by them, in any conceivable way, apart from creating client-side applications, of course for data visualization as well.

Expand

Why a platform representing the Italian culture is conceived in English ?

Well, surely because English is the lingua franca of our times.

Then because the native language of world of technology, to which this platform refers to, is English.

Then because this would be also a demonstration of the ability of a kind of "Italian culture" to speak a technological language without diverting from its authentic nature, which is intrinsically humanistic.

Then of course because the audience for this platform is meant to be international, that is being able to speak only partially Italian language: but where "prospective students" would find that an international and common language (English and computer language) originates, in this specific case, from a web of ideas of which the natural language or mother tongue is Italian language itself, will devote himself to the study of it with the feeling to keep up with the times and possibly to participate to the development of them from a privileged side. this text has been added in a subsequent edit and might be not consistent to the the natural flow of the initial statement

Expand

How the front-end counterpart of this site is created ?

Well, while the back-end side of this platform is built upon a Apache/PHP/MySQL technology, the front-end side is built on Node.js, eventually Nginx, and a client side Javascript framework like Vue.js.

The latter side is fueled with data retrieved from Mediawiki (a forked version with some extended features, mainly an enhanced support for pages and files with a path involving subpages/subfolders) through a Node.js script querying the Mediawiki database every few minutes for changes and on the same time invoked by Mediawiki itself following any direct page's edit: by this way, we can ensure real time synchronization between the two sides on direct page's editing, and a sync "within minutes" where the wiki site is updated in some indirect way, for instance through import of pages or edits performed by maintenance scripts or extensions.

The Node.js script (together with a custom extension which forwards any relevant action to that script) is the core of the bridge between the two sides, since during that process it performs some convoluted operation structuring data in such a way that they can be retrieved or even "consumed" by a front-end interface in a way that would be not possible without some intermediate operation and a further elaboration of data. (for instance such infrastructure allows offline navigation).

The front-end itself, however, while dynamically takes data from the Node.js back-end (as a middleware to the Mediawiki database, not directly queried), and is fundamentally decoupled by it, is created ad hoc and is just one of the possible data consumer application of the data organized by the Node.js script and exposed through a dedicated API.