Multilanguage support

nahoj1976 wrote on Thursday, August 11, 2005:

Hi

I have started to test including support to other languages according to what
was said in the discussion thread about it.

I have so far added a directory structure like this:

openemr
             /locale
                      /se
                      /en

I have added a variable into two files: ($lang="se")
/interface/globals.php
/library/sqlconf.php

Then I have created files with similar names as the files I change and placed
them into the directories /se and /en

For each changed file have I added a few lines in the beginning.

The file login_screen.php located in /interface/login is changed so that it
looks like this:
- - -
<?
$ignoreAuth=true;
include_once("./globals.php");
include_once("…/locale/$lang/login_screen.php");

?>

<html>
<head>

</head>                                                                                 
<body ONLOAD=“javascript:top.location.href=’<?echo
“$rootdir/login/login_frame.php”?>’;”>
<a href=’<?echo “$rootdir/login/login_frame.php”?>’><?echo $text1?></a>                 
<p>                                                                                     
<?echo $text2 ?>                             

</body>
</html>
- - -
the file /locale/en/login_screen.php looks like this:
- - -
<?php
// /locale/$lang/login_screen.php
$text1 = "Follow manually";
$text2 = "OpenEMR requires Javascript to perform user authentication."
?>
- - -

The other files I have changed and added in a similar way.

This works all right but there are a few things that I don’t like and therefor
should need to discuss with someone before doing more:

1. In openemr the files don’t have unique names. This will give problems when
using this nomenclature if one uses the file-structure with one directory for
local/$lang.

2. The alternative to use one $lang sub-directory for each directory in the
structure is possible but not very good when later on adding more languages
and when checking that everything is working and that everything is
translated.

3. Another alternative is to not use files with the same name as the ordinary
file but then one needs a place to keep tracking of what languagefile
corresponds to what file.

4. Another possibility is to use the smarty-functions for multi-language
support but then one need to add smarty into the system and I am not too keen
on that.

Please give me some feed-back since multilanguage support in openemr will
influence all code written and we therefore need to agree on the structure.

In  sql-ledger one adds all text-variables into a large array and then one uses a
perl-script to include it into the files but I am not sure exactly how. That could also be an option if one understands how it is done.

/Johan

sunsetsystems wrote on Thursday, August 11, 2005:

I’m very pleased that you are working on this.  It’s definitely time for OpenEMR to become more global.

One thing to consider might be language files for larger areas of functionality, rather than one language file per source module.  We don’t want huge files, but keeping the number of them down will make things easier for everyone.

– Rod (http://www.sunsetsystems.com/)

nahoj1976 wrote on Thursday, August 11, 2005:

Yes I thought about that too. But a lot of the files have 1 - 4 text variables so there we don’t have much to gain but I suppose there are other files with more text-variables. Probably a lot text-variables will appear in many different files but I don’t know if it is worth the extra work picking those out to another ‘global’ language-file. Maybe it is better to let them appear many times. As long as all variables are local and get killed when closing the file they will not steal resources from the system. (In sql-ledger they have both a general language-file but then they have the option to use separate files for each source module in case the translation means splitting the same english word into 2 or 3 different words in the language of choice to get the right meaning. We might meet the same problem in openemr if using global variables…)

/Johan

nahoj1976 wrote on Tuesday, August 16, 2005:

The translations are progressing. I found that I not only want to translate the texts, I also add date-formats as a typical national issue. That means that when You display the dates as “Sunday October 16th 2005” I will get the same date displayed as “2005-10-16” which I am more used to. I haven’t decided yet how to get weekdays displayed in different languages as I am not sure where the module is located…"

The calendar is a problem.
It is a Smarty-function, and Smarty have a language-module that one could add but that would produce 2 different language-systems into the same software which I don’t like.

The problem with Smarty (what I understand) is also its ‘smart’ way to work: You need to put extra directories beneath the directory where you would like to use smarty. In one system the same smarty-modules needs to be put in 5-10 or more different places. Or is it a way around this?

Any suggestions on how to get language-support into the calendar the best way?