How it works/Logically related questions

(another way of indicating "frequently asked questions" which have not yet been asked)

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 contents (i.e. the appearance of the website) can be completely decoupled by contents themselves: 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 it, in any conceivable way, apart from creating client-side applications, of course for data visualization as well.

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 being intrinsically humanistic, should not interpose hiatuses or ditches between disciplines but to pursue a universal vocation.

Then of course because the audience for this platform is meant to be international, that is able to speak only partially Italian language, in such a way that where they will experience that a distinguished (not trivial, nor anonymous) English language originates from a specific wit of the Italian culture itself, they will be inclined to study and to learn Italian not only because it stands at a specific position in the rank of world's most studied languages (for whatever reason) but for its inclusive and possibly universal character, therefore providing the feeling of being at the center of cultural changes of our times.

Then because the aim of each language is poetry, in such a way that expressing oneself in a foreign language (rather than in the mother tongue) refrains precisely from doing, or is ultimately expected, poetry, and allows to write in a rather plain way focusing on contents (that is on a stiffened form of expression) limiting one's own activity within conventional limits, ultimately productive in the daily life.

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.