BIP39 multilingual display wordlists, looking for review and native-speaker feed

[daniosem]

Hi everyone,

I wanted to share an open-source contribution for BIP39 recovery UX:

https://github.com/osem23/bip39-wordlists-tzur

This is not a new seed standard, not a wallet promotion, and not a replacement for the existing BIP39 wordlists.

The goal is to make BIP39 recovery more accessible to users who are not comfortable with English.

Many Bitcoin users around the world still have to write down and recover seed phrases in English, even when they do not understand English well.

For English speakers, seed words are familiar words.

For many non-English users, they can feel like random foreign symbols that must be copied perfectly.

This project provides native-language display and input wordlists for BIP39 recovery UX.

Important clarification:

The canonical BIP39 seed flow remains unchanged.

The English BIP39 mnemonic remains the source of truth.

PBKDF2 still runs on the canonical BIP39 form.

The native-language words are an optional display/input layer, not a new cryptographic scheme.

The repo includes wordlists and mappings for additional languages, with the goal of making recovery easier to understand for users who are not comfortable with English.

I understand that the original BIP39 wordlists were not simple direct translations. They were designed with important constraints such as avoiding confusing words, avoiding multiple spellings, avoiding similar-sounding words, and supporting short-prefix identification where possible.

Feedback is very welcome, especially around:

Are native-language display/input layers useful for wallet recovery UX?

What risks does this approach create?

Should something like this stay outside BIP39 as a wallet-specific UX layer?

Are there languages where this approach is especially risky?

How should native-speaker review be handled?

Are there better ways to help non-English users recover safely without changing BIP39?

I would especially appreciate review from wallet developers, BIP39 implementers, and native speakers of the included languages.

GitHub:
https://github.com/osem23/bip39-wordlists-tzur

Thank you.

[ABCbits]

Feedback is very welcome, especially around:

Some language such as Korean already exist on BIP 39 itself. When i compare the word list between actual BIP 39 and yours, it's different.

https://github.com/bitcoin/bips/blob/master/bip-0039/korean.txt
https://github.com/osem23/bip39-wordlists-tzur/blob/main/wordlists/tzur-original/korean.txt

Personally i would recommend to remove all language that already exist on BIP 39 itself.

What risks does this approach create?

People could make wrong assumption recovery words generated by your Tzur wallet can be used on other wallet.

[bitmover]

There are already other wordlists of different languages

Portuguese community of this forum even made the Portuguese bip39 words in 2020, which was merged into the bitcoin github

https://bitcointalk.org/index.php?topic=5273606.msg55130902#msg55130902

[nc50lc]

The English BIP39 mnemonic remains the source of truth.

Perhaps this is a mistranslation?
Because "source of truth" sounds nothing like a technical term.

Do you mean the "entropy"?
So, in other words, the mnemonic remains in English when used to derive the binary seed.
Your implementation just maps it to other unsupported languages for native language backup, but everything in the background follows BIP39 spec, correct?

Should something like this stay outside BIP39 as a wallet-specific UX layer?

The main problem that I'm seeing is if it's wallet-specific:
Non-tech savvy users might rely too much on the "translated mnemonic" as a backup and will come into issue when they try to restore it to others wallets that did not implement this.
Even though BIP39 is still used in the background, the translated mnemonic itself will cause incompatibilities if it's not implemented by the majority of the wallets.
So something like this should be an update to BIP39 standard rather than wallet-specific.

But I think updating the BIP39 word list to accommodate other languages should be enough if updating BIP39 is an option.
That way, it wont need any mapping and just derives that binary seed directly from the normalized local characters.