06 August 2009, 0:27

Hi guys,

I've been doing a bit of work on keeping customisations for Mahara sites out of the core/plugin code, using a '/local' directory like Moodle has.

So far I've just done database installs/upgrades but I'd also like to add support for overriding individual strings in language packs.

My current thinking is to put modified strings for language files into the /local/lang directory, but all at the same level, for example:

lang/en.utf8/mahara.php ==> local/lang/en.utf8/mahara.php

artefact/file/lang/en.utf8/artefact.file.php ==> local/lang/en.utf8/artefact.file.php

I don't expect this will affect translation work, but does anyone have any strong opinions on this?

R.

06 August 2009, 1:11

Awesome!

Does that mean you can add *new* strings as well as override existing ones?

Moodle 2.0 will have a full 'local' plugin system.  The analogy for Mahara would be that local woud be a new plugintype, and then every sub directory in there is a plugin, which means it would benefit from event subscriptions and cronjobs, both of which may be helpful too.  That's probably too much work, but you could add support for local event subscriptions and cronjobs without going the full plugintype route.

Either way, the file structure looks fine to me :)

06 August 2009, 2:25

Hi Richard,

I like your idea too.

And it would be very nice if  admin user can download a zipped local/lang directory.

Mits

06 August 2009, 3:46

Hello Richard,

If I have understood you correctly that means that Mahara administrators will be able to customize their own language strings just by adding the modified files into the local/lang directory. Am I right?

These are the changes in the code under the commit "Add checking for local upgrades".

I personally think that this new feauture would not interfire the transalation work  On the contrary, it would make it easier, as users can always customized their own strings if they are not happy with the "official translation".

 Regards

06 August 2009, 10:10

06 August 2009, 17:16

Yes, that's right.  Administrators can put modified (or new) language files in local/lang and have strings in there override the official translations.  So for example if an admin wanted to change "View" to "Page" for a site, they could do this without needing to hack on the original language files. That makes site upgrades easier (no merging), but they would still need to keep an eye out for new strings in an upgrade that contain "View".

I just made the change now, it's not the "Add checking for local upgrades" one, it's the later commit called "Look for strings in local/lang before searching language packs".  But it's not set in stone yet; it will be easy enough to change the behaviour any time before 1.2 comes out.