Same as in Drupal 7. Drupal will always record a new
t() source string dynamically when it encounters it. So this will of course work:
$string = 'Source string';
The reason we advise against this strongly is:
- Often you end up translating twice, so
t($var) and then some bunch of code and then
t($whole_string) that contains
t($var) output, etc. Can pollute the source string database.
- Often people ended up with
$string = $count . ' apples'; t($string) which could grow your locale sources indefinitely and consequently make your locale cache unusable.
- Similar problem for
t($userinput) which could also quickly become a security issue.
Telling people they should trace their code so the variable is surely not user input and does not contain dynamic portions and is surely not translated already is not a simple advice. But basically you could use dynamic strings as long as they are actually static strings.
And then when people want to publish this same code on drupal.org none of the clever dynamic static techniques you used would work since localize.drupal.org would need to parse the source code without running it, so it would need to be statically analysable or it is not translatable.
Applying that best practice regardless of who you are developing for is most consistent to document. Then you don't grow bad habits when developing in-house code and will not submit wrong patches or modules to drupal.org.