There is a change in the update process of moodle systems in 1.9 The installed language packages are updated automatically without any request during the update process. Admins who changed the language packages not in local _lang versions will lose the changes.
Lang files from additional blocks and mods are deleted also.
In my opinion this is an unexpected behaviour. Its the first time that during updates files in the moodledata folder are overwritten.
http://tracker.moodle.org/browse/MDL-10227
Automatic update of language package while updating in 1.9
by Ralf Hilgenstock -
Number of replies: 11
In reply to Ralf Hilgenstock
Re: Automatic update of language package while updating in 1.9
by Tim Hunt -
That's MDL-10227 to make a link to the bug.
From 1.8 on, all plugins should have their lang files inside the plugin folder.
And local customisations should be in the _local lang pack.
Sure, not everyone is in that situation yet, but in the long term it is better for everyone if we do get to that situation. However, people are not going to change their behavior unless we make it a little painful for them in the short term.
The trick is to cause just enough pain that people actually move, but not so much it actually leads to dataloss.
From 1.8 on, all plugins should have their lang files inside the plugin folder.
And local customisations should be in the _local lang pack.
Sure, not everyone is in that situation yet, but in the long term it is better for everyone if we do get to that situation. However, people are not going to change their behavior unless we make it a little painful for them in the short term.
The trick is to cause just enough pain that people actually move, but not so much it actually leads to dataloss.
In reply to Tim Hunt
Re: Automatic update of language package while updating in 1.9
by koen roggemans -
I aggree with Tim: It will finaly stop an ongoing discussion about where language files should be:
Languages in moodledata/lang/XX_utf8
locale changes in moodledata/lang/XX_utf8_local
modules, filters and blocks in the lang folder in the module, filter or block folder.
Thanks to David, the interface is really clear, with just a switch to click on to make Moodle do the right thing, with a help file and a link to the docs on the page ... what more can an admin want
? Oh yes, a read documentation attitude 
I do aggree that for translators it is a little bit inconvenient that very often you upgrade your language developpement Moodle, your lang files get overwritten and (at least in my case) the write rights on those folders get mixed up. What could help for that is to set allow_url_fopen = Off in your PHP.ini (and that way mess up the download capability of your test server) or comment out upgrade_language_pack(); in admin/index.php (about line 313)
Languages in moodledata/lang/XX_utf8
locale changes in moodledata/lang/XX_utf8_local
modules, filters and blocks in the lang folder in the module, filter or block folder.
Thanks to David, the interface is really clear, with just a switch to click on to make Moodle do the right thing, with a help file and a link to the docs on the page ... what more can an admin want
? Oh yes, a read documentation attitude I do aggree that for translators it is a little bit inconvenient that very often you upgrade your language developpement Moodle, your lang files get overwritten and (at least in my case) the write rights on those folders get mixed up. What could help for that is to set allow_url_fopen = Off in your PHP.ini (and that way mess up the download capability of your test server) or comment out upgrade_language_pack(); in admin/index.php (about line 313)
In reply to Tim Hunt
Re: Automatic update of language package while updating in 1.9
by Ralf Hilgenstock -
Hi Tim,
sorry, but I found only now time to check it again.
There is just an other problem with local customization. Lang files that are not in the moodle/lang/ folder are not found in the internal language system. So its not possible to create local customized strings.
If we store the plugin lang files in the plugin folder it is an easier process for installation. I agree in this point, but I disagree in an other topic: it is not a better solution if it breaks all the principles in the language editing system.
In reply to Ralf Hilgenstock
Re: Automatic update of language package while updating in 1.9
by Tim Hunt -
Well, then the language editing system needs to be improved.
It is not very hard to find the language files, just look at get_string, and do the same.
Sorry, that does not sound very sympathetic. I am sure that making it easier to install plugins is the right way to go, and I don't think enhancing the language editing system will be difficult.
It is not very hard to find the language files, just look at get_string, and do the same.
Sorry, that does not sound very sympathetic. I am sure that making it easier to install plugins is the right way to go, and I don't think enhancing the language editing system will be difficult.
In reply to Tim Hunt
Re: Automatic update of language package while updating in 1.9
by Ralf Hilgenstock -
Can you explain how we should add the new translated file back in CVS? As far as I know translators don't have writing access to the moodle-folders. Or can we write in the main system?
In reply to Ralf Hilgenstock
Re: Automatic update of language package while updating in 1.9
by Tim Hunt -
As I understand it, there is no plan to move the language files for the modules in core Moodle. They will stay in the lang folder. So there is no change when producing language packs for the official Moodle distribution.
It is only 3rd party plugins that should now have the lang files in module folder. And for those, the lang files need to go into contrib, which is (as I understand it) where they have always gone. It is just that people installing those modules no longer have to fiddle around moving the lang files around, and maybe they are in a slightly different place in contrib.
Certainly this makes it more complicate for programmers to make a nice interface for administrators to use to customise the language strings in their Moodle, and for translators to create language packs. However, as a developer, I feel it is my job to make software that deals with the complications and makes things easy for users. And extending the language editing system to cope with this extra complexity is not impossibly difficult, it is just a bit more difficult (not that I am volunteering to help).
It is only 3rd party plugins that should now have the lang files in module folder. And for those, the lang files need to go into contrib, which is (as I understand it) where they have always gone. It is just that people installing those modules no longer have to fiddle around moving the lang files around, and maybe they are in a slightly different place in contrib.
Certainly this makes it more complicate for programmers to make a nice interface for administrators to use to customise the language strings in their Moodle, and for translators to create language packs. However, as a developer, I feel it is my job to make software that deals with the complications and makes things easy for users. And extending the language editing system to cope with this extra complexity is not impossibly difficult, it is just a bit more difficult (not that I am volunteering to help).
In reply to Tim Hunt
Re: Automatic update of language package while updating in 1.9
by Ralf Hilgenstock -
Tim, after some thinking about it I agree with you.
Koen wrote on Monday about lang files for mod/block/filter in the folder of the activities, blocks, filter. If we understand it that this is only for third party modules I agree.
Summarizing the discussion there is only one open topic about the local_lang files.
Koen wrote on Monday about lang files for mod/block/filter in the folder of the activities, blocks, filter. If we understand it that this is only for third party modules I agree.
Summarizing the discussion there is only one open topic about the local_lang files.
In reply to Ralf Hilgenstock
Re: Automatic update of language package while updating in 1.9
by koen roggemans -
yes, it is only for thirth party modules. They come (or should come) with a eg moodle/mod/modulename/lang/ln_utf8 folder. Unzipping the module on the right spot (in mod in this case) will make the available translations work without moving the language files (as was necessary at some point).
For translating thirth party modules, I think the easiest way it to translate the :ang/en_utf8/module.php file it with a UTF8 aware tekst editor and email that file to the maintainer of the module, who can put it in CVS.
I added a small new chapter to http://docs.moodle.org/en/Translation about this.
For translating thirth party modules, I think the easiest way it to translate the :ang/en_utf8/module.php file it with a UTF8 aware tekst editor and email that file to the maintainer of the module, who can put it in CVS.
I added a small new chapter to http://docs.moodle.org/en/Translation about this.
In reply to koen roggemans
Re: Automatic update of language package while updating in 1.9
by David Mudrák -
Hi guys, and thank you for this discussion.
Please, note my comments and questions at MDL-9361, including the following one:
Have the example from my previous post:
mod/data/preset/imagegallery/lang/en_utf8/data.php
Now imagine there is another database preset developed 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.
So, the non-lang location of string files is NOT only 3rd party modules issue. At least, the previous example shows that strings are stored in the module directory even in case of standard module. It is not clear for me yet and that is why I haven't implemented any changes in the language editor features.
Of course Tim is right - we need to improve lang.php to be easy to understand for users and not easy to code for a programmer. So more comments and ideas are welcome.
p.s. I am on holiday these days, so please expect delays of my responses.
Please, note my comments and questions at MDL-9361, including the following one:
Have the example from my previous post:
mod/data/preset/imagegallery/lang/en_utf8/data.php
Now imagine there is another database preset developed 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.
So, the non-lang location of string files is NOT only 3rd party modules issue. At least, the previous example shows that strings are stored in the module directory even in case of standard module. It is not clear for me yet and that is why I haven't implemented any changes in the language editor features.
Of course Tim is right - we need to improve lang.php to be easy to understand for users and not easy to code for a programmer. So more comments and ideas are welcome.
p.s. I am on holiday these days, so please expect delays of my responses.
In reply to David Mudrák
Re: Automatic update of language package while updating in 1.9
by Tim Hunt -
Actually, the way it works, the lang files for a database preset cannot be called data.php. The lang_file file for the 'bookmarks' database preset much be called 'datapreset_bookmarks.php'. Only then will Moodle know to look in the mod/data/preset/bookmarks/lang/ folder.
That is how the system knows what sort of thing it is looking for, that prefix. block_ for blocks, qtype_ for question types, and no prefic for activity modules. And so on.
It may be that the database preset in core lump all their string into data.php. That works but is not terribly good practice. It won't work for third part presets.
Of course, any preset may re-use common strings from the main data.php, or even moodle.php lang files, if it wants.
That is how the system knows what sort of thing it is looking for, that prefix. block_ for blocks, qtype_ for question types, and no prefic for activity modules. And so on.
It may be that the database preset in core lump all their string into data.php. That works but is not terribly good practice. It won't work for third part presets.
Of course, any preset may re-use common strings from the main data.php, or even moodle.php lang files, if it wants.
In reply to Tim Hunt
Re: Automatic update of language package while updating in 1.9
by David Mudrák -
I see now. Thank you for the clarification.