Talk:Language API

David, before documenting your proposed solution, please could you add a few words about the problem you are trying to solve. What is it about the current language file system that is not good enough?

Please remember that one of the things the current system does very well is performance. All it has to do is look in some directories then load some PHP files that just define some variables (which any good PHP accelerator will pre-compile for you). Also note that it takes care to only load the files needed by the current page, and only loads each file once, and remembers the results.

So if you are proposing a change, you may be expected to do before and after performance testing before the new system goes into core.

Re: Performance issue

Tim, thanks for your comments. Yes, I've got performance impact on my mind. What I want to do is to write a very thin wrapper around the current functionality. Therefore, current implementation of get_string() will stay untouched as it is very well tuned and tested. The basic application of the proposed Language API will be the new translation interface which I am currently working on (AJAX based with some additional feature like search, search & replace etc.). Also, some additional tools (e.g. to create a duplicate of a current string in all language packs) are planned.

When I was writing first concepts of these tools, I had an idea it might be useful to have general language API that is not bind to the current implementation but might enable other developers to write their own implementation. This API should enable to write a simple plugins that deals with translation in other ways (as said - XMl, PO files, direct CVS access etc.).

So, to summarize - the Language API provides common interface for all future translation tools, not for the Moodle core itself.

--David Mudrak 06:54, 18 November 2008 (CST)

Great! I'll stop worrying then :-)--Tim Hunt 19:31, 18 November 2008 (CST)