Moodle

Hi Anthony,

why did you open this new MDL-17763 with the priority "minor"? If you own language is english then it should be no problem that the language falls back to english. But if your language by example is german de_du_utf8 and you only get english strings from en_utf8 then you will have a problem.

One problem could be that every user can change his own language in profile. If an admin and all teachers would use the language parent package de_utf8 then nobody of them will see the problem why their participants get the module in english language.

I think that the priority should higher than "minor"

Best regards, Ralf

Ralf - By definition a minor issue entails "Minor loss of function, or other problem where easy workaround is present." This problem only presents itself in a very specific situation which most of the time is not an issue. First it requires a parent language, then it requires using code (like the mrbs block) that does not have the child language defined. If there were a de_du_utf8 language pack with the langconfig.php file then this is not an issue and it will find and use the strings in the de_utf8 language pack. I believe that this is a low impact issue that will effect but only a few users and thus in terms of priority is something for the developers to get to when they get a chance. As I mentioned, the easy workaround for this is to create a de_du_utf8 language pack for the mrbs block. Even if it just has the parentlanguage string it will fix all of the other issues. Peace - Anthony

Attached is a patch that I believe would work. It creates the get_parent_language function. I opted to not use $lang since it seemed unnecessary and better to just have the function get the current language itself. It receives locations; however, we could set it NULL by default and then have it setup the default locations as it does in get_string if the value is NULL which may potentially (I have no specific examples in mind) make it more useful in other places.

In terms of logic, what changes is that rather than checking for each location's specific parentlanguage parameter from that locations langconfig.php file, it gets one parent language and then will check all of the locations for the existence of the file in the location's parent language.

So for the MRBS block example, it sees that the site has a parent language defined in /lang/de_du_utf8/langconfig.php as de_utf8. Now when it checks the location /blocks/mrbs/lang it will assume that since the string was not already found that it should check the parent language and thus check /blocks/mrbs/lang/de_utf8/block_mrbs.php for the string where previously it was being skipped because /blocks/mrbs/lang/de_du_utf8/langconfig.php did not exist.

Tantum quantum (use the patch in so far as it is helpful; otherwise, ignore it). In other words:

if ($patch=='helpful') { use($patch); } else { ignore($patch) }

I did another test not with MRBS but with Feedback.

Take the Module Feedback in Moodle 1.9. It's an additional modul that comes with its own language internal package de_utf8. I wanted to know in which order the language files are read. Feedback is a nice module to test this because there are 18 strings which are translated in die official german language package but not in the module Feedback.

My user language is de_du_utf8. I thought that the order should be the following....

• 1. look into de_du_utf8_local (not present),
• 2. look into de_du_utf8 (not present),
• 3. look into moodle/mod/feedback/lang/de_du_utf8 (not present).

After these lookups with only negative results the module Feedback should try the parent language pack de_utf8 and this meens

• 4. look into de_utf8_local (not present)
• 5. look into de_utf8 (present)
• 6. look into moodle/mod/feedback/lang/de_utf8 (not pesent)

After this fall back to the english version en_utf8

• 7. look into en_utf8_local (not present)
• 8. look into en_utf8 (present)
• 9. look into moodle/mod/feedback/lang/en_utf8 (present)

Because the 5th step in lookup gets a positive result this string should be shown on the page but it does not. It gets its result from my 9th step.

This meens that it is impossible to get a new file feedback.php into the official language package de_utf8 to help all people who use the Feedback module. There are 18 missing strings in the german language pack of the module ... and if the maintainer will use the correct file next time he updates then a lot of admins have to reinstall the Feedback module to get these 18 missing strings The other way would be to copy the language file into de_utf8_local but this choice gets problems if the official language file changes next time.

I could write the same for the book mudule ... the official language pack contains the file book.php and it's complete ... but there are 9 missing strings in a lot of Moodle installations because the strings are missing in the german language pack of the module Book

Regards, Ralf

