How to improve multilingual capability of Moodle?

How to improve multilingual capability of Moodle?

by Vanyo Georgiev -
Number of replies: 11

I will try to summarize the current state of this problem and I will be glad if somebody will discuss it in this forum.

There are many moodle sites which have to provide language dependent content. I mean content which must be shown in the user's language and change if the user language is changed.

1. The only way to provide such kind of content now is the multilanguage filter. But there are some problems with this filter. Much effort is done to improve it, but the improvement is not integrated yet https://tracker.moodle.org/browse/MDL-32257 The reason this improvement was not integrated is lack of testing and unresolved dependencies of this filter from other functions in moodle code. (PARAM_TEXT cleaning in lib/moodlelib.php)

 There are ideas to change the multilanguage filter syntax to non-html markup such as:

{multilang en}English{multilang}{multilang de}Deutsch{multilang}

(Petr Škoda in a comment on MDL-32257)

or syntax based on closed <span> tags as:

<span class="multilangwrapper-start" />
    <span class="multilangblock-start multilang-en" />
        <h1>Note that you can have anything here now</h1><p>and it is valid</p>
    <span class="multilangblock-end multilang-en" />
    <span class="multilangblock-start multilang-cs" />
        <h3>Even completely different HTML structure for different languages</h3>
    <span class="multilangblock-end multilang-cs" />
<span class="multilangwrapper-end" />

(https://moodle.org/mod/forum/discuss.php?d=179540&parent=855283 )

Unfortunately there is no discussion on these ideas and no development is made to implement them.

2. There are other ideas to provide language dipendent content.

Two ideas are suggested here: https://moodle.org/mod/forum/discuss.php?d=175008

I think it would be good to add a new language setting for all contexts in Moodle (category, course, resource and activity) with value: 'All languages' or one of the installed languages. If the value of this setting is 'All languages' the Moodle context will be always shown, but if a language is chosen this context is shown only if the user's current language is the same as the language setting of this context. May be users with editing capability must have access to these contexts all the time despite of their current language.

I read another idea in a forum here (but I can't find it now to cite) to add a similar language setting to all textual parameters in Moodle.

 

Thank you for reading this post!
What do you think about?
Which of these ideas to improve multilingual capability of Moodle is best and is worth to implement?

 

Average of ratings: -
In reply to Vanyo Georgiev

Re: How to improve multilingual capability of Moodle?

by Anne Krijger -

First off; I haven't used this in Moodle context.

I have however worked on multilingual systems and they are a royal pain, specially if they need to be fine-grained.

I would not opt for a solution where markup or span/div tags in the same text differentiate between the various languages.

I would guess I would put the choice at the course level, because I don't see how you would have a course where large parts were multilingual (AKA understandable in all supported languages).

Even in math courses the questions and explanations would be in a specific language, just the formulas could be the same.

What is the use case where at a lower level than course level one would need multi0ligual support?

Anne.

Average of ratings: Useful (2)
In reply to Vanyo Georgiev

Re: How to improve multilingual capability of Moodle?

by Michael Milette -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Vanyo,

I share your frustration with the current multilang filter. It is simply not user friendly as it requires HTML editing. It is also not WYSIWYG editor (like TinyMCE) friendly because it is a pain to have to apply spans on small chunks of information.

Petr Skoda's suggestion of also enabling multilang divs is definitely a step in a better direction, especially if you can have the filter parse matching DIV tags correctly so that you can have whole blocks of code including other divs within it. If you include an add-on for TinyMCE that makes this easily accessible in the toolbar and it could really work.

Of course the solution would also need to include an easy way to remove multilang language tags. As a developer, this solution is highly desirable.

For end users such as teachers who might not be comfortable working in HTML code, your suggestion to change the multilanguage filter syntax to non-html markup makes a lot of sense as demonstrated in your example:

{multilang en}English{multilang}{multilang de}Deutsch{multilang}

I might even suggest something easier to remember, less intrusive and might make reading the text easier:

{lang:en}English{lang}{lang:de}Deutsh{lang}

That being said, I see a couple of potential issues with your solution:

1) If someone opened a {lang:xx} tag in one type of HTML tag and closing {lang} it it in another. For example:

<p>{lang:en}English</p>

<div>{lang} and more text.</div>

Then again, at least the WYSIWYG editors that have HTML validation enabled would not arbitrarily eliminate invalid HTML code as it currently does with the SPAN tag which would allow you to fix the issue.

2) You could end up with empty paragraph tags which would end up rendering as invalid HTML code. For example:

