I work for TotaraLMS which is a distribution of moodle. We are looking at using AMOS to manage our own language packs (e.g. strings for modules that we've added which we need translate and distribute ourselves).
I've checked out the code and I'm trying to get it up and running against our repository (which contains totara commits along with merges from stable moodle branches).
I've got a few questions:
- What should the AMOS_REPO_LANGS repository contain and how is it different from AMOS_REPO_MOODLE?
- AMOS requires moodle 2.3 but Totara is based on moodle 2.2 at the moment - is it okay to modify the requires version or should I use an older version of AMOS?
- There are various hard coded commit hashes that don't seem to exist, even in the moodle git repo. For example 'AMOS_REPO_MOODLE_ROOT' => '2e35f0aa005d07298b575f77f7cde56149103fe0' in config-dist.php and $rootcommit = '1a3e88ac5edec427cb3f1154edab665b8af160e3'; in parse-lang.php. Could you explain what these should be set to?
- Is there anything else I should look out for? I've read all the documentation I can find online but I guess it's not really designed to be used this way so I'm expecting to have to make some modifications to get it working.
Thanks for any advice!
David Mudrák would be the best person to answer your questions and hes on holiday until next week, so the main purpose of your my post was to let you know and have some patience in the meantime.
Of course i'm not sure we ever really envisaged people running their own versions of AMOS, so it might be full of peril.
Also, I think ideally we'd love to have your translations coming to us where possible and there has been some recent work to link up with moodle.org/plugins/ for contrib code which may or may not be relevant. (http://tracker.moodle.org/browse/MDLSITE-1836)
Thanks, I'll keep investigating and await David's return.
We're definitely keen to contribute any moodle strings back that you don't yet have - we may well have some new strings for a few 3rd party modules that we include with Totara.
I guess it'll be easier to figure out if we already have ours in an AMOS database.
Firstly, as Dan mentioned, AMOS was never expected to be run in multiple instances. There were a lot of low-level tweaks, hacks and direct SQL statements executed during the initial import of data and even later after that. At lang.moodle.org, we have a couple of additional shell scripts run via crontab that actually control all the AMOS jobs (tracking for changes in Moodle branches etc).
As mentioned by Dan, more effective way seems to be to implement your Totara extensions either via new plugins (forked off the standard ones) or via a custom local_totara plugin that would just provide extra strings you added to your own versions of plugins. That way, this local_totara plugin could be imported into lang.moodle.org and be translated as an ordinary plugin.
- AMOS_REPO_LANGS points to a local clone of the Git mirror of the CVS repository with translations. It was used to read all translations for Moodle 1.x (as since 2.x AMOS only is used). AMOS_REPO_MOODLE is path to the clone of moodle.git that AMOS tracks and gets English string changes from it.
- AMOS requires 2.3 because lang.moodle.org runs at 2.3. I'm not sure (can't remember) if it relies on some 2.3 specific features though.
- As you can easily find by grepping for that constant, it is not used any more in the code. It was required for the initial bootstrap (git log might tell you more). Those root commits in config-dist.php are probably just some fake commits that were replaced with real values in config.php.
- As said, we never expected someone being that crazy to run their own AMOS instance so yes, modifications would be required and no HOWTO-RUN-OWN-AMOS.txt should be expected to be honest. Sorry.
In summary, let me discourage you from this approach. Better to reorganise your Totara modifications in a way that will allow you to use standard AMOS interface (via local_totara for example as mentioned above).
Thanks for the reply, very helpful.
The web services plugin idea looks really cool but I'm not sure it will work for us as we've modified a fair number of core strings to better suit our target market. For example we have "audiences" instead of "cohorts" because it's better understood in the corporate space.
At the moment I can't really see how we could manage two sets of core strings within a single AMOS install although I'd be happy to be wrong!
> how we could manage two sets of core strings
My idea was that Totara creates local_totara plugin that provides (among other things probably) a set of customized strings. Then, instead of modifying the strings in the core, you would just amend get_string() calls to use local_totara as the plugin. That way, you could have local_totara published in AMOS.
Note it was just a technical idea though. I'm not sure translators would be happy about having free and proprietary plugins mixed in AMOS, for example.
Yes having a mixture of Moodle and Totara components in one site is potentially confusing so I can see why you might not want that. From our point of view I think it also makes sense to manage our own infrastructure.
We've actually managed to get an instance up and running, and have imported the lang strings for our 1.1 and 2.2 releases so it looks like it might just work! Many thanks for making the code available as it has saved us a lot of work implementing a similar system.
We have a few bug fixes and might well end up adding some additional features down the line - would you be interested in receiving pull requests?