Moodle

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

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.

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.

Re-opening in order not to loose the track

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.

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.

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.

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.

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

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.