Currently modules have the option of either putting their language files into the main lang directory or to keep them in a lang subdirectory of their own directory. The later option is very useful for newly developed custom modules. It also makes the installation of new modules so much simpler for the novice if they do not have to move the language files into the right subdirectory of the main lang directory.
Will this option stay in 1.6? Is the admin language editing interface able to deal with these language files in the module directories?
I am mainly asking at this moment because I would like to extend this mechanism to cover question type plug-ins.
At the moment, the language editor doesn't support editing language files in mod/lang. Translators who want to work on the translation of a contrib module, need to store the English originals in moodle/lang/en_utf8. The translated file will be written to /dataroot/lang/XX
It's a pro that the installation of new modules goes easy without moving the language file, but it is IMHO not a good idea
Language files are and work on 3 places: dataroot/lang, moodle/lang and moodle/mod/tralala/lang. One example of things that can go wrong with it, are files in the main language pack distribution, wich don't belong there since they are not standard modules, e.g. questionnaire.php in en_utf8, but a lot of other files in other language packs. What happens is that Moodle doesn't search for the most recent file, but in a specific order (if I'm not wrong: 1 local language location 2 moodle/mod/tralala/lang. So when there is an outdated language pack in moodle/lang and or in dataroot/lang, the updated version in moodle/mod/... will not be found, causing brackets on the page.
So, two things can be done:
Another thing that mustn't be forgotten is the conversion of the language packs in contrib to utf8. The way I see it is like this: either the translator of a module does the conversion himself or sends an email to translation@moodle.org, saying something like "Hi, I stopped the translation of module tralala from this.developer@thisdomain.net for 1.5. Can you convert these files in attachement to UTF8 and send them to him?" and I'll take care of it and send it back to the translator or to the developer of the module if the address is mentioned.
The reason I propose to do it like this is because we don't have an automated system for converting the languages in contrib and we don't have a way to stop translators working for 1.5 on the contrib files. That way it could be possible to have two different translations for 1.5 and 1.6, wich is obviously not a good idea and waste of time.
Comments and translations welcome
It's a pro that the installation of new modules goes easy without moving the language file, but it is IMHO not a good idea
Language files are and work on 3 places: dataroot/lang, moodle/lang and moodle/mod/tralala/lang. One example of things that can go wrong with it, are files in the main language pack distribution, wich don't belong there since they are not standard modules, e.g. questionnaire.php in en_utf8, but a lot of other files in other language packs. What happens is that Moodle doesn't search for the most recent file, but in a specific order (if I'm not wrong: 1 local language location 2 moodle/mod/tralala/lang. So when there is an outdated language pack in moodle/lang and or in dataroot/lang, the updated version in moodle/mod/... will not be found, causing brackets on the page.
So, two things can be done:
- add support in the editor for editing language files in the modules, but then all non-standard modules must be and stay out of the standard language location (I think that should be done anyway)
- Move all language files of non-standard modules to the language packs and stop supporting the lang folder in modules. Since 1.6 this becomes somewhat possible, because the languages are downloaded and updated as needed and not the whole Moodle translation at installation
Another thing that mustn't be forgotten is the conversion of the language packs in contrib to utf8. The way I see it is like this: either the translator of a module does the conversion himself or sends an email to translation@moodle.org, saying something like "Hi, I stopped the translation of module tralala from this.developer@thisdomain.net for 1.5. Can you convert these files in attachement to UTF8 and send them to him?" and I'll take care of it and send it back to the translator or to the developer of the module if the address is mentioned.
The reason I propose to do it like this is because we don't have an automated system for converting the languages in contrib and we don't have a way to stop translators working for 1.5 on the contrib files. That way it could be possible to have two different translations for 1.5 and 1.6, wich is obviously not a good idea and waste of time.
Comments and translations welcome
Koen, I really like your first solution, of imposing that language files for non-standard modules have to stay in their module folders and the editing interface edits them there. That will avoid so much of the current confusion. Keeping the language files with the module also makes updating modules from CVS so much simpler.
Are there rules for making your own language files in the Modules unicode compliant?
Not necessary Ger: If they are not unicode, they will produce garbage in a decently (=dbmigrated) installed moodle 1.6. The Latin1 languages might get a little bit lucky, as long as you don't use funny things, like anciënt greek letters or curly quotes in your translation.
Fine for me off course. I think it's here up to Moodle HQ to take a decide (since they will adjust the editor )
But then I really think we (=I) should clean out all language packs and remove non-standard modules to fulfil the rule of thumb to store what should be identical information only on one place: so translations of contrib modules NOT in language packs, but in their own lang folder.
But then I really think we (=I) should clean out all language packs and remove non-standard modules to fulfil the rule of thumb to store what should be identical information only on one place: so translations of contrib modules NOT in language packs, but in their own lang folder.