Moodle
  1. Moodle
  2. MDL-17763

get_string: parent language not getting checked for blocks and similar additional locations in particular cases

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.9.3
    • Fix Version/s: 2.0
    • Component/s: Libraries
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE
    • Fixed Branches:
      MOODLE_20_STABLE
    • Rank:
      31620

      Description

      The current program logic for getting parent language strings is:

      1) check location for existence of parent language
      2) check parent language for string in that parent language location

      The problem is that if the site has a parent language defined one would expect that parent language to be checked for the block; however, if the block does not have the parent language defined there is no langconfig.php for that location and a parent language for that location never gets checked. To re-create the issue with a fresh install:

      1) Install the de_utf8 language pack
      2) Install the de_du_utf8 language pack
      3) Install a 3rd party block (for this example mrbs which has a lang folder for de_utf8 but not de_du_utf8)
      4) Set your language to de_utf8
      5) You should notice that all the regular blocks get translated to German; however, the mrbs block does not and is shown in English because the one location that defines the parent language /lang/de_du_utf8/langconfig.php then looks in that location for the string /lang/de_utf8/block_mrbs.php but the file is not there. Instead it is in /blocks/mrbs/lang/de_utf8/block_mrbs.php. But when the location /blocks/mrbs/lang/de_du_utf8 is checked there is no folder and thus no langconfig.php and thus no parent language is detected. However, I would still want and I think most users would expect that /blocks/mrbs/lang/de_utf8/block_mrbs.php would be checked.

      I wonder if having a separate function for parent_lang would help defined along the lines of:

      parent_lang($lang, $locations)
      $lang is the current language (say de_du_utf8)
      $locations are the various locations defined by get_string
      if there is a parent language defined it will return it as a string (i.e. de_utf8)
      if not it will return false

      That way we can simply check
      if ($parentlanguage=parent_lang($lang, $locations)) {
      then if the $location/$module file does not exist ($CFG->dirroot/blocks/mrbs/lang/de_du_utf8/block_mrbs.php)
      and there is a $parentlanguage defined we can check for $CFG->dirroot/blocks/mrbs/lang/de_utf8/block_mrbs.php

      One problem is that if different langconfig.php files point to different parent languages. I cannot think of a case when this would practically happen but theoretically that could confuse things but for the sake of this issue I think it can be presumed that each child language has one and only one parent language.

      CONTRIB-957 has more information about what brought about this issue. Let me know if there are any questions. I will try to work on a patch.

      Peace - Anthony

      1. MDL-17763.diff
        4 kB
        Anthony Borrow
      2. MDL-17763 block lang fix.diff
        3 kB
        Alastair Munro

        Issue Links

          Activity

          Hide
          Ralf Krause added a comment -

          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

          Show
          Ralf Krause added a comment - 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
          Hide
          Anthony Borrow added a comment -

          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

          Show
          Anthony Borrow added a comment - 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
          Hide
          Anthony Borrow added a comment -

          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) }

          Show
          Anthony Borrow added a comment - 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) }
          Hide
          Ralf Krause added a comment -

          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

          Show
          Ralf Krause added a comment - 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
          Hide
          Anthony Borrow added a comment -

          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

          Show
          Anthony Borrow added a comment - 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
          Hide
          Ralf Krause added a comment -

          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

          Show
          Ralf Krause added a comment - 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
          Hide
          Ralf Krause added a comment -

          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

          Show
          Ralf Krause added a comment - 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
          Hide
          Anthony Borrow added a comment -

          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

          Show
          Anthony Borrow added a comment - 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
          Hide
          Anthony Borrow added a comment -

          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

          Show
          Anthony Borrow added a comment - 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
          Hide
          Anthony Borrow added a comment -

          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

          Show
          Anthony Borrow added a comment - 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
          Hide
          Tatsuya Shirai added a comment -

          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.

          Show
          Tatsuya Shirai added a comment - 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.
          Hide
          Tim Hunt added a comment -

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

          Show
          Tim Hunt added a comment - Reassigning to David, it seems more like his sort of thing.
          Hide
          Alastair Munro added a comment - - edited

          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

          Show
          Alastair Munro added a comment - - edited 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

            People

            • Votes:
              0 Vote for this issue
              Watchers:
              6 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: