We have identified an issue with the locale system in interaction with translators...
Problem/Motivation
With locale strings, you never know if something after %!@ is really a placeholder or not - and the information is completely missing, if.
This is a major user / translator experience limitation and leads to wrong translations. Also, it can't be solved in contrib.
When passing locales to a translator, tools like XLIFF could mark placeholder as untranslatable.
Without masking, translators often also translate the placeholder, leading to dysfunction.
When guessing placeholders, a string "@counts" (which is @count with s for seconds) is mis-detected as a single placeholder @counts.
As a result, tools like TMGMT can't protect placeholders, nor can we validate what comes back from translators in any kind.
Proposed resolution
Approaches are
A) The original definition adds meta on what actually a real placeholder is - leading to severe locale definition change
B) The text should escape somehow if these characters are used regularly
C) The placeholders should be delimited with brackets like @{count}
It seems, C is the most appropriate for readability.
Remaining tasks
- Reimplement the replacement function
- Update all strings with placeholders
User interface changes
Locale string placeholders are better readable / identifyable.
API changes
All strings with placeholders will change (and thus need to be retranslated).
All contrib calls with placeholders need to be changed.
Resources
None.