Multilinguality of Mahara artefacts

[Gregor Anželj]

Mahara supports different language packs for the web interface of the individual user account, but it isn’t possible to have portfolio pages in two languages at the same time (for example a presentation portfolio with a CV in German and one in English). To achieve this it would be necessary for artefacts to contain values in different languages.

The main problem are not labels (which can be in different languages), but artefact values, which can not be in more than one language at a time.

In the terms of multilinguality it would be also good if the user would have the option of selecting in which language the page should be displayed.

[Robert Lyon (robertl-9)]

There is a booklet patch
https://reviews.mahara.org/#/c/3107/

That deals with allowing a cv to be displayed in multiple languages on a page

This could be a good place to start with this request

[Aaron Wells (u-aaronw)]

The booklet plugin deals more with labels. What Gregor's getting at, I think, is user-entered contents. It sounds like what he's asking for, is the ability for a user to enter multilingual content. For instance, if I was setting up my resume, and I wanted under educational experience to put both the English and Spanish name for my university. And then when the page is viewed by someone whose languages setting is English they would see "University of Nevada, Reno", and when the page is viewed by someone whose language setting is Spanish they would see "Universidad de Nevada a Reno".

It's hard to think of a good interface for this, though. There are two options I'm aware of, neither of which is great:

1. Moodle 1.9, I recall, let users enter content using a special Moodle-only tag that specified what language it was in and then used a post-processing text filter to swap out the proper language. Like, I would type in my university as "<filter lang="en">University of Nevada, Reno</filter><filter lang="es">Universidad de Nevada a Reno</filter>". But that's rather unwieldy, and it requires educating users about the existence of these tags.

2. Another option is to have a drop-down for language selection next to each text field where a user can enter artefact text. But that seems like it would be overkill, for a feature that would probably be rarely used.

It might be worth seeing if anyone else has solved this UI riddle, though. Are there other web applications that allow users to enter multilingual content? What do they do?

Unless we can come up with an intuitive and non-intrusive UI for this, I'm leaning more towards the booklet approach, of requiring users to create separate artefacts and separate pages, if they want to have content in separate languages.

[Aaron Wells (u-aaronw)]

Identified as a usability priority by the Slovenian Mahara user group: https://mahara.org/interaction/forum/topic.php?id=6283&offset=0&limit=10

[Simon Coggins (simon-coggins)]

I was thinking about the same problem in Moodle/Totara and came up with another approach that could be considered a hybrid between the two.

I have two ideas for how it could work:

1. Define first, use later

* Each user would have an area where they could define multilingual strings. Each string would require a unique key, then a set of language/text pairs, one for each language they choose to provide. One language would be marked as the default. For example a user might create a key 'aboutme' with translations in English and French.
* To use a multilingual string the user enters it into a text field anywhere on the site surrounded by a special delimiter. E.g. for example the delimiter might be %%% in which case a user would enter '%%%aboutme%%%' into a text box.
* A site-wide filter could detect the short delimiter wrapped keys and convert them into the viewing user's language if available, otherwise use the default.

2. Use first, define later

* The system defines a special delimiter to indicate something will be multilingual. Let's say '%%%' again.
* When users enter content in any text field they provide text in their language, but surround each phrase to be translated with those tags. For example:

Page title: %%%This is a page title in English because my language is set to English%%%

* This is the tricky bit - something, perhaps in dml.lib needs to scan for and detect new delimited strings. When found the contents between the delimiters is hashed and new entries are made in two tables:

translation_keys
id hash usrid

translation_strings
id translation_key_id lang value

In the second table lang would be the user who inserted the string and value would be the contents between the delimiters.

* With those records in place it would be possible to display an area to the user containing template strings in their language that they have used and allow them to translate into other languages (which creates more records in translation_strings
* Finally a filter would detect any delimited strings, hash the contents, and do a lookup in the viewing user's language if available (falling back to the original string).

I think the second approach would be cleaner from a user point of view but potentially harder to implement.

There are several parts of this idea that need further consideration (performance for one) but thought I'd put it out there for discussion.

Simon

[Kristina Hoeppner (kris-hoeppner)]

I'd prefer a solution that doesn't involve special characters / delimiters as they are always awkward for regular users.

In the LMS I used several years ago which we then repurposes as CMS for a conference, the developers implemented a language switcher. When we clicked on a flag, the text box would switch to the other language. In this case, we had only two languages, which doesn't work if you want to allow for more.

The languages that the user users can be different from the interface languages, thus the user should be able to define the language themselves, e.g. via drop-down list. then they could enter text in the different language. A question is how many different languages should be provided for. Ideally, they would be able to provide different text for every text input, which is A LOT. And sometimes they might also want to upload a different file.

Thus, for some items it may not be worthwhile to provide a translation interface because they could just upload a different file or create a different text box. On the other hand, if you want to have the convenience of creating a page and then switching into a different language and have all the content already there that you then overwrite with the other language, then we'd need to be able to translate all artefacts.

[Kristina Hoeppner (kris-hoeppner)]

Of similar interest:
- bug #800127 Multi-lingual site pages
- bug #806615 Unable to specify the language of a Page/View