Creating a true RTL (right to left) UI view

system · March 7, 2016, 9:38pm

tmccormi wrote on Monday, March 07, 2016:

Matrix has recently been awarded (with MI-Squared’s help) a contract to provide OpenEMR to Israel Health Services. To that end they need to implement a true RTL interface for the project as well as beef up the Hebrew translation.

https://sourceforge.net/p/openemr/feature-requests/126/

They are interested in knowing if anyone else has RTL development ongoing.

Tony

system · March 7, 2016, 9:43pm

tmccormi wrote on Monday, March 07, 2016:

As well as any advise that the learned folks on this community have to impart about that topic

system · March 8, 2016, 6:10am

bradymiller wrote on Tuesday, March 08, 2016:

Hi,
I think(although I am not sure) that Visolve may of worked on this issue in the past.
-brady
OpenEMR

system · March 8, 2016, 12:51pm

visolveemr wrote on Tuesday, March 08, 2016:

Hello Brady

We have done some analysis on implementing persian calendar but we haven’t started to work.

Thanks
OpenEMR Customization/Support Team,
ViSolve Inc

system · March 8, 2016, 2:46pm

osverdlov wrote on Tuesday, March 08, 2016:

Hi Brady, Tony, et all,
We are working on adding the RTL languages support.
What version would do you recommend to open pull request for?

system · March 8, 2016, 5:46pm

tmccormi wrote on Tuesday, March 08, 2016:

All new work should be done against the most current development tip (master branch)
–Tony

system · March 9, 2016, 6:20am

bradymiller wrote on Wednesday, March 09, 2016:

Hi Visolve,
For some reason, I thought there was already some initial code out there(I think I was confusing this with your date internationalization code). thanks for the clarification.
-brady
OpenEMR

system · March 9, 2016, 7:38am

bradymiller wrote on Wednesday, March 09, 2016:

Hi,

Thoughts to initially support this would be placing a flag column ‘rtl’ in the lang_languages, which will store ‘1’ if the language is a rtl language. Then would create a function that collects the flag akin to the following function:

github.com

openemr/openemr/blob/master/library/translation.inc.php#L214


   }
}
// ---------------------------------------------------------------------------


// ---------------------------------
// Miscellaneous language translation functions


// Function to return the title of a language from the id
// @param integer (language id)
// return string (language title)
function getLanguageTitle($val)
{


// validate language id
   if (!empty($val)) {
        $lang_id = $val;
   } else {
        $lang_id = 1;
   }


// get language title

maybe a function like isRtl()

Then guessing there will be very significant code changes. Note there is a rather large ongoing project for improving the gui here:
https://sourceforge.net/p/openemr/discussion/202506/thread/53f41e90/

The concern is that your work may have tough time merging with this when it gets into the official codebase. Since this project is very near completion, it likely makes sense to base your work from the following branch:

(to switch to the new theme in OpenEMR, do Administration->Globals->Appearance->Theme->style_bootstrap.css)

-brady
OpenEMR

system · March 9, 2016, 9:38am

osverdlov wrote on Wednesday, March 09, 2016:

For the language detection we’ve created a function http://pastebin.com/bPD44FG3 I’d rather prefer it to use the database. How do we send you patches to SQL ? What’s a format for migration files?

DONE:

New CSS template style_sky_blue_rtl.css contains a block of all RTL changes in CSS. You can take those changes and append them to other theme CSS.
In framesets we have to add switch order of vertical frames if a language is RTL.
some HTML tags contains inline style declarations or old-style attributes such as ALIGN=LEFT. To keep backward compatibility we decided to add class or ID attributes, so we could’ve overridden them with !important in the CSS theme.

TODO:

We have problems with PDF generation and character set.
Additional and 3rd party modules that were not initialized by default will need additional attention.

system · March 9, 2016, 9:42am

osverdlov wrote on Wednesday, March 09, 2016:

We will check the Bootstrap branch.

If this is done against Bootstrap 3.x , then I would recommend to include
GitHub - morteza/bootstrap-rtl: RTL Theme for Bootstrap v3.x . This is a RTL for bootstrap, quite reliable and tested.

system · March 9, 2016, 5:30pm

tmccormi wrote on Wednesday, March 09, 2016:

Definately use the bootstrap branch and tools and also note that the next big merge after the bootstrap code will be yehster’s code removing replacing frameset with iframes and making the menu data driven (no left nav frame at all).

system · March 10, 2016, 8:31am

bradymiller wrote on Thursday, March 10, 2016:

Hi,

I wouldn’t worry too much about yehster’s code. That is still a ways off and it shouldn’t conflict with the ongoing RTL work.

-brady
OpenEMR

system · March 10, 2016, 8:43am

osverdlov wrote on Thursday, March 10, 2016:

Attached screenshot of Hebrew in the RTL -ed frameset.
If that’s possible, we’d definitely want to merge whatever we have done with RTL to the frameset (main) branch.

system · March 10, 2016, 8:44am

bradymiller wrote on Thursday, March 10, 2016:

Hi Oleg,

Your getLanguageDir() function will work fine, but do note the id’s do change on official OpenEMR releases. May be better to hard-code the title instead. At some point in future, will then transition your function to use the elements stored in the database when they exist(it’s a bit complicated to store them in the database, because to add this field, I will need to make several simultaneous changes in the google doc translation spreadsheet and the translation perl pipeline scripts).

Note there is a TCPDF library within OpenEMR which was recently added that is supposed to provide better international support:

If needed, could consider converting places that use pdf to use this. Note that in order to support internationalization several years back, we ensured that html can be produced wherever a pdf is offered.

-brady
OpenEMR

system · March 10, 2016, 10:39am

yehster wrote on Thursday, March 10, 2016:

The general approach of modifying adding the appropriate styling to a .CSS file is good.

That is much cleaner than trying to add more global settings/language flags to the database.

One potentialy problem is if both Left to Right and Right to Left are needed in the same enivironment, since the CSS theme is a single global. However, since the theme can be chosen/overriden on a per user basis, there as already a solution.

Not sure what happens to “float:left” styling when RTL is specified at the “top” of a page. That’s the big question in my mind with what happens to the iframe UI in the context of RTL.

system · March 10, 2016, 10:43am

yehster wrote on Thursday, March 10, 2016:

The next step for merge is to get the code changes into a GIT repository for review.

system · March 10, 2016, 10:52am

osverdlov wrote on Thursday, March 10, 2016:

in RTL float:left will appear at the left side. We override them with float:right

system · March 10, 2016, 10:54am

osverdlov wrote on Thursday, March 10, 2016:

What version to fork?

system · March 10, 2016, 10:55am

osverdlov wrote on Thursday, March 10, 2016:

Since we’re new in the development, can you guide us what version to fork from?

system · March 10, 2016, 12:19pm

yehster wrote on Thursday, March 10, 2016:

Fork from the official Master

It’s always best to work from the master.

Git is can manage merging changes from multiple branches should there be conflicts in the future.

When development is done well, there should be minimal conflicts.