search

open-i18n / rust-unic

UNIC: Unicode and Internationalization Crates for Rust
https://crates.io/crates/unic
Other
234 stars 24 forks source link

Why fork unicode-bidi? #265

Closed SimonSapin closed 5 years ago

SimonSapin commented 5 years ago

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?

CAD97 commented 5 years ago

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.

SimonSapin commented 5 years ago

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.

CAD97 commented 5 years ago

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.

behnam commented 5 years ago

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. :)

windelbouwman commented 5 years ago

I understand the monorepo idea, it's easy to keep the different modules in sync.

Is this project still maintained, or is it abandoned?

behnam commented 5 years ago

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.