LCMS Languages

From Dokeos

Jump to: navigation, search

Contents

General description

We need to clean up all the language files. See the analysis what's going wrong for the moment.

  • Do we need to rethink the whole language-system?
  • Do we need to change the DLTT?

Version/Due date

Dokeos 2.0

Analysis

We have two topics to discuss:

1. cleanup of the double, triple language strings (See http://bonny.hogent.be/ for an automatically generated list of language problems)

2. too many files that are read while browsing through different Dokeos pages. Can we change this system? Can we have one language file for each application? And when entering the application for the first time, put all language strings in one array? That way we don't need to read the language file each time the get_lang() function is called.

3. the current system to retrieve language variables is extremely slow. A benchmark revealed it takes a simple test-script about 140 ms to retrieve 40 variables out of a list of 10.000. An alternate method would be to make language string retrieval array-based (checking for key existence to retrieve the string), which took only 11 ms according to the benchmark. (same testing parameters)

Implementation proposal

An alternative way to retrieve language strings would be to make the system array based. Retrieving a string would then become checking for key existance to retrieve that particular variable. The language files would be included at the start of script execution.

Example file format:

$lang['weblcms']['Actions'] = 'Bewerkingen';
$lang['weblcms']['AddAttachments'] = 'Bijlagen toevoegen';
$lang['weblcms']['Amount'] = 'Aantal';
$lang['weblcms']['AnnouncementToolTitle'] = 'Aankondigingen';
$lang['weblcms']['Attachments'] = 'Bijlagen';
$lang['weblcms']['BrowserTitle'] = 'Bladeren';
$lang['weblcms']['By'] = 'door';
$lang['weblcms']['CalendarToolTitle'] = 'Agenda';
$lang['weblcms']['Category'] = 'Categorie';

(Possible) disadvantages

  • We load the entire array whenever a script is executed
  • Could take more memory because of the above ?

(Possible) advantages

  • No need to access the file system every time we need to look up a variable.
  • The chosen array format improves readability of the language files
  • Quicker page loading
  • No increase in memory load ?

Benchmark results

Testing parameters were identical to the ones mentioned above. (10.000 variables, 40 retrievals).

  • It took the test-script 11 ms to retrieve all strings. (as opposed to the current system's 140 ms)
  • Memory usage was 1240 kb (as opposed to the current system's 1279 kb)

Unresolved issues

Comments

The array-based solution does seem very elegant to me! It also allows to quite easily add application-specific translations where necessary in certain languages. I think we also need some kind of 'sorting' convention, to make sure we don't put in the same language variable multiple times and to improve readability. --ThijsBraem 14:51, 24 January 2008 (CET)

I'm a bit surprised by this proposal as it seemed to me that Dokeos (at least 1.8.4 which I just had a look at) already loads everything into memory (it's not in an array so far, which is wrong, but that could be solved easily). In fact, looking at the 1.8.4 global.inc.php script (=claro_init_global), it already loads all the language files into the global space ($GLOBALS), then later on, when calling get_lang(), it initially checks into the $GLOBALS array and only reads a file if needed. That is, only in production mode (in test mode, it still goes and reads the file in any case). I'm not sure if LCMS is not based on an older version of the whole get_lang() stuff, but maybe it is (should be checked).
In any case, loading them into a proper array is good (definitely). The only thing I'm worried about is the session space. I think it might be a good think to benchmark a situation where common language files are loaded into the session (but not tool-specific language files), so that we don't even have to read those files again (I know trad4all is quite big now). --YannickWarnier 23:11, 14 February 2008 (CET)

Personal tools