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?

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?

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.

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.

http://moodle.org/mod/forum/discuss.php?d=75088

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

Core string files should never be in the module space, any that are should be fixed.