{lang:en}<div class="float-right">some text</div><other HTML code></other HTML code>{lang}

When saved in TinyMCE, this becomes:

<p>{lang:en}</p>

<div class="float-right">some text</div><other HTML code></other HTML code>

<p>{lang}</p>

Rendered by the filter, you would end up with:

<p><div class="float-right">some text</div><other HTML code></other HTML code></p>

... which is unlikely to result in valid HTML code.

As an inline solution, I really like your suggestion. However it could easily become problematic as a block solution.

I think it is important to keep in mind that end users don't necessarily have the HTML skills so the solution should be easy to use yet as robust as possible.

Perhaps we need one inline solution and another block solution.

Best regards,

Michael Milette

In reply to Michael Milette

Re: How to improve multilingual capability of Moodle?

by Michael Milette -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

I just had another idea for a block level solution:

<p>{lang:en}</p>

and

<p>{lang}</p>

When filtering out, the filter would remove everything in between including the <p>{lang:en}</p> and<p>{lang}</p> tags (paragraph tags included), leaving behind perfectly valid HTML code.

From the end end user's point of view, all they would need to be told is to put {lang:en} and {lang} on blank lines to mark the language for specific sections of their page.

The best parts are, no WYSIWYG editor add-on would be required and you could use the same tag syntax for an inline solution - just filter out the block level tags first.

Let me know if you have any questions, comments or suggestions.

Best regards,

Michael

In reply to Michael Milette

Re: How to improve multilingual capability of Moodle?

by Robert Brenstein -
I suggested a more radical change of approach not that long ago, although it was deemed not acceptable. See MDL-39767
In reply to Robert Brenstein

Re: How to improve multilingual capability of Moodle?

by Vanyo Georgiev -

Thank you Robert.

When I wrote:

"I read another idea in a forum here (but I can't find it now to cite) to add a similar language setting to all textual parameters in Moodle."

i meant your suggestion, but I couldn't remember that it was in the tracker, but not in a forum.

 

In reply to Robert Brenstein

Re: How to improve multilingual capability of Moodle?

by Michael Milette -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Robert,

I read your proposal. I agree that what you proposed is definitely radical but I also believe it would be complex and could severely limit multilingual support in existing plugins. It also sounds like it would help keeping languages separate in the search engine results.

That being said, I also agree that there are be simpler and more compatible solutions to be found.

I really appreciate you sharing the link to your suggestion and will keep it in mind when coming up with a new solution.

Best regards,

Michael

In reply to Michael Milette

Re: How to improve multilingual capability of Moodle?

by Vanyo Georgiev -

Hi Michael,

Just for precision. The syntax
{multilang en}English{multilang}{multilang de}Deutsch{multilang}
is not my idea, it is suggested by Petr Škoda.

I saw these issues with non html syntax too, and I tried to put a comment in MDL-32257, but I couldn't manage to format correctly my comment and may be it is unclear.

These issues make implementation of such syntax to be a not easy task and that is why I would prefer to make moodle to support multilingual content based on some other idea but not only on the multilang filter.

In reply to Vanyo Georgiev

Re: How to improve multilingual capability of Moodle?

by Michael Milette -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Hi Vanyo,

Thanks for the clarification

