Hi all, I worked on the Egyptian Archaeological Database translation to Arabic (following steps that Andrea Zerbini had written down from his work on EAMENA) for Arches 3. What I recall is: Django handles translation in a way where you actually do kind of just "flip a switch." What I mean is that there is an underlying language setting, the properties of which (including directionality: request.lang.LANGUAGE_BIDI) can be acquired in templates with tags like these:
https://docs.djangoproject.com/en/3.0/topics/i18n/translation/#other-tags. I found that the automatic reordering of text that takes place in templates when you have a right-to-left language set is somewhat smart, but also quite finicky.
Most importantly, the language setting determines which set of translations will be used.
Arches doesn't expose a "switch-to-flip" to allow you to switch between languages, meaning the first thing you would need to do is either permanently change the
LANGUAGE_CODE in settings.py or change a template somewhere to add a dropdown that would allow your users to do that. You would then need to follow standard Django steps toward creating "localization files" which hold translations of all of the strings in the interfaces (individual translations for which you will provide, using something like
django rosetta which I found very easy to use).
As Dennis says, there is a lot of dynamically generated text exposed in the app, so I'll let the team speak to that, to say nothing of the data itself. In theory concept labels should be translated properly based on the language settings themselves (here's an old thread with Andrea and Alexei discuss that), but string values will not be translated (for good reason). In the EAD we ended up with two Description nodes (one in English and the other in Arabic) and I changed the report to look at the Django language settings and show only the appropriate node.
At any rate, I would recommend starting from the bottom (Django) up, and handling the special Arches cases as they come.
Adam