Moodle
  1. Moodle
  2. MDL-9361

Ability to edit language in third party modules and plugins w/o copying the language files

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 1.9, 2.0
    • Fix Version/s: 1.9
    • Component/s: Language
    • Labels:
      None
    • Affected Branches:
      MOODLE_19_STABLE, MOODLE_20_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      34468

      Description

      Third party modules and plugins have their translations in their lang subfolder. That works for activity modules since 1.7 (or was it 1.6?), and for all types of plugin in 1.8. The lang.php could be able to translate these files as well.

      Is this really good solution? Maybe we could be strict and keep language files in one place...

        Issue Links

          Activity

          Hide
          David Mudrak added a comment -

          http://moodle.org/mod/forum/discuss.php?d=70451
          by Tim Hunt - Tuesday, 1 May 2007, 05:19 PM
          That is clearly a bug, and it needs to be fixed. The language editor needs to use the places_to_search_for_lang_strings() function from about line 4200 of lib/moodlelib, so it can look for language files in exactly the same place that get_string() and help.php look for them.

          Show
          David Mudrak added a comment - http://moodle.org/mod/forum/discuss.php?d=70451 by Tim Hunt - Tuesday, 1 May 2007, 05:19 PM That is clearly a bug, and it needs to be fixed. The language editor needs to use the places_to_search_for_lang_strings() function from about line 4200 of lib/moodlelib, so it can look for language files in exactly the same place that get_string() and help.php look for them.
          Hide
          David Mudrak added a comment -

          Increasing the priority from minor to major.

          Show
          David Mudrak added a comment - Increasing the priority from minor to major.
          Hide
          David Mudrak added a comment -

          The first important question is: where should the translation of 3rd party modules go?
          Let us have some cool mod/coolmodule installed with its own mod/coolmodule/lang/en_utf8/coolmodule.php
          I want to create Czech translation of this module. Where should cs_utf8/coolmodule.php be created?

          1) into standard - dataroot/lang/cs_utf8/coolmodule.php
          Rather not - whole this directory is being replaced by fresh version from download.moodle.org during every Moodle upgrade See MDL-8330

          2) into mod/coolmodule/lang/cs_utf8/coolmodule.php
          Looks like a good place, doesn't it? Apache write access is needed into this directory

          The second issue discovered deals with more complicated locations of language files. Take e.g. lang/en_utf8/enrol_ldap.php. So far it used to be the only place where LDAP plugin strings have been stored. Nowadays, the get_string() also looks into enrol/ldap/lang/. So where are the English string supposed to be stored? And where should they be translated?

          Show
          David Mudrak added a comment - The first important question is: where should the translation of 3rd party modules go? Let us have some cool mod/coolmodule installed with its own mod/coolmodule/lang/en_utf8/coolmodule.php I want to create Czech translation of this module. Where should cs_utf8/coolmodule.php be created? 1) into standard - dataroot/lang/cs_utf8/coolmodule.php Rather not - whole this directory is being replaced by fresh version from download.moodle.org during every Moodle upgrade See MDL-8330 2) into mod/coolmodule/lang/cs_utf8/coolmodule.php Looks like a good place, doesn't it? Apache write access is needed into this directory The second issue discovered deals with more complicated locations of language files. Take e.g. lang/en_utf8/enrol_ldap.php. So far it used to be the only place where LDAP plugin strings have been stored. Nowadays, the get_string() also looks into enrol/ldap/lang/. So where are the English string supposed to be stored? And where should they be translated?
          Hide
          David Mudrak added a comment -

          OK, let us have for example
          mod/data/preset/imagegallery/lang/en_utf8/data.php

          As far as I understand, the correct location of its translation should be
          mod/data/preset/imagegallery/lang/xx_utf8/data.php

          1) what about _local?
          2) how is translator supposed to commit changes? They usually have access rights only into their language pack, not into the core code repository
          3) how shall we find all these possible locations of language files? The get_string() function get $module as paramater and tries to guess the possible location of the translation. Is there a way how to get the list of all possible plugins with their own language packs?
          4) any ideas how the lang.php GUI should be improved to help with translating this?

          Show
          David Mudrak added a comment - OK, let us have for example mod/data/preset/imagegallery/lang/en_utf8/data.php As far as I understand, the correct location of its translation should be mod/data/preset/imagegallery/lang/xx_utf8/data.php 1) what about _local? 2) how is translator supposed to commit changes? They usually have access rights only into their language pack, not into the core code repository 3) how shall we find all these possible locations of language files? The get_string() function get $module as paramater and tries to guess the possible location of the translation. Is there a way how to get the list of all possible plugins with their own language packs? 4) any ideas how the lang.php GUI should be improved to help with translating this?
          Hide
          Koen Roggemans added a comment -

          Some thoughts...

          It is clear that increasing the ease of installation of thirth party modules makes a clear view on translation locations impossible.
          May be we should rethink one and other to recreate some transparency for both human and machine where translations can be found/installed/created. Here's my rethinking attempt:

          There are core language files and thirth party module language files
          There are distributed language files and locally created language files
          and the combination: distributed thirth party module language files and locally created thirth party module files

          What never should happen, is that locally created language files are overwritten by an upgrade.
          What always should happen is that locally created language files have priority over distributed files.

          Therefore I suggest to search for langstrings in
          moodledata/lang/XX_utf8_local
          moodledata/lang/XX_utf8
          moodle/mod/modname/lang/XX_utf8
          moodle/lang/en_utf8
          moodle/mod/modname/lang/en_utf8

          I suggest to write all translations by default in
          moodledata/lang/XX_utf8_local

          Translators who maintain a language pack can switch to the moodledata/lang/XX_utf8 folder
          Translators who want to share their translations for thirth party modules can find their work in the local_XX folder and send it to the maintainer of the module, who can put it in the right place for redistribution (like it should be done already).

          I don't like the idea of saving localised lang files together with the thirth party module files: I don't like to make it necessary to give apache write access to a /public_html folder, especially since it is not necessary (we have the moodledata/lang folder). It also makes upgrades more difficult, since you cannot replace the whole Mooldescript (you have to search your modifications on language files first in a bunch of different /mod folders)
          The only modification to the interface requires for this, is that it defaults to local_utf8 for translations and that it doesn't offer the opportunity to put non-standard module translations in /XX_utf8.

          Show
          Koen Roggemans added a comment - Some thoughts... It is clear that increasing the ease of installation of thirth party modules makes a clear view on translation locations impossible. May be we should rethink one and other to recreate some transparency for both human and machine where translations can be found/installed/created. Here's my rethinking attempt: There are core language files and thirth party module language files There are distributed language files and locally created language files and the combination: distributed thirth party module language files and locally created thirth party module files What never should happen, is that locally created language files are overwritten by an upgrade. What always should happen is that locally created language files have priority over distributed files. Therefore I suggest to search for langstrings in moodledata/lang/XX_utf8_local moodledata/lang/XX_utf8 moodle/mod/modname/lang/XX_utf8 moodle/lang/en_utf8 moodle/mod/modname/lang/en_utf8 I suggest to write all translations by default in moodledata/lang/XX_utf8_local Translators who maintain a language pack can switch to the moodledata/lang/XX_utf8 folder Translators who want to share their translations for thirth party modules can find their work in the local_XX folder and send it to the maintainer of the module, who can put it in the right place for redistribution (like it should be done already). I don't like the idea of saving localised lang files together with the thirth party module files: I don't like to make it necessary to give apache write access to a /public_html folder, especially since it is not necessary (we have the moodledata/lang folder). It also makes upgrades more difficult, since you cannot replace the whole Mooldescript (you have to search your modifications on language files first in a bunch of different /mod folders) The only modification to the interface requires for this, is that it defaults to local_utf8 for translations and that it doesn't offer the opportunity to put non-standard module translations in /XX_utf8.
          Hide
          David Mudrak added a comment - - edited

          The capabilities seem to be right way how to prevent the overwriting of distributed language packs by non-maintainers. I have added the link to MDL-8012

          Show
          David Mudrak added a comment - - edited The capabilities seem to be right way how to prevent the overwriting of distributed language packs by non-maintainers. I have added the link to MDL-8012
          Hide
          David Mudrak added a comment -

          Koen,

          thank you for your thoughts! I agree with the approach proposed.Several last things are not clear too much for me:

          Haver the example from my previous post:
          mod/data/preset/imagegallery/lang/en_utf8/data.php

          Now imagine there is another database preset devoleped and distributed as a part of the core installation, e.g. "bookmarks". As I understand, its strings should then be saved into
          mod/data/preset/bookmarks/lang/en_utf8/data.php

          There is already one master moodle/lang/en_utf8/data.php, these two other data.php files just add more strings. Where should the translation of these files be saved? In case of moodledata/xx_utf8_local/data.php, the translated data.php contains more strings than the original master does.

          I am sure that core guys who said ''OK let us the `lang` directory be there, there, there and there" knew how to deal with translations. I just do not know, whom to ask.

          Show
          David Mudrak added a comment - Koen, thank you for your thoughts! I agree with the approach proposed.Several last things are not clear too much for me: Haver the example from my previous post: mod/data/preset/imagegallery/lang/en_utf8/data.php Now imagine there is another database preset devoleped and distributed as a part of the core installation, e.g. "bookmarks". As I understand, its strings should then be saved into mod/data/preset/bookmarks/lang/en_utf8/data.php There is already one master moodle/lang/en_utf8/data.php, these two other data.php files just add more strings. Where should the translation of these files be saved? In case of moodledata/xx_utf8_local/data.php, the translated data.php contains more strings than the original master does. I am sure that core guys who said ''OK let us the `lang` directory be there, there, there and there" knew how to deal with translations. I just do not know, whom to ask.
          Hide
          David Mudrak added a comment -

          Many thanks to Tim Hunt for clarifying the previous issue at <http://moodle.org/mod/forum/discuss.php?d=75088> . Now, I have got a function looking for string files in non-standard location. As of my current 1.9-dev version, the function returns three string files in non-standard location:

              • blocks/search/lang/en_utf8/block_search.php
                filename : block_search.php
                location : blocks
                plugin : search
                prefix : block_
              • mod/data/preset/imagegallery/lang/en_utf8/data.php
                filename : data.php
                location : mod/data/preset
                plugin : imagegallery
                prefix : datapreset_
              • mod/stampcoll/lang/en_utf8/stampcoll.php
                filename : stampcoll.php
                location : mod
                plugin : stampcoll
                prefix :

          As you can see, mod/data/preset/imagegallery/lang/en_utf8/data.php should be renamed to datapreset_imagegallery.php. At the moment, I am working on patch using these extra locations as well.

          Show
          David Mudrak added a comment - Many thanks to Tim Hunt for clarifying the previous issue at < http://moodle.org/mod/forum/discuss.php?d=75088 > . Now, I have got a function looking for string files in non-standard location. As of my current 1.9-dev version, the function returns three string files in non-standard location: blocks/search/lang/en_utf8/block_search.php filename : block_search.php location : blocks plugin : search prefix : block_ mod/data/preset/imagegallery/lang/en_utf8/data.php filename : data.php location : mod/data/preset plugin : imagegallery prefix : datapreset_ mod/stampcoll/lang/en_utf8/stampcoll.php filename : stampcoll.php location : mod plugin : stampcoll prefix : As you can see, mod/data/preset/imagegallery/lang/en_utf8/data.php should be renamed to datapreset_imagegallery.php. At the moment, I am working on patch using these extra locations as well.
          Hide
          Martin Dougiamas added a comment -

          See MDL-10920

          Core string files should never be in the module space, any that are should be fixed.

          Show
          Martin Dougiamas added a comment - See MDL-10920 Core string files should never be in the module space, any that are should be fixed.
          Hide
          David Mudrak added a comment -

          I am almost done with the patch. I have got the last issue: let us have a 3rd party module, e.g. stampcoll. It is distributed with module space lang pack for English and Czech. The lang.php should provide Czech administrators to customize their _local translations according to the distributed one.

          Show
          David Mudrak added a comment - I am almost done with the patch. I have got the last issue: let us have a 3rd party module, e.g. stampcoll. It is distributed with module space lang pack for English and Czech. The lang.php should provide Czech administrators to customize their _local translations according to the distributed one.
          Hide
          David Mudrak added a comment -

          IMHO there is only one reasonable solution is: for non-core (3rd party) plugins, the translation can go only into _local.

          Show
          David Mudrak added a comment - IMHO there is only one reasonable solution is: for non-core (3rd party) plugins, the translation can go only into _local.
          Hide
          David Mudrak added a comment -

          Just commited in CVS. Please test.

          Show
          David Mudrak added a comment - Just commited in CVS. Please test.

            People

            • Votes:
              3 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: