Non-core contributed modules

Ralf - As I understand language packs, if there is no specified language it defaults to the English. Since the mrbs block does not have a de_du_utf8 language pack it may be defaulting to English. Although I would expect it to default to the regular german pack. I suspec this is not unique to the MRBS block but to all blocks. We avoid duplication in specialized language packs by just having the strings that are different. So if a particular phrase is expressed differently in a sub-language pack only that string is there. The order of preference would then be:

Is the string defined in de_du_utf8? If not, use the string in de_utf8.
Is the string defined in de_utf8? If not, use the string in en_utf8.
Is the string defined in en_utf8? If not, return [[stringname]].

Does that make sense or explain the behavior you are seeing? Could you provide me a specific example or string that I can look at and/or screen shot?

Thanks for giving the MRBS block a close look and helping out with testing. I have neglected it as I have become involved with other projects.

Peace - Anthony

p.s. I'm getting ready to head to Lousiana - currently in Texas - so I will be traveling most of the day but please post what you find and I'll look at hopefully later tonight.

Hi Anthony,

I think that your order for the language files is correct ... first de_du_utf8, second de_utf8, third en_utf8 and at last [[stringname]].

I cant understand that MRBS does not work in this order because inside the code the function get_string is used ... and this function should do all the work to fall back in the correct order. I found the function in Moodle and in all other additional blocks. The only one I found with the incorrect language handling is MRBS.

I cant see what to do.

Best regards, Ralf

On the left side you see the block MRBS with de_utf8 and on the right side I changed to de_du_utf8. The right picture shows MRBS in english language while the other parts of Moodle are shown in german language.

Ralf - I will try to replicate this and take a look when I get a chance. Peace - Anthony

Ralf - OK, I've had a chance to review this more carefully and it is not a bug. First, I do not have an official version of the de_du_utf8 language file for the mrbs block. If you would like to send me one that would be great. The issue was that we need to have a langconfig.php file in the /blocks/mrbs/lang/de_du_utf8 folder that sets the parent directory. Otherwise, it will look in /lang/de_utf8/block_mrbs.php which does not exist and hence bounce to the English. I'm going to resolve this as not a bug. I saw that you had created some other issues and if one of those includes the de_du_utf8 version of the block_mrbs.php then I will upload that and we will begin supporting it; however, currently we do not have that and therefore it cannot be a bug. If you want to create one, just create a new issue in the tracker as a feature request to add de_du_utf8 lang support for the mrbs block and attach the block_mrbs.php file containing only those strings which are different from the de_utf8 version and I will happily upload it. Thanks again for reporting this and let me know if you come across any other issues. I really do appreciate having another set of eyes looking at things. Peace - Anthony

Hi Anthony,

this is not correct. As you wrote yesterday there are 4 steps in Moodle language fallback ... first de_du_utf8, second de_utf8, third en_utf8 and at last [[stringname]]. You should not need to have any file for de_du_utf8. If there are some translations in de_utf8 you will get them in german. If there ars some strings missing in de_utf8 you will get the strings from en_utf8.

The module MRBS has a file for de_utf8 so I should get translated german strings for any user who set de_utf8 OR de_du_utf8.

In my own test Moodle I installed also the modules feedback and book. Both do not have any file for de_du_utf8. Both fall back to de_utf8 correctly when an user sets the language to de_du_utf8 in his user profile or chooses de_du_utf8 in the language menu on the frontpage.

Please look at my Moodle to see the feedback and the book. It's open for guests. You may choose the language on the frontpage and then come back to the course.
http://moodle4mac.dyndns.org:8888/moodle19/course/view.php?id=12

Ralf

Ralf - You may want to check out #9 at http://docs.moodle.org/en/Translation#Translating_the_Moodle_interface_language_files_.28the_.22string.22_files.29

It is possible that those other modules have a 'parentlanguage' string defined somewhere. I was testing it without it being defined in config settings. The steps are still correct in terms of how they are designed to work; however, as I read the code it looks for the parentlanguage around line 5376 in the get_string function of /lib/moodlelib:

