How it works

From Redazione
Jump to navigation Jump to search


Cultura italiana is a project aiming to create a network and to enhance cooperation among centers of Italian culture and language at abroad.

It is meant to be composed of at least 2 components: a back-end platform, represented by this Mediawiki site where authorized staff of centers of Italian culture and language can add or structure their organization information in a collaborative way and with attention for semantic data, and by a front-end platform, currently represented by this site, where the created contents can be viewed, searched and enjoyed by visitors in an attractive and modern way, including from mobile devices. (depending on what side you are reading this content, one of the links will point to itself)

The project has been initially implemented, since November 2019, within the frame of a European Solidarity Corps project (funded by European Union), is supported at the moment by the center of Italian culture and language in charge of the project which ensures its continuity over time (as well as that the requirements of the project are met) and foresees the inclusion of other institutions and organizations interested in taking part to the initiative.

Find out more...

Application form

The use of this platform is free for all Italian language and culture organizations world-wide.

Just fill-in the form below and we will contact you promptly in order to set up your account and to send you any useful information.
You will be immediately able to:

  • manage a wiki-like page of your organization plus an arbitrary number of sub-pages (like the following)
  • structure your data and information through a reach set of features allowing their visualization in a front-end like the following, where external visitors can find all the material created by organizations, divided by geographical area and kind of contents

Find out more...

Tips & guidelines

Once that you are provided with an account, and consequently with the privileges to edit your organization's page and sub-pages, just keep in mind the following principles and guidelines.

  • Thus Mediawiki and wiki text are not precisely user-friendly (for a legitimate reason, that is precisely to encourage the creation of quality contents) we have provided this platform with all the tools to make the creation and editing of contents as easy and profitable as possible, in such a way that supposedly any member of a center of Italian culture and language with an average IT literacy, will be able to create and edit all the required information, and to address himself or herself either to the IT department of their organization or to the editorial staff of this platform, only to enhance the general structure of their pages, or to fix some issue.

Find out more...

Interface elements

Besides a number of edits in the installed Mediawiki's source code to fit our specific requirements, mainly to achieve an enhanced sub-pages management, Cultura italiana includes a custom extension which adds (nowadays) a large number of functionalities over standard wikis, like automated creation of pages through (in turn enhanced) PageForms, auto-generated TOCs, page's properties (including meta-data), automatic privileges management based on the affiliation of logged-in user, a deep integration with the front-end, magic words, parser functions, [several more entries, either seductive or not], and indeed the following UI elements:

Find out more...

Pages structure

After registration, you will be assigned with a specific "domain" corresponding to a page in the form[organization name]

which can contain an arbitrary number of sub-pages within it. Here are some information of a sub-page from wikipedia:

Making a new [[link]] that begins with a / (slash) is the common way to start a subpage. The page to which this link points is considered "subordinate" to its host page, and is titled and linked as [[Parentpage/Subpage]]. It is possible to create a subpage of a subpage (or a sub-subpage). At the top of each subpage or sub-subpage, you can find a backlink (a.k.a. breadcrumb) to the higher levels of the page.

In short all the pages of your organization will be located under a dedicated address but at the same time they will reside in a shared environment, both to ensure collaborativeness among organizations, and because by this way you can enjoy, de facto, a fully maintained platform, where site's administrators (meant to be IT professionals) will advice you of any consistency of the wiki text (which entails some complexity) and will take care of extensions, templates, modules, semantic properties, and all other elements which guarantee a profitable and rich experience both from the side of visitors, and the organizations themselves.

By default, your organization's data structure will take this form:

Find out more...

Every page of your organization can be headed by your organization's banner. Just upload a banner image under your page named "Banner.jpg", so that it will appear in the following url:[organization name]/Banner.jpg

(the banner is therefore expected to be in jpeg format) and the system will automatically display it on the top of each of your pages, including on the front end site !

Find out more...

Semantic forms and structured data

Semantic or structured data allow a data consumer to accurately retrieve data based on their semantic meaning. For instance, an internal search engine might serve all your pages marked as "article" to a user searching for articles created by your organization, or articles of a given author, written in a specific time frame, courses of a given languages, delivered by a specific teacher, and so forth.

In order to reach this purpose, we have created a rich set of semantic properties and forms (a form might be considered a container of a consistent set of semantic properties) which can be simply inserted in any wiki page, can be edited as a form therein, and which will transform an "anonymous" wiki page (or html page as soon as it is served) in a database of semantic contents which can be used in the most profitable ways.

