Language selection at login

bradymiller wrote on Monday, April 13, 2009:

hey,

I was hoping to get input from the developers and anybody else having interest in the appearance of the login screen.

Would it be ok to place a language selection menu in the login screen?  It will default to English, and I’ll make an option that can turn off the menu in globals.php.  I’ve already got this working well on my computer locally, just don’t want to commit anything that involves the login screen without getting others input.

We’ve also rebuilt some of the language translation table (swedish, spanish, dutch, norwegian). There is basically a pipeline that creates the sql dumpfile from a collaborative Google Doc.  On my local computer I’ve gotten loading of this sql dumpfile to happen in the setup.php script to work well.

This means if I commit my local changes, the user will be presented with a menu of language translations at the login screen (menu can be turned off in globals.php) and they will see translations in OpenEMR for swedish, spanish, dutch, and norwegian if selected.  It’s very cool, and I think will give OpenEMR much more international presence in the online CVS demo.

What do you think?  Is it ok to put the language selection menu in login screen (it seems this is standard for international programs)?  Or should it be moved to a user menu option (of course, my argument is how can a user who doesn’t speak english log into openemr and set this in their user account in English)?  

-brady

blankev wrote on Monday, April 13, 2009:

Brady,

can you take that part of Languages that shows English, Swedish, German, Dutch, Hebrew of the Language tab and use that in the login screen?

Right now, if I want to ADD language, let’s say French, it shows in Language page as:

English; Swedish; German; Dutch; French

If these languages are included as lang_definitions these extra languages can now be used after new login.

Is this the same as what you are implementing in your latest suggestions? TO see oncluded LANGUAGES and if wanted include NEW LANGUAGE if you know how to implement.

Would be a great solution for me.

lang_constants have only two columns, lang_defininitons have four columns, lang_languages has three columns and all have some interaction, and do show up in LANGUAGE tab, and NOW can be changed in globals.php.

Adding Language, IMHO should not be included in the login screen.

Pimm

bradymiller wrote on Monday, April 13, 2009:

To further clarify, here are some screenshots:
http://www.sparmy.com/pics/screenshot60.jpg
http://www.sparmy.com/pics/screenshot61.jpg

And we have an ever-growing translations for swedish, spanish, french , norwegian (continually being produces on a Google Docs collaborative spreadsheet).  Again, this menu can be turned off/on in globals.php (there is no more hard-coding of languages in globals.php)

This is still in transition, still plan:
-To incorporate a Default choice, which will be set in a user’s preferences in the ‘user_prefs’ .

I had to make changes in many files to get this working (about 8 files); used $_SESSION.  I’d like to commit these changes, which will allow:
-the translators to use the CVS demo to test/check/modify their translations
-give Jason a starting point/template for enabling the language selection and other selections in the ‘users_prefs’ table 

Before the next production release, it we choose not to want the menu on the login screen, then can turn off in globals.php (thus using the default choice per user).

I want to make sure all the developers (Rod, Sam, Mark, Mike, Joe, etc., especially Jason since he’s working on the users_prefs table) agree with this plan before I commit these changes.

-brady

sunsetsystems wrote on Monday, April 13, 2009:

Sounds good to me if you are reasonably confident that it’s not breaking anything.

Keep in mind there will surely be a growing list of user preferences besides just language.

Rod
www.sunsetsystems.com

drbowen wrote on Monday, April 13, 2009:

I think the next generation of installation scripts should start with a drop down box of the available languages in the actual language being selected.

If a non-English speaking Spanish only IT admin wants to install OpenEMR he should be greeted with a language choice of

Español

I also need to have Russian added to the list.

Sam Bowen, MD

drbowen wrote on Monday, April 13, 2009:

Ultimately we need to have language selected per user.

In South Africa therre are eleven official languages (11).  You need four languages to get around the country pretty well: Zulu, Northern Sotho, Southern Sotho, Afrikaans.  English is the defacto language standard for the physicians but this is probably not true with nurses and other ancillary staff.

English
Afrikaans
Northern Sotho (Sepedi)
Southern Sotho (Sesotho)
Zulu
Xhosa
Tswana
Swati
Venda
and Tsonga

******
Hi Dr Bowen

I do believe there are physicians who would appreciate being able to use the
system in an indigenous language, but I feel that it’s usefulness would be seen
first amongst the nursing staff, who would definitely find it easier to work
with a program in their home language instead of english, which is possibly
their 2nd or third language. Another potentially useful application for the
different translations would actually be to have an option of using two
translations symultaneously. Let me illustrate this idea - If I as a doctor
have a consultation with a patient who speaks only zulu, and I cannot find a
translator, it would be of some help if my screen for physical examination has
the Zulu and English phrases, then I can try and communicate with the patient.
This is not a necessity, it’s just a nice-to-have; I don’t know how feasible
that is programming wise.

