User tests: Successful: Unsuccessful:
Generally, I would suggest we should not hardcode class and method names into Exception messages and instead dynamically resolve those at runtime through various available resources (i.e. get_class($this)
or __METHOD__
. This PR changes Exception messages that do not have language keys to dynamically set these values over hardcoding them. One of the benefits of this, especially with the namespacing efforts, is that the message text doesn't have to be changed as the class is renamed (the right name will always resolve).
As well, some minor improvements are made to a few messages to be more useful in debugging (primarily affects the Feed package).
Code review
Status | New | ⇒ | Pending |
Category | ⇒ | Libraries |
Generally Exception messages are intended to be developer resources to help with debugging code and should rarely be shown directly to the end user. So for this reason the rule of thumb I would use is no, they shouldn't be translated (especially as translations may lose context of the intended error message). Of course we don't do an adequate level of error handling in the code so a lot of these messages do end up reaching the end user, but that's another discussion.
Thanks for the explanation
Labels |
Added:
?
|
I have tested this item
Good by me on code review
I have tested this item
Code review
Status | Pending | ⇒ | Ready to Commit |
Ready to Commit after two successful tests.
Thanks for Tests.
Status | Ready to Commit | ⇒ | Fixed in Code Base |
Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2017-12-21 00:09:28 |
Closed_By | ⇒ | mbabker | |
Labels |
Added:
?
|
Would it be better if these were translatable? Just asking to learn.