Re: [bitcoindev] [bitcoin-dev] Proposal discussion: BIP39 native-language display wordlists

[Daniel Osemberg <daniosemberg@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 3939 bytes --]

Hi,

I understand the point, but I think this misses the practical issue the
proposal is trying to address.

Yes, BIP39 is an application-layer specification, and yes, wallet
developers can theoretically offer locale options. But in practice, most
wallets do not provide full localization of the recovery experience, and
they do not provide a standardized way to map native-language input back to
the canonical English BIP39 flow.

That is the gap this proposal is addressing.

My own work started with BlockSight, a free Bitcoin block explorer
available in 31 languages. TZUR Wallet came later as a Bitcoin-only
self-custody wallet that integrates BlockSight natively inside the app. It
does not offer trading, conversion, buying, selling, custody, brokerage, or
any financial service. It only uses Bitcoin standards for wallet creation,
backup, receiving, and sending.

The reason this issue became obvious to me is that localization of Bitcoin
tools is still very incomplete. I am from Israel, and there are no
mainstream Bitcoin wallets with a fully Hebrew-native recovery experience,
and there is no Hebrew seed phrase experience that remains compatible with
the standard English BIP39 flow.

So while the responsibility is indeed on wallet developers to implement
good UX, there is currently no common convention for doing this safely and
interoperably across wallets.

The proposal is not saying that BIP39 itself is broken. It is saying that
the current ecosystem around BIP39 leaves many non-English users dependent
on English recovery words, and that creates a real UX and recovery-risk
problem.

This proposal tries to define a simple, optional, wallet-level convention:

English BIP39 remains canonical.

The localized words are fixed independent display/input lists.

The localized phrase maps deterministically by index back to the English
BIP39 wordlist.

The localized words are not passed directly into PBKDF2.

Wallets must always allow export of the canonical English BIP39 phrase.

In that sense, TZUR Wallet is simply one implementation of the proposal.
The broader contribution is the methodology and the prepared wordlists,
which are already available for review, testing, and potential adoption by
other wallet developers.

No one is asking for compensation for this work. The intent is to
contribute something useful back to the Bitcoin ecosystem, especially for
users who do not think, read, or back up critical financial information
naturally in English.

So I agree that wallet developers are responsible for implementation. But
that is exactly why a shared convention can be useful: it gives wallet
developers a common way to support native-language recovery UX while
preserving compatibility with English BIP39.

Best,
Daniel

On Wed, Jun 17, 2026 at 4:58 PM Randy McMillan <randy.lee.mcmillan@gmail.com>
wrote:

> “Many users around the world are asked to back up and restore Bitcoin
> wallets using English recovery words, even when English is not their native
> language. This creates UX risk, spelling mistakes, misunderstanding, and
> lower confidence during backup and recovery.”
>
> Note: Bip39 is categorized as an Applications layer specification - the
> concern in your motivation falls on the wallet developer and IMO isnt a
> short coming of the specification itself. Many applications give the user
> the ability to select locale - a wallet UI should offer wordlist options
> based on user locale preference.
>

-- 
You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/bitcoindev/CAFS8eiVN2WmJi0gpRFR%2Bab_C6VOFi6oPBx-g_EULwMDvaF%3DEtQ%40mail.gmail.com.

[-- Attachment #2: Type: text/html, Size: 5173 bytes --]