05 January 2009, 17:41

This is an interesting idea - the only issue being where the dataroot path should go on english sites - because we don't want that to appear before docroot.

I guess it's worth pointing out that what language a site is doesn't actually matter - instead, what language a given request is for is more important. Any given request may need to generate language strings in any language the site has installed, but by default will generate most strings in the language of the user who is viewing the page.

Given that information, an interesting plan might be:

if user language is english then
  searchpath = docroot, dataroot, langpacksearchpaths
else
  searchpath = dataroot, langpacksearchpaths, docroot

That should result in optimal behaviour for all cases. langpacksearchpaths may almost become completely unused as most people will put language packs in dataroot, but that won't make it completely useless.

06 January 2009, 3:13

I have made a rudimentary patch for this. One thing I did discover was that you can't check for what language is being used in the searchpath function because that relies on checking that whatever language will be "current" is installed, and once I had fixed language_installed to use the searchpath it got stuck in an endless loop: searchpath needs currentlanguage, which needs to check if it's installed, which needs searchpath...

But I did have a look at the source of all the language functions, and established that there's only a one time loop to look for where any given language is installed, in get_language_root(). The result to that is cached, so I think the end result is that there's only one more stat() per request than necessary if the language path has docroot and then whatever language the user has installed on it. That's not a terrible performance hit.

I need to clean up and then check the patch in to both branches, I will do that tomorrow.

06 January 2009, 6:54

I wouldn't add to much complexity to deal with the theoretical performance hit. On any decent modern Unix-like operating system, the VFS is going to cache both stat information (on Linux the dircache) and file contents aggresively, unless you are seriously running out of memory, which is a problem in itself ;-).

I haven't done any benchmarking on Windows to see its stat performance, but I'd expect Windows 2003 and later server versions to perform at least passably in this respect. Of course XP is not going to cut it, but no one should be using XP (or Vista for that matter) to run Mahara, except for very small sites.

This (cacheing) is obviously not going to happen that much in a shared host environment (all the users will be "fighting" for the VFS cache contents) but then again if you run Mahara on a shared host you shouldn't expect great performance (with VFS cacheing or not).

So I'd say we'd better keep the code as simple as possible and don't try to do micro-optimizations.

Saludos. Iñaki.

06 January 2009, 6:59

Of course this assumes that non-English strings are always located in dataroot. But then, if I make a third-party artefact and bundle all of my language packs inside the artefact directory (to keep installation as clean and easy as possible, which is one of the goals of the current Mahara design, according to the wiki), you would be looking in the "wrong" order.

As I say in my other post, I think this is micro-optimization and it's not worth the trouble.

Saludos. Iñaki.

06 January 2009, 18:04

04 January 2009, 19:03

I've now moved it to http://wiki.mahara.org/Developer_Area/Language_Packs/Structure

08 January 2009, 22:37

09 January 2009, 7:28

05 January 2009, 0:51

I have finally got around to setting up your adminlang branch. There were some mistakes in the instructions, but I have managed to set it up and get it working quite nicely now.

I guess you might want to move the instructions on to the wiki at some point, but these are the mistakes I found:

• You clone mahara from git.mahara.org now, not git.catalyst.net.nz
• $cfg->langpacksearchpaths should be array($cfg->dataroot) - no extra stuff on there, else the path is not searched correctly (in particular this leads to a crash on the site options screen if you set it the way your readme says to).
• URL to the translating forum is now incorrect

There are one or two smaller behaviour things that would be nice to tweak but they're no big deals. I think that interface is good enough to recommend for people to use it if they want to make new language packs.

I'm still structuring some documentation for language packs. Armed with the knowledge of how adminlang works, I'm pushing on with that now

05 January 2009, 1:50