Complete question from the July 27th Developer's Forum: Have you given any thoughts on i18n of the UI? How easy or difficult it would be to translate the UI to other languages, especially, right-to-left languages?
Ease of localization is absolutely a concern. It is not currently implemented in the platform, but it will be. We’re happy to discuss options and to work with others to make this happen.
Should we start be creating an “internationalization SIG”? That way the developers and designers would have a pool of people to call on that have interest and expertise in this area.
There are library systems / consortia that cross localisation and internationalisation boundaries. i18n and l10n can’t be a platform configuration, it has to be driven by the preferences of a particular end-user. Perhaps this could be done by respecting the HTTP Accept-Language header.
Declaimer: I am not a native of a right-to-left language or culture. But I am not inexperienced in Arabic.
To support right-to-left languages and cultures, the user experience designs need to be careful to distinguish elements that truly are left / right of the page, versus those elements that are just left / right of the page because left-to-right languages and cultures expect them to be like that.
A classic example of the later point are navigation bars. For horizontal navigation bars, the order of the links need to be reversed. First link, which appears on the left for left-to-right languages / cultures, would need to appear on the right.
Another example is vertical navigation bars. Right-to-left cultures actually expect vertical navigations bars to be on the right of the page, not on the left.
I’ve seen this as left / right versus reading-order / anti-reading-order.
@jim.nicholls Thank you for your input! Language support, support of different alphabets, RTL support and even cultural differences to consider are things that we have been thinking about to make sure Folio becomes a system useful for a global audience. So we’re trying to think this into the platform from the beginning; Making sure all interface labels are placed in localized strings; Making sure the layout will work for people who use RTL. There are also a lot of usability concerns to consider, like the fact that different alphabets behave differently when placed in the same layout, so the layout needs to adjust when a different font is being used, etc. It’s super important to us that the system works well for everyone. I’ll mention this briefly in my first presentation of the design thoughts in the OLF WebEx on the 24th of this month, and we will be looking at it much more in depth as we go along.
It was me who raised this question on the Dev Forum webinar. I don’t speak Arabic, but have worked with many clients in the Middle East region where systems without Arabic interface have very few takers. I just hope that this aspect is not completely ignored at this stage, before it’s too late to fix.
Customizing a platform like DSpace for RTL layout has been a real pain. Whereas CMS platforms generally have better support for i18n. For example, I like the flexibility of Drupal in making multi-lingual sites. It not only has an intuitive web-based interface for translation of UI labels but also supports context-sensitive CSS styling. For example, it allows having css files named ‘*-rtl.css’ (e.g. ‘style-rtl.css’) which will be applied only for languages with RTL layouts – automatically. We can probably take some inspiration from such conventions.
Filip mentioned the User Interface and User Experience Principles forum next week. Registration is now open for that forum. You can watch the archived recording of the webinar.
Good points, @saiful! We are very aware that we need to think about this from day one, and we are currently working with RTL and localization as some of the first things in the UI code.