View Issue Details

IDProjectCategoryView StatusLast Update
0005853OXID eShop (all versions)4.06. Language and translationspublic2023-12-06 13:32
ReporterBergfreunde Assigned To 
PrioritynormalSeverityminorReproducibilityalways
Status confirmedResolutionopen 
OSWindowsOS Version7 
Product Version4.7.4 / 5.0.4 revision 57063 
Summary0005853: Translation of non language-parameter
DescriptionOXID is trying to translate words, which are not part of the language-files, via function "$oLang->translateString".
e.g.: core/oxemail.php - line 628
$this->setRecipient( $oShop->oxshops__oxowneremail->value, $oLang->translateString("order") );

"order" is just a parameter and not a language variable, so there is no translation for it.
Additional InformationIn order to find missing language-parameters I have written a little function which logs parameter when OXID is trying to translate parameters with no translation.
TagsLanguages
ThemeAzure
BrowserAll
PHP Version5.3
Database VersionNot defined

Activities

jurate.baseviciene

2014-08-21 14:32

reporter   ~0010084

Reminder sent to: Bergfreunde


Hi,

Thank you a lot for submitting this issue, but for us is no clear which behaviors is incorrect. Please give us more details about the case?

Best regards,
Jurate

Bergfreunde

2014-08-22 08:35

reporter   ~0010085

Hi,

I mean Oxid is trying to translate the parameter "order" which is not part of the translation-files. So there is no result by $oLang->translateString("order") and that's incorrect.
There will be display no error, but the behaviour is wrong.

Sven Brunk

2023-12-06 13:32

administrator   ~0016027

Actually, translateString will just return the input string in such a case (plus eventually a warning in the log). This is why you get "order" as the recipient of order emails by default.

I guess this is a leftover of some hacky way to allow mail sorting rules on the base of sub-themes or similar.
If you put a language mapping file or a custom language file to a module or sub-theme, you could change the recipient for the order email per sub-shop this way.

Since this is a very unclean way to do such things, I will confirm this issue and have this removed. The recipient of the order emails should get a proper configuration setting instead.