JLIB_FILESYSTEM_ERROR_WRITE_STREAMS="%1$s(%2$s): %3$s"

I am really not a fan of strings like this unless they are accompanied by a comment explaining the meaning of %1, %2, %3

The only reason that we have this type of string is so that a translator can change the order of parts if needed in their language but without any reference it might as well just be hardcoded

Crowdin does not show comments.

"%1$s(%2$s): %3$s" WTF?! haha

Strings with hardcoded class::method are changed to the method is injected into the string.

The whole point (I made) about refactoring these messages was to REMOVE any reference to the class or method.

Job Bloggs DOESNT CARE what code is running and raising the messages - he cares about the message.

The app should never be leaking Class Names and Method Names in error messages

Can you image going to Facebook.com and getting a message "Sorry, FbSnoopOnWebcam::takeNudeSnapshot could not write to Amazon S3" or on amazon.com getting a message "AmazonS3SavePersonalAnalytics::toDevelopersLaptopDesktop could not save file"..... No other user centric website would use PHP Class names or Method names in its error messages.

I know those strings aren't nice. But then they weren't nice before either.
The example above was JFile: :write(%1$s): %2$s". All I did was replacing JFile: :write with an injected method.

I fully agree that a string like "Failed to write file %1$s. Error was %2$s" would be more helpful. The classname isn't really needed.
My intention with this PR was just to get rid of unneeded strings and replace hardcoded class::method names. However if someone wants to suggest a better string, I'm happy to include it.

@PhilETaylor Just for your information: This PRs weren't motivated by any of your inputs. I wouldn't know of those. The input came from a translator who asked if the class and method names should be translated, and if not why they are part of the strings.
Which doesn't mean your thoughts would be wrong or anything - I just didn't know them before ?

I have tested this item ✅ successfully on 6e8441b

I have tested this item ✅ successfully on 6e8441b

RTC

@wilsonge @HLeithner
Asked JSST about this

Are these error messages or only log entries?

I think there are errors

EDIT: Did not test all but some are definitely logs

Ok, I got informed that the 'jerror' category get displayed to the user. So changing this to user friendly strings would be good. Can you do this @Bakual or is it beyond the scope of this PR?

We need two separate messages. A log message that is added - which will have method information added (and doesn't have the jerror category. Secondly a message enqueued to the application with a nice friendly message to the user. The problem here is we want one message to do both things.

It's beyond the intention of this PR to change the meaning of the strings. I just wanted to get rid of hardcoded class names.

We need two separate messages. A log message that is added - which will have method information added (and doesn't have the jerror category. Secondly a message enqueued to the application with a nice friendly message to the user. The problem here is we want one message to do both things.

Agree on this. But it means that we have to do that all over J., not only for the strings concerned here. And evidently add new strings aimed at user.

Definitively out of scope of this PR

Merged as the messages aren't worse than they are now. But this does need cleaning up

I've created a new issue #31846 for the discussed topic.