Why fork unicode-bidi?
SimonSapin opened this issue · comments
Hi there,
I’ve been aware of the Unic project for a while, but I’ve only today realized that it includes an unic-bidi crate. Its README contains:
Initial code for this component is based on
unicode-bidi.
I also see that @behnam has contributed to unicode-bidi in the past, and is listed as “owner” on https://crates.io/crates/unicode-bidi. So why fork it? Why not find a way to collaborate and make everyone profit from the improvements?
The reason for forking to start with was the ideal of UNIC was to have everything in the monorepo to aid in keeping all of UNIC in sync.
That said, the project has lost momentum with me and @behnam being busy doing other things, so I'm not sure what the status even is right now.
I believe the ideal would be that unicode-bidi would migrate to the open-i18n organization and participate in the UNIC project, though whether that would be in-tree or out-of-tree I'm not sure.
I think the Servo team would have been very open to transferring the library to the UNIC umbrella project and/or repository. But as far as I can tell there was no communication at all.
All that's on @behnam; I've only been helping out with the UCD part of things. And at this point I'm really not sure where the project stands.
Hey @SimonSapin,
Sorry for the confusions caused here. Let me try to explain....
Since its inception, the goals I've had in mind for UNIC has been to take i18n work into another level, where there's need to access to plenty of data (from Unicode, ISO, etc) and new ways of working with encoded text and data models.
IMHO, the amount of integration needed between various data sources and API would make it harder to maintain things in separate repos, hence the need for setting up a copy of various existing repos. I have mentioned previously that, unfortunately, this comes at a cost of extra maintenance cost. But, by no means, it's been about taking over ownerships of things.
It's true that right now almost all of string-level API in unic-bidi is exactly the same as unicode-bidi. We really have not spent any time on the level yet, and when we do, I expect many changes there. From my experience in developing unicode-bidi package to version 0.3 and updating servo to use it, I realized that it would be impractical to set up a larger-sized project while maintaining API for a specific package, like unicode-bidi.
So, my personal goal for UNIC is, still, to provide as much as i18n functionality possible, out of the box, and most of it in no-std mode, so that more languages can be supported in more new environments.
I'm not sure having Servo using UNIC right now is the best option, as Servo has its own low-level models for dealing with languages, locales, etc, while UNIC does not have model for extended string types, like language-aware string and/or direction-aware string.
That, and the project being fairly inactive recently, are the main reasons I have postponed talking with your team directly about it. Anyways, if there's any specific problem caused in this path, I'll be happy to help resolving them. :)
I understand the monorepo idea, it's easy to keep the different modules in sync.
Is this project still maintained, or is it abandoned?
The project is maintained, but growing very slowly at this time. And we always welcome new contributors, specially if there's a specific need for something that you like to see happen in UNIC.
I'm going to close this issue, per comments above. Please feel free to continue the convo, if needed.