Hi,
I'm getting non translated emails (although Strings are translated).

Solution
Replace components/com_uddeim/uddeim.php line 32-33:
[code:1]
if (file_exists($pathtoadmin.'/language/'.$mosConfig_lang.'.php')) {
include($pathtoadmin.'/language/'.$mosConfig_lang.'.php');
[/code:1]

With:
[code:1]
if (file_exists($pathtoadmin.'/language/'.$GLOBALS.'.php')) {
include($pathtoadmin.'/language/'.$GLOBALS.'.php');
[/code:1]
(notice the $GLOBALS)

That is very strange since it works on my sites?!? $mosConfig_lang should always be available.

I suggest to add "$mosConfig_lang" to the "global" statement at the very beginning of uddeim.php and admin.uddeim.php. It does the same and I when I change the code in future again to have a native J!1.5 component it is easier to find


btw: fixed in trunk now, thanks

Post edited by: slabbi, at: 2007/12/21 09:14

mtk wrote:

Hi,
I'm getting non translated emails (although Strings are translated).

I checked the code again and again and this CAN'T be the solution. Either all strings are translated or none.

So when the strings are translated (I assume that hebrew is very easiy to recogize in the frontend ) could you check if the following language strings are really translated in your language file:

_UDDEIM_EMN_FORGETMENOT
_UDDEIM_EMN_BODY_WITHMESSAGE
_UDDEIM_EMN_BODY_NOMESSAGE

When these strings are translated I am at a loss with that. Could you do some more investiations please why these strings are taken from the wrong from when the language file is only loaded once at the beginning of the main file?

Btw: I plan to support html notification messages in uddeIM. But only globally switchable for all users by the admin. Any concerns regarding this?

slabbi wrote:

So when the strings are translated (I assume that hebrew is very easiy to recogize in the frontend ) could you check if the following language strings are really translated in your language file:

_UDDEIM_EMN_FORGETMENOT
_UDDEIM_EMN_BODY_WITHMESSAGE
_UDDEIM_EMN_BODY_NOMESSAGE

These are not translated at the front-end (not even shown). These are part of a back process that translates them and send the email notification.
We have to change the code to test if these are translated prior to sending.
I had this same problem with AEC Plugin, & this was the same solution that worked:
globalnerd.org/index.php?option=com_fireboard&func=view&Itemid=88&catid=11&id=4546#4546


slabbi wrote:

Btw: I plan to support html notification messages in uddeIM. But only globally switchable for all users by the admin. Any concerns regarding this?

If you're asking in regards to Hebrew, the no concerns as long as you don't add any hard-coded Styling into it. (left align/float etc)

Post edited by: mtk, at: 2007/12/21 10:59

In AEC the correct solution would be:
$mainframe->getCfg( 'lang' );
and not
$mainframe->getCfg( 'mosConfig_lang' )
So the result is always empty and the conditional cluse will always be false because of the wrong path which let AEC load the default language file.

I am not a fan using globals (though uddeIM does because of historical reasons, which will be removed in future versions).

In uddeIM the language file is loaded only once at the very beginning and then all language strings should be avaiable (or none). So either all text is in hebrew or all in english (I do not know how uddeIM could access the english text without loading the file).