That’s all for now. Let me know what needs to be translated in the demo and how
to go about it, and I’ll give the Afrikaans a shot!

Thanks

– Angela Smith

drbowen wrote on Monday, April 13, 2009:

Does this mean that we could potentially get rid of "globals.php"?

Sam Bowen, MD

drbowen wrote on Monday, April 13, 2009:

Uh…

I also need Chinese.

Sam Bowen, MD

sunsetsystems wrote on Monday, April 13, 2009:

We can get rid of the need for a normal installation to be concerned with globals.php.  I assume that’s what you mean.  The file itself will probably continue to exist for experimental/development reasons if nothing else.

Rod
www.sunsetsystems.com

bradymiller wrote on Tuesday, April 14, 2009:

hey,

Converting settings from hard-coding in globals.php to $_SESSION variables is not as straightforward as I thought it was gonna be.  To do this to the language required modifcation of multiple files.  Here’s what I modified:
openemr/setup.php   - install the translations tables during installation
openemr/interface/globals.php  - removed id hard coding (added config settings)
openemr/interface/language/lang.info.html - updated documentation
openemr/interface/login/login.php - language selection menu
openemr/interface/patient_file/encounter/coding.php - dealt with dutch hard-coding
openemr/library/auth.inc - set up the language $_SESSION variable
openemr/library/date_functions.php - use $_SESSION variable, in future use language names.
openemr/library/translation.inc.php - fix to use sessions variable and optimize xl() function if language is english
openemr/library/classes/Controller.class.php - dealt with dutch hard-coding
openemr/library/plugins/function.xl.php - smarty xl() fix to use session variable

The language is no longer hard-coded in globals.php (language menu at login is automatically figured out by what in the lang_languages table), although I did put optional settings in there (these can easily be migrated to the adminstration interface in future).  Here’s the new globals.php settings (list of languages not needed; likely remove at some point):
// Language Control Section
//
//  Current supported languages:
//   English
//   Swedish
//   Spanish
//   German
//   Dutch
//   Hebrew
//   French
//   Norwegian
//
//  ‘language_menu_login’ toggle
//    -If set to true then will allow language selection on login
//    -If set to false then will not show menu in login and will use default (see below)
$GLOBALS[‘language_menu_login’] = true;
//
//  ‘language_menu_all’ toggle
//    -If set to true then show all languages in login menu
//    -If set to false then only show chosen (see below) languages in login menu
$GLOBALS[‘language_menu_showall’] = true;
//
//  ‘language_menu_show’ array
//    -ONLY pertinent if above ‘language_menu_all’ toggle is set to false
//    -Displays these chosen languages in the login menu
$GLOBALS[‘language_menu_show’] = array(‘English’,‘Swedish’);
//
//  ‘language_default’
//    -Sets the default language
//    -If login menu is on, then it will be the ‘Default’ choice in menu
//    -If login menu is off, then it will choose this language
$GLOBALS[‘language_default’] = “English”;

The other key thing is in the setup.php installation script it now creates the language tables (currently have definitions for dutch, spanish, swedish, and norwegian) created from our Google Docs collaborative spreadsheet pipeline.  For details on pipeline check here:
http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/contrib/util/language_translations/README?revision=1.3&view=markup

I restart the cvs demo, so you can see how it works there:
http://oemr.org/modules/wiwimod/index.php?page=DemoCVS

Hopefully this will get one step closer to eliminating the globals.php file.

Sam,
If you have any people out interested in translating, it’s very easy to make new languages I can give them access to the language spreadsheet at google docs.

-brady

bradymiller wrote on Tuesday, April 14, 2009:

Sam,
     Regarding chinese, the Google Docs translation spreadsheet is encoded in UTF8 as is the OpenEMR language tables, so in theory it should work.  Just got to find a translator.
-brady

bradymiller wrote on Tuesday, April 14, 2009:

more regarding chinese,

I’ll see if he’s up for helping with translations.  Still a little more work to do before chinese would be completely functional, since would likely require entire database inclduing php-gacl in UTF8.  See this message regarding database changes that likely need to happen:
https://sourceforge.net/forum/forum.php?thread_id=3208277&forum_id=202506

That being said, the translations should hopefully show up; they would just be limited on inputting some data in chinese (especially user login names because of phpgacl limitation)

I also have to put a disclaimer here about what I’m talking about because I’m basically figuring out this stuff as I go.

-brady

blankev wrote on Friday, April 17, 2009:

Having been on the new CVS demo login screen

======================================
I restart the cvs demo, so you can see how it works there:

http://oemr.org/modules/wiwimod/index.php?page=DemoCVS

Hopefully this will get one step closer to eliminating the globals.php file.

I wonder if it is wise for a no developer like me to get this in OpenEMR Version 3.0.0 and/or Version 3.0.1?

Or should I try to keep my enthusiasm under control and wait for a next official release?

