> Yes! This is exactly the type of thing I'm talking about, mirroring arrows > are needed for internationalization.
When talking about internationalization, or adapting to support different cultural conventions, it will matter whether the strings in question are static application resources that the app develop and UI localizer controls, or whether they are dynamic strings coming from the user or external sources. If static UI resources, then rather than coming up with some abstracted representation or considering some convoluted control mechanism, why not just provide an annotation on the resource to explain the intent and requirement for the localizer? * “the arrow must always point to the left, for both LTR or RTL scripts” Or * “the arrow must always point from ‘source’ to ‘output’ according to the appropriate word order of the language and direction of the script” Or whatever comments make most sense in a given situation. But if the strings are from user or external content, then the language of the UI is constant. Relevant factors might be the UI design (e.g., is there a single text control a string containing the arrow and the two entities in relation, or are the two entities and the arrow in three separate UI controls?), or perhaps whether the entire string comes from a single source vs. there is a template message string containing the arrow and two replacement parameters for the two entities that come from some other source). In other words, simply saying, “This would be useful for internationalization” is overly simplifying, and more analysis of a scenario is needed to determine the best solution. But in any case, as Markus stated, “Encoding characters that look the same but behave differently is a bad idea.” Peter
