Short calendar day names are always in english

We think there are a few ways of fixing this issue :
1. Use in the name of the days in the calendar the short names of the days (3 letter Mon,Tue..) In this case any language can use the letters that ar used to display short day names.
* + This is a really small change
* - Changes the look and feel

1. Display only the first letter of the short name of the day
   • • Small change
   • • Doesn't change the look and feel
   • • If some language doesnt use the first letter as day identifier this solution doesnt work
       *
2. Change the calendar date/time names instead of sending a "constant" use the setlocale functions in php
   • • Bigger project , locale language needs to be insalled in the server for php to get the translations
   • • No need to add translations to any date/time constant

We would be happy to hear your thoughts about this issue

When those constants are defined, they are passed through the translation engine.

However the current version doesn't not provide appropriate context (can't distinguish between S/S for saturday sunday, T/T for Tuesday/Thursday

If we bring in this commit, then the appropriate transslation definition can be added for each language

https://github.com/yehster/openemr/commit/4f36f6cf90373d8b33b323c67341452a06c63f64

Incidentally, I put together some tools for managing translations as a CSV file which IPPF is using to manage their translations, that you might find useful.

https://github.com/ippf-dev/openemr/tree/ippf-merge/ippf/translation

Hi,
Agree with Kevin's solution. Note that the stuff within the {{ }} function as a way to differentiate constants and also as a comment (that the translators sees in the translation spreadsheet).
-brady

Looks great...in which version we will be able to use that code?

The context tags for short day names has been pushed to the HEAD of the official master branch.

That's great news, one question i see this code in interface/main/calendar/modules/PostCalendar/pnlang/eng/global.php

define('_CALMONDAYSHORT', 'M');
define('_CALTUESDAYSHORT', 'T');
define('_CALWEDNESDAYSHORT', 'W');
define('_CALTHURSDAYSHORT', 'T');
define('_CALFRIDAYSHORT', 'F');
define('_CALSATURDAYSHORT', 'S');
define('_CALSUNDAYSHORT', 'S');

This constanst shoud stay as constanst or its better to be consistent with the other define?

The best solution would be to figure out if the redundant definitions can be removed from one of the files.

If not, then the constants in global.php should be made consistent with the update made in calendar.php.

Note Kevin's solution was brought into the codebase:
https://github.com/openemr/openemr/commit/61778900eb218055456b5a06f869b0123d91599f
(and these new constants are in the translation spreadsheet)

The commit does not work for me; for this to work, need to replace the constants in global.php

define('_CALMONDAYSHORT', xl('M{{Monday}}') );
define('_CALTUESDAYSHORT', xl('T{{Tuesday}}') );
define('_CALWEDNESDAYSHORT', xl ('W{{Wednesday}}') );
define('_CALTHURSDAYSHORT', xl ('T{{Thursday}}') );
define('_CALFRIDAYSHORT', xl( 'F{{Friday}}') );
define('_CALSATURDAYSHORT', xl ('S{{Saturday}}') );
define('_CALSUNDAYSHORT',xl('S{{Sunday}}') );

Sharon's observation that the constants are defined in both

eng/calendar.php and eng/globals.php

is consistent with my original commit not working. Either the ones in calendar.php are never used, or the ones in globals.php overwrite them.

If deleting the defines in globals.php works, then it's probably best to keep the one copy in calendar.php (near the other related constants...)

Regardless, there should be only one set of definitions.

Hi,

If this becomes complicated (for example, if deleting them in globals.php doesn't work), wouldn't it be ok to just change them in both places?

-brady

Actually,

After looking at these scripts, my guess is that these things may be used in different places. May be safer just to change them in both places.

-brady

Verified that adding the translation functions in the global.php does indeed impact the interface element in question and pushed the appropriate code to the master repo.

https://sourceforge.net/p/openemr/code/ci/53f10193552068123fbc9bfba6b5856767cd4d3d/

Leaving them in both places, but as an academic exercise, tried various combinations to try and understand exactly how the files get included.

calendar.php does not seem to be involved at all in rendering this screen. Having the constants only defined in calendar.php results in missing definitions. (_CALSHORT... is displayed in that case)

Marked as closed-fixed.