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.
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.
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)
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.
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 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).
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.
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.
Please, note my comments and questions at MDL-9361, including the following one:
Have the example from my previous post:
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
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.
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.