|
Increasing the priority from minor to major.
The first important question is: where should the translation of 3rd party modules go?
Let us have some cool mod/coolmodule installed with its own mod/coolmodule/lang/en_utf8/coolmodule.php I want to create Czech translation of this module. Where should cs_utf8/coolmodule.php be created? 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 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? OK, let us have for example
mod/data/preset/imagegallery/lang/en_utf8/data.php 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? Some thoughts...
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. The capabilities seem to be right way how to prevent the overwriting of distributed language packs by non-maintainers. I have added the link to
Koen,
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. Many thanks to Tim Hunt for clarifying the previous issue at <http://moodle.org/mod/forum/discuss.php?d=75088> . Now, I have got a function looking for string files in non-standard location. As of my current 1.9-dev version, the function returns three string files in non-standard location:
*** 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. I am almost done with the patch. I have got the last issue: let us have a 3rd party module, e.g. stampcoll. It is distributed with module space lang pack for English and Czech. The lang.php should provide Czech administrators to customize their _local translations according to the distributed one.
IMHO there is only one reasonable solution is: for non-core (3rd party) plugins, the translation can go only into _local.
Just commited in CVS. Please test.
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Improvement
Resolved
Major
Ability to edit language in third party modules and plugins w/o copying the language files
 |
|
by Tim Hunt - Tuesday, 1 May 2007, 05:19 PM
That is clearly a bug, and it needs to be fixed. The language editor needs to use the places_to_search_for_lang_strings() function from about line 4200 of lib/moodlelib, so it can look for language files in exactly the same place that get_string() and help.php look for them.