get_string_from_file('parentlanguage', $langfile, "\$parentlang")) {

I think at a minimum you will need the langconfig.php file. Otherwise, Moodle will not know where to look for the string.

I'll have to play with the feedback module and see where it is getting the information it needs to fall back. If your site's preferred language is de_utf8 that might work.

Peace - Anthony

Ralf - I did try to play with the 1.9 version of the feedback block and I was not even able to get it to switch languages which was rather bizarre and I do not feel like playing with why that might have been the case. There is the site default language, the user language, and other options that may be giving you different experiences. For the mrbs block, I believe the correct thing to do is to provide a de_du_utf8 translation and include a langconfig.php file. I suspect you have one at /lang/de_du_utf8/langconfig.php which has the parentlanguage string defined as de_utf8. My guess is that is how the others are finding their way but without access to the code on your machine it is difficult for me to troubleshoot. Some screenshots might be helpful or if we wanted to setup a common test server I would be willing to do that. Peace - Anthony

Ralf - Part of the reason I was having trouble with the feedback block is because it is in HEAD and now has a block_feedback.php file in the language pack so it was finding that string rather than the ones I was trying to use in block/feedback/lang. So let's just go ahead and do things properly and create a de_du_utf8 language folder with both the block_mrbs.php file and a langconfig.php file with the defined parentlanguage string. I think that would be the best thing to do. Peace - Anthony

Anthony, I want to say it once more.

Every Moodle module should be able to use the parent language de_utf8 automaticly if the user's language is de_du_utf8 and the module doesn't have the package de_du_utf8. The same thing by example must happen also for es_utf8 when the user's language could be es_es_utf8 (Espania), es_ar_utf8 (Argentinia) or es_mx_utf8 (Mexico).

As I understand the Moodle coding of get_string() everything should work perfectly with this function. If not there will be a problem with this Moodle function and we should tell this as a bug in Moodle. It would not be a good thing to implement an own coding for MRBS. get_string() should search automaticly for the right language package de_utf8 if the special package de_du_utf8 does not exist.

If you want to see the langconfig.php for de_du_utf8 then you can get it from http://cvs.moodle.org/lang/de_du_utf8/langconfig.php

Best regards, Ralf

Ralf - Thanks for your patience with me and for re-iterating your point. Eventually it gets through my skull (or at least a little more each time). Yes, you are right that if the site has installed the de_du_utf8 language pack then they have a /lang/de_du_utf8/langconfig.php file that declares the parentlanguage as de_utf8. I kept thinking about the mrbs block language files rather than site's language files. So to test this we want to install both de_utf8 and de_du_utf8 language packs on a fresh Moodle install as well as the MRBS block. I did create one small improvement for the get_string function for better error checking.

There is a bit of a logical flaw in get_string which I will create a tracker issue for. As the various locations get iterated through it checks to see if a parent language is defined for that location. If it is, then it checks for strings in that parent language. The problem is that the parent language is defined for the $CFG->dirroot/lang file (in this case $CFG->dirroot/lang/de_du_utf8) but the block_mrbs.php file is not located in that location. Since the $CFG->dirroot/blocks/mrbs/lang/de_du_utf8/langconfig.php file does not exist it correctly believes that that location does not have a parent language defined. What we want and probably need is a separate function to determine if there is a parent language and if there is a parent language then check for the existence of the block_mrbs.php file in all of the locations. The program logic is currently not set to do this. I am not sure if that makes sense but I will work on resolving it.

Peace - Anthony

re-opening until MDL-17763 gets resolved

Ralf - Just to rule out, you did have the de_utf8 language pack installed on your system correct? I just want to make sure that it is not related to MDL-17573. Peace - Anthony

Hi Antony,

yes I'm very sure that the language pack de_utf8 is installed correctly. And I made an cvs update for Moodle 1.9 to get all new files. It seems so that Petr Skoda only updated the moodlelib.php only in Moodle 2.0 but not in Moodle 1.9.

He wrote that he fixed the problem http://tracker.moodle.org/browse/MDL-17573 but when I searched in the cvs postings I found two updates for moodle/lib/moodlelib.php (1.1166 -> 1.1167, 1.1167 -> 1.1168). But these update were for Moodle 2.0 .... sorry but Moodle4Mac 2.0 does not work in this moment because MAMP has no PHP 5.2.8.

I still get the same problem as before.

Ralf

Ralf - I am sorry but I cannot reproduce the behavior you are experiencing. I would be happy to look at your setup with you and see if we can track down what is happening. We can setup a test installation on one of my servers if you wish. Just provide me with the location to the a zip version of your Moodle installation so that I can ensure that I am seeing the exact code you are using. You can remove the config.php file from that zip file for security reasons (I do not need your password). I am going to resolve this as cannot reproduce but let me know how I can be of help. Peace - Anthony