Improve handling of missing language strings#1696
Conversation
|
I am fine with
|
True it's not very hard, but still extra effort to grep for the missing string, when we actually have this information and can easily provide it to them for immediate action.
That does not work with our recommended dev config for $g_display_errors, as there is no stack trace displayed when errors are shown inline. The developer would need to set |
|
I thought I am using the recommended dev config, as I tried on localhost.
When using localhost, we set Should we change what is documented as recommended dev config, or should we change the settings for localhost? |
I never realized that we had a discrepancy between documentation and the actual defaulted localhost config. They should definitely be aligned, and they were when I originally introduced this feature (see #215). It appears that when @vboctor enforced halting of scripts on errors (as part of #1240, commit c816588), he changed the defaulted localhost behavior by adding IMO, DISPLAY_ERROR_INLINE is better for our internal warnings in development mode, as it is less intrusive; I would suggest to align the localhost settings to the documented values. |
527366c to
a212dc0
Compare
|
I updated Admin Guide, PHPDoc for $g_display_errors and the default developers settings. This should now be ready to merge. |
a212dc0 to
55be3e0
Compare
When an English language string is missing, MantisBT currently displays an empty string; this is not very friendly to the user, who may be missing important information (e.g. a button label). If English string is missing, display the language string itself (i.e. the $p_string parameter to lang_get()). Fixes #27241
55be3e0 to
2838272
Compare
If the error type is 300 (ERROR_LANG_STRING_NOT_FOUND), we retrieve the details (file name and line number) of the parent error. Properly handles the case when user's language is not English, by going through the error stack trace until the first lang_get() call is found. This allows printing information about the actual location of the missing string, instead of a not-so-useful reference to lang_get(). Fixes #27241
Better document the fact that $p_error can be either int or string, depending on whether a MantisBT internal or a PHP system error has been thrown. Follows discussion in https://github.com/mantisbt/mantisbt/pull/1696/files#r483995299
There were discrepancies between the PHPDoc block for $g_display_errors in config_defaults_inc.php, the defaulted developer-specific settings when the server is localhost, and the indications in the Admin Guide. Fixes #27300
2838272 to
53fba47
Compare
Fixes #27241