Talk:Languages subsystem improvements 2.0
I really like your functional proposal, David - makes a lot of sense and adds possibly a lot of flexability for both developers and translators. All depends on how you see the storage. --koen roggemans 19:33, 1 December 2009 (UTC)
Quick notes from our meeting in Prague
(David feel free to add/modify in line)
It is important for translators to be able to work with external tools, because there are problems in RTL languages to use online tools.
It is also important to keep the translation process a simple as possible.
It will be difficult/impossible to unite all our requirements in an external tool, so there will be the need to create/update a build in translation tool.
For grammar and plural problems there will be a php-function that handles that. It will not be easy to use, but grammar and plural problems are not easy to solve. The whole string should be replaced by the function, based on a variable, because in some languages there is a lot more changing than just a few letters in plurals
The compiling of a language pack is a good idea, but when working with the language editor (in admin menu and the new to implement one at the bottom of the screen) there should be a way to start the compiling process so the translator can see the result immediately. This can be done on file refresh, on leaving the page, with a button, ... It will depend on the time the compilation takes.
Proposal for changes to the translation process: We replace CVS-access for translators with an upload button in a moodle installation to upload the files to moodle.org. That upload button handles a lot of requirements. It will be the only way for translators to commit files to Moodle.
- it adds the Moodle version to language files so moodle.org knows in which branch they need to go.
- access rights for the upload should be checked on moodle.org
- power users can still work on the files directly or use other translation tools, but the upload to moodle should be done with the correct moodle version
- each string gets a time stamp, put there by the build-in translation tool or by the upload process if the file is modified externally. That can be checked by calculating an md5 for every file on download and on working with the build in translation tool. That is necessary to be able to inform translators about modified English strings
- for translating a new moodle distribution, the translator should install a new distribution copy, import the old language files (they are pre processed on moodle.org = taking out all unused strings) and start working locally, preferably with the build in tool that creates a time stamp for every string, otherwise with an external tool - then the time stamp is created on upload.
- it could handle syntax checking, but that can also be done in the translation tool, on moodle.org after upload or in the compilation process after download. I (Koen) think that the checking in the translation tool is too early, since there are other ways to create the file, and on compilation is too late, because the error is then already in the language pack. I think it is better to prevent the upload of a file with errors so the translator has to fix them immediately before upload.
- I think the editor should be able to do syntax checking. It should just hi-light any bad strings in some way. That way, if you do edit a file in another tool, you just have to load it into the built-in editor to check it is OK. This is how the XMLDB editor works.--Tim Hunt 09:13, 6 December 2009 (UTC)
- the upload button only appears on beta release, witch is the start of the translation process and the stop of adding new features.
--koen roggemans 10:26, 5 December 2009 (UTC)
- To notify translators some string was modified, can we change strings as below?
$string['abouttobeinstalled'] = 'about to be installed';
$string['action'] = 'Action';
$string['actions'] = 'Actions'; -- Mitsuhiro Yoshida 17:35, 8 December 2009 (UTC)