Ideally strings not shown to the user would also not be wrapped in pht(...) at all to avoid wasting translator's time. This is contrary to the documentation inherited from old upstream at https://we.phorge.it/book/contrib/article/internationalization/, though,

In T15903#18780, @pppery wrote:

Ideally strings not shown to the user would also not be wrapped in pht(...) at all to avoid wasting translator's time.

Notice that the error message here is expected to be shown to the user (in their own language) so this isn't the case here.

pht() also does some escaping, formatting, and other safety related stuff, and it's more convenient to use the same methods for all human-readable messages rather then "user-readable" vs "admin-readable".

But yes, the logs should not show up in the language of the user that triggered the exception - they should either stay proto-English, or translated to some selected system level language.

From a technical POV, I think we can't do that right now because pht() returns a plain string. We talked about making pht() return some kind of a lazy string-like object, so that translations (and formatting) can be avoided for strings that are not shown, and this might be another good use-case for that. I can't find the old discussion right now.

But also, I'd expect the log to come with a stacktrace that points to a useful line in the code?

In T15903#18783, @avivey wrote:

pht() also does some escaping, formatting, and other safety related stuff

https://we.phorge.it/source/arcanist/browse/master/src/internationalization/pht.php calling https://we.phorge.it/source/arcanist/browse/master/src/internationalization/PhutilTranslator.php indeed handles variants (plural, gender, number localization) plus checking for things like PhutilSafeHTML and doing phutil_escape_html.

and it's more convenient to use the same methods for all human-readable messages rather then "user-readable" vs "admin-readable".

I'd personally disagree with Translate all human-readable text, even exceptions and error messages. on https://we.phorge.it/book/contrib/article/internationalization/ when it comes to exceptions / code-related bugs.
Feedback on user input like Projects must have a name. should be translatable.
Output on code issues like Map returned by "newPagingMapFromCursorObject()" in class "ManiphestTaskQuery" omits required key aren't helpful for end users.
And there's the blurry on-the-verge class after Conduit use with error output usually due to invalid user input but sometimes bugs in the code.

Question is how to differentiate such string class, not even technically but first semantically.
Maybe too hard to do and not worth the hassle.

From a technical POV, I think we can't do that right now because pht() returns a plain string. We talked about making pht() return some kind of a lazy string-like object, so that translations (and formatting) can be avoided for strings that are not shown, and this might be another good use-case for that.

My very poor workaround would be to output both the translated (if existing) and non-translated string.

But also, I'd expect the log to come with a stacktrace that points to a useful line in the code?

It does, still having the error message in a language you (Phorge admin / developer) can understand is helpful to quickly judge the severity of the issue.