For instance, if you create a wiki page describing one of your language courses for a given academic year, that information can be displayed within the main portal of this platform (or by whatever other data consumer which will query the APIs) within a list of available language courses, and to fuel interactive functions, for instance the purchase of lessons by students, a filter of available language's courses based on level and language, to put in direct communication teachers and prospective students through a chat, and more.

Find out more...

Images upload & gallery

The Mediawiki version (1.35) powering this platform has been improved in order to support the storage of images and media files at a specific path, so that each organization can save all their images within a specific "folder" (under the main page itself of the organization, or whatever sub-page within it) and can easily retrieve them from the Visual editor's Media gallery, without mixing up their files with those of other organizations, and without file names conflicts or restrictions.

Find out more...

Page status & SEO

Since the Mediawiki site containing all the public pages of Cultura italiana is both a standalone site which can be autonomously visited, and a "content management system" (CMS) of a font-end allowing a more interactive and "streamlined" experience (as an example this is the "front-end" url of this page and this is the "back-end" url, in the sense now explained), we have integrated the "back-end" with a way to define some property for each page, and specifically its publishing state, its language, and even some meta-data to be used for SEO ("search engine optimization") purposes.

Find out more...

Table of contents

The system automatically creates a Table of contents for each organization (as well as for any other set of pages which includes a TOC template on top of it) with the tree of all its sub-pages, at a location like the following:[organization name]/Table of contents

The Table of contents (which can contain an arbitrary number of nested sub-pages) can be interactively edited through the related form (pages can be shown/hidden and rearranged) and is used as a reference to display the organization's pages (which could be also called "site") on the front-end, in the desired order, with only the desired pages, and in a way that they can be easily navigated, both through previous/next buttons below each page, and through a side navigation panel.

Currently (November 2020) the system is designed in such a way that a TOC can be put within any set of pages intended to be displayed on any front-end, and is not limited to the pages of organizations themselves. We are using such feature, for instance, to populate a directory of authors and open-source books, currently using a general TOC, but as soon as the number of authors grow, the TOC will be split simply creating a TOC on top of each author's page and then programmatically recomposed if a data-consumer wants to display all the authors and all the works of them in a single-page application: which should be discouraged both because writers tend to be prolific, once they reached a perfect command over the language of their mind, and, I would say, even before, to achieve that level – and because authors are expected to be different each other, to be such.

Find out more...

Front-end features

The front-end side of this wiki (a streamlined single-page-application allowing an instantaneous access to set of pages) is automatically created and updated as you create, edit, move or delete pages on the back-end, and it includes the following features:

  • Server side rendering
  • Navigable table of contents
  • Dynamic components
  • Offline navigation
  • Breadcrumbs and navigation between pages
  • Hyphenation
  • Filtering of contents in multiple languages
  • email widget

Find out more...

Multiple choice questions

"Multiple choice questions" are a way to implement a "reading comprehension test" to determine that the text served has been actually read, and in this sense the solution exceeds the requirements inasmuch as a read text (of a certain value) typically is not fully understood, but just, "understood to some degree", with reference to the intellectual contents of the reader in that specific time. On the other side, we simply couldn't rely on the amount of scroll as a meaningful indicator that the text was read "to some degree", and for this reason, in the absence of a scan of mind miniaturized in the user's device (which hypothetically might measure precisely the portions of text actually read, and the kind of comprehension for each of them) we opted for "Multiple choice questions" as an appreciable compromise, given that you might equally go through the text of which to provide proof of understanding, quite chaotically and instructing yourself to just recognizing the elements useful for passing the test: so that, in this case, the solution would not exceed the requirements and would appear to be perfectly adequate.

Currently (November 2020) a "Multiple choice questions" test is implemented as a parser function in the following form:


At what time the family members gather together ?
- 20
- 21
+ 17
- 19 

| What does"reumi" mean ?
- dialectal variation for "remi"
- a typo
- a piece of clothing in vogue at that time
+ designation of diseases or disorders in the rheumatic area

which, on the front-end, will produce this result.

Find out more...


Templates are a way to insert elements commonly used among your pages by reference, and they are usually invoked with one or more parameters which will be wrapped or transformed by the template in various ways. Besides all the Wikipedia's or Mediawiki's templates which can be used or imported if missing, here are some additional templates specifically created for this platform. To use them, go to "Edit source" in the top menu, and insert the wiki text as shown below.

