cultura italiana

How it works

Introduction[edit | edit source]

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 the 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 is being implemented 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[edit | edit source]

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 able to manage a wiki-like page of your organization plus an arbitrary number of sub-pages, to contribute to the creation of contents of general interest (for instance Opportunities, Reading suggestions, Digital libraries) and to structure your own data 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 in their wiki, divided by geographical area.


Find out more...


Tips & guidelines[edit | edit source]

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

  • 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...


Pages structure[edit | edit source]

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

https://culturaitaliana.org/wiki/[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 take care of the consistency of the wiki text (which entails some complexity) as well as 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.


Find out more...


[edit | edit source]

Every page of your organization can be headed by your organization's banner. Just upload a banner at an address like the following

https://culturaitaliana.org/wiki/[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!


Find out more...


Forms & semantic data[edit | edit source]

Semantic 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 a number of lessons by a student, a chat between a prospective student and school's manager, and more.


Find out more...


Images upload & gallery[edit | edit source]

The Mediawiki version (1.34) powering this platform has been enhanced 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...


Table of contents[edit | edit source]

The system automatically creates a Table of contents for each organization (as well for to other sets of pages containing a template TOC) containing the tree of all its sub-pages, at a location like the following:

https://culturaitaliana.org/wiki/[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 reference to create the organization's page on the front-end, in such a way that it includes only the pages selected in the TOC and in the desired order, together with a specular navigation panel.

Currently (November 2020) the system is designed in such a way that a TOC can be put within any set of pages a data consumer wants to display on any front-end, and is not limited to the pages of the organizations themselves. We plan to use such feature, for instance, to create a directory of authors and books, either with a general TOC, or (preferably, as the number of authors and works grows) with a TOC for each author (a general TOC, however, might coexist with others specific, provided that the queries are handled correctly through the APIs, while an optimal solution for a data consumer who wants to display a page with all the authors and their books, at the same time keeping the individual TOCs of a manageable size on the back-end, would be just to retrieve all the required specific TOCs, and then to combine them together either in "realt-time" or with some pre-processing operation).


Find out more...


Front-end features[edit | edit source]

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


Find out more...


Templates[edit | edit source]

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 }}

produces:

text to highlight



Find out more...


"Magic words" and parser functions[edit | edit source]

Magic words and Parser functions are a way to empower the wiki text (the specific language through which pages of all wikis are written, thus one can also use Visual editor where available) with some programmatic feature, for instance the ability to add the current date to a page (which will update during subsequent access) or to trigger whatever other function available in the wiki on the server side. They are both completely comparable to templates, with the difference that the second ones are always called with a parameter, and that the logics behind them is not placed within a template or module (so that it can be accessed on the wiki) but is coded server side.

Here is a list of the additional magic words provided by our platform (as usual they are prefixed with the string "CI_" to distinguish them easily from other Mediawiki magic words and parser functions)

name what it does
CI_userAffiliatedTo shows the organization to which the logged in user is affiliated
CI_userRealName shows the real name of logged in user (by contrast to the username)
CI_isSysop returns 1 if the logged in user is an admin ("sysop")
CI_loggedIn returns 1 if the page's visitor is logged in
CI_visitorIsoCode returns the iso code of country of the visitor
CI_visitorCountry returns the country name of the visitor


Find out more...


Multiple choice questions[edit | edit source]

"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 a "Multiple choice questions" test is implemented as a parser function in the following form:



{{#CI_multiple_choice_questions:

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...


Private WIKIs[edit | edit source]

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)

https://culturaitaliana.org/wiki


Find out more...


APIs[edit | edit source]

While you are establishing your organization's page structure at an address like the following

https://culturaitaliana.org/wiki/Centro_italiano_Barcellona

that is structuring all your information optionally using semantic data through this wiki platform, you can start querying your pages (or even all your site) through the following set of APIs, for instance in order to display them in your wordpress site, or in whatever third party site written in any computer language.

The following endpoints do not directly query the standard mediawiki APIs, but an extended APIs built on top of the mediawiki APIs (called autonomously by an internal script running in the background which keeps updated all the information) providing additional data, like the detected language for each page, all the semantic data related to each page, the "title structure" (to allow the use of slashes within the title itself, ensuring at the same time the coherence of the hierarchical structure) and more.

Basically, through the following APIs you can query all the information of the created pages or a specific "folder" within it (also retrieving a structured table of contents which can be easily used to create navigation panels, and of course, html content of pages) without dealing with the complexity and lack of immediacy of the standard Mediawiki api, which would require multiple calls and further elaboration to reach that result.

Find out more...


Join team[edit | edit source]

If you want to participate with the maintenance, management and/or development of this platform just fill in the form below and we will contact you promptly.


Find out more...



Technology we use[edit | edit source]

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.)[edit | edit source]

(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 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.