Working with RTL languages

Right-to-left scripts are first-class. Daxlate detects RTL cultures by their .NET culture descriptor (Arabic ar-*, Hebrew he-*, Persian fa-*, Urdu ur-*, etc.) and flips the affected cells without any setting.

In the grid #

When a culture column belongs to an RTL script, its grid cells render with FlowDirection: RightToLeft:

• Text aligns to the right
• The text cursor moves right-to-left as you type
• Embedded Latin numbers and punctuation render with the correct bidirectional algorithm, so no surprises with phone numbers or product codes inside an Arabic caption

You don’t toggle anything. Click into the cell and type. The editor adapts automatically.

On disk #

The Power BI semantic model stores translations as plain UTF-8 strings. There’s no embedded direction marker; renderers infer it from the script. Daxlate round-trips the bytes intact, including any Unicode bidirectional control characters (LRE, RLE, PDF, LRM, RLM) the translator may have added to nail down ambiguous cases.

Working in Excel #

Excel renders RTL strings correctly as long as the system has the relevant font support, which Windows installs by default for major RTL scripts.

If your translator’s Excel shows characters in the wrong order, the issue is usually display-only: the underlying bytes are correct and will round-trip back to Daxlate intact. As long as the translator doesn’t manually reverse the characters, you’re fine.

Common pitfalls #

• Leading or trailing whitespace on RTL captions is hard to spot in any editor. What looks like the start of the string visually may be the end of the string logically. When something looks off, copy the cell contents into a hex-aware editor and check.
• Mixed-direction strings (e.g. an Arabic caption that includes a Latin product code) sometimes render differently in Excel and in Power BI. The bytes are the same in both; the difference is the renderer’s bidirectional pass. If Power BI shows what you want, trust it as the source of truth.