Skip to content

Conversation

@legounix
Copy link

@legounix legounix commented Nov 1, 2025

@legounix legounix force-pushed the feat_lang_german branch 4 times, most recently from 6273640 to 70a2832 Compare November 1, 2025 15:49
@tnull tnull self-requested a review November 3, 2025 10:21
Copy link
Collaborator

@tnull tnull left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for the contribution! I'm not sure we're ready to accept additional languages outside of the ones specified in BIP39 itself at this moment. Could you share a bit more about your use case/requirement? Do you already use rust-bip39 and have to support german?

Also note that CI doesn't pass with the current changeset.

(cc @elsirion Any thoughts here?)

@legounix
Copy link
Author

legounix commented Nov 6, 2025

Thank you for the contribution! I'm not sure we're ready to accept additional languages outside of the ones specified in BIP39 itself at this moment. Could you share a bit more about your use case/requirement? Do you already use rust-bip39 and have to support german?

Also note that CI doesn't pass with the current changeset.

(cc @elsirion Any thoughts here?)

Thanks for the project & quick review :)

We started using rust-bip39 and as our userbase is mainly german we simply added the german wordlist.
I believe the changes are not really intrusive and as each language is feature gated this crate can work
like defined in the standard and also modified to work with "non standard" languages.
But i think it's important to clarify further that german is not part of the BIP39 standard and that german wordlist
has overlaps with couple of other languages. Added this info to the Language::German docstring :)

@elsirion
Copy link
Collaborator

elsirion commented Nov 6, 2025

I'm with @tnull here, we have to draw a line somewhere for supporting languages and "it's in the BIP" is a pretty objective and good one. If there is sufficient demand I'd be open to thinking about ways to support arbitrary external word lists if we can keep API compatibility, i.e. it's a pure addition.

I could see a way by making Laguage a trait and the enum in the repo is just one implementer thereof. Would be tricky to get lifetimes right for it to work in a no-alloc environment.

If someone with sufficient rust skills can present a solution not breaking compatibility or no-std support I'd be open to reviewing, but I think both @tnull and I want to keep the effort low on our side since this is only a small part of our day to day focus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants