This has to do with the way that unicode process rules about mixing LTR and RTL text. You can override the default behaviour by explicitly using special characters that indicate an intention to directly embed 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 an embedded Left-To-Right character (U+202A) before the string and follows it with a Pop-Directional-Formatting (U+202C) character. The latter removes the embedded directional formatting cue and returns the text direction to whatever it was in the previous context. The returned string, therefore, is safe to use in either an RTL or LTR context.
The rules for parsing LTR and RTL text in various contexts are extensive and complex. For reference you can find the bidirectional algorithm specification here. Certain characters are classified as "weak" or "strong" in terms of their affinity for LTR or RTL contexts. Things like /
and -
are weak so you have to be explicit when mixing them about which text direction and layout you wish these characters to respect.