Problem in finding translations in third party plugins

[Dominique-Alain JAN]

Branch 1.4
Branch main

From Mahara 1.2 the mechanism to get display other language than English has changed. Previously localized strings where placed in different parts of the core code, together with the /lang/en.utf8 folders.

For now, the lang menu is showed only if one or mere xx.utf8 folders are found in the maharadata/langpack folder. And after a discussion about this with François I agree this is fine.

Normally, when a non-English language is selected by the admin or the user, it seems to me, that Mahara first looks into the core lang folders for the appropriate xx.utf8 folders and if not found, goes into the langpack afterwards.

With some plugins this works fine (e.g., CPDS) and for example French strings are displayed from the fr.utf8 folders embeded in the plugin folder. With some others (embdly, externsource, ldap, ...) this doesn't work. To get the French translation, the admin has to move the fr.utf8 from the core plugins folders and place them into the langpack folders in the maharadata.

I don't understand that the behaviour is different from one plugin to another.

Moreover, I would propose that the multilingual mechanist become the following:

1) I can cope with the obligation to create a xx.utf8 folder in the maharadata/langpack folder to avoid having a list of undesired languages in the language menu. This gives system admin a way to control languages displayed on the platform.

For each string to be displayed:

2) Mahara gets the user/system selected language (xx)
3) Mahara first looks into the langpack/xx.utf8 folder. If the folder is found, Mahara uses all the strings of these files to display information
4) If the string is not found, Mahara looks into the core lang/xx.utf8 folders to find it, if found, it displays the information
5) If the string is not found, Mahara looks into the langpacks/en.utf8 folder
6) If the string is not found, Mahara looks into the core lang/en.utf8 folder
7) If the string is not found, Mahara displays an error with the name of the string? (But this should never happen).

That way:

A) developers can offer localised versions of their plugin without giving more work to the system admin for moving files from the plugin to the maharadata/langpack

B) Wether admins want override a translation or the en.utf8 strings, they can by adding xx.utf8 or en.utf8 folders into the langpack folder.

Maybe a discussion could start here about this (bug report and feature request)
-dajan

[Dominique-Alain JAN (dajan)]

Linked with the bug #1417120

https://bugs.launchpad.net/mahara/+bug/1417120

[Aaron Wells (u-aaronw)]

Hi Dajan,

I think Bug 1417120 actually satisfies the requirements for this bug, right? It makes it so that language strings for a plugin are checked for in the following locations, in order of precedence:

1. /local string in selected language
2. theme or plugin directory, in selected language
3. langpack, in selected language

4. /local string in parent language (if any)
5. theme/plugin directory, in parent language
6. langpack, in parent language

7. /local string in English
8. theme or plugin directory, in English

So under this system, a plugin developer can include multilingual support directly in their plugin's distribution ZIP file. And/or a langpack developer could potentially include support for third-party plugins directly in their langpack (although I think in practice, the use of Launchpad for our translation system makes this impossible.)

[Dominique-Alain JAN (dajan)]

Hello Aaron,

I think so, it is because when I found this old bug report and wanted to inform you that both were linked.

Thanks to had the time to look at this old odd Mahara behaviour.