I've read the MDL-32257 thread as well as everything that it links to. It's not easy to get consensus because I don't think there is one solution that will meet everyone's needs, especially if they continue with a parsing routine that just matches closing tags instead of matching nested closing tags.

There is definitely a clear need for language filter support at both an inline level and at a block level.

If both SPAN and DIV support were included, and the parser handled nested tags, the HTML tag solution could works well for developers and technically savvy (i.e. HTML) users.

However the HTML solution doesn't provide the ease of use required by teachers and other content creators when editing using TinyMCE, CKEditor or similar WYSIWYG editor.

Adding a language icon in TinyMCE would help but would not be a complete solution for them because there still wouldn't be any visual indicators to help them when editing. These folks need something simple while ensuring that we don't complicate things for others running unilingual sites.

PROPOSED SOLUTION (concept)

Feel free to offer suggestions if any of the following doesn't make sense to you or you don't think it is possible.

First, I think a new solution should require a new plugin filter. The multilang filter is an inline HTML filter which should not be modified, but might be enhanced for block support as I am sure there are many sites currently using it.

Therefore a new add-on mlang filter (Moodle or Multi Lang - name changed to reduce potential confusion with multilang filter) should be created. This filter would rely on text based tags instead of HTML. It would be in a style similar to that proposed by Petr and Vanyo.

BASIC SYNTAX

{mlang en} - Sets the language to the specified language. This would be the opening tag. All text appearing after this tag would be filtered out if current_language() does not match the language specified in the text tag.

{mlang} - Sets the language to all languages. No filtering applies after this tag.

BLOCK LEVEL EXAMPLE

Start language filtering:

<p>{mlang en}</p>

or

<div>{mlang en}</p>

End language filtering:

<p>{mlang}</p>

or

<div>{mlang}</div>

Support for the DIV syntax is needed because cut and pasted content in TinyMCE sometimes ends up in DIV's instead of paragraph tags behind the scenes.

INLINE EXAMPLE

Starting and Ending Language filtering

{mlang en}English{mlang}

QUESTIONS...

1. Which of the following two approaches to syntax do you think would be cleared and easier to work with for a non-HTML savvy content creators:

{mlang en}English{mlang fr}Français{mlang} Language

or

{mlang en}English{mlang}{mlang fr}Français{mlang} Language

2. Vanyo, is the code you created in your attempt to make the {multilang en} syntax work available somewhere online?

Best regards,

     Michael

In reply to Michael Milette

Re: How to improve multilingual capability of Moodle?

by Vanyo Georgiev -

Hi Michael,

I haven't published any code, but I can send here my attempt to implement a syntax with {mlang xx}...{mlang} elements. See the attached file.

I don't like this implementation because the user must be very careful to prevent html editor to insert some unwanted tags that will make the resulting html code not valid or will make the filter not to work.

If the user knows html and can inspect the code it is OK, but if he or she can't do that it will be easy to make the filter not to work.

 

In reply to Michael Milette

Re: How to improve multilingual capability of Moodle?

by Michael Milette -
Picture of Core developers Picture of Documentation writers Picture of Particularly helpful Moodlers Picture of Plugin developers Picture of Testers Picture of Translators

Correction:

<div>{mlang en}</p>

... should have been...

<div>{mlang en}</div>

... in the above text.

In reply to Michael Milette

Re: How to improve multilingual capability of Moodle?

by Rosario Carcò -

I started using the multilanguage tags as soon as they were available in Moodle 1.x

Without thinking too deeply, why not implement them as class, e.g.

<div class="lang_en">english text</div>

<div class="lang_de">deutscher Text</div>

<p class="lang_fr">texte en français</p>

Or alternatively with an ID, eg.

<div id="lang_it">testo in italiano</div>

This way the language selection could also be combined with any css directions/formats. I think this would not break any html-browser nor html-editor as it is standard (x)html? And  Moodle would be free to do anything with it.

Rosario