Ralf - Feedback is probably not the best one to use to test; however, it would probably be helpful to refer to a specific example. Keep in mind that there is a block_feedback.php file and a feedback.php file in the /lang/de_utf8 language packs. So those do use the same location as third party blocks which would be in something like /block/blockname/lang/de_utf8. You really need to look at the code to see what is happening. The patch I provided will fix the earlier issue you mentioned about it going to the English language pack for third party blocks.

I am not sure what you mean when you say it is impossible to get a new file feedback.php into the official language package de_utf8. The file is already there and if there are missing strings then those can be added by whomever is responsible for handling that language pack. You can always send Koen Roggemans a Moodle message or create an issue in the tracker. If I understand what you are saying, it would probably be best to create an issue in the tracker and identify the 18 strings that need to be added to /lang/de_utf8/feedback.php. You could even suggest translations for them.

When you talk about the maintainer, I am not sure which one you are referring to. The maintainer of the language pack or the feedback module? I am not sure why someone would need to upgrade the feedback module to get the new strings. If they update their language packs they should have the new strings. I would not recommend copying things to local (let Moodle handle the making and management of local copies).

You are correct the /lang/de_utf8/book.php is part of the official language pack. I'm not sure why but it is there. You can do another tracker request to get the 9 missing strings added to it. Missing strings in files is not really what this issue in the tracker is about. With this issue I'm trying to make sure that get_string functions as expected for third party modules. Let me know if you think I have overlooked something.

Peace - Anthony

Hi Anthony,

the feedback.php is totally complete for this moment. I'm one person of the german translation team. feedback.php is part of the official language pack and the german feedback.php is dated from the 27th Dec, 2008.

Inside the modul feedback for Moodle 1.9 you will find an incomplete version that is dated from 12th Sept, 2007 .... very old!! The fact is now that we have a complete new version inside the official language pack but an incomplete very old version inside the modul ... every of the 18 strings is shown in english language which is not in the module language file even if the string is translated in the official language pack. Bad thing!!

Regards, Ralf

Anthony,

I found another module that shows english strings while the user is logged in with de_du_utf8. If you will try the Moodle module book then you will have the same effect as we saw it with the mrbs block.

Ralf

Ralf - Please provide a URL for the feedback module for Moodle 1.9 you are referring to. I need to be sure I am looking at the right file. I guessed you might have been referring to:

http://cvs.moodle.org/contrib/plugins/mod/feedback/lang/de_utf8/block_feedback.php?view=log&pathrev=MOODLE_19_STABLE

but that was modified in May 2007 not Dec 27th. In any case, if you find that there are language issues for a particular block or activity please create a separate issue in the tracker for that component so that the maintainer of it can make the necessary changes. As I mentioned previously, feedback is a complicated example as it is being added to Moodle core in 2.0.

Yes, I would expect book to behave like mrbs; hopefully, the patch provided with this issue will resolve that issue.

Peace - Anthony

Just looking again at the patch, I would probably add one more check to the first part of the patch:

+ if (!empty($locations)) {
+ $parent=get_parent_language($locations);

if (empty($parent)) { $parent=defaultlang; }

+ } else { + $parent=$defaultlang; + }

just to ensure that no matter what a parent language is defined. I could see it happening that a language is passed which does not have a parent so in those cases using the default language would be best.

Peace - Anthony

Koen - I've added you as a watcher since this impacts languages. I think the patch would help ensure that any third party blocks have better checking of parent language. Let me know if you have any questions. Peace - Anthony

This countermeasure is not enough since if there is no langconfig.php in blocks/*** or mod/***, get_string() send back english terms or [[****]].
If langconfig.php does not exists, please use get_string('parentlanguage') for getting $parentlang. It's defined in moodledata/lang/***_utf8.

Reassigning to David, it seems more like his sort of thing.

We came across the same issue in Totara with languages not falling back to their parent language correctly. I've attached a patch of our solution which was to add another loop that goes through all the normal locations it looks for the language strings after finding the parent language.

Cheers,
Alastair