text highlight

{{CI text highlight| text to highlight }}


text to highlight

Find out more...

Forms & quizzes

Cultura italiana offers effective tools for rapid creation of forms, either standard forms with input fields aimed at receiving data from visitors, or forms with multiple choice questions or even Cloze tests to be used as teaching tools for current students or to engage prospective ones.

All forms include automatic validation, are protected by the latest version of Google recaptcha and are automatically "mirrored" by the respective dynamic component on the front-end (or "by the respective parser functions on the back-end, depending on what side you are reading this page), respectively for an optimal user-experience, and to just create the form in a "programmatic" and at the same time simple way without the need to create the interface itself using, namely, a tool like "Google form", which is actually a more convoluted process.

Conversely, "CI forms" have been inspired by this extension at Wikiversity and they diverge from it, apart the features above, mainly because the submitted data are sent to the provided email address, rather than used to compute a score.

Find out more...

Private WIKIs

Besides the two main components composing this platform (the back-end part represented by this wiki, and the front-end for the navigation among contents within the scope of a single-page-application) a third component completing its design is represented by an arbitrary number of private WIKIs where to store all reserved information and to make them conditionally available on the front-end, for instance to students accessing their own data or the digital representation of their classes, to readers accessing some paid content, and so on: through the combination of a streamlined interface as client, a collaborative wiki for contents intended to the public domain, and an arbitrary number of private wikis managed by the respective owners or by a data controller, every requirement conceivable within the frame of IT, information technology, may be potentially met.

The overall structure of this platform therefore is expected to be composed by a public wiki at this address (1)

Find out more...

Advanced use

Magic words & parser functions


Join team

If you would like to participate to enrich the content of this platform for creating an unique eco-system of Italian culture and language, fill in this form and we will be happy to discuss the kind of contribution you might bring with you!

Find out more...

Technology we use

Here is a list of the tools we use to make this platform work. Of course each of them depends in turn by other tools (for instance Quasar Framework depends on Vue.js, and Vue.js is in turn composed by several components, like the router and vuex, a "state management pattern"), however, given a set even arbitrary of the most prominent tools we use, the reader might explore on his or her own both in extension and in depth the vast areas not covered by the following table.

Find out more...

Logically related questions (L.R.Q.)

(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 the uniqueness 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 paid 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 wiki text 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 and their languages 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 that 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 or updated?
Well, while the back-end side of this platform is built upon a traditional technology (specifically Apache/PHP/MySQL) the front-end side is built on Node.js, eventually Nginx, and a client-side Javascript framework based on Vue.js like Quasar framework. The latter side is fueled with data retrieved from Mediawiki (a forked version with some extended features, mainly an enhanced support for a non-flat namespace that is with sub-pages and sub-folders) through a Node.js script triggered every time that a page or file is created, updated, moved and deleted, and autonomously checking the mediawiki database with a specific frequency for any other indirect change (for instance when pages are imported through the mediawiki import page, or after the execution of some maintenance script). By this way, we can ensure a real time synchronization between the two sides on direct page's editing, and an accurate synchronization "within minutes" when the wiki site is updated in some indirect way. During this process the Node.js script 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 not be possible without some intermediate operation and a further elaboration of data (for instance such infrastructure allows offline navigation through consistent set of pages). In short the front-end application (which of course is built ad hoc for this purpose, and is subjected to a development process completely decoupled by that of Mediawiki, even if the inter-dependency of the two is taken into account) retrieves its data through a dedicated API from a specific Node.js back-end, and these data are continuously updated and structured following the changes performed on the Mediawiki back end.
Why Mediawiki rather than Wordpress ? (again)
Because the ultimate aim of this platform is to organize and structure significant data ensuring interoperability and a frictionless dissemination in the public domain (under specific terms, or after a specific amount of time) in such a way that Mediawiki has been chosen for its complementarity with Wikidata which aims to represent a common platform for the world's repositories of semantic data, and possibly to participate with its development. In this sense Mediawiki is an open platform and an open archive through which data recorded therein are not registered in an arbitrary or proprietary data structure, but in a universal vocabulary (or they are conceptually prone to be so) which can be understood potentially by every one: where of course we don't mean a limited set of specific enterprises holding the data ingenuously provided by users at the expense of their lives.