RTL Support: Interest Check and Offer to Help

[mumendiraneyya]

Hello!

I'm trying to help my father transition from Excel to Grist for managing his private clinic in Jordan. Excel has excellent Arabic and RTL support, and while Grist would solve many problems he faces, the lack of RTL support makes it difficult to use with Arabic text.

My questions:

1. Is RTL support on your roadmap? If so, what's the priority/timeline?
2. Would you be interested in seeing a proof-of-concept fork demonstrating RTL implementation? I could create a minimal prototype to help assess the scope of work needed.
3. If I create such a prototype for my father's use, would you be open to discussing it? I'd love to understand the right architectural approach before investing significant effort.

My goal: I want to eventually contribute proper RTL support and Arabic localization to Grist, but I'd like to start with a small proof-of-concept to:

• Understand how complex the implementation would be
• Get feedback on the right places to make changes
• Ensure any future contributions align with your architecture and standards

I'm not asking you to merge anything immediately or maintain experimental code. I just want to know if you'd welcome collaboration on this feature, and if you have any guidance on where RTL logic should live in the codebase.

Thanks for creating such great software! I'm excited about the possibility of making it work well for Arabic users.

[paulfitz]

Hi @mumendiraneyya. Thanks for considering working on this! There are other people interested in forums, discord, and issues:

• A few people mention RTL on https://community.getgrist.com/t/translating-grist/2086
• Some mentions on discord, some tips on related issues https://discord.com/channels/1176642613022044301/1176642613663760456/1432806430137782344
• @manuhabitela, a developer at DINUM, has been keeping RTL in mind along the way https://github.com/gristlabs/grist-core/pull/1536#discussion_r2039926002

For sure Grist Labs would welcome RTL support. Your step 2 would be helpful. I don't think we could provide much guidance initially, since we have no experience working with RTL. If you ask questions like "I want to achieve this specific change in this specific part of the UI" with a mock-up of what you'd like, we could perhaps provide tips on how to achieve that effect.

[mumendiraneyya]

Hello @paulfitz.

Your step 2 would be helpful. I don't think we could provide much guidance initially, since we have no experience working with RTL. If you ask questions like "I want to achieve this specific change in this specific part of the UI" with a mock-up of what you'd like, we could perhaps provide tips on how to achieve that effect.

Thanks for being open to exploring RTL support. I want to be transparent about my approach, which seems to agree partially with your approach in the above quote.

I plan to create a functional prototype fork using LLM assistance to demonstrate how RTL features could work for Arabic users (specifically to help my dad use Grist). The implementation in this prototype will likely be messy and touch many files—it's meant purely as a working demonstration to help me communicate the right functionality, not as code ready for merging.

Once we've tested the prototype and it checks out and you've reviewed the functionality, I'd appreciate guidance on how to properly implement the approved features myself, including:

• Whether changes should go in core vs. Desktop repository
• Any architectural or style considerations I should know about

My first prototype will be a simple RTL inversion of the table page/client area (possibly the entire interface, without translations initially). I'll share this for feedback before proceeding further.

Does this approach work for you?

(For context: I've done similar prototype-driven work on other projects like codemirror-vim and Zettlr, where rapid prototyping helped clarify intended functionality before proper implementation.)

Kind regards, Orwa

[paulfitz]

Whether changes should go in core vs. Desktop repository

All changes are likely to go to core. The desktop is a wrapper around core, and has almost no UI code of its own. You (and the LLM) will make most progress if you run grist core built from source:

https://github.com/gristlabs/grist-core/?tab=readme-ov-file#building-from-source

You can periodically make desktop builds of that by replacing the "core" directory in grist-desktop to point to your new work.

A messy bot-assisted prototype step sounds fine. Thanks Orwa! And good luck.