I agree. I work a lot with GitHub repos and often I end up cloning locally projects in all sorts of languages (either the project was created by some user from a country with a RTL language, or because of i18n there will be some folders and files in RTL languages). Besides, I work with RTL languages myself.Petr Solin wrote: ↑20 Dec 2017, 22:35But I don't think it is a good idea to not support RTL names in general.
Unicode was a great step forward, and it has already become well grounded in most OSs and apps.
Also, the RTL support doesn't affect only paths and file names, it also affects plugins (parameters, arguments, input and output). So I agree 100% that Unicode awareness in AS needs to be properly implemented; if not, unexpected result might ensue from interactions with the environment and other tools. But I do understand that it's going to be a major work, requiring rewriting a great deal of code (and possibly tweaking every function dealing with strings).
Surely, adding full RTL support is too huge a task, but this was to say that just handling strings visualization is complex. And if you accept paths and filenames with micxed RTL and LTR, you must support basic operations with these — think of the Rename plugin, for example. How is it going to handle RegExe renaming for multiple files with mixed directions?
Search operations bring another level of coplexity. In Hebrew and Arabic all vowels should be stripped out from the search terms and the searched items. If AS will support mixed direction filenames and paths, then this might affect also search and filter operations.
I recently peeked at some Python libraries for Arabic that prof. طه زروقي created to handle these problems:
https://github.com/linuxscout
... he went to great lengths to handle the cases mentioned above — ie: stripping vowels for searching and indexing, etc. — and these libraries are well known. The problem is that they are language specific, and my guess is that there similar libraries for each specific language.
Just think of the problem of asciibetical sorting... There are lots of Unicode libraries out there that provide (or promise) locale support for ascii- (well, Unicode really) sorting, as every locale has a different order for its alphabet (eg, letters with diacritics or accents are grouped togehter). But not many such libraries are able to handle sorting semitic and Asian languages (or to do it well and in an optimized way).