If it is possible I would suggest to get the Language choice in the right upper corner. And, if possible, can the DEFAULT be left to be the same as last login (If I login with Dutch, almost sure I want next time again to login with Dutch, only for fun purpose, I love to see the differences in Language use)?
Or is this just a stupid non-programmers idea?

Pimm

aperezcrespo wrote on Friday, April 17, 2009:

Hi folks

   Little item.  Accented character don’t look right.

But I do like it!!!

Thanks

aperezcrespo wrote on Friday, April 17, 2009:

Oh and by the way.

try it in spanish and you will notice the seach area just below popups looks really off.

But I still like it…

Thanks Again

bradymiller wrote on Friday, April 17, 2009:

ajperezcrespo,
  The accented characters issue has to do with the encoding.  In firefox, you should change in menu to ‘View’->‘Character Encoding’->Western to see it correctly.  Windows explorer actually shows up fine by default.  However, starting this weekend, it will actually flip-flop.  Since we’re adding chinese characters I’m changing the characters to UTF8 encoding, so will work fine by default in Firefox, but not explorer.  Definitely some work to do in OpenEMR to ensure optimal encoding (having chinese has at least forced a decision to UTF8, so have a starting point).

pimm,
  I’d consider with all the changes, the current cvs to be rather unstable, so wouldn’t place these changes on your production server.  If you want to get rid of the annoying dutch_pc hard coding stuff though, it’d be safe to substitute following two files from cvs:

http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/interface/patient_file/encounter/coding.php?revision=1.12&view=markup
http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/library/classes/Controller.class.php?r1=1.5&r2=1.6

Also, the mysql translations dumpfiles will continue to work with the 3.0.1.  So the translations will continue to improve in 3.0.1.

-brady

bradymiller wrote on Friday, April 17, 2009:

Realized i didn’t answer everything…

ajperezcrespo,
The search area below popups is because the translator put in the longer entry of ‘Fecha de nacimiento’ as translation for the ‘DOB’ english constant.  This throws off spacing.  If you can I’d change that to a shorter abbreviation in the translation spreadsheet.  I’m planning to update the translations from the spreadsheet every 1-2 weeks to allow testing/fixing for these issues (it only takes me about 10 minutes to produce it, so not much of a pain). 

pimm,
Once we get away from the global.php to havings the config settings in the mysql database, then we could allow the option of saving last setting (basically copy the session variable wehn logging out).  Right now in the cvs version, you can set a default language in the globals.php file.  Note we’ll use the language name in the future, no more pesky id numbers or codes.

there are more details regarding the translation effort in this thread:
https://sourceforge.net/forum/forum.php?thread_id=3130655&forum_id=202506

In two weeks we’ve gone from 173 definitions to over 3000, which is pretty amazing.

-brady

blankev wrote on Friday, April 17, 2009:

Brady ,

thank you for all those Language translations solutions! Great work. I will continue to make changes in the Google spreadsheet whenever I see a need in translations CVS Demo.

I assume you make Changes in Demo Language Version CVS known in your great Language OpenEMR News letter !!!!!!!!!!!!!!!!

======For all interested in prescriptions PLEASE READ and let me know where to go?====

QUESTION:

Who was/is in charge of the development of Prescriptions:

I got the impression that there are two roads to travel that lead to print prescription. Both won’t work with the same print options. CAMOS and Rx from the radio/tree buttons. Did I overlook something or should I dive into old Help/Users/Developers Forums?

I filled my Drug Dispensary and can use the screen to change available amounts etc.

Except for a few minor changes in the lay-out of recipe print I would like to pint more than one prescription on the same piece of A6 paper without leaving any orphan lines when printing more than several prescriptions on the same piece of paper. Normally I would use the A6 type of paper and can print up to four prescriptions on my momentary used Q uickB ooks receipt prints. (Without complaints of Dispensary personel about need for reading glasses.  :wink:

Pimm

Pimm

blankev wrote on Friday, April 17, 2009:

CAVE!!!!!!!!!

When changing your localhost computer with globals.php into Language = "5" the program will start to generate programs affiliated with OpeEPR, the Dutch Psychiatry affiliated program.

The Dutch translated OpenEMR inlog screen at the Demo CVS version is specially prepared to avoid this problem!

If you want to use Dutch on a local machine, please ask for special instructions.

Need to change the table CSV import file of lang-languages the next two fields:

lang-id into anything but "5"

lang_code into any two lower case letters, anything but "du"

and you should be on the go, without all psychiatric changes.

Be sure to change the import Language_Definition file with the appropriate identification fields.

Pimm

bradymiller wrote on Saturday, April 18, 2009:

hey,

To fix this issue replace these two files from cvs (will work as long as version 2.9.0 or greater):

http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/library/classes/Controller.class.php?revision=1.6

http://openemr.cvs.sourceforge.net/viewvc/openemr/openemr/interface/patient_file/encounter/coding.php?revision=1.12

-brady