SMF
SMF copied to clipboard
SimpleMachines
error log not all in default language
i have seen on sm.org and i assume the same in SMF 2.1, the error log reports the errors in whatever language the user has set and does not consider the forum default language. i think the errors should be logged in the default language and not the language of the user that generates the error.
i keep reading and reading this issue and i see no solution for this behavior...
@albertlast error message contains two parts, splitting them into two and logging differently and showing the first part (which is generic) via template solves this problem. Log_error is your lead actually.
Example; 8: Undefined index: (part 1) message (part 2)
Does setting INSERT INTO smf_settings VALUES ('disable_language_fallback', '1'); help at all?
This is similart to the other issues with sending notifications in whatever language the person who sent the notification was using.
In this case, the error gets logged using the person's language preferences. The same solution applies for both cases, in this particular case, before logging an error, drop the user's language preferences and load the default one, after the log was done, revert the change.
A simple fix for this .. add a veriable "error_lang" in the setting.php This the admin can handle like the default language in the settings screen ;-)
Some question around this: What is the default language(where it's defined)? Did we know that all string which exists in the user language also exists in the default language?
- exp. User got english and default is german
What would be the behavior when the default language doesn't had the string?
Something in advanced should be the "id" of the error text mention somewhere?
So when a error apear that the user/admin doesn't only hav a error message in his language also an error id which is undepend to the used language (could help the support guys):
On db error (the second entry in this pic) i would place the error code from mysql and postgres.
This is a really nasty complex issue - because you're not just dealing with SMF's languages at this point. You can potentially have more languages involved depending on the PHP locale settings and if it's a database error, you can also have whatever MySQL's own language settings are set to. (For example, certain versions of WAMPServer shipped with the default language of MySQL set to French, so you'd have PHP errors in English and MySQL errors in French.)
So even if you set the language to, say, German - there's no guarantee all the errors will be in German. Trying to set this to administrator's language is also a frightening concept - because multiple admins might have multiple languages.
I think the error code approach might be the best one - store the DB error code (with some SMF specific prefix), also assign error codes to SMF-issued loggable errors and just store the metadata needed to resolve it afterwards.
E.g. for the above example, log security_wrong and enough data to reconstitute the error message. For DB errors, you could log it as database_mysql_1050 or whatever and log the query itself as metadata to resolve it down afterwards.
The alternative is to always log it in English even if a different language is shown to the user. You're still going to get PHP level messages in whatever the server is set to but frequently that's English anyway.
Behind the error code we could place a url to smf wiki with the error code, so that user could click on this and hope that a wiki entry exists? Something like this: https://wiki.simplemachines.org/smf/Error_mysql_2201
In theory I like the idea of logging error codes and retrieving them to reconstruct the error message, but in reality it would be difficult for a number of reasons, as @Arantor rightly notes.
An alternative would be to implement some logic in log_error() similar to this code from fatal_lang_error().
https://github.com/SimpleMachines/SMF2.1/blob/c84bf54d547e3e2bc008bacac00048c8370725a5/Sources/Errors.php#L214-L229
We'd need to use conditional checks to see if $error_message was a key in $txt. If so, then we could log the value of $txt[$error_message], and fall back to logging the raw value of $error_message if not. We'd also need to go through all the current calls to log_error() in the codebase and migrate all the hardcoded error message strings into the Errors language file.
This approach wouldn't do anything about error messages generated by PHP itself or the database engine, but I don't think there is anything reasonable we can do about that anyway.
To solve this issue in his fully complexity i would say, you need to handle the error not any more as a string, sutch as you had to handle the error by some kind of class. A class where the error got all basic infos + error code + error text in orginal + error in default language etc. to implement this is to late in my eyes and since 2.0.x wokr also without this, i would like to vote to close this issue...
This is one I would not recommend for RC3.
(I'd be tempted not to address it at all, but I'm likely in the minority with that viewpoint...)
I agree, not doable for RC3, perhaps not even for final since it isn't a stopper in any way. Annoying? sure but not a stopper.
Would be tempted to mark this for a future 2.1.x release.
