This is due to how unicode rules handle mixing LTR and RTL text. You can override the default behavior by explicitly using special characters that indicate the intention to directly insert RTL or LTR text:
private const char LTR_EMBED = '\u202A'; private const char POP_DIRECTIONAL = '\u202C'; private string ForceLTR(string inputStr) { return LTR_EMBED + inputStr + POP_DIRECTIONAL; } private void Form1_Load(object sender, EventArgs e) { string followUpFormula = "FIF"; string renewAbbreviation = "ุน.ุช"; string abbreviation = ForceLTR(followUpFormula + "-" + renewAbbreviation); textBox1.Text = 10 + "/" + abbreviation + "/" + 2016; }
This places the embedded character from left to right (U + 202A) in front of the line and follows it using the Pop-Directional-Formatting character (U + 202C). The latter removes the built-in directional formatting hint and returns the direction of the text to what it was in the previous context. Thus, the returned string is safe to use in the context of RTL or LTR.
The parsing rules for LTR and RTL in various contexts are extensive and complex. For reference, you can find the specification of the bidirectional algorithm here . Certain characters are classified as โweakโ or โstrongโ in terms of their proximity to LTR or RTL contexts. Things like / and - are weak, so you have to be explicit when mixing them regarding the direction of the text and layout you like for these characters.
J ... source share