Moodle
  1. Moodle
  2. MDL-8012

restrict editing standard language files and support automagic creation of local language files

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Fixed
    • Affects Version/s: 1.8
    • Fix Version/s: 1.9
    • Component/s: Language
    • Labels:
      None
    • Affected Branches:
      MOODLE_18_STABLE
    • Fixed Branches:
      MOODLE_19_STABLE
    • Rank:
      37151

      Description

      Since Moodle interface allow editing language files, user tend to modify standard files to customize the language for local sites. However, it has long been recommended to use either local or child language to do such customizations.

      It may be a good idea if the language editing interface by default created _local version of the language files with the strings edited by users. Editing standard files should still be possible, since it is needed for, for example, translators, but should require extra hoops to go through to get into that mode.

      Furthermore, the admin interface could automate producing child languages. After all, it is not that different from editing local language except for having to create the language config.

        Issue Links

          Activity

          Hide
          Koen Roggemans added a comment -

          Personally I think that editing languages and customising languages is an advanced administrator task, not something to start doing without reading the documentation, available on the bottom of the page. With the current interface it just requires a push on the "switch" button ...

          I'll assign the bug to David, since he works on lang.php

          Show
          Koen Roggemans added a comment - Personally I think that editing languages and customising languages is an advanced administrator task, not something to start doing without reading the documentation, available on the bottom of the page. With the current interface it just requires a push on the "switch" button ... I'll assign the bug to David, since he works on lang.php
          Hide
          David Mudrak added a comment -

          I agree with Koen. You should read the documentation before modifying the lang pack. Anyway, I will test the approach with _local pack set as default and will see.

          Thank you for the report.

          Show
          David Mudrak added a comment - I agree with Koen. You should read the documentation before modifying the lang pack. Anyway, I will test the approach with _local pack set as default and will see. Thank you for the report.
          Hide
          David Mudrak added a comment -

          Well, the quick fix would be easy. You can just set LANG_DEFAULT_USELOCAL to 1. But...

          IMHO the lang.php is mostly used by translators. And they do want to use standard lang pack. It is not very translator-friendly to have to keep in mind to always switch from default _local to standard storage. Yes, maybe we could keep the setting LANG_DEFAULT_USELOCAL in user preferences (session etc.) but it would need more coding.

          Also, this could be handled by Roles: we could define "Local translator" and "Global translator" roles with capatibilities to edit local or system lang pack, respectively. These capabilities should not be granted to anybody by default, so admin would have to grant these roles to herself or to whomever. With the role "Local translator", only _local packs are editable then.

          Show
          David Mudrak added a comment - Well, the quick fix would be easy. You can just set LANG_DEFAULT_USELOCAL to 1. But... IMHO the lang.php is mostly used by translators. And they do want to use standard lang pack. It is not very translator-friendly to have to keep in mind to always switch from default _local to standard storage. Yes, maybe we could keep the setting LANG_DEFAULT_USELOCAL in user preferences (session etc.) but it would need more coding. Also, this could be handled by Roles: we could define "Local translator" and "Global translator" roles with capatibilities to edit local or system lang pack, respectively. These capabilities should not be granted to anybody by default, so admin would have to grant these roles to herself or to whomever. With the role "Local translator", only _local packs are editable then.
          Hide
          David Mudrak added a comment -

          Re-opening in order not to loose the track

          Show
          David Mudrak added a comment - Re-opening in order not to loose the track
          Hide
          Robert Brenstein added a comment -

          I did not mean to suggest that editing should be done by teachers. You read more into my words that I wrote. My suggestions had exactly the site administrators in mind. I agree that editing languages requires reading the documentation. But let's face it, Moodle has lots of administrators that are not technically trained. This is one of its advantages actually. And it is the reality that many people read the instructions only when they run into trouble.

          The issue is, Moodle's interface, as it is now, encourages to edit standard files, which is in opposition to recommendations.

          I disagree that language editing is done mostly by translators. As far as I can see, there are quite a few Moodle sites which modify (customize) a number of strings and there are some that do quite extensive changes. Check forums for how often people are advised to not modify standard language files but create own language or the local files for small customization. We have some 80 languages, so with let's say 3 translators per language, it is barely over 200 people for whom the interface is designed. I bet that far many more Moodle sites have customized languages (some may have only a few strings).

          We have locally modified quite a few language files (in more than one language), including having our own language. Since I have to maintain them through Moodle upgrades, I tend to watch posts related to language editing on moodle.org. I feel that since the switch to utf8 and changing the location of language files, there have been a visible increase of issues related to dealing with those files. Utf8 in particular created issues for direct editing. Also more and more sites seem to be run on commercial ISP's and direct editing requires there extra steps.

          I do not see roles as the solution here. Roles can be used to control who specifically is allowed to edit the langauges, but that is a different issue. I am after having proper, or at least better, support for language editing through the web interface by administrators not only by translators. A simple solution could be to have separate links for editing standard language files and for customizing language files. I think such a distinction would make it clear what's going on and it should not be that difficult to have an internal file location pointer that tells the code whether we are editing master file or local extension.

          Show
          Robert Brenstein added a comment - I did not mean to suggest that editing should be done by teachers. You read more into my words that I wrote. My suggestions had exactly the site administrators in mind. I agree that editing languages requires reading the documentation. But let's face it, Moodle has lots of administrators that are not technically trained. This is one of its advantages actually. And it is the reality that many people read the instructions only when they run into trouble. The issue is, Moodle's interface, as it is now, encourages to edit standard files, which is in opposition to recommendations. I disagree that language editing is done mostly by translators. As far as I can see, there are quite a few Moodle sites which modify (customize) a number of strings and there are some that do quite extensive changes. Check forums for how often people are advised to not modify standard language files but create own language or the local files for small customization. We have some 80 languages, so with let's say 3 translators per language, it is barely over 200 people for whom the interface is designed. I bet that far many more Moodle sites have customized languages (some may have only a few strings). We have locally modified quite a few language files (in more than one language), including having our own language. Since I have to maintain them through Moodle upgrades, I tend to watch posts related to language editing on moodle.org. I feel that since the switch to utf8 and changing the location of language files, there have been a visible increase of issues related to dealing with those files. Utf8 in particular created issues for direct editing. Also more and more sites seem to be run on commercial ISP's and direct editing requires there extra steps. I do not see roles as the solution here. Roles can be used to control who specifically is allowed to edit the langauges, but that is a different issue. I am after having proper, or at least better, support for language editing through the web interface by administrators not only by translators. A simple solution could be to have separate links for editing standard language files and for customizing language files. I think such a distinction would make it clear what's going on and it should not be that difficult to have an internal file location pointer that tells the code whether we are editing master file or local extension.
          Hide
          David Mudrak added a comment -

          Hi Robert.
          Yes, I finally agree with you. There are much more administrators customizing their site strings than people maintaining official moodle language packages. But I think that Roles might be solution for this anyway. Imagine following scenario:

          There are new capabilities introduced, called e.g.:
          Capabilities/moodle/lang:editmaster - user can edit master (system, global, official or whatever) language packs
          Capabilities/moodle/lang:editlocal - user can only customize _local language packs

          There are two roles introduced to respect these capabilities: e.g. "Master Language Maintainer" and "Local Language Customizer".

          By default, these capabilities are granted to nobody at the server. Thus when an administartor comes to the Edit language page, there is just notice about missing permissions and some short explanation. According to the instructions provided, the administrator has to assign the role "Local Language Customizer" to herself to be able to customize language pack. From now onwards, she (or anybody else - you can e.g. ask some students to help with the translation) is allowed only to customize local language - with no button "switch", no problems with overwriting local changes during next update etc. Because she is missing lang:editmaster permission, she can not accidently edit master language pack.
          Maintainers of master language packs may assign themselves the role "Master Language Maintainer" and have the full functionality of the current interface (let us hope they know what they are doing

          Thank you very much for your comments and ideas. Looking forward to hear from you again.

          Show
          David Mudrak added a comment - Hi Robert. Yes, I finally agree with you. There are much more administrators customizing their site strings than people maintaining official moodle language packages. But I think that Roles might be solution for this anyway. Imagine following scenario: There are new capabilities introduced, called e.g.: Capabilities/moodle/lang:editmaster - user can edit master (system, global, official or whatever) language packs Capabilities/moodle/lang:editlocal - user can only customize _local language packs There are two roles introduced to respect these capabilities: e.g. "Master Language Maintainer" and "Local Language Customizer". By default, these capabilities are granted to nobody at the server. Thus when an administartor comes to the Edit language page, there is just notice about missing permissions and some short explanation. According to the instructions provided, the administrator has to assign the role "Local Language Customizer" to herself to be able to customize language pack. From now onwards, she (or anybody else - you can e.g. ask some students to help with the translation) is allowed only to customize local language - with no button "switch", no problems with overwriting local changes during next update etc. Because she is missing lang:editmaster permission, she can not accidently edit master language pack. Maintainers of master language packs may assign themselves the role "Master Language Maintainer" and have the full functionality of the current interface (let us hope they know what they are doing Thank you very much for your comments and ideas. Looking forward to hear from you again.
          Hide
          Robert Brenstein added a comment -

          If you think roles is the way to go, fine with me.

          Would one has to be "Master Language Maintainer" in order to create and edit our own local language pack? I wonder whether you need to add a third role e.g. "Local Language Maintainer" or "Custom Language Maintainer" (as opposed to "Local Language Customizer") plus appropriate capability. The complication here would be that Moodle must somehow know which language comes from the mother ship and which is created locally.

          How is your approach going to work, in terms of interface, when the same admin need to be able to both edit the master or local language packs as well as being able customize a language?

          In terms of implementation for _local files, it would be nice if the text from standard language file was displayed in the column where normally the English original is. Of course, only non-empty entries should still be saved into the _local file.

          For custom language, the "original" column should IMHO contain the texts from the parent language. I believe that any custom language should have a parent, be it English if nothing else is specified or suitable.

          Show
          Robert Brenstein added a comment - If you think roles is the way to go, fine with me. Would one has to be "Master Language Maintainer" in order to create and edit our own local language pack? I wonder whether you need to add a third role e.g. "Local Language Maintainer" or "Custom Language Maintainer" (as opposed to "Local Language Customizer") plus appropriate capability. The complication here would be that Moodle must somehow know which language comes from the mother ship and which is created locally. How is your approach going to work, in terms of interface, when the same admin need to be able to both edit the master or local language packs as well as being able customize a language? In terms of implementation for _local files, it would be nice if the text from standard language file was displayed in the column where normally the English original is. Of course, only non-empty entries should still be saved into the _local file. For custom language, the "original" column should IMHO contain the texts from the parent language. I believe that any custom language should have a parent, be it English if nothing else is specified or suitable.
          Hide
          Koen Roggemans added a comment -

          Robert, you are probably right about the number of people changing language packs, although I still believe in reading documentation

          Another approach could be the combination of both suggestions: make separate links for local and main language pack (I like that idea) and by default the administrator can edit both. You can give the capability to another role too.

          Show
          Koen Roggemans added a comment - Robert, you are probably right about the number of people changing language packs, although I still believe in reading documentation Another approach could be the combination of both suggestions: make separate links for local and main language pack (I like that idea) and by default the administrator can edit both. You can give the capability to another role too.
          Hide
          Robert Brenstein added a comment -

          No argument about reading the docs from me

          I think that Roles as proposed by David are really needed. Actually, not so much predefined Roles but the capabilities. I agree with Koen that the primary administrator should have the capabilities given by default.

          I also like the combo solution. Having the links explicitly visible would make things more transparent. Links could appear and disapear depending on user's role and its capabilities.

          In Moodle 1.7, we have the "Language editing" panel with title "Edit Current language:" (why current is capitalized and language is not?) with a popup list of installed language packs. I think the title could change to just "Edit Language" (the 'current' is a misnomer IMHO since we select language to be edited) followed by

          Check for untranslated words or phrases
          Edit words or phrases
          Edit help documents
          Customize words or phrases for local site
          Customize help documents for local site
          Create new local language pack

          Show
          Robert Brenstein added a comment - No argument about reading the docs from me I think that Roles as proposed by David are really needed. Actually, not so much predefined Roles but the capabilities. I agree with Koen that the primary administrator should have the capabilities given by default. I also like the combo solution. Having the links explicitly visible would make things more transparent. Links could appear and disapear depending on user's role and its capabilities. In Moodle 1.7, we have the "Language editing" panel with title "Edit Current language:" (why current is capitalized and language is not?) with a popup list of installed language packs. I think the title could change to just "Edit Language" (the 'current' is a misnomer IMHO since we select language to be edited) followed by Check for untranslated words or phrases Edit words or phrases Edit help documents Customize words or phrases for local site Customize help documents for local site Create new local language pack
          Hide
          David Mudrak added a comment -

          Fixed in the current CVS HEAD by implemented two new core capabilities. Improvements in lang.php GUI should help navigation.

          Ad child languages: there is no plan to implement automatic creation of child language pack at the moment. Since this is an action that only several people will do just once in all life or (probably) never, I do not think we need a GUI for this.

          Show
          David Mudrak added a comment - Fixed in the current CVS HEAD by implemented two new core capabilities. Improvements in lang.php GUI should help navigation. Ad child languages: there is no plan to implement automatic creation of child language pack at the moment. Since this is an action that only several people will do just once in all life or (probably) never, I do not think we need a GUI for this.

            People

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

              Dates

              • Created:
                Updated:
                Resolved: