Uploaded image for project: '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
    • Status: Closed
    • Priority: 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

      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...

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák added a comment -

              Increasing the priority from minor to major.

              Show
              mudrd8mz David Mudrák added a comment - Increasing the priority from minor to major.
              Hide
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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 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 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              dougiamas 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
              dougiamas 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák 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
              mudrd8mz David Mudrák added a comment -

              Just commited in CVS. Please test.

              Show
              mudrd8mz David Mudrák 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:
                    Fix Release Date:
                    3/Mar/08