drbowen wrote on Monday, September 19, 2005:
It seems per our previous agreement we are due (over due?) for the next release.
What do you guys think of wrapping up details for a new release (freeze new features until the the new release is published)?
Can we name the release just OpenEMR (instead of OpenEMR tarball). Currently the "OpenEMR for Mandrake" is listed first because of alphabetization when it is fact hopelessly out of date.
nahoj1976 wrote on Monday, September 19, 2005:
I would like to know what to do with the language-support. I have been working with this for quite some weeks and I would like to get some kind of feed-back and some hint if this is a method that is accepted or not. If this method (using include-files for each file used) should be used we need to decide before making an upgrade since an upgrade will force redoing everything again.
The alternative is to use the same syntax as in sql-ledger having one large array and a perl-script (which just the same could be a php-script) to put the right language texts in place.
In any case: we need to decide what way to go before next upgrade, or one needs to start all over again which I don’t think is very intelligent!
Best regards,
/Johan
andres_paglayan wrote on Monday, September 19, 2005:
HI Johan,
I think you posted a link, could you please re send it.
I’ll be happy to check your translation modules this week.
Still I think they should be included in the repository after the release.
Andres.
nahoj1976 wrote on Tuesday, September 20, 2005:
I will gladly send the link to anyone interested. But I don’t like to post it here on the forum (It’s not my web; I just borrow place from my brother) 
I send you a personal message, Andres.
nahoj1976 wrote on Tuesday, September 20, 2005:
About the language-support:
There is a file in /doc that describes what files have been changed
In native code there is support for english and swedish. What language to use defines in the file lang.php
/Johan
drbowen wrote on Tuesday, September 20, 2005:
Dear Johan,
I don’t think a new release is going to force you “to start over”. The changes you have made are still there. If I understand correctly how you are making these changes.
A practitioner or practice who wants to enable your language support will make a configuration change in lang.php. Otherwise the default language will stilll apply.
In wrapping up a release, we just stop introducing new features, make sure that the new changes don’t adversely affect existing production installations, and make sure installation is still working as expected.
In this way the practices who want to upgrade and take advantage of the most recent improvements can do so and new clients get a fresh version.
Fresh, semi-working code is still in the release, just not enabled. That way it does not adversely affect production installations.
So your changes are most welcome. I don’t think you will have to “start over.”
I think I like the current approach that you have proposed. Big monolithic files may be read repetively, a lot, in PHP code. This can have a negative drag on performance. So if my vote counts, I would prefer not making just one big PERLish module.
Sam Bowen, MD
nahoj1976 wrote on Tuesday, September 20, 2005:
Dear Sam
I understand your points. I have not been through the whole system yet, but so far about 75 - 90% of the files in the directories I’ve been through have been changed. That means that nearly every file need changing in the same way as sql-ledger uses the same text-array for every single file in the system.
But offcause for the single practitioner in the future it will only be needed to change the file lang.php in order to decide what language to use.
There are a few things to decide, that might be important for first of all the developers:
1) Using one large or many small files?
- I tend to think many small files are better. Especially since one in an easy way can add more modules and let the needed language-files come with the module in an easy way.
2) Using arrays or single variables.
- I don’t know enough about php-coding to know if this makes any difference for memory-usage or speed. I must say that I am not sure that it even makes a difference using constants or variables in php. (In c-code it would be better to use constants since these steal less memory and makes faster programs but in an interpreted language like php I don’t know)
3) Naming of the variables.
- So far I mostly have used simple naming in order to not get conflicts with existing variables and make fast programming. But the readability is more difficult using this naming. It might be worth working out a better naming but it will take more resources too.
Best